Klipper auf dem RF2000V2

[zero K]

Guten Morgen Andreas

Danke für die ausführliche Antwort

Zuhause gibt es es Linux in der Version openSuse Tumbleweed für alles was einen PC braucht.
Einen Pi über die Konsole einzurichten ist auch nicht das größte Problem.
Auch die funktionale Trennung von Firmware und Server ist mir eigentlich geläufig.

Mangels Fehlermeldungen bei Installation und Einrichtung war ich natürlich der Meinung alles richtig gemacht zu haben aber auch hier steckt der Teufel im Detail.
Heute Abend erzeuge ich mit Deiner .cfg frische Klippylogs.

Doch jetzt sagt mir ein Video-Pi dass eine meiner Prüfmaschinen eine Probe zertrümmert hat - die sollte eigentlich überleben.

Bis später, zero K

[mhier]

Octoprint und der geflashte Drucker ließen sich verbinden und der Drucker genau einmal homen, aber das war es dann auch "internal Error on command G1" Auf der Homepage Octopi fand ich nix dazu.

Das klingt wie der hier bereits berichtete aber noch immer nicht gefixte Bug in unserem Z-Offset-Scan-Modul. Das erwartet ein gültigies Bed Mesh (das was früher die Heat Bed Matrix war). Deaktiviere einfach das Z-Offset-Scan-Module (einfach die entsprechenden Zeilen in der cfg auskommentieren), bis du einen Mesh Scan durchgeführt und abgespeichert hast.

[zero K]

Guten Abend Martin

Gut, werde ich nach dem Abendbrot testen und mich wieder melden.

Gruß zero K

[FB]

Hat von euch auch jemand ein V2 dual?

[af0815]

jein. Dual ja, aber nur ein Hotend in Betrieb. Und der ist ein E3D, abgesehen von einem anderen Fühler ist das gleich.

[FB]

Hat von euch schon mal jemand ein "Kilpper state: Shutdown Recv: !! Internal error on command:"G1"" gehabt?
Bin grad am Einrichten meines neuen Klipper RF2000v2, Grundfunktionen wie homen, heizen, Endstops funktionieren, und jetzt kommt der Extruder dran: hab also noch nie gedruckt und der Extruder ging mit Klipper noch nie, mit der Conradversion davor schon. Hardware-Fehler sind also auszuschliessen. Auch geht der STEPPER_BUZZ auf X,Y,Z und extruder einwandfrei, ein 2. Extruder wäre verbaut, ist aber in der Firmware noch nicht konfiguriert.

Wenn ich aber auf Temperatur heize und dann über die Octoprint Steuerung/Extrude mache passiert folgendes:

Code: Alles auswählen

Send: G1 E5 F300
Recv: // Klipper state: Shutdown
Recv: !! Internal error on command:"G1"
Recv: ok
Send: M82
Recv: // Internal error on command:"G1"
Recv: // Once the underlying issue is corrected, use the
Recv: // "FIRMWARE_RESTART" command to reset the firmware, reload the
Recv: // config, and restart the host software.
Recv: // Printer is shutdown
Recv: !! Internal error on command:"G1"
Recv: ok
Send: G90
Recv: // Internal error on command:"G1"
Recv: // Once the underlying issue is corrected, use the
Recv: // "FIRMWARE_RESTART" command to reset the firmware, reload the
Recv: // config, and restart the host software.
Recv: // Printer is shutdown
Recv: !! Internal error on command:"G1"
Recv: ok
Send: M105

Dasselbe passiert, wenn ich einen G1 oder G0 -Befehl für die X-Achse eingebe.
Hier noch das Klippy:

[af0815]

grundlegend einmal wie von mhier beschrieben den z offset scan in der konfiguration einmal herausnehmen und einen HBS durchführen versuchen. g1 und g0 sind gleichwertig und genaugenommen nur ein Befehl.

So um die Zeile 2840 sieht man was im Log. Deswegen das Modul bis zu einem erfolgreichen HBS deaktivieren. Das heisst aus der config löschen.

[FB]

Soory wenn ich auf dem Schlauch steh, aber wo hat denn mhier das beschrieben?
Versuches aber gleich mal...

[af0815]

[z_offset_scan]
aus der config löschen. War in einem Thread wo ein anderer genau dasselbe Problem hatte.

Grundlegend braucht man einen Z Offset Scan nicht unbedingt. Er wird nur benötigt wenn man zwischen dem Heatbedscan und dem Drucken unterschiede hat. Zum Beispiel unterschliedliche Druckplatten oder kalter Heatbedscan (HBS) und Extruder der nachlängt.

Da der Z Offset auf den HBS draufgerechnet wird, gibt es ev ein Problem bei der Berechnung ohne vorhergehenden HBS.

[mhier]

Ja ist etwas unpraktisch, dass wir zwei Threads haben...

Zum Thema Z-Offset-Scan gibt es auf github eine inzwischen längere Diskussion:
https://github.com/KevinOConnor/klipper ... -753838010

Ich denke, so langsam kristallisiert sich eine Lösung heraus, die ich demnächst mal angehen will. Die wird sich dann in der Logik zwar deutlich von unserer bisherigen Lösung unterscheiden, integriert sich aber besser in das Klipper-Konzept und mit den anderen Modulen.