• Klipper RF2000v2 Dual Konfig

(

Kannst du mir das Log-File des Absturzes (/tmp/klipper.log) mal zukommen lassen? Da steht drin, in welcher Code-Zeile es genau schief geht. Das würde sehr helfen

@mhier Hallo Martin das log habe ich hier hochgeladen. https://github.com/Juifen3D/klipper-RF-testing
Ich habe heute noch ein bed calibrate mit kaltem Bett und Hotend durchgeführt. Alles ohne Probleme, so hast du Vergleichsdaten.

Was mir aufgefallen ist, mein Bett hat + und - Gegenüber der Z-Achse im bed mesh. Wenn ich mit der Schieblehre messe von der X-Platte zum Bett, bzw Y-Platte so ist der Unterschied zw. links und rechts so im 0.04- 0.07mm Bereich. Für eine mechanische Einstellung der Kugelumlaufspindeln ist das doch in Ordnung oder ? War ein Conrad Fertiggerät.

Z-sense-offset hatte ich noch nicht genutzt, in meiner cfg war da bei force_threshold: 4000, im Wiki grad mal die Hälfte.

Code: Alles auswählen

[z_sense_offset]
force_threshold: 1800
max_z_offset: 0.2

Die anderen Parameter aus der z_sense_offset.py hab ich überhaupt nicht verstanden ob ich die anpassen muss oder einfach auf default lasse.

Code: Alles auswählen

max_z_height
n_average_force
smoothing
step_size
relative_tolerance
acuteness
max_steps_at_once

Juifen hat geschrieben:Was mir aufgefallen ist, mein Bett hat + und - Gegenüber der Z-Achse im bed mesh.

Das ist für Klipper in Ordnung. Nur bei der Repetier-basierten Firmware darf die Matrix (möglichst) nicht im Positiven liegen. Klipper funktioniert ganz anders und hat da keinerlei Beschränkungen.

Wenn ich mit der Schieblehre messe von der X-Platte zum Bett, bzw Y-Platte so ist der Unterschied zw. links und rechts so im 0.04- 0.07mm Bereich. Für eine mechanische Einstellung der Kugelumlaufspindeln ist das doch in Ordnung oder ?

Geh ich von aus, denn ich bin lange mit einem deutlich größeren Unterschied gefahren

Z-sense-offset hatte ich noch nicht genutzt, in meiner cfg war da bei force_threshold: 4000, im Wiki grad mal die Hälfte.

Der Wert hängt stark vom Hotend, den Druckparametern und wohl auch vom Material ab. Ich würde den etwas über den Wert einstellen, den man am Anfang des ersten Layers beobachtet. Die Idee ist, wenn der Druck ansteigt, soll der Abstand zwischen Bett und Düse vergößert werden, um die Nachlängung des Hotends durch die Wärmeausdehnung zu komensieren. Als Test kann man auch sein Hotend einmal voll durchheizen (20 Minuten warten oder so) und dann erst den Druck starten - in dem Fall sollte der z-Sense-Offset idealerweise untätig bleiben.

Die anderen Parameter aus der z_sense_offset.py hab ich überhaupt nicht verstanden ob ich die anpassen muss oder einfach auf default lasse.

Ich denke, die kann man so lassen. Das hatte Nibbels damals alles genau ausprobiert und bedarf eigentlich keiner Anpassungen.

Juifen hat geschrieben:@mhier Hallo Martin das log habe ich hier hochgeladen. https://github.com/Juifen3D/klipper-RF-testing
Ich habe heute noch ein bed calibrate mit kaltem Bett und Hotend durchgeführt. Alles ohne Probleme, so hast du Vergleichsdaten.

Achso, das wichtigste hab ich vergessen

Danke dafür, jetzt verstehe ich das Problem zumindest teilweise.

Was da passiert ist folgendes:

Der Scan fährt zunächst in negative Z-Richtung, bis ein Schwellwert überschritten ist. Das bedeutet, dass die Düse Kontakt mit dem Bett hat. Allerdings ist er dann zu weit gefahren, weil aus Geschwindigkeitsgründen relativ große Schritte gefahren werden. Um den genauen Messpunkt zubekommen, muss er jetzt erst noch einmal zurück fahren, so dass kein Kontakt vorhanden ist, aber möglichst knapp über der Oberfläche. Um das zeitsparend hinzubekommen, fährt er ein Stück in positive Z-Richtung, misst noch mal, und schätzt dann über die Steigung (Kraftänderung pro z-Weg) ab, wie weit er fahren muss. Das wiederholt er so lange, bis die Kraft wieder unter dem Schwellwert ist (denn oft reicht ein solcher Schritt nicht). Aus irgendwelchen Gründen kommt es bei dir offenbar häufgier vor, dass die zwei Messungen exakt den selben Wert liefern, wodurch bei der Berechnung der Steigung dann durch 0 geteilt wird. Ich vermute, er hat zu dem Zeitpunkt bereits keinen Kontakt mehr zum Bett, trotzdem ist er nicht unter dem Schwellwert. Das ist der Teil, den ich nicht ganz verstehe.

Klar ist aber, dass diese Situation nicht zu einem Absturz führen darf. Ich habe gerade einen entsprechenden Schutz eingebaut. Statt einem Kraftunterschied von 0 nehme ich jetzt immer mindestens einen Unterschied von 1 an. Dadurch wird er in dem Fall einfach ein kleines Stück weiter fahren und erneut messen. Ich hoffe, das löst das Problem, und schafft kein neues (im Extremfall erreicht er seine Ziel-Bedingung nie, das glaube ich aber eher nicht). Sag mal bitte bescheid, ob das funktioniert!

Werde es später ausprobieren wenn mein Druck fertig ist und berichten.

@mhier Hallo Martin, Ich habe mir den fix gezogen. In kaltem zustand alles bestens mi z_calibrate
Dann aufgeheizt und nochmal getestet ->

File "/home/pi/klipper/klippy/extras/load_cell_probe.py", line 302, in _find_fit_start
slope = (self.step_size[self.probing_axis]/2)/max(force2-force1,1)
ZeroDivisionError: float division by zero
MCU 'mcu' shutdown: Command request

Ich verstehe es nicht, der fix ist doch da

slope = (self.step_size[self.probing_axis]/2)/max(force2-force1,1)

Wenn force2-force1<1 dann liefert max doch die 1 . Woher komme die Null?
Das log hab ich wieder hochgeladen: https://github.com/Juifen3D/klipper-RF- ... %20(5).log

Mir ist noch aufgefallen, dass es immer dann zum Problem kommt, wenn die erste Messung fast perfekt ist.
r=0.85 also 2 Nachkomma stellen, beim Vergleich werden aber 6 Nachkommastellen genommen. Daher werden Werte wie unten, die gerundet die 0.85 ergeben verworfen, allen folgenden R Werte sind dann erstmal viel schlechter.

// Fit failed, fit quality factor r too small: 0.845874 < 0.850000
// Fit failed, fit quality factor r too small: 0.848875 < 0.850000

Juifen hat geschrieben:Wenn force2-force1<1 dann liefert max doch die 1 . Woher komme die Null?

Hä? Das kapier ich jetzt auch nicht. Da muss ich noch mal drüber nachdenken... Das ist vielleicht irgend ein Python-Typ-Problem...

Generell scheint bei deinem Drucker was nicht gut zu laufen. r=0.85 ist schon eher schlecht. Normal sind die meisten Messpunkte im mittleren bis oberen 0.9er Bereich und nur einzelne Ausreißer mal knapp unter 0.9. Ich vermute, das Viereck aus Wägezellen, Traverse und Führungswagen ist unter Spannung. Das passiert gerne. Löse einfach mal die drei zugänglichen Schrauben (an die 4. kommt man nur mit Demontage des Motors), und ziehe sie dann rings um in kleinen Schritten wieder an. Dadurch wird man die Spannungen los.

Guten Abend

Gerade habe ich das letzte verfügbare nightly build 64 bit von Octopi (also das all in one Image von der Homepage) auf eine MicroSD gebracht.
Octopi ließ sich auch ohne Fehlermeldung starten.

Nach menuconfig erhielt ich folgende Ausgabe:

pi@octopi:~/Klipper$ make menuconfig
make: python2: No such file or directory
Makefile:99: out/board-link: No such file or directory
make: *** [Makefile:109: /home/pi/Klipper/.config] Error 127

Klipper wünscht sich wohl die etwas betagte Python2 Umgebung.

pi@octopi:~/Klipper$ python2 --version
Command 'python2' not found, but can be installed with:
sudo apt install python2
pi@octopi:~/Klipper$ python3 --version
Python 3.9.7

Man erkennt an der dummen Frage sicher meine herausragende Qualifikation als Programierer.

Platt gefragt, gibt es in Klipper einen Abschnitt bei dem das Ziel von Python2 nach Python3 umgestellt werden kann.
Python3 ist nach den Angaben auf Octoprint.org der neue Standard.

Gruß, zero K

Soweit ich es verstanden habe, ist Klipper am Wege zu Python 3.x aber dort noch nicht angelangt aufgrund Performanceprobleme. Aktuell kenne ich nur Klipper mit dem teilweise nicht mehr von den Distributionen unterstützen Python 2.x

Es ist schön, wenn Octoprint Python 3 als neuen Stand auspreist, was auch grundlegend stimmt. Aber Klipper ist ganz einfach nicht soweit den Sprung zu machen. Was in der Branche durchaus mal passieren kann. Normalerweise können Python 2.x und 3.x meiner Erfahrung nebeneinander existieren.

Danke, eigentlich dachte ich, dass sich die Ausführung von

./klipper/scripts/install-octopi.sh

die erforderlichen Python 2.7 herunter läd.

Gruß, zero K

Martin, ich habe mittlerweile das Hotend auf E3D V6 umgebaut. Seitdem keine Probleme mehr mit bed mesh scan oder z_calibration.
Ich gehe mal davon aus dass es and dem Conrad V3 hotend lag. Warum auch immer das 0 entstand.

So wie ich das sehe wird eh jeder der mit einem RF2000v2 Klipper fährt die printer-rf2000v2.cfg nur als Einstieg benutzen können und muss hinsichtlich der Hotendkonfiguration anpassen. Von daher macht es nicht mehr viel sinn zwischen single und dual zu unterscheiden.

Ich habe eine printer-rf2000v2.cfg, die von den X werten auf nummer Sicher geht und einen dual mit Conrad V3 ( der ist breiter) annimmt.
Von dieser cfg ausgehend als inlcude erstellt sich dann jeder seine angepasste printer.cfg. Was ja dem Grundsätzlichen vorgehen entspricht.

Ich werde in die printer-rf2000v2.cfg noch ein paar macros einarbeiten, die man zu starten braucht wie bed_mesh, z_calibration, filament load/unload etc. Alle Makros dann an die neuen Klipper vorgaben angepasst was Behandlung von default Werten usw. angeht.

Sobald das fertig ist schicke ich dir einen pull request auf github.

Klipper RF2000v2 Dual Konfig

Re: Klipper RF2000v2 Dual Konfig

Re: Klipper RF2000v2 Dual Konfig

Re: Klipper RF2000v2 Dual Konfig

Re: Klipper RF2000v2 Dual Konfig

Re: Klipper RF2000v2 Dual Konfig

Re: Klipper RF2000v2 Dual Konfig

Re: Klipper RF2000v2 Dual Konfig

Re: Klipper RF2000v2 Dual Konfig

Re: Klipper RF2000v2 Dual Konfig

Re: Klipper RF2000v2 Dual Konfig