Klipper mit dem RF1000

[nikibalboa]

So ich hab jetzt das log mit dem Fehler, es gehen scheinbar bytes verloren wenn ich das richtig versteh.

[af0815]

Ich lese eher das es ein Problem mit G1 mit Z=-10 gibt und deswegen der mcu abgewürgt wird.

[mhier]

Code: Alles auswählen

Traceback (most recent call last):
  File "/home/pi/Klipper/klippy/gcode.py", line 177, in _process_commands
    handler(gcmd)
  File "/home/pi/Klipper/klippy/extras/gcode_move.py", line 135, in cmd_G1
    self.move_with_transform(self.last_position, self.speed)
  File "/home/pi/Klipper/klippy/extras/z_offset_scan.py", line 74, in move
    self.bed_mesh.get_mesh().mesh_offset - self.mesh_offset
AttributeError: 'NoneType' object has no attribute 'calc_z'

Das ist der entscheidende Teil. Da läuft was falsch im Z-Offset-Scan-Modul, bzw. im davon aufgerufenen Bed Mesh Modul. Mir ist allerdings etwas unklar, was genau. Vielleicht fehlen im Z-Offset-Scan-Modul gewisse Prüfungen für ungültige Zustände. Es wird z.B. vorausgesetzt, dass du einen gültigen Bed Mesh Scan hast. Ist das bei dir der Fall?

[nikibalboa]

In der Fräs konfig nicht, aber wenn ich das erste mal mit der printer konfig starte und dann auf die Fräs konfig wechsle geht alles, auch nach einen Neustart mit der Fräs konfig.

Wie ist das wenn man noch nie einen scan gemacht hat?

Und die Meldungen invalid bytes kommt erst danach wo der mcu bereits weg ist oder?

Die eigentliche Fehlermeldung dürfte ich überblättert haben.

Ohne z_offset modul funktioniert es.

[mhier]

Wie ist das wenn man noch nie einen scan gemacht hat?

Ich denk mal, das ist ein Bug

Schau ich mir demnächst mal an. Ich komme leider im Moment nur sehr mühsam vorwärts, sorry...

[mhier]

Ich habe mir den Bug zwar noch nicht ansehen können, aber immerhin mal auf die aktuelle Klipper upstream Version geupdated. Die scheint aber eine neue MCU-Firmware zu erfordern (also auf dem Drucker-Mainboard), also bitte nach Update einmal neu flashen:

Code: Alles auswählen

sudo service klipper stop
make flash FLASH_DEVICE=/dev/serial/by-id/usb-1a86_USB2.0-Serial-if00-port0
sudo service klipper start

(/dev/serial/by-id/usb-1a86_USB2.0-Serial-if00-port0 durch den richtigen USB-Port ersetzen wie in der Config eingetragen.)


Nachtrag bezgl. dem Z-Offset-Scan: Nach der Diskussion auf Github mit dem Autor von Klipper werde ich den Befehl in zwei Teile zerlegen und in die load-cell-probe integrieren. Der Hintergrund ist, dass es die Funktionalitäten für andere Probes (BL-Touch etc.) in Klipper bereits gibt.

Zum einen gibt es Z_ENDSTOP_CALIBRATE, mit dem man über die manuelle Probe (also z.B. mit einem Blatt Papier und manuellem Bewegen der Z-Achse) den Z-Endstop justieren kann. Das entspricht der häufigsten Anwendung unseres Z-Offset-Scan. Normale Probes können den absoluten Offset ja nicht messen (sondern müssen selbst justiert werden), daher wäre unser Z-Offset-Scan für solche Probes sinnlos. Ich werde also für unsere Probe einen Z_ENDSTOP_CALIBRATE Befehl einführen, der "position_endstop" in der Config für die Z-Achse einstellt.

Die andere Anwendung ist quasi ein Homing-Ersatz, was z.B. bei einem schlechten Z-Endschalter (schlechte Wiederholgenauigkeit) oder zum Fräsen (Werkzeuglängensensor) benutzt werden kann. Das ist für normale Probes so gelöst, dass diese zum Homen genutzt werden können. Das geht wiederum mit unserer Probe nicht direkt, da sie viel zu langsam arbeitet (normale Probes haben einfach einen Schalter). Diese Funktionalität würde ich etwas flexibler dadurch abdecken, dass ich einen Befehl einführen werde, der mit der Probe Z=0 sucht und dann dort stehen bleibt. Anschließend kann man per SET_KINEMATIC_POSITION Z=0 die Position setzen.

Diese Lösung hat den Vorteil, dass sie besser mit dem Rest von Klipper zusammenarbeitet.

[mhier]

So, ich habe endlich mal eine erste Version des Kanten Antastens fertiggestellt. Dokumentation ist hier zu finden:

wiki/index.php/Klipper_GCodes#G-Codes_f ... 4s-Betrieb

Das Ganze ist noch nicht gut getestet. Vieles ist aber deutlich einfacher zu implementieren als in der Repetier-Firmware (man kann halt ohne Bedenken größere Datenmengen speichern, ordentliche Fits durchführen usw.), deshalb erwarte ich weniger Probleme mit Sonderfällen.

Die Bedien-Logik entspricht jetzt auch schon dem, wie demnächst auch der Z-Offset-Scan beim Drucken werden soll: Der PROBE Befehl führt nur den eigentlichen Scan durch und bleibt am Kontaktpunkt stehen. Was man dann anschließend damit macht, bleibt einem selbst überlassen. Der Z-Offset-Scan zum Einstellen des Endstops wird also künftig erst ein "PROBE" in Z-Richtung sein, gefolgt von einem "Z_ENDSTOP_SELF_CALIBRATE" o.ä.

[af0815]

A ) Gibt es grundlegend die Möglichkeit mit G-Code Befehlen und Rückmeldung der DMS anzutasten - beim Drucken ? Nur damit man kontrollieren kann ob im G-Code Koordinatensystem etwas in der erwarteten Höhe vorhanden ist. Das müsste doch mit dem Kantenantasten nur in Z ident sein.

B ) Kann ich mir die DMS Werte im Betrieb irgendwie auf der Konsole ausgeben lassen ? Wenn ich zB. in Z fahre welchen DMS Wert ich gerade habe.

C ) Grundlegend ist die DMS ja ein Paralellogramm das verschoben wird und der Wert der Verschiebung kommt als Änderung der Brücke zurück und kann gemessen werden. Das heisst aber auch, das die Position des Heatend gering positiv oder negativ verschoben wird. Beim Antasten in die eine Richtung, beim Drucken in die andere Richtung.

Mich würde bei C interessieren wie das Diagramm aussieht. Ich will da ein paar Versuche machen um einen Verdacht zu untermauern (oder entkräften).

[mhier]

A ) Gibt es grundlegend die Möglichkeit mit G-Code Befehlen und Rückmeldung der DMS anzutasten - beim Drucken ? Nur damit man kontrollieren kann ob im G-Code Koordinatensystem etwas in der erwarteten Höhe vorhanden ist. Das müsste doch mit dem Kantenantasten nur in Z ident sein.

Ich glaube ich verstehe nicht ganz, was du vorhast. Willst du wirklich im laufenden Druckvorgang was antasten? Was soll das denn genau sein, da ist doch nur Material, was der Drucker vorher gedruckt hat (und damit ist normalerweise klar, wo sich das befindet)? Oder denkst du daran, auf ein bestehendes Teil etwas draufzudrucken (z.B. Recovery nach Druckabbruch, oder auf ein anderweitig hergestelltes Teil etwas draufdrucken - wobei da würde ich lieber kleben...)?

Generell ist Antasten mit unseren Mitteln eine recht zeitraubende Geschichte. In Z-Richtung tasten wir die Oberfläche des Heizbetts an, das ist exakt das selbe (sogar gleicher Algorithmus). Ob du da jetzt das Bett antastest oder ein anderes Objekt, ist tatsächlich egal. Du machst einfach folgendes:

Code: Alles auswählen

G0 Z100
G0 X100 Y100
PROBE
SET_KINEMATIC_POSITION Z=15

In dem Beispiel fährt er an die Position X=100 Y=100, tastet in Z-Richtung (startend bei Z=100) an, was auch immer da ist, und definiert dann die Höhe der gefundenen Oberfläche als Z=15. Zahlen kannst du entsprechend austauschen.

In X/Y mit dem Druckkopf Antasten dürfte wegen der Düsenform schwierig sein. Du kannst also nur Z-Koordinaten finden.

B ) Kann ich mir die DMS Werte im Betrieb irgendwie auf der Konsole ausgeben lassen ? Wenn ich zB. in Z fahre welchen DMS Wert ich gerade habe.

So ich nehm das mal als Feature-Request. Das fehlt ja schon lange. Ebenfalls werde ich versuchen, den Wert auf das Display zu bringen.

C ) Grundlegend ist die DMS ja ein Paralellogramm das verschoben wird und der Wert der Verschiebung kommt als Änderung der Brücke zurück und kann gemessen werden. Das heisst aber auch, das die Position des Heatend gering positiv oder negativ verschoben wird. Beim Antasten in die eine Richtung, beim Drucken in die andere Richtung.

"Verschoben" ist nicht ganz richtig, eher verbogen. Das Hotend wird sich abhängig von der ausgeübten Kraft minimal in Z-Richtung bewegen - logisch, denn diese Verbiegung ist ja genau das, was die Wägezellen messen. Die Repetier-Community-Firmware hatte dafür sogar eine Korrektur drin. Ich bin da eher skeptisch. Der Weg dürfte im Normalbetrieb ziemlich minimal ausfallen. Wenn du mit dem Filament so viel Kraft auf das Hotend ausübst, dass die Layerhöhe signifikant verändert wird, hast du ganz andere Probleme. Die Korrektur wird immer an der geringen Sampling-Rate und an recht starken temperaturbedingten Drifts der Messwerte leiden. Ich würde das Problem lieber an der Wurzel lösen.

Mich würde bei C interessieren wie das Diagramm aussieht. Ich will da ein paar Versuche machen um einen Verdacht zu untermauern (oder entkräften).

Ich weiß nicht genau, was du mit "Diagramm" meinst. Weg in Z über Kraft? Das kannst du leicht messen. Schau dir einfach an, was Klipper in die Konsole printet, wenn du nen Z-Offset-Scan machst (bzw. o.g. PROBE Befehl). Wenn die Oberfläche sehr hart ist (Alu ist in dem Zusammenhang hart genug denke ich, Pertinax eher nicht), kann die Düse ja nicht ins Bett eindringen, und der weitere Z-Verfahrweg kommt nur durch Verbigung der DMS zu stande. Ich hatte hier mal so einen Plot gepostet, sogar mit deinen Daten:

viewtopic.php?p=30964#p30964

Ich vermute aber mal, das war mit Pertinax (Verlauf ist recht flach -> weiches Material)? Klipper macht ja sogar einen Fit an die Daten und sollte dir das Ergebnis auch ausspucken. "m" ist dabei die Steigung, allerdings ist der Fit "gestürzt", d.h. es wird z über der Kraft gefittet (Achsen vertauscht gegenüber dem Plot), dementsprechend ist die Steigung m also in mm/Digits, was evtl. auch genau deine Frage beantwortet: bei x Digits wird die Düse m*x mm in Z-Richtung bewegt.

Bei mir ist da z.B. m = 0.000045 mm/Digits, also bei 2000 Digits ca. 0.1mm. (Das gilt natürlich für Digit Differenzen zum Ruhezustand!) Das habe ich gerade im Fräsmodus nachgemessen, da ist allerdings der Hebelarm etwas länger. Dürfte im Druckbetrieb etwas günstiger sein (mehr Digits pro mm nötig).

(Es gibt theoretisch auch noch eine Bewegung in Y-Richtung, aber die ist nun wirklich vernachlässigbar...)

[mhier]

B ) Kann ich mir die DMS Werte im Betrieb irgendwie auf der Konsole ausgeben lassen ? Wenn ich zB. in Z fahre welchen DMS Wert ich gerade habe.

So, gerade gepushed:

Code: Alles auswählen

Send: read_load_cell
Recv: // Uncompensated: 2152.7  compensated: 2152.7
Recv: ok
Send: compensate_load_cell
Recv: ok
Send: read_load_cell
Recv: // Uncompensated: 2152.7  compensated: 1.0
Recv: ok

compensate_load_cell wird implizit auch bei jedem probe-Befehl ausgeführt.

Jetzt muss ich nur noch rausfinden, wie ich den aufs Display bekomme...