Klipper auf dem RF2000V2

[AtlonXP]

Hast du als Hitzebrecher das PEEK Teil vom V3 in deinem Vulcano drin?
Ich gehe davon aus, dass bei so eine Konfiguration es auch eine Längenausdehnung + Nachlängungen gibt.

Der Faktor der Längenausdehnung + Nachlängung dürfte etwa bei 0,5 liegen,
im Vergleich zum V2.

Das macht dann so etwa knapp 0,2 mm aus.
Leider hat hier noch niemand das V3 so vermessen wie ich das V2.

Hier eine Doktorarbeit über das V2:
viewtopic.php?p=21710#p21710

LG AtlonXP

[af0815]

Es hat in diesen Fall nichts mit der bekannten Längenausdehnung zu tun. Für den V3 werde ich das nicht mehr tun, für den E3D Vulcano könnte ich es machen. Auch für den normalen E3D wäre es mir möglich.

Ich habe bisher gesehen, das die Längenausdehnung beim E3D geringer sein muss als beim V3.

Nur direkt vergleichen kann man nicht, da ich fix auf Klipper bin.

[AtlonXP]

Hallo af0815,
für das originale (Vollmetall) E3D macht die Vermessung keinen Sinn.

Die Längenausdehnung ist vernachlässig bar.
Nur wenn das PEEK Kunststoffteil mit im Spiel ist, würde eine Vermessung Sinn machen.

Kunststoff hat einen wesentlich höheren Ausdehnungskoeffizient wie Metall.
Auch gibt es keine Kriechwärme die für die Nachlängung verantwortlich ist.

Was wir hier im Forum meistens nicht erwähnen, dass bei einer Temperatursenkung im Dual Druck,
mit dem V2 oder V3, eine hebe senke Funktion im 0,1 mm Bereich besteht.

LG AtlonXP

[af0815]

Wie richtig erkannt kein PEEK mehr. Bei meinem RF2000V2 war schon in den beiden Hotends beim Kauf der Wurm drinnen. Nachdem ich sowieso das wusste mit den Ersatzteilen, habe ich mich gleich mit verschiedenen Varianten des E3D eingedeckt.

[mhier]

Das hat mhier bereits im klipper thread gepostet das es da noch ein Problem gibt. Oder sollte das schon behoben sein?

Ja es gab ein Problem, da hatte ich im RF1000-Klipper-Thread gepostet. Das Problem ist teilweise behoben. Teilweise in dem Sinne, als dass das Verhalten evtl. noch immer nicht in allen Fällen der Erwartung entspricht.

Bisher war das Problem, dass der Z-Offset unabhängig vom Bed-Mesh-Scan erhalten blieb. Ein neuer Bed-Mesh-Scan hat aber einen etwagigen Offset dann ja beinhaltet. Wenn du also eine mechanische Änderung vornimmst, durch die sich der Offset stark ändert, und diese mit dem Z-Offset-Scan korrigierst, dann aber später einen neuen Bed-Mesh-Scan durchführst, war der Offset doppelt kompensiert (bis zum erneuten Ausführen des Z-Offset-Scan).

Der entscheidende Commit ist c9ced61f446da9df54bc3a10e3bdc5e9d26eb015 vom 23.12. "keep scanned z offset correct even when bed mesh is rescanned". Mit dem sollte dieses Problem behoben sein.

Es gibt aber noch ein weiteres Problem: Weiterhin wird der effektive Offset des Z-Offset-Scan durch einen Bed-Mesh-Scan aktuell nicht geändert. D.h., wenn du eine mechanische Veränderung vornimmst, und versuchst diese nur mit einem Bed-Mesh-Scan zu korrigieren, wird der Offset tatsächlich weiterhin falsch sein. Ich bin noch nicht ganz sicher, wie man das Problem am besten löst. Der Hintergrund ist, dass der Bed-Mesh-Scan und der Z-Offset-Scan zwei getrennte Module sind. Der Z-Offset-Scan kennt zwar das Bed-Mesh-Scan-Modul und benutzt auch dessen Ergebnis, andernfalls würde der Offset falsch berechnet werden. Umgekehrt gibt es aber keine mir bekannte Möglichkeit, der Z-Offset zurückzusetzen, wenn ein neuer Bed-Mesh-Scan durchgeführt wird, ohne dass ich eine umgekehrte Abhängigkeit (Bed-Mesh-Scan vom Z-Offset-Scan) einführe. Das möchte ich vermeiden, da das eher die Akzeptanz für einen späteren Merge in Upstream erschweren wird.

Irgendwelche Ideen?

PS: Bitte grundsätzlich vorsichtig sein, was die Erwartung für ein bestimmtes Verhalten angeht. Das Verhalten von Klipper ist nicht identisch mit dem von Repetier, auch nicht, wenn wir gewisse Features an der Repetier-Version anlehnen. Bitte immer genau prüfen, ob eine Aktion das gewünschte Ergebnis liefert. In vielen Punkten sind Verhaltensunterschiede zu erwarten, das sind nicht immer Bugs. Das Verhalten wird sich auch ggf. im Lauf der Zeit ändern, wenn wir hier und da feststellen, dass bestimmtes Verhalten unpraktisch oder unintuitiv ist. Das war bei Repetier vor ein paar Jahren ebenfalls so. Ich habe viele Düsen geschrottet, als ich den RF1000 neu hatte, weil die Firmware damals sich in vielen Punkten komplett unlogisch verhalten hat. Das ist schon jetzt besser bei Klipper, aber wir sind sicher noch ein Stück von "optimal" entfernt...

[AtlonXP]

Hallo mhier,
ich weiß natürlich nicht, welche Möglichkeiten du in Klipper hast.

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

Wir haben in der Matrix (Mesh) einen Z- Offset Wert.
Dieser wird mit dem HBS oder mit dem Z Scann aktualisiert.

Dann habe wir noch eine zusätzlichen Z Offset der ebenfalls im EEPROM hinterlegt ist.
Dieser bleibt immer bestehen außer er wird von Hand geändert.
Ich denke der wird auch beim Fräsen als Werkzeugkorrektur verwendet.

Der Sense Offset benutzt noch für seine eigenen Zwecke, einen dritten Z Offset.
Dieser ist jedoch flüchtig und ist nur im RAM hinterlegt.

LG AtlonXP

[af0815]

Der entscheidende Commit ist c9ced61f446da9df54bc3a10e3bdc5e9d26eb015 vom 23.12. "keep scanned z offset correct even when bed mesh is rescanned". Mit dem sollte dieses Problem behoben sein.

Es gibt aber noch ein weiteres Problem: Weiterhin wird der effektive Offset des Z-Offset-Scan durch einen Bed-Mesh-Scan aktuell nicht geändert.

Ich kenne die Commits, da ich das ganze sehr genau verfolge. Die sind bereits alle am Drucker.

Den Effekt mit dem Z_Offset und Bed-Mesh dachte ich mir. Eine Lösung wäre nur dann möglich, wenn der Z-Offset-Scan nicht stateless ist und sich den letzten Wert des Bed-Mesh merken würde. Damit könnte man zumindest eine falsche Kompensation erkennen und bei einem neuen HBS den Z_Offset entweder korrigieren oder deaktivieren. Weil dann hätte der Z-Offset eine Indikation für eine Änderung.

In unserer Community FW ist das denke ich sehr gut gelöst.
Wir haben in der Matrix (Mesh) einen Z- Offset Wert.
Dieser wird mit dem HBS oder mit dem Z Scann aktualisiert.

Bei Klipper sind die Möglichkeiten auch da, man muss dort aber sehr stark auf das was dort an usus herrscht eingehen, sonst wird es nicht aktzeptiert. Man kann dort einen HBS nicht beliebig Werte ändernlassen, da Klipper nicht exklusiv nur für unseren Drucker ist. Der Z_offset-Scan kann die Infos vom HBS lesen, nur die Abhängigkeit sollte immer nur in eine Richtung gehen. Der HBS weis aktuell nichts vom Z-Offset und er braucht es auch nicht zu wissen, da der Z-Offset-Scan in der Kette weiter hinten steht. Deswegen auch der Vorschlag, das der Z-Offset-Scan das erkennt und sich dannach richtet. Genaugenommen sollte der Z-Offset nach einem aktuellen HBS ja IMHO 0.0 sein (theoretisch).

BTW: Eine der Gründe warum ich aktuell eine Pertinax Bettauflage habe ist, weil damit Schrammen nicht so schlimm sind. - Ausserdem Teste ich gerade die Haftungen darauf.

[nikibalboa]

Sind dann die Profile auch falsch wenn man diese läd?
Könnte man nicht denn mesh_calibrate mit einem "Sonderbefehl" vom offset_scan Modul starten und vorher den offset wert zurück setzen? Das wäre natürlich auch nicht ganz sauber.

Lg nikibalboa

[af0815]

Ich würde sagen, nicht die Profile, sondern dann nur der Z-Offset, da er zu einem anderen Profil erstellt wurde.

[zero K]

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 ?
- ist bei Start eines HBS ein vorhandener Z-Offset entfernbar?

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

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?

gruß zero K