Klipper auf dem RF2000V2

[mhier]

In unserer Community FW ist das denke ich sehr gut gelöst.

Leider überhaupt nicht. Es gibt in der Community FW zahlreiche Offsets, und die Situation ist extrem unübersichtlich. Wir haben uns nur daran gewöhnt.

Ja, es ist richtig, dass der Z-Offset-Scan in der Repetier-Community-Firmware den selben "Offset" wie der HBS bedient (das ist technisch meiner Erinnerung nach kein einzelner Offset sondern quasi der Mittelwert der Matrix). Ich bin mir unsicher, ob so eine Verquickung bei Klipper erwünscht ist, zumal es ein sehr eng verwandtes Feature in Klipper bereits gibt. Vielleicht sollte ich einfach mal auf Github bei Klipper nachfragen, ob ein solches Feature gewünscht ist.

Evtl. gibt es auch eine halbwegs transparente Möglichkeit, das Z-Offset-Modul vom Bed-Mesh-Calibrate aus über eine neue Kalibration zu benachrichtigen.

[mhier]

Sorry, wenn das mal wieder ein doofer Einwand ist - Programme lesen ist für mich wie ein Buch mit sieben Siegeln.

- Ist der Z-Offsetscan die Erfassung nur eines einzigen Höhenwertes oder sind es mehrere Punkte quasi ein reduzierter HBS, also wirklich ein Scan ?

Es wird ein einzelner Punkt gemessen. Der Begriff "Scan" bezieht sich hierbei darauf, dass der Berührungspunkt zwischen Heizbett und Düse gesucht wird, nicht darauf, dass mehrere Punkte erfasst werden.

- ist bei Start eines HBS ein vorhandener Z-Offset entfernbar?

Nein, das ist sicher ein fehlendes Feature.

Besonders für jene die Wechseldruckplatten betreiben.
- kann sich der Z-Offset auf den höchsten Punkt einer gespeicherten Matrix setzen?

Was genau meinst du damit, und was genau soll damit bezweckt werden? Es spielt keine Rolle, wo man den Offset scannt.

Kann es etwas wie "align extruders" geben, etwa mit einem Z-Offsetscan am höchsten Punkt der aktuellen Matrix, Werkzeugwechsel, sodass dann das zweite Hotend aufgesetzt werden kann?

Das hat nichts mit dem Z-Offset-Scan zu tun. Ich bin mir nicht sicher, ob es so etwas in Klipper schon gibt (ich habe kein Dual-Extruder bisher ). Falls nicht, kann man das aber relativ leicht implementieren. Allerdings sollte m.E. der Offset für den zweiten Extruder nicht software-seitig korrigiert werden, sondern du solltest deinen zweiten Extruder in der Höhe so justieren, dass beide Düsen auf gleicher Höhe sind. Andernfalls kollidiert ja immer die tiefere der beiden Düsen mit dem Druckteil, wenn der höhere Extruder aktiv ist. Oder verstehe ich da was falsch?

In dem Fall müsste man lediglich an die höchste Position des Betts fahren und dann auf Z=0 stellen. Dann muss man den Extruder so justieren, dass er gerade eben das Bett berührt.

[zero K]

Da ist er doch schon wieder der doofe Einwand - Z-Offset auf einem Punkt der aktuellen Matrix reicht - nachdenken hätte helfen können.

- align extruders
Ja so direkt hat das auch nix mit dem Offsetscan an sich zu tun.
Bis kurz vor Weihnachten wurde hier mit Hotend V3 gedruckt - für jeden Werkstoff ein oder zwei separate Hotends.

Wenn ich das rechte Hotend wechselte,
starteten align Extruder,
links setzte auf und erzeugte ein paar Digits,
Werkzeugwechsel,
Ablage des rechten Hotends,
unter Beachtung der Digits Fixierung des rechten Hotends.

In dieser seltsamen Art bin ich fast zweieinhalb Jahre gut gefahren - viele der hier geschilderten Probleme hatte ich nicht.
Layer unter 100 µm an großen Modellen wären aber trotzdem spannend
Mal schauen wie es mit dem neuen Druckkopf gelingt - da wechsele ich nur noch den Heizblock mit Düse und Heatbrake am Stück

Gruß zero K

[af0815]

Z Offset Scan ist an einem Punkt. Erweitert also die Korrektur des HBS. Um es noch komplizierter zu machen, gibt es noch einen weiteren möglichen Scan den du nach der Startraupe machen kannst, der aber nicht in der Config gespeichert wird. Ist also für alle, die Wechselplatten verwenden, die nur geringfügig abweichen.

Der Z Offset wird in der Config hinterlegt, dazu muss die Config gespeichert werden und die Configuration durch einen Restart neu eingelesen werden. Das verwende ich dann, wenn ich die Auflage generell wechsle. Bsp. Bluetape gegen Pertinax. Der HBS bleibt gleich, nur knapp 1mm ist der Höhenunterschied. Ebenso, wenn ich das Glasbett auflegen würde.

[mhier]

Z Offset Scan ist an einem Punkt. Erweitert also die Korrektur des HBS.

Nein, du kannst einen Z-Offset-Scan durch einen HBS ersetzen. Der Z-Offset-Scan ist lediglich eine Abkürzung, wenn sich nur der Z-Offset, nicht aber die Unebenheiten des Bettes geändert haben können.

Um es noch komplizierter zu machen, gibt es noch einen weiteren möglichen Scan den du nach der Startraupe machen kannst, der aber nicht in der Config gespeichert wird.

Besser vor der Startraupe bei etwas niedrigere Temperatur, aber nach dem Homen. Die Idee davon war, Ungenauigkeiten des Z-Schalter auszugleichen, sowie die thermische Ausdehnung des Hotends zu korrigieren. Das war das erste Feature unserer Community-Version Das mit der thermischen Ausdehnung hat nur so mittel gut funktioniert, weil zumindest das v2 Hotend sich signifikant nachlängt. Daraus hat sich dann der Z-Sense-Offset entwickelt. Mit einem vernünftigen Z-Schalter und einem Hotend, welches sich weniger stark ausdehnt (z.B. E3D v6) braucht man ggf. beides nicht.

Ist also für alle, die Wechselplatten verwenden, die nur geringfügig abweichen.

Nein, wer Wechselplatten benutzt, muss komplett neu scannen, denn jede Platte wird unterschiedlich gekrümmt sein. Wenn diese Eigenschaften einen Wechsel "überleben", kann man mit mehreren Matrizen / Bed Mesh Profilen arbeiten (geht sowohl in der Repetier-Version als auch in Klipper) und muss gar nicht scannen nach dem Wechsel (wenn man die Z-Schraube nicht anfasst).

Der Z Offset wird in der Config hinterlegt, dazu muss die Config gespeichert werden und die Configuration durch einen Restart neu eingelesen werden.

Ja, aber der Z-Offset ist auch sofort aktiv. Du kannst also den Z-Offset-Scan sowohl zur schnellen Korrektur des Bed Profils benutzen (mit SAVE_CONFIG abspeichern) als auch zur o.g. Korrektur der Z-Schalter-Ungenauigkeiten und der anfänglichen thermischen Ausdehnung (im Start-Code nach dem Homen, dann natürlich ohne SAVE_CONFIG).

Das verwende ich dann, wenn ich die Auflage generell wechsle. Bsp. Bluetape gegen Pertinax. Der HBS bleibt gleich, nur knapp 1mm ist der Höhenunterschied. Ebenso, wenn ich das Glasbett auflegen würde.

Wie gesagt, in solchen Fällen würde ich immer empfehlen, komplett neu zu scannen. Mindestens würde ich das mal ausprobieren und die Scans vor und nach dem Wechsel vergleichen. Ich benutze eine Dauerdruckplatte (leider weiß ich das Material nicht) als auch das nackte Original-RF1000-Bett, beide Oberflächen sind erheblich unterschiedlich. Da reicht ein einfacher Offset-Scan definitiv nicht.

[af0815]

Aktueller Erfahrungsbericht nach einigen Drucken:

* ) Drucken kein Problem, Achsen sind viel leiser und rütteln besonders bei kurzen Bewegungen nicht so stark
* ) Kann für mich als standard Software eingesetzt werden. Ich gehe nicht mehr zurück.
* ) Klipper geht auch sehr gut mit dem Repetier-Server, dann aber unbedingt V0.99.4 oder besser verwenden, damit die erweiterten Befehle von Klipper besser verarbeitet werden. (Ich sehe gerade das Version 1.0.2 herausgekommen ist und meine 0.99.4 nie veröffentlich wurde )

Offene Kleinigkeiten die mir aufgefallen sind:
Ev. habe ich nur nicht die richtige konfig EInstellung gefunden

A ) Die Temperaturregelung ist nicht so stabil wir bei der Communityversion. Überheizt gerne beim Hochfahren und schwingt stärker
B ) Wenn ich einen Output mache, so muss ich anschliessen 2x Homen, da das erste mal der 5 mm Z-Hop nach unten in die Softwarebegrenzung fährt. beim 2 ten mal ignoriert er das.
C) Ich habe nach dem HBS und Z-Offset Scan trotzdem immer einen konstaten Höhenversatz. Es ist kein Problem, da ich nach den Scanns die Höhe einmal händisch messe und das als G_Code_Offset einfüge. Dieser bleibt dann absolut konstant bis zum nächsten HBS + Z_Offset_Scan.
D ) Die Belegung der Tasten mit den Befehlen muss ich mir noch umbelegen, ich weis nur nicht wie ich es haben will
E ) Die Anzeige der DMS am Display geht mir ab

Ich danke mhier für die viele Arbeit die er in das Projekt hineinsteckt, das Klipper auch am RFx000 so stabil läuft. Mir ist auch bekannt, das er mit HBS und Z Offset Scan noch einiges am laufen ist und auch Anfragen dazu an die Entwickler von Klipper laufen.

Konklusio: Ja man kann Klipper am Rf2000(V2) bereits sehr komfortabel und stabil laufen lassen

[af0815]

Zur Info das bekomme ich, wenn ich der Ouput Position ein Homing mache

Recv:10:17:21.885: Slow command added:G28
Send:10:17:21.885: N63852 G28
Recv:10:17:21.887: !! Move out of range: 119.179 245.000 186.114 [1844.700]
Recv:10:17:21.887: ok
Recv:10:17:24.323: Slow command added:G28
Send:10:17:24.323: N63856 G28
Recv:10:17:24.324: // No zhop performed, target Z out of bounds: 186.113678651

Was unangenehmes ist, ist der Home in einem Script (die Position noch bekannt) und dannach ein Fahrbefehl, so fährt die Z Achse mit voller Geschwindigkeit hoch auf die Position. Richtig wäre beim Homing, das er keinen Z-Hopp macht, wenn die Grenzen in Z verletzt werden würden.

Und eine weitere Sache muss ich noch konfigurieren, die Maximalgeschwindigkeit der Achsen. Die dürfte generell zu hoch sein, weil bei der Fahrt ist der Stepper überlastet.

[mhier]

A ) Die Temperaturregelung ist nicht so stabil wir bei der Communityversion. Überheizt gerne beim Hochfahren und schwingt stärker

Das ist bei mir eher umgekehrt, aber eigentlich nimmt es sich nichts. Nur sicherheitshalber: Du hast deine PID-Parameter via PID_CALIBRATE eingemessen? (Sonst kann das nicht klappen...)

B ) Wenn ich einen Output mache, so muss ich anschliessen 2x Homen, da das erste mal der 5 mm Z-Hop nach unten in die Softwarebegrenzung fährt. beim 2 ten mal ignoriert er das.

Schalte doch einfach die Stepper ab nach dem Output Object. Dadurch verliert er die Homing-Position und kann nicht mehr in das Software-Limit laufen. Oder baue dir ein Homing-Script, das erstmal SET_KINEMATIC_POSITION Z=0 und dann G28 ausführt, dadurch umgehst du die Begrenzung ebenfalls.

C) Ich habe nach dem HBS und Z-Offset Scan trotzdem immer einen konstaten Höhenversatz. Es ist kein Problem, da ich nach den Scanns die Höhe einmal händisch messe und das als G_Code_Offset einfüge. Dieser bleibt dann absolut konstant bis zum nächsten HBS + Z_Offset_Scan.

Das finde ich merkwürdig. Auf welcher Git-Revision bist du? Wie groß ist dieser Offset, und wie hast du ihn gemessen/abgeschätzt?

D ) Die Belegung der Tasten mit den Befehlen muss ich mir noch umbelegen, ich weis nur nicht wie ich es haben will

Geht mir ähnlich...

E ) Die Anzeige der DMS am Display geht mir ab

Mir auch... Kommt irgendwann...

Code: Alles auswählen

Recv:10:17:21.885: Slow command added:G28
Send:10:17:21.885: N63852 G28
Recv:10:17:21.887: !! Move out of range: 119.179 245.000 186.114 [1844.700]
Recv:10:17:21.887: ok
Recv:10:17:24.323: Slow command added:G28
Send:10:17:24.323: N63856 G28
Recv:10:17:24.324: // No zhop performed, target Z out of bounds: 186.113678651

Vielleicht reportest du das dann mal an Klipper auf Github. Das scheint mir eher ein Bug in Klipper zu sein. Z-Hop ist ja kein neues Feature von uns.

Und eine weitere Sache muss ich noch konfigurieren, die Maximalgeschwindigkeit der Achsen. Die dürfte generell zu hoch sein, weil bei der Fahrt ist der Stepper überlastet.

Gut möglich, ich habe das auf mein RF1000-Exemplar eingestellt. Andere Exemplare laufen vielleicht etwas schwergängiger. Wir sollten natürlich garantiert funktionierende Geschwindigkeiten und Beschleunigungen einstellen. Bitte schreibe mir mal deine Werte, dann übernehme ich die.

PS: Ich habe eben mal die aktuelleste Verison von Klipper upstream gemerged. Vielleicht probierst du die mal aus, bevor du das mit dem Z-Hop reportest. Anscheinend erfordert die neue Version eine neue Firmware auf der MCU, musst also neu flashen.

[af0815]

af0815 hat geschrieben:
A ) Die Temperaturregelung ist nicht so stabil wir bei der Communityversion. Überheizt gerne beim Hochfahren und schwingt stärker


Das ist bei mir eher umgekehrt, aber eigentlich nimmt es sich nichts. Nur sicherheitshalber: Du hast deine PID-Parameter via PID_CALIBRATE eingemessen? (Sonst kann das nicht klappen...)

Ja, wie in der Wiki beschrieben und er hat auch Werte mit save_config eingetragen.

af0815 hat geschrieben:
C) Ich habe nach dem HBS und Z-Offset Scan trotzdem immer einen konstaten Höhenversatz. Es ist kein Problem, da ich nach den Scanns die Höhe einmal händisch messe und das als G_Code_Offset einfüge. Dieser bleibt dann absolut konstant bis zum nächsten HBS + Z_Offset_Scan.

Das finde ich merkwürdig. Auf welcher Git-Revision bist du? Wie groß ist dieser Offset, und wie hast du ihn gemessen/abgeschätzt?

Anhand der Tiefe der Riefe im Heatbed (habe sicherheitshalber aktuell Pertinax) Dann mal auf 0,50 mm gefahren und mit dem Spion gecheckt. Anschließend einen Probedruck gemacht und den ersten Layer an einigen Stellen vermessen und dann den GCode Offset entsprechend korr. (0,13). Jetzt passt es bei meinen Drucken. Das ist für mich jetzt nicht so tragisch, da ich den Spass kenne und nach HBS oder Z Offest Scan mal den Abstand mit Spion und Probedruck prüfen.

]af0815 hat geschrieben:
Und eine weitere Sache muss ich noch konfigurieren, die Maximalgeschwindigkeit der Achsen. Die dürfte generell zu hoch sein, weil bei der Fahrt ist der Stepper überlastet.

Gut möglich, ich habe das auf mein RF1000-Exemplar eingestellt. Andere Exemplare laufen vielleicht etwas schwergängiger. Wir sollten natürlich garantiert funktionierende Geschwindigkeiten und Beschleunigungen einstellen. Bitte schreibe mir mal deine Werte, dann übernehme ich die.

Da habe ich noch einiges zum Nachtragen bin ich im laufe des heutigen Tages draufgekommen. Und noch auf einiges mehr. Wenn es getestet ist, so werde ich es wieder über GIT machen.

---
Die neue Version probiere ich dann aus, wenn ich etwas mehr Zeit habe. Aktuell drucke ich ein paar Sachen. Ich muss auch mal meine Hotends nach den ganzen Umbauten in Griff bekommen Habe ja auf dem Drucker ein paar Baustellen zugleich aufgemacht (aktuell E3D Vulcano mit threaded Heatpipe - weil am kompatibelsten zum originalen V3).

[nikibalboa]

Das mit den Geschwindigkeiten ist mir beim vorbereiten fürs Fräsen aufgefallen. Da rattert der Motor durch und gut so sonst wäre mir das Bett in die Fräse gefahren. Daher habe ich in meinem kleinen modul auch das mit dem z-hop im matrix scan eingebaut.

Achja ich werde das Modul dann auch in mill_mode oder so benennen hätte ich mir gedacht.