Klipper ohne Raspberry

[mhier]

So jetzt hört mal bitte auf, das hier zu zerreden. Es gab die Anfrage von mjh11, wie man Klipper oder Raspberry Pi nutzen kann. Das ist eine legitime Frage, die wurde mehr oder weniger in meinem Wiki-Eintrag beantwortet. Wenn es Frage dazu gibt, bitte hier rein. Auf diese Frage mit irgendwas zu antworten, in dem wieder ein Raspberry Pi vor kommt, ist doch unsinnig. Ja es geht einfacher mit dem Pi, das wurde oft genug gesagt, aber wer es dennoch anders will, kann das doch machen. Ich nutze übrigens auch keinen Pi für Klipper, weil ich ohnehin einen "Server"-PC permanent laufen habe (Fileserver).

[rf1k_mjh11]

Erste Erfahrungen mit Klipper:

Nachdem dennis02121978 so nett war, mir beim Einrichten zu helfen, konnte ich einige erste Erfahrungen sammeln. Ich hoffe, es werden keine umfangreichen Erfahrungen erwartet.

Das System läuft prinzipiell wie folgt:
Linux (Ubuntu) läuft in einer virtuellen Maschine auf dem Windows PC (in meinem Fall Windows 8.1). Über die Linux virtuelle Maschine wird die Firmware an den Drucker übertragen (muss nur ein Mal gemacht werden - damit ist der Drucker 'geflasht'). Das wurde eben auf diese Weise gemacht, da schon ein bereits kompiliertes Hex-File der Klipper Firmware auf der Linux Maschine bereitstand (Dank dem Image vom dennis02121978).

Danach wird MainSail gestartet. MainSail ist eine Web Applikation, die (bei mir zumindest) interessanterweise wieder auf der Windows Seite läuft. Damit das klappte, musste ich die richtige IP-Adresse angeben (die wird bei jedem User anders sein und hängt von der Anzahl der eingebundenen Geräte im jeweiligen Netzwerk ab. Bei mir war es die glückliche '13', genauer 192.168.1.13. Danach startet/öffnet sich das MainSail Fenster.

Wie man sieht, lag ich falsch in der Annahme, die bestehende Firmware des Druckers wird nicht angegriffen. Diese wird überschrieben. (Das war in meinem Fall kein Malheur, da ich sowieso kurz davor eine uralte Version aufspielte (siehe hier) und diese alte Version natürlich nicht behalten wollte.

Und dennis02121978 erklärte mir freundlicherweise die wichtigsten Teile der MainSail Oberfläche. Danach war ich auf mich alleine gestellt.

Das Homen der Achsen und das Hin- und Herfahren mit den virtuellen Tasten klappte erwartungsgemäß. Das Homen ging für mich ungewohnt langsam vor sich, besonders an der Z-Achse. Kein Problem, mir wurde gezeigt, wo man 'Änderungen an der Firmware' durchführt. Dort habe ich die max_z_velocity um 30% hinauf geschraubt. Neuerlich gehomed und wieder mittels virtueller Tasten ein wenig gefahren. Damit war ich irgendwo mitten über dem Bett, mit einen Düsenabstand von 50mm+ angekommen.
So weit zufrieden.
Nächster Schritt: HBS durchführen (HBS=Heat(ed) Bed Scan) damit die Firmware die Unebenheiten des Betts kennenlernt.
OK, in der 'Konsole M3010 eingetippt. Ergebnis: Unknown command:"M3010". Aha, nächste Erkenntnis: nicht alle GCode Befehle werden unterstützt (auch M105 X0 nicht). Na ja, dennis02121978 hat mir gezeigt, wo die 'Skripts' untergebracht sind. Da findet man ein eigens programmierter Skript für den HBS namens BED CALIBRATE.

Flugs auf den Skript-Knopf geklickt.

Das Bett rauschte in einem Wahnsinnstempo 2-3 cm nach oben und Klipper und der Drucker hängten sich auf (mit einer nichtssagenden Fehlermeldung). (Zum Glück blieb der Drucker stehen! Sonst hätte vielleicht das Hot End, die Düse, das Bett oder der Z-Endschalter Schaden genommen!)
Ein Versuch, Klipper neu zu starten, die Firmware neu zu starten, den Klipper Dienst neu zu starten sowie die Host-Steuerung neu zu starten schlugen alle fehl. Auch ein Aus- und Einschalten des Druckers, gefolgt von neuerlichen Versuchen, die diversen Systeme neu zu starten, brachte keinen Erfolg.
Ich musste die virtuelle Maschine runter fahren und neuerlich starten. Dabei gelang es mir nicht mehr, mit dem Drucker über USB zu kommunizieren und ich musste auch den PC neu starten.
Danach gelang ein neuerliches Verbinden mit dem Drucker.
Als erstes habe ich max_z_velocity auf nur mehr 10 (mm/s?) gestellt - man kann nie wissen!
Dann BED CALIBRATE ausgeführt.

Klipper_HBS.jpg

Das Ergebnis entspricht in etwa dem gewohnten Bild der HBS der Conrad oder Community Firmware.

So weit, so gut.

Um zu sehen, wie sich der Drucker im Betrieb verhält, wollte ich einfach eine (alte) GCode-Datei laden und OHNE Filament den Drucker den Extruder durch die Gegend fahren lassen. Damit sollte ich mir ein Bild der Geräuschkulisse machen können.
Ich lud eine GCode-Datei aus dem letzten Jahr hoch. Die Datei wurde damals mit Prusa Slicer erzeugt.
; generated by PrusaSlicer 2.2.0+win64 on 2020-10-04 at 14:32:23 UTC
Keine sonderlich große Datei, 600kB.
Damit sieht der Bildschirm dann so aus:

ScreenWithGCode.jpg

Einmal darauf geklickt kommt die Frage, ob man diese drucken möchte. Diese beantwortete ich mit 'JA'. Nur tut sich nichts. OK, machen wir es halt noch einmal: immer noch nichts. Kein Hinweis, keine Fehlermeldung, einfach weihnachtliche Stille, der Jahreszeit entsprechend.

Damit kommt die Zeit für die Ursachenfindung.
Nur ein Klick auf 'Dashboard' oder 'Konsole' bringen einen ein Stück weiter:
12:16:25 Malformed command 'SDCARD_PRINT_FILE FILENAME="Fan4Part(SideVersion)4V2_v1c_Funnel_Only_16;32.gcode"' Steht da in leuchtendem Rot.

Das ist schon sehr aufschlussreich. Ich weiß jetzt genau was zu tun ist! (Entschuldigt den Sarkasmus, bitte).

Noch ein Vorteil von Klipper, der schmeißt einem dann ne ordentliche Fehlermeldung um die Ohren *duck-und-weg*

Also, an der GCode-Datei liegt es nicht unbedingt, da ich das Teil vor 14 Monaten mit exakt dem GCode ausgedruckt habe.

Kann sein, dass Klipper einiges nicht am GCode mag. Zum einen ist es voll mit Kommentaren (Einstellung 'verbose Gcode'). Aber Kommentare sind ein zulässiges Mittel für GCodes und sollten korrekt behandelt werden.
Aufgefallen ist mir, dass der GCode keine "Linefeed" & "Carriage Return" Kombination aufweist, sondern nur "Linefeed". Aber das habe ich gleich gegengeprüft - daran liegt es auch nicht. Liegt der Fehler an den vielen, nicht unterstützten GCode-Befehlen? (Zum Beispiel M3000, M3001, M3070, usw.)
Liegt der Fehler nicht daran oder an den Kommentaren, würde ich nicht mehr wissen, wie ich den GCode zum drucken bringen könnte.

OK, eine andere Datei geladen. Diese stammt nicht von mir, sondern von einem User im Forum. Ich kann mich nicht mehr erinnern wer es war oder wieso ich die Datei noch habe. Es handelt sich um einen einfachen Zylinder, 200mm hoch. In Repetier-Host betrachtet, sieht man immer wieder skurrile 'Ausreisser' in X- und Y-Richtung. Sieht so aus:

ZylinderWithOddMoves.jpg

Diese Datei lässt sich drucken - bis zu einem gewissen Punkt, wo die (brauchbarere) Fehlermeldung kommt:
13:10:18 Unable to parse move 'G1 X117.348 Y'
Betrachtet man den GCode dort, findet man:
     G1 X117.348 Y
     115.679 E1.59996
Hier wurde offensichtlich eine Zeile durch einen Zeilenumbruch zerstört, wodurch ein ungültiger GCode-Befehl entstand. (Das könnte der Grund für die 'Ausreisser' sein.)

Da hat Klipper sauber reagiert.

So weit nicht sehr ermunternd, leider. Aber hoffentlich bekommen wir das hin. Ein paar Tage gebe ich es noch, dann wird die RF.01.47ag wieder aufgespielt.

Immunität über Alles! Nieder mit COVID-19!

mjh11

Für die, die das Problem untersuchen möchten, hänge ich die GCode-Datei an.

_Fan4Part(SideVersion)4V2_v1c_Funnel_Only_16;32.zip

EDIT: Habe die Falsche Datei erwischt - nun korrigiert.

[rf1k_mjh11]

OK die Ursachenforschung hat weiteres ergeben.

Scheinbar liegt es nicht unbedingt an den Befehlen in der Datei, eventuell an der Größe.

Ich habe die problematische Datei mehrfach gekappt. Die ersten 50 Zeilen gingen ohne Probleme. Zeilennummer 30 bis 12000 läuft gerade - auch scheinbar ohne Probleme.

mjh11

[af0815]

Hast du den Startcode und Endcode an Klipper angepasst ? Und die nicht passenden Codes rausgeworfen, ich glaube nicht.
Startcode

Code: Alles auswählen

;--------------------------------------
; RF1000
;--------------------------------------
G28 ; home all axes
; Acceleration up to...
; Acc printing
M201 X6000 Y6000 Z900  ; accel values when printing
M202 X6000 Y6000 Z900  ; accel values when moving (travel)
M400  ; wait for all moves to finish
G92 Z0 ; zero out Z, to be safe
; next line will move Z-axis n-(mue-meter) up (see manual)
M3001  ; enable Z-Compensation
M3006 S-14 ; + n moves bed down by X-(mue-meter) // - n moves bed up! ("S90" = lowers bed -0.09mm)
G1 Z0.45 F5000 ; lift nozzle
M109 S240 ; wait for extruder temp to be reached
G90 ; use absolute coordinates
M82 ; use absolute distances for extrusion
G92 E0 ; 
G1 F300 E-0.5
G1 X140 Y18 Z0.35 F5000  ; go to start of priming drawing line
G1 F800 E11.5
G1 X25 E29 F1000  ; do priming line
G1 X16 F400
G1 X14 F200
;Put printing message on LCD screen
M117 Printing...
;--------------------------------------

Endcode

Code: Alles auswählen

; Filament-specific end gcode 
;END gcode for filament
M104 S0
M140 S0
; G91
G92 Z0 E0  ; zero out Z and Extruder
G1 E-0.5 F300
;move Z up a bit and retract filament even more
G1 Z+0.5 E-0.5 X0 Y210 F4500 ;  move extruder & part to unload position
; Steppers off
M84                                            
;Acceleration to default...
;Acc printing
M201 X1000 Y1000 Z1000
;Acc travel
M202 X1000 Y1000 Z1000
;
M300 S1800 P333	; beep
G4 P333		; pause one-third second
M300 S2400 P333	; beep
G4 P165		; pause
M300 S2660 P333
G4 P80
M300 S1800 P666	; beep
G4 P1		; pause, End of custom "end.gcode" for RF1k
M104 S105            ; set temp to 105 deg.
M106 S255        ; keep fan on

Es ist so, das mit Klipper der RFx000 ein neuer Drucker geworden ist, die alten Files gehören wie für einen neuen Drucker nochmals überarbeitet (Gesliced)
Ich habe eine eigene Prusa Konfiguration speziell für Klipper und auch eine für die Communityversion

Nur so als Beispiel, so sieht bei mir der Startcode aus

Code: Alles auswählen

START_PRINT EXTRUDER_TEMP=[extruder0_temperature] BED_TEMP=[bed2_temperature]
PRINT_STARTLINE
SET_GCODE_OFFSET Z=0.0
;@make_snapshot

und

Code: Alles auswählen

G1 F600 E-1.5
END_PRINT 

in Klipper habe ich alles hinter Macros gebracht, damit ich vom Slicer unabhängig bin

[af0815]

Hier noch meine Macros für den RF2000V2

Code: Alles auswählen

######################################################################
# Start Print and End Print
######################################################################

# Replace the slicer's custom start and end g-code scripts with
# START_PRINT and END_PRINT.

[gcode_macro OUTPUT_OBJECT]
gcode:
	G90
	G1 Z175	F540
	G1 Y230 F4800
    # Disable steppers
    M84
	M18

[gcode_macro START_PRINT]
default_parameter_EXTRUDER_TEMP: 190
default_parameter_BED_TEMP: 60
gcode:
    # Start bed and hotend heating
    M140 S{BED_TEMP}
    M104 S{EXTRUDER_TEMP}
    # Home the printer
    G28
    # Use absolute coordinates
    G90
    # Reset the G-Code Z offset (adjust Z offset if needed)
    SET_GCODE_OFFSET Z=0.0
    # Move the nozzle near the bed
    G1 Z5 F3000
    # Move the nozzle very close to the bed
    G1 Z0.15 F300
    # Wait for bed to reach temperature
    M190 S{BED_TEMP}
    # Set and wait for nozzle to reach temperature
    M109 S{EXTRUDER_TEMP}

[gcode_macro PRINT_STARTLINE]
gcode:
	# start line
	G1 Z5
	G1 X0 Y0 F5000
	G1 Z0.5
	G92 E0 
	G1 E-0.5 F300 
	G1 E20 F800 
	G1 X0 Y5
	# Preperation for Z_Sense_offset
	#G1 Z5
	#G1 X0 Y60
	#G1 X50 Y60 Z0.3 F5000
	#;Z_SENSE_OFFSET
	SET_GCODE_OFFSET Z=0.0
	G1 Z5
	# Startmade
	G1 X0 Y30 Z0.3 F5000
	G1 X170 Y25 E30 F1000
	# Fertig

[gcode_macro END_PRINT]
default_parameter_RETRACT_MM: 2
gcode:
	G21
	G92 E0
	G1 E-{RETRACT_MM}
	G4 P100
	G92 E0
    # Turn off bed, extruder, and fan
    M140 S0
    M104 S0
    M106 S0
	OUTPUT_OBJECT

[rf1k_mjh11]

Weiterer Druckversuch.

Die problematische Datei hat 24300+ Zeilen.
Ich habe ca. 6000 aus der Mitte entfernt. Jetzt ist die 'neue Datei' 18300+ Zeilen Lang. Der Drucker begann anstandslos zu drucken und hat jetzt

mjh11

[rf1k_mjh11]

Nachdem ich jetzt tatsächlich einige Druckversuche durchführen kann, hier meine ersten Eindrücke:

Der Drucker scheint tatsächlich etwas leiser zu sein. Ich führe das auf:

• Dem Ignorieren des M300 Befehls, mit dem ich den Drucker bei jedem Layerwechsel piepen lasse.
• Einer deutlich reduzierten Geschwindigkeit. Laut GCode sollten beim Infill und beim Perimeter 55mm/s, solid_infill_speed = 52mm/s vorkommen, Mainsail zeigt aber Geschwindigkeiten um die 20mm/s an:
  KlipperPrintSpeed.jpg
  . Vielleicht ist was in der printer.cfg daneben (dort steht unter max_velocity 200).

Hast du den Startcode und Endcode an Klipper angepasst ? Und die nicht passenden Codes rausgeworfen, ich glaube nicht.

Klipper ignoriert problemlos Befehle, die er nicht kennt, z.B. die M300 Befehle. Daher ist es scheinbar nicht unbedingt nötig, GCode Dateien extra aufzubereiten. Andererseits bringen die zusätzlichen Makros sicherlich einiges.

Gesundheit!

mjh11

[mhier]

Einmal darauf geklickt kommt die Frage, ob man diese drucken möchte. Diese beantwortete ich mit 'JA'. Nur tut sich nichts. OK, machen wir es halt noch einmal: immer noch nichts. Kein Hinweis, keine Fehlermeldung, einfach weihnachtliche Stille, der Jahreszeit entsprechend.

Das klingt nach einem Mainsail Problem. Bei OctoPrint bekomme ich als Rückmeldung im Fehlerfall ein rotes Fenster in der rechten oberen Ecke, wo schon mal eine gewisse Information drin steht. Evtl. muss man dann noch auf die Konsole wechseln um die echte Fehlermeldung zu sehen, aber man weiß immerhin, das etwas schiefgelaufen ist.

Nur ein Klick auf 'Dashboard' oder 'Konsole' bringen einen ein Stück weiter:
12:16:25 Malformed command 'SDCARD_PRINT_FILE FILENAME="Fan4Part(SideVersion)4V2_v1c_Funnel_Only_16;32.gcode"'

Entweder ist das der Inhalt deiner G-Code-Datei (dann ist sie kaputt), oder Mainsail schickt aus irgendwelchen Gründen diesen Befehl an Klipper (dann ist Mainsail kaputt oder falsch konfiguriert). Setzt Mainsail ein konfiguriertes virtual_sdcard Modul voraus?

Das ist schon sehr aufschlussreich. Ich weiß jetzt genau was zu tun ist! (Entschuldigt den Sarkasmus, bitte).

Noch ein Vorteil von Klipper, der schmeißt einem dann ne ordentliche Fehlermeldung um die Ohren *duck-und-weg*

Ja bekommt man auch. Die Fehlermeldung sagt dir, dass Klipper mit dem Befehl "SDCARD_PRINT_FILE" nichts anfangen kann. Was genau erwartest du denn mehr, wenn Klipper einen Befehl bekommt, den es nicht kennt? Wenn man nach "Klipper SDCARD_PRINT_FILE" googlet, findet man sofort, dass das zwar ein gültiger Klipper-Befehl ist, aber nur, wenn eben das "virtual_sdcard" Modul aktiviert ist. Das ist bei der von mir erstellten printer-rf1000.cfg nicht der Fall, weil ich keinen Sinn in diesem Modul sehe (es gibt sehr spezifische Anwendungsfälle).

Kann sein, dass Klipper einiges nicht am GCode mag.

Ja, Klipper mäkelt G-Code an, den er nicht kennt. Ich finde es ziemlich dämlich, wenn Firmware einfach stillschweigend unbekannte Befehle ignoriert. Solange Mainsail auf die Fehlermeldung von Klipper aber nicht mit einem Emergency Stop reagiert, wird der Druck trotzdem fortgesetzt werden.

So weit nicht sehr ermunternd, leider.

Das scheinen mir aber alles Mainsail-Probleme zu sein, die kannst du Klipper nicht wirklich anlasten. Vielleich ist der Tipp, Mainsail zu benutzen, doch nicht so super. Wie gesagt ist OctoPrint bei Klipper standard. Da könnte ich dir auch weiterhelfen. Das generelle Setup bliebe übrigens ähnlich, auch OctoPrint würdest du über den Browser von Windows aus steuern können.

[rf1k_mjh11]

Hallo mhier,

Das klingt nach einem Mainsail Problem.

Das kann gut sein. Wie geschrieben, die weiteren Erkenntnisse zeigten, dass es nicht an der Datei an sich lag. Der Anfang der Datei ließ sich drucken, beim Ende der Datei gab es auch kein meckern (als ich 6000 Zeilen aus der Mitte der Datei löschte).

Geräuschverhalten:
Als ein weiterer Grund, wieso sich der Drucker etwas leiser anhört, stellte sich heraus, dass die Schrittmotoren geringere Ströme eingestellt haben.
X, Y und Z haben 1.8A eingestellt (mit der Conrad FW sind es hier 2.38A, 2.38A und 2.0A, respektive). Der Extruder ist auf 1A beschränkt, wo Conrad 2.0A vorsah.

Interessanterweise sind die Geschwindigkeiten (und das Geräuschverhalten) ziemlich genau dort, wo sie mit der Conrad-FW waren, jetzt, da ich die Ampere-Werte auf jene der Conrad-FW gestellt habe (mittels leicht editierbarer 'printer.cfg Datei ). Die schnellsten Segmente druckt er jetzt mit 52mm/s.
Damit stellt sich die Ampere Zahl als eine der Hauptursachen der Geräuschentwicklung. Falls man mit weniger Ampere keine Probleme hat (=Schrittverluste), sollte man die Herabsetzung als erstes ins Auge fassen (vorausgesetzt, die liebliche Musik des arbeitenden Druckers stört einen ).

Hoch die Maske! Es lebe die Immunität!

mjh11

[rf1k_mjh11]

Hallo Dennis,

Die Problematische Datei hat massenhaft Strichpunkte. Jeder Kommentar beginnt damit. Das scheint aber nicht das Problem zu sein.
Aber der Dateiname hat ein Strichpunkt (anstelle eines verbotenen Doppelpunkts als Teil einer Zeitangabe):

_minus6000Lines_Fan4Part(SideVersion)4V2_v1c_Funnel_Only_16;32.gcode

Und Du hast Recht! Der Strichpunkt im Dateinamen mag MainSail (oder Octoprint?, oder Klipper?) NICHT!
Ich hatte den Strichpunkt durch eine Raute '#' ersetzt und auch dieses führte zu einer Fehlermeldung.
Durch einen Unterstrich '_' klappte es.

_minus6000Lines_Fan4Part(SideVersion)4V2_v1c_Funnel_Only_16_32.gcode klappt!

Fazit: Es sind keine Strichpunkte und keine Rauten im Dateinamen erlaubt! Der Fehler lag nicht an der Dateigröße.

Möge COVID-19 uns alle verschonen!

mjh11