Klipper mit dem RF1000

[mhier]

Ich würde gar keine Parameter machen. Man kann sich rasch durch gewisse Kombinationen was drastisch verschlechtern. Wenn wer optimieren will, dann kann er das händisch immer machen.

Parameter mit Default-Werten und entsprechenden Erklärungen in der Dokumentation. In der Beispiel RF1000.cfg werden die dann nicht auftauchen. Eigentlich sollte man als Benutzer nicht im Python-Code rumpfuschen (müssen). Das macht nur Ärger. Wenn das Modul in das offizielle Klipper integriert wird, ist es durchaus möglich, dass es noch ganz andere Nutzer davon gibt. Für die sind die Parameter evtl. in unseren Default-Einstellungen falsch.

[af0815]

ACK, man muss ein wenig breiter sehen

Ich habe jetzt einen Pullrequest beim rf1000/klipper Repository gemacht.

Wäre es nicht sinnvoll ein zweites Klipper repository zu machen, wo man die ganzen Makros und Erweiterungen rein gibt die nicht direkt mit Klipper zusammenhängen, aber für die RFx000 Klasse interessant sein können. Z.B. KlipperRFx000 ?

Edit: ist von den Whitespaces noch nicht ganz sauber laut CI

Run ./scripts/ci-build.sh 2>&1
=============== check_whitespace Check whitespace
+ ./scripts/check_whitespace.sh

ERROR:
ERROR: White space errors
ERROR:
config/printer-rf2000v2-single.cfg:170: Line has trailing spaces
klippy/extras/z_sense_offset.py:18: Line has trailing spaces
klippy/extras/z_sense_offset.py:19: Invalid tab character
klippy/extras/z_sense_offset.py:25: Line longer than 80 characters

xargs: ./scripts/check_whitespace.py: exited with status 255; aborting
Error: Process completed with exit code 124.

[mhier]

Ich habe jetzt einen Pullrequest beim rf1000/klipper Repository gemacht.

Danke, schau ich mir an.

Wäre es nicht sinnvoll ein zweites Klipper repository zu machen, wo man die ganzen Makros und Erweiterungen rein gibt die nicht direkt mit Klipper zusammenhängen, aber für die RFx000 Klasse interessant sein können. Z.B. KlipperRFx000 ?

Würde ich dann machen, wenn klar ist, dass es da was gibt, was nicht im "upstream" Klipper erwünscht ist. Im Moment scheint mir noch alles, was ich gerade mache, zumindest theoretisch interessant für andere Drucker, die auch Wägezellen verwenden, zu sein.

Edit: ist von den Whitespaces noch nicht ganz sauber laut CI

Jupp, da hab ich vor allem am Anfang nicht drauf geachtet. Muss ich vor evtl. merge requests an upstream noch fixen.


Ich habe gerade noch ein paar Bugs gefunden, die den konstanten Offset erklären. Da waren tatsächlich Rechenfehler drin. Der Fix ist schon gepuscht.

Das hat auch noch mal eine deutliche Genauigkeitssteigerung erreicht:

Code: Alles auswählen

Recv: // probe accuracy results: maximum -4.707980, minimum -4.710544, range 0.002564, average -4.709344, median -4.709320, standard deviation 0.000757

[af0815]

Mein aktueller Stand mit blauen Tape:

Recv:12:58:52.539: // FINISHED z = -0.762939
Recv:12:58:52.541: // probe accuracy results: maximum -0.755962, minimum -0.762939, range 0.006977, average -0.760309, median -0.761083, standard deviation 0.002384

[mhier]

Das sieht gut aus! Läuft der Mesh scan so durch? Ich hab da noch Probleme mit evtl zu strengem Qualitätskriterium Im Fit...

[mhier]

So, ich habe noch einen subtilen Bug gefunden: Die Bewegungen ware nicht richtig mit den DMS-Messungen synchronisiert. Mir war nicht klar, dass die tool.manual_move() Befehle nicht sofort ausgeführt werden. Man muss ein tool.wait_moves() einfügen, damit man sicher ist, dass die Bewegung abgeschlossen ist. Deshalb waren die Messungen immer scheinbar etwas hinterher. Ich habe gleichzeitig den Code noch mal etwas vereinfacht und "historisch" gewachsene Strukturen entfernt, die so nicht mehr nötig sind. Alles in allem sollte das jetzt noch mal deutlich robuster geworden sein, allerdings leider auch etwas langsamer. Möglicherweise hat die alte Implementierung auch immer noch einen gewissen systematischen Fehler gehabt eben durch die fehlende Synchronisierung.

[mhier]

Hm, was definitiv noch falsch ist, sind die Parameter vom Original-v2-Hotend Temperatursensor. Ich habe das gerade mal wieder in Betrieb genommen, und die Temperatur stimmt überhaupt nicht - ich brauchte angebliche 350 Grad bis man PLA halbwegs Extrudieren kann.

Das dürfte auch für falsche Bett-Temperaturen sorgen, allerdings bei Weitem nicht so extrem. Je weiter die Temperatur von 25 Grad entfernt ist, desto falscher wird sie. Aber da sie zu niedrig ist, besteht zumindest mal keine Gefahr.

Ich hatte die Parameter aus dem Datenblatt extrahiert, vielleicht habe ich da aber den falschen Sensor-Typ erwischt - das ist leider recht unübersichtlich. Kennt jemand den exakten Typ?

[AtlonXP]

Hallo mhier,
welchen Thermistor das V2 tatsächlich drin hat weiß ich nicht genau.
Es ist in unserer FW der Type Nr.3.

Der Standard Thermistor mit dem Type Nr. 13 ist sehr ähnlich.
Dieser ist ein NTC 100K 3950
So lange du nichts Besseres hast, nimm diesen.
Der ist auch im V3 verbaut.

LG AtlonXP

[mhier]

Hm, dann muss ich wohl aus dem Repetier-Type den Koeffizienten extrahieren. Sollte ja eigentlich auch nicht so schwer sein. Danke dir!

[mhier]

Ok, Typ 3 und 13 sind nicht nur ähnlich, sondern Identisch:

TempSensorsRepetier.png

Allerdings haben angeblich die Typen 13 und 14 beide 100k und ein Beta von 3950, die beiden Typen sind aber nicht identisch. Einer von beiden lügt also...

Nach der Modell-Berechnung (grüne Linie) passt ein Beta von 4150 ganz gut zu unserem Typ (3/13). So richtig perfekt passt das ohnehin nicht, aber auf 1-2 Grad kommt es ja nicht unbedingt an (ggf. muss man seine Druck-Temperaturen leicht anpassen).

Bei dem Repetier-Firlefanz ist ja eh unklar, wo wie Werte herkommen. Nicht unwahrscheinlich, dass die leicht falsch sind oder auf Messungen beruhen, die dann eine Exemplarstreuung drin haben (und nicht dem Mittelwert aller Exemplare entsprechen).