Klipper mit dem RF1000

Firmware Veröffentlichungen und Einstellungen können hier angekündigt und diskutiert werden.
nikibalboa
Donator
Donator
Beiträge: 125
Registriert: Mo 13. Nov 2017, 11:12
Wohnort: Friedberg
Hat sich bedankt: 158 Mal
Danksagung erhalten: 39 Mal

Re: Klipper mit dem RF1000

Beitrag #141 von nikibalboa » So 10. Jan 2021, 20:58

So ich hab jetzt das log mit dem Fehler, es gehen scheinbar bytes verloren wenn ich das richtig versteh.
Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.
Rf1000 Bausatz mit allen wichtigen Optimierungen + Umbau auf E3dv6.

Fw1.44.01Mod

Benutzeravatar
af0815
Donator
Donator
Beiträge: 335
Registriert: Di 2. Jun 2020, 14:45
Wohnort: Laxenburg
Hat sich bedankt: 19 Mal
Danksagung erhalten: 36 Mal

Re: Klipper mit dem RF1000

Beitrag #142 von af0815 » So 10. Jan 2021, 21:32

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

mhier
Developer
Developer
Beiträge: 600
Registriert: Fr 11. Sep 2015, 11:37
Hat sich bedankt: 59 Mal
Danksagung erhalten: 90 Mal

Re: Klipper mit dem RF1000

Beitrag #143 von mhier » Mo 11. Jan 2021, 14:48

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
Donator
Donator
Beiträge: 125
Registriert: Mo 13. Nov 2017, 11:12
Wohnort: Friedberg
Hat sich bedankt: 158 Mal
Danksagung erhalten: 39 Mal

Re: Klipper mit dem RF1000

Beitrag #144 von nikibalboa » Mo 11. Jan 2021, 15:55

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.
Rf1000 Bausatz mit allen wichtigen Optimierungen + Umbau auf E3dv6.

Fw1.44.01Mod

mhier
Developer
Developer
Beiträge: 600
Registriert: Fr 11. Sep 2015, 11:37
Hat sich bedankt: 59 Mal
Danksagung erhalten: 90 Mal

Re: Klipper mit dem RF1000

Beitrag #145 von mhier » Di 12. Jan 2021, 17:53

nikibalboa hat geschrieben: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
Developer
Developer
Beiträge: 600
Registriert: Fr 11. Sep 2015, 11:37
Hat sich bedankt: 59 Mal
Danksagung erhalten: 90 Mal

Re: Klipper mit dem RF1000

Beitrag #146 von mhier » So 17. Jan 2021, 15:57

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.


Zurück zu „Firmware / Tweaks“