Neue Development Firmware (RF.01.33)

[xmachina]

Habe die 1.33 erneut geflasht und danach den Drucker "echt" an- und aus geschaltet.
Nun läuft der HBS problemlos durch:

11:08:00.393 : Printer reset detected - initalizing
11:08:00.393 : start
11:08:00.409 : start Watchdog
11:08:01.987 : Free RAM:1945
11:08:02.174 : FIRMWARE_NAME:Repetier_RF.01.33 FIRMWARE_URL:https://github.com/RF1000/Repetier-Firmware/ PROTOCOL_VERSION:1.0 MACHINE_TYPE:Mendel EXTRUDER_COUNT:2 REPETIER_PROTOCOL:2
11:08:02.206 : Printed filament:0.00m Printing time:0 days 0 hours 0 min
11:08:02.237 : X:0.00 Y:0.00 Z:0.00 E:0.00
11:08:02.237 : Begin file list
11:08:02.237 : End file list
11:11:09.583 : scanHeatBed(): the scan has been started
11:11:09.615 : outputScanParameters(): current scan parameters:
11:11:09.615 : 152.38;[steps];axisStepsPerMM[X_AXIS]
11:11:09.615 : 152.38;[steps];axisStepsPerMM[Y_AXIS]
11:11:09.646 : 2560.00;[steps];axisStepsPerMM[Z_AXIS]
11:11:09.646 : 0;[steps];g_nScanXStartSteps
11:11:09.646 : 3047;[steps];g_nScanXStepSizeSteps
11:11:09.646 : 0;[steps];g_nScanXEndSteps
11:11:09.677 : 27428;[steps];g_nScanXMaxPositionSteps
11:11:09.677 : 4571;[steps];g_nScanYStartSteps
11:11:09.677 : 3047;[steps];g_nScanYStepSizeSteps
11:11:09.708 : 761;[steps];g_nScanYEndSteps
11:11:09.708 : 36572;[steps];g_nScanYMaxPositionSteps
11:11:09.708 : -64;[steps];g_nScanHeatBedUpFastSteps
11:11:09.740 : -12;[steps];g_nScanHeatBedUpSlowSteps
11:11:09.740 : 640;[steps];g_nScanHeatBedDownFastSteps
11:11:09.740 : 32;[steps];g_nScanHeatBedDownSlowSteps
11:11:09.771 : 5;[ms];g_nScanFastStepDelay
11:11:09.771 : 100;[ms];g_nScanSlowStepDelay
11:11:09.771 : 250;[ms];g_nScanIdleDelay
11:11:09.771 : 10;[digits];g_nScanContactPressureDelta
11:11:09.802 : 5;[digits];g_nScanRetryPressureDelta
11:11:09.802 : 0;[digits];g_nScanIdlePressureDelta
11:11:09.802 : 15;[-];g_nScanPressureReads
11:11:09.818 : 15;[digits];g_nScanPressureTolerance
11:11:09.818 : 15;[ms];g_nScanPressureReadDelay
11:11:14.052 : busy: processing
11:11:17.099 : busy: processing
11:11:17.490 : X:0.00 Y:0.00 Z:0.00 E:0.00
11:11:17.490 : scanHeatBed(): move = 1280
11:11:20.396 : readIdlePressure(): pressure calibration: 0 / 639
11:11:21.177 : readIdlePressure(): idle pressure: 640
11:11:42.552 : busy: processing
11:12:24.865 : busy: processing
,,,
,,,
11:27:02.080 : busy: processing
11:27:03.315 : X:0.00 Y:0.00 Z:0.00 E:0.00
11:27:03.377 : scanHeatBed(): raw heat bed compensation matrix:
11:27:03.393 : front left ... front right
11:27:03.393 : ... ... ...
11:27:03.393 : back left ... back right
11:27:03.393 : ;7;0;0;20;40;60;80;100;120;140;160;180
11:27:03.424 : ;0;0;0;0;0;0;0;0;0;0;0;0
11:27:03.424 : ;30;0;-312;-328;-352;-192;-248;-132;-64;-52;-12;12
11:27:03.424 : ;50;0;-348;-208;-280;-220;-176;-160;-68;8;-100;48
11:27:03.455 : ;70;0;-428;-280;-284;-312;-168;-188;-212;-64;36;52
11:27:03.455 : ;90;0;-344;-436;-308;-276;-224;-164;-184;-92;52;-128
11:27:03.487 : ;110;0;-432;-464;-376;-292;-388;-184;-112;-228;-100;44
11:27:03.487 : ;130;0;-468;-376;-500;-364;-200;-288;-180;-184;-144;-16
11:27:03.518 : ;150;0;-576;-512;-388;-468;-308;-252;-216;-108;-40;-96
11:27:03.518 : ;170;0;-548;-572;-444;-420;-460;-280;-252;-264;-96;-28
11:27:03.549 : ;190;0;-572;-516;-500;-392;-280;-416;-224;-228;-196;-120
11:27:03.549 : ;210;0;-660;-544;-408;-548;-424;-264;-260;-184;-188;-148
11:27:03.565 : ;230;0;-556;-604;-520;-396;-416;-356;-296;-224;-140;-112
11:27:03.596 : offset = 52 [steps] (= 0.02 [mm])
11:27:03.596 : g_uZMatrixMax[X_AXIS] = 11
11:27:03.596 : g_uZMatrixMax[Y_AXIS] = 12
11:27:03.596 : g_nActiveHeatBed = 1
11:27:03.659 : scanHeatBed(): total scan time: 954
11:27:03.690 : scanHeatBed(): g_uZMatrixMax[Y_AXIS].1 = 12
11:27:03.690 : scanHeatBed(): g_uZMatrixMax[Y_AXIS].2 = 13
11:27:03.705 : scanHeatBed(): converted heat bed compensation matrix:
11:27:03.705 : front left ... front right
11:27:03.721 : ... ... ...
11:27:03.721 : back left ... back right
11:27:03.752 : ;7;0;20;40;60;80;100;120;140;160;180
11:27:03.752 : ;0;-312;-328;-352;-192;-248;-132;-64;-52;-12;12
11:27:03.752 : ;30;-312;-328;-352;-192;-248;-132;-64;-52;-12;12
11:27:03.784 : ;50;-348;-208;-280;-220;-176;-160;-68;8;-100;48
11:27:03.784 : ;70;-428;-280;-284;-312;-168;-188;-212;-64;36;52
11:27:03.815 : ;90;-344;-436;-308;-276;-224;-164;-184;-92;52;-128
11:27:03.815 : ;110;-432;-464;-376;-292;-388;-184;-112;-228;-100;44
11:27:03.846 : ;130;-468;-376;-500;-364;-200;-288;-180;-184;-144;-16
11:27:03.846 : ;150;-576;-512;-388;-468;-308;-252;-216;-108;-40;-96
11:27:03.877 : ;170;-548;-572;-444;-420;-460;-280;-252;-264;-96;-28
11:27:03.877 : ;190;-572;-516;-500;-392;-280;-416;-224;-228;-196;-120
11:27:03.909 : ;210;-660;-544;-408;-548;-424;-264;-260;-184;-188;-148
11:27:03.909 : ;230;-556;-604;-520;-396;-416;-356;-296;-224;-140;-112
11:27:03.924 : ;245;-556;-604;-520;-396;-416;-356;-296;-224;-140;-112
11:27:03.924 : offset = 52 [steps] (= 0.02 [mm])
11:27:03.940 : g_uZMatrixMax[X_AXIS] = 10
11:27:03.940 : g_uZMatrixMax[Y_AXIS] = 13
11:27:03.940 : g_nActiveHeatBed = 1
11:27:05.268 : scanHeatBed(): idle pressure at start: 640
11:27:05.284 : scanHeatBed(): idle pressure at stop: 628
11:27:17.721 : continuePrint(): continue is not available at the moment
11:27:32.081 : busy: processing
11:27:34.112 : busy: processing
11:27:36.127 : busy: processing
11:27:37.221 : X:0.00 Y:0.00 Z:0.00 E:0.00
11:27:37.409 : saveCompensationMatrix(): valid data detected
11:27:39.377 : busy: processing
11:27:40.862 : scanHeatBed(): the heat bed compensation matrix has been saved
11:27:40.862 : scanHeatBed(): the scan has been completed


So weit, so gut...
Wofür sind "Scan ABS" und "Scan PLA"?

Mark

[rf1k_mjh11]

Mark/xmachina,

Wofür sind "Scan ABS" und "Scan PLA"?

Da wird zusätzlich die Extruderlängung, bei einer ABS- bzw. PLA-typischen Temperatur, mit berücksichtigt. Nach dem HBS wird der Extruder eine Zeitlang auf die entsprechende Temperatur aufgeheizt, ein letztes Mal an einer bekannten Stelle das Bett abgetastet, und der erhaltene Differenzwert auf die gesamte Matrix umgelegt (glaube ich).

mjh11

[Zaldo]

Ich glaube Du glaubst richtig

[Darrol]

Hallo,

ich bin vorgestern von RF.01.10 auf 01.33 gegangen und habe gestern auch sehr erfolgreich ein paar Kleinigkeiten gedruckt.
Heute habe ich einen Materialwechsel gemacht zur Optimierung einmal den CalCube(Slicer: Cura) gedruckt, was soweit prima geklappt hat.
Allerdings hat nach dem Druck die Y-Achse beim Objekt-Output keine Anstallten gemacht anzuhalten.
Ich habe den Krach dann mal mit dem Not-Aus beendet.
Ich kann soweit keine Schäden erkennen und der Y-Motor bleibt auch ganz ordentlich stehen wenn ich die Druckplatte(nach Homing) nach vorne fahre.

Hat jemand schon was ähnliches gehabt? Den G-Code habe ich leider nicht mehr, weil ich während dem Druck schon den nächsten Lauf vorbereitet habe.

Der End-G-Code ist bei all meinen Templates aber eigentlich identisch:

Code: Alles auswählen

;--------------------------------------
; RF1000 end code
;--------------------------------------
G92 E0
M107
M104 S0
M140 S0
G91
; retract filament
G1 E-5 F300
; Output Object
M400
M3079
M400
;Steppers off
M84                                         
;Acceleration to default...
;Acc printing
M201 X1000 Y1000 Z1000
;Acc travel
M202 X1000 Y1000 Z1000
;--------------------------------------

Ich werde mal sehen ob ich das Phänomen, sofern nicht schon bekannt, reproduzieren kann.

[rf1k_mjh11]

Darrol,

Vermutlich stimmt der Y-Endanschlag nicht ganz.

Die Firmware weiß wie groß das Druckbett ist und begrenzt den Verfahrweg auf den theoretisch maximalen Weg (mit 1-3mm Sicherheitsabstand). Ist der Y-Anschlag um mehr als dieser Sicherheitsabstand daneben, fahrt der Tisch mechanisch gegen irgend einen Anschlag da die Firmware fälschlicherweise glaubt, es ginge noch - das macht einen schrecklichen Lärm, ist aber nicht lebensbedrohend. Meist verliert der Schrittmotor dabei einfach einige Schritte oder der Zahnriemen springt über (falls er nicht genug gespannt ist).

In deinem Fall kommt der "Output-Object-Script" ins Spiel. Hier wird das Druckobjekt/der Tisch am Ende des Druckauftrags zwecks der Zugänglichkeit ganz nach Vorne gebracht (also der 'volle' Verfahrweg ausgenutzt).

Prüfe den Endanschlag für die Y-Achse. Falls alles deiner Meinung nach OK ist, und das Problem weiterhin besteht, müssten wir User RF1000 bemühen.
Falls dein Anschlag nicht laut Anleitung, aber so wie du es haben willst, müsstest du den Output-Object-Script in der Firmware anpassen um den Verfahrweg in Y zu reduzieren.

mjh11

[roiber]

Hallo,

...
Allerdings hat nach dem Druck die Y-Achse beim Objekt-Output keine Anstallten gemacht anzuhalten.
Ich habe den Krach dann mal mit dem Not-Aus beendet.
...
Hat jemand schon was ähnliches gehabt?
...

Ja, habe ich. Mehrfach.
Ich glaube, das hängt mit einer Art "doppelten Auswerfen" zusammen: Der RepetierHost fügt optional einen End-GCode hinzu. Zusammen mit dem Auswurf-Code vom Slicer habe ich genau das Problem. Ich schätze, dass da nach dem ersten Auswerfen die Motoren ausgeschaltet werden (M84) und damit die Referenz verlieren. Der Nachfolgende Auswurf-Befehl vom RepetierHost wird dann anscheinend trotzdem nochmal gemacht, und da die Motoren beim Einschalten in der Auswurf-Position stehen (und das vermutlich nach dem Einschalten als 0-Position verwendet wird) fahren sie ins Nirvana.
Ich habe jetzt beim Slicer im End-Code M84 deaktiviert und im RepetierHost bei den Druckereinstellungen angegeben, dass er nach dem Job Beenden nicht in die Parkposition fahren soll. Beim Speichern für SD-Druck die Job beendet Befehle nicht hinzufügen.
Seither habe ich kein Problem mehr.

Ich denke, dass es ein Bug in der Firmware ist: Diese darf ein Fahren im nicht referenzierten Zustand eigentlich nicht erlauben.

roiber

[Sven]

Ich habe ein Problem mit dem Auswurf bei der Z-Achse.
Nach dem Update von Version 0.96 auf 1.33 Druckt alle Prima, auch der Scan hat funktioniert. Aber der Auswurfbefehl (der Interne, direkt vom Panel aus) fährt zu weit runter, so das mein unterer Z-Endschalter (fürs Fräsen) auf dem Boden aufsetzt. Das gab es bei der alten Version auch schon mal, da hab ich es manuell gefixt, in dem ich den Z_MAX_LENGTH verkleinert habe (wurde hier auch schon mal drüber geschrieben http://www.rf1000.de/viewtopic.php?f=67 ... abe#p14949 ), aber anscheinend hat das bis jetzt niemand in die Standardkonfiguration der Software übernommen!

Wär es nicht mal ein feiner Zug die Firmware gleich so anzupassen, das da nicht immer was knirscht, wenn man den Fräsumbau gemacht hat ? Für alle die die letzten Millimeter ihres Z-Druckbereiches nutzen wollen, könnte man es ja von der Aktivierung der Fräsoption in der Software abhängig machen!

Sven

[rf1k_mjh11]

Sven,

Wär es nicht mal ein feiner Zug die Firmware gleich so anzupassen, das da nicht immer was knirscht, wenn man den Fräsumbau gemacht hat ? Für alle die die letzten Millimeter ihres Z-Druckbereiches nutzen wollen, könnte man es ja von der Aktivierung der Fräsoption in der Software abhängig machen!

Guter Punkt. Für die Programmierer müsste das ein Klacks sein.

Sonst kann man es auch mit einem einmaligen Schreiben ins EEPROM erreichen.

M206 T3 P153 Xnnn.nn

Wobei "nnn.nnn" der gewünschte, angepasste Längenwert darstellt.
Hinweis: es gab hier schon mindestens einmal einen Interpretationsfehler - das X ist schon richtig, es hat nichts mit der X-Achse zu tun.
Für spätere Firmwareversionen sollte man diese Angaben nochmals prüfen, da sich die EEPROM Adresse geändert haben könnte (also später als RF.01.33).

Beim nochmaligen Nachdenken muss ich mich/dich fragen, wieso wirkt der Endschalter nicht?
Eigentlich müsste der Drucker das Abwärtsfahren des Betts beim Erreichen des Endschalters sofort stoppen, oder?

mjh11

[Sven]

rf1k_mjh11 schrieb:
Beim nochmaligen Nachdenken muss ich mich/dich fragen, wieso wirkt der Endschalter nicht?
Eigentlich müsste der Drucker das Abwärtsfahren des Betts beim Erreichen des Endschalters sofort stoppen, oder?

Gute Frage! Das liegt wohl daran, das trotz dem die "FEATURE_CONFIGURABLE_MILLER_TYPE" Option beim RF1000 gesetzt ist, der ENDSTOP_TYPE auf SINGLE voreingestellt ist, den gab es bei meiner alten Firmware nicht als Konfigurationseinstellung, und deshalb hat er nicht angehalten.Hab ich jetzt umgestellt.

Und schräg ist auch das Verhalten nachdem ich ihn eingeschaltet habe! Wenn man jetzt nach ordentlichem Homing im Printer-Mode mit der Abwärts-Taste den Tisch gegen den unteren Endschalter fährt (weil er noch ein zu großes Z_MAX_LENGTH hat geht das ja, fährt er automatisch wieder ein Stück hoch (Meldung "Z FREE", also hat die Firmware die Richtung erkannt, und richtig geschlossen, das es sich um den unteren Schalter handeln muss), und meldet danach z=0.82! Was soll das jetzt ? Wenn man jetzt gegen den oberen Schalter fährt, gibt's eine "Z MIN REACHED" Fehlermeldung, aber Z wird nicht genullt, obwohl es hier durchaus richtig wäre.

Jedenfalls komm ich da, wenn ich den Wert nicht nur in der Software, sondern auch im EEPROM auf 190mm Stelle, nicht mehr hin, und alles ist paletti. Aber irgendwie hab ich den Eindruck, so richtig ausgegoren ist das mit den Voreinstellungen noch nicht!


Sven

[Nibbels]

Guten Morgen,

ich habe mir http://www.rf1000.de/viewtopic.php?f=7&t=1380 und http://www.rf1000.de/viewtopic.php?f=7&t=1242&p=13439, sowie die Kommentare hier durchgelesen.
Wie die Kompensation funktionieren soll, (g_minCompensation und g_maxCompensation als Verhaltensgrenzen) habe ich soweit ich weiß verstanden.

Für mich als Nutzer macht es überhaupt keinen Sinn, eine funktionierende Z-Kompensation irgendwann deaktiviert haben zu wollen.
Die erste Lage sollte grundsätzlich immer passen.
[Ein einlagiger Druck wäre dann idealisiert so wellig wie das Bett - überall gleich dick.
Ein mehrlagiger Druck wäre unten wellig und je nach g_minCompensation / g_maxCompensation -Grenzen oben auch noch wellig oder eben plan.]

Ich kalibriere den RF2000 nicht über diese Z-Schalter-Schraube, sondern über Homing und das herunterlassen der Hotends. Das ist wohl anders als beim RF1000, denn dort wird glaube ich noch alles über diese "blöde fummelige" Schraube genau eingestellt (?).
Der Drucker fährt auf "Z-Origin", wenn die Lichtschranke schaltet. Dann lasse ich die Düse auf quasi -0,3 {+-2mm} herunter und stelle es fest.
G-Code Z=0 wäre also z.B. bei -0,3mm (Etwas höher gefahren als Schalterkontakt). Soweit ich verstanden habe, macht die Z-Compensation und das Z-Offset die Übersetzung von Z-Origin=0 auf Z_real = -0.3 in jedem angefahrenen Punkt.

Warum gibt es die Möglichkeit, die Z-Kompensation an und auszuschalten?

Ich würde nun annehmen, dass wenn in meiner Z-Matrix nur 0 stehen würde und das Offset nur 0 beinhalten würde, wäre meine Düse immer mindestens 0,3mm vom Bett weg.
Die Verfahrwege würden immer ohne Veränderung von Z stattfinden.
Ich würde also ohne Korrektur meines Materialflusses quer über Berge und Täler drucken, wenn die Z-Kompensation aus ist.
Ich würde also nur mit dem Z-Offset oder "Z-hoch"/"Z-runter"-Tasten die wahre Höhe meines ersten Layers einstellen. (Z.B. Z_real = -0,3 mit Gcode Z=0 zusammenführen wollen - wenn mir die Unebenheit des Bettes egal ist.)

Darum sehe ich überhaupt keinen Sinn, warum hier darüber diskutiert wird, wieso man die Z-Kompensation an und ausschalten sollte??
Ergo habe ich offensichtlich ein Detail nicht verstanden - oder noch nirgends gefunden

LG