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).

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.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: 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).

mhier hat geschrieben: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: 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.EDIT: Habe die Falsche Datei erwischt - nun korrigiert.

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

Hast du den Startcode und Endcode an Klipper angepasst ? Und die nicht passenden Codes rausgeworfen, ich glaube nicht.
Startcode Endcode 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 und in Klipper habe ich alles hinter Macros gebracht, damit ich vom Slicer unabhängig bin

Hier noch meine Macros für den RF2000V2

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

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).

afo815 hat geschrieben: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

rf1k_mjh11 hat geschrieben: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.

rf1k_mjh11 hat geschrieben: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?

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

mhier hat geschrieben: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.

Hallo mhier,

mhier hat geschrieben: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

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