Klipper auf dem RF2000V2

[mhier]

(rel)Position zu DMS-Wert

Deine Messung sieht sehr nicht-linear aus. Da stimmt was nicht. Ich fürchte, du kannst das nicht so einfach nachmessen. Wenn du es manuell überprüfen willst. solltest du bei jeder Messung noch unmittelbar danach eine zweite machen, die bei einer Z-Höhe ohne Bett-Kontakt ist. Dann betrachtest du die Differenz. Alles andere ist viel zu unzuverlässig.

Ist einmal sehr interessant. Das heisst für mich, das nach einer DMS Messung die entsprechende Z-Änderung mitberücksichtigt werden muss. Ich glaube die Community-Version hat sowas.

Wenn man es genau nimmt, wäre das ideal. Aber: Wir können die DMS lediglich mit einer niedrigen Frequenz auslesen (8 Hz bei voller Auflösung). In Realität wird die Kraft sich laufend ändern, denn sie wird Abhängig von der Extruder-Geschwindigkeit sein. Die Genauigkeit ist aber genau dann am wichtigsten, wenn sich die Extruder-Geschwindigkeit ändert: nämlich an Ecken. Mit einer naiven Kompensation würde man da schnell mehr falsch als richtig machen, deswegen bin ich da erstmal skeptisch. Außerdem, welches sichtbare Problem im Ergebnis willst du damit konkret angehen? Ich vermute, der Effekt ist im Ergebnis zu vernachlässigen.

Wenn man es ordentlich machen will, sollte man mit einem adaptiven Modell aus der aktuellen Extruder-Geschwindigkeit die nötige Z-Kompensation berechnen. "Adaptiv" heißt, es werden laufend die Parameter der Umrechnungsformel durch eine DMS-Messung angepasst. Da sich die Parameter aber nicht wirklich ständig ändern, kann man also gut die nötige Z-Korrektur aus der Extruder-Geschwindigkeit ableiten und ist nicht in der Geschwindigkeit dieser Korrektur begrenzt.

[af0815]

Ist einmal sehr interessant. Das heisst für mich, das nach einer DMS Messung die entsprechende Z-Änderung mitberücksichtigt werden muss. Ich glaube die Community-Version hat sowas.

Wenn man es genau nimmt, wäre das ideal.

Ich spreche hier (noch) nicht von einer laufenden Kompensation, sondern nur für die 'statischen' Messungen bei den Scans. Für den Betrieb während des Druckens müsste man sich was anderes überlegen.

Für mich war es einmal interessant zu sehen, um welche Beträge es hier geht. Das das DMS/Weg Diagramm nicht so schön ist, sieht man. Auch wie die Wägezelle schön linear bei Kraft arbeitet und nicht beim Weg. Wenn ich es genauer haben will, so mache ich mir da einen ganz anderen Aufbau, auch mit der Software. Phyton ist nicht wirklich meines und mit Pascal kann ich viel besser, nachdem es mein aktueller Brotberuf ist.

Aktuell bin ich einmal zufrieden und drucke recht gut. PLA, Pet-G und TPU (Flex medium) gehen relativ gut.

[mhier]

Ich spreche hier (noch) nicht von einer laufenden Kompensation, sondern nur für die 'statischen' Messungen bei den Scans.

Achso, also bei der Probe ist das kompensiert (also für den Bed Mesh Scan und den Z-Offset-Scan). Das macht doch einen Großteil der Komplexität der Probe-Implementierung aus. Der misst doch genau aus diesem Grund die Kraft in Abhängigkeit der Z-Koordinate (mit Kompensation durch eine Nullvergleichs-Messung für jeden Messpunkt) und macht einen linearen Fit. Das Scan-Ergebnis definiert sich dann durch den Punkt der Gerade, bei der die Kraft 0 ist. Dort gibt es dann definitionsgemäß keine Auslenkung der DMS.

Für mich war es einmal interessant zu sehen, um welche Beträge es hier geht. Das das DMS/Weg Diagramm nicht so schön ist, sieht man. Auch wie die Wägezelle schön linear bei Kraft arbeitet und nicht beim Weg.

Der Punkt ist mir bisher immer noch ein bisschen ein Rätsel. Es gibt teilweise ganz merkwürdige Effekte. So passen z.B. die Messungen aus unterschiedlichen Richtungen (fahre Z ins negative, anschließend wieder ins positive) teils überhaupt nicht zusammen. Die beste Methode, die ich gefunden habe, diese Probleme loszuwerden, ist die Kompensation mit einer Nullvergleichs-Messung bei jedem Messpunkt. D.h. ich mache für jeden Messpunkt quasi ein "homing" der DMS-Digits, in dem ich einmal ein Stück das Bett runter fahre, so dass sicher kein Kontakt mehr vorhanden ist. Nur dann werden die Messungen halbwegs linear und auch reproduzierbar. Einfach einmal eine Nullmessung zu machen und für alle Messpunkte abzuziehen, reicht halt nicht.

[zero K]

Guten Abend

Ich habe mal wieder versucht mit Klipper klar zu kommen - das ging wieder schief, aber diesmal sehr früh.
Weil mir zwei Thermistorn unterschiedliche Temperaturen anzeigten wollte ich einen PID durchführen.

Könnt Ihr an den Terminalauszügen erkennen in welche Richtung ich suchen muss?

Code: Alles auswählen

 Neustart
 -
Changing monitoring state from "Offline" to "Opening serial connection"
Connecting to port /tmp/printer, baudrate 250000
Changing monitoring state from "Opening serial connection" to "Connecting"
Connected to: Serial<id=0xab1c9a90, open=True>(port='/tmp/printer', baudrate=250000, bytesize=8, parity='N', stopbits=1, timeout=10.0, xonxoff=False, rtscts=False, dsrdtr=False), starting monitor
Send: N0 M110 N0*125
Recv: ok
Send: N0 M110 N0*125
Changing monitoring state from "Connecting" to "Operational"
Recv: ok
Send: N0 M110 N0*125
Recv: ok
Send: N1 M115*39
Recv: ok FIRMWARE_VERSION:v0.9.1-309-g89e8b766-dirty FIRMWARE_NAME:Klipper
Send: M851
Recv: // Unknown command:"M851"
Recv: ok
Send: M105
Recv: ok B:22.5 /0.0 T0:31.8 /0.0 T1:24.5 /0.0
Send: M105
Recv: ok B:22.5 /0.0 T0:31.8 /0.0 T1:24.5 /0.0
Send: M105
Recv: ok B:22.5 /0.0 T0:31.7 /0.0 T1:24.5 /0.0
Send: M105
-
PID für den ersten Extruder über das Menü zum Klipperplugin von Octoprint
-
Recv: B:21.9 /0.0 T0:236.1 /240.0 T1:33.1 /0.0
Recv: B:21.9 /0.0 T0:237.1 /240.0 T1:33.2 /0.0
Recv: // PID parameters: pid_Kp=28.613 pid_Ki=1.372 pid_Kd=149.147
Recv: // The SAVE_CONFIG command will update the printer config file
Recv: // with these parameters and restart the printer.
Recv: ok
Send: Status
Recv: // Klipper state: Ready
Recv: ok
Send: Status
Recv: // Klipper state: Ready
Recv: ok
Send: M105
Recv: ok B:21.9 /0.0 T0:239.6 /0.0 T1:33.3 /0.0
Send: M105
-
Dann ein SAVE_CONFIG
-
Send: M105
Recv: ok B:21.9 /0.0 T0:238.5 /0.0 T1:34.0 /0.0
Send: SAVE_CONFIG
Recv: !! SAVE_CONFIG section 'extruder' option 'control' conflicts with included value
Changing monitoring state from "Operational" to "Error: SAVE_CONFIG section 'extruder' option 'control' conflicts with included value"
Send: M112
Send: N2 M112*35
Send: N3 M104 T0 S0*34
Send: N4 M104 T1 S0*36
Send: N5 M140 S0*96
Changing monitoring state from "Error: SAVE_CONFIG section 'extruder' option 'control' conflicts with included value" to "Offline (Error: SAVE_CONFIG section 'extruder' option 'control' conflicts with included value)"
Connection closed, closing down monitor

Und die Kiste schmiert ab
Ich kann mich per ssh an pi@opi anmelden

meine Printeconfig sieht wie folgt aus

[include Klipper/config/printer-rf2000v2-single.cfg]
[include KlippMacro]
[mcu]
serial: /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A506MX0D-if00-port0

[stepper_x]
step_distance: 0.0065625
position_min: -25
position_endstop: -20
position_max: 200

#[z_endstop_set_calibration]

[stepper_z]
position_endstop: 0
position_max: 202

[extruder]
step_distance: 0.0006155625
nozzle_diameter: 0.400
filament_diameter: 1.75
sensor_type: ATC Semitec 104GT-2
min_extrude_temp: 190
min_temp: 8
max_temp: 280

# ---für den zweiten Extruder------------
[extruder1]
step_pin: PC1
dir_pin: PC3
enable_pin: PC7
step_distance: 0.0006155625
nozzle_diameter: 0.400
filament_diameter: 1.75
heater_pin: PH6
sensor_type: ATC Semitec 104GT-2
sensor_pin: PK6
pullup_resistor: 4700
inline_resistor: 0
min_extrude_temp: 190
min_temp: 8
max_temp: 280


[drv8711 extruder1]
cs_pin: PJ7
spi_software_sclk_pin: PD5
spi_software_miso_pin: PD4
spi_software_mosi_pin: PD6
current: 1.0

[display]
display_group: _default_20x4

[bed_mesh]
horizontal_move_z: 2
mesh_min: 20,10
mesh_max: 200,285
algorithm:bicubic
probe_count: 10,10

[display_data _default_20x4 load_cell_digits]
position: 0, 14
text: { render("_load_cell_digits") }

#*# <---------------------- SAVE_CONFIG ---------------------->
#*# DO NOT EDIT THIS BLOCK OR BELOW. The contents are auto-generated.
#*#
#*# [heater_bed]
#*# control = pid
#*# pid_kp = 52.804
#*# pid_ki = 2.200
#*# pid_kd = 316.825
#*#
#*# [extruder]
#*# pid_kp = 28.493
#*# pid_ki = 1.387
#*# pid_kd = 146.382
#*#
#*# [bed_mesh default]
#*# version = 1
#*# points =
#*# 	-0.162168, -0.146806, -0.150407, -0.130541, -0.135853, -0.133621, -0.146516, -0.134696, -0.107489, -0.065659
#*# 	-0.165811, -0.157882, -0.156531, -0.147890, -0.136273, -0.147455, -0.149407, -0.134954, -0.141917, -0.125392
#*# 	-0.313276, -0.259293, -0.277246, -0.317614, -0.267782, -0.266956, -0.259337, -0.257388, -0.243316, -0.251431
#*# 	-0.334178, -0.321929, -0.327421, -0.369101, -0.309993, -0.273594, -0.253783, -0.262381, -0.267953, -0.252044
#*# 	-0.342343, -0.328415, -0.328639, -0.366887, -0.311734, -0.271329, -0.272628, -0.273632, -0.268220, -0.261528
#*# 	-0.350462, -0.347720, -0.345514, -0.416215, -0.328781, -0.282587, -0.271310, -0.262490, -0.278016, -0.253172
#*# 	-0.338029, -0.333994, -0.337090, -0.357897, -0.340106, -0.347843, -0.331587, -0.338535, -0.325874, -0.331946
#*# 	-0.319679, -0.323017, -0.312758, -0.348264, -0.318559, -0.316225, -0.274871, -0.327490, -0.319178, -0.313350
#*# 	-0.246672, -0.220837, -0.236690, -0.239690, -0.247521, -0.251949, -0.236311, -0.264808, -0.263156, -0.260531
#*# 	-0.167116, -0.167776, -0.206385, -0.224906, -0.203020, -0.165784, -0.177332, -0.225551, -0.230976, -0.234818
#*# tension = 0.2
#*# min_x = 20.0
#*# algo = bicubic
#*# y_count = 10
#*# mesh_y_pps = 2
#*# min_y = 10.0
#*# x_count = 10
#*# max_y = 284.95
#*# mesh_x_pps = 2
#*# max_x = 200.0
#*#
#*# [extruder1]
#*# control = pid
#*# pid_kp = 30.620
#*# pid_ki = 1.701
#*# pid_kd = 137.790

Nur mit dem Netzschalter konnte ich die Kiste wieder starten.

Gruß, zero K

[af0815]

Schau mal in der Klipper/config/printer-rf2000v2-single.cfg nach ob dort nicht schon control=pid drinnen steht (nebst den ganzen pid_* Zeug). Ich habe das mal fälschlicherweise für den ersten Exrruder auch in der 'Basis'-Konfiguration drinnen gehabt.

Wenn dann gehört das in der Basis-Konfigurationsdatei gelöscht, ghört dort nicht hinein. Sollte nur im Save_Config teil auftauchen, nach dem bestimmen der PID Faktoren.

Edit: In der Zeile 105 steht noch "control: pid" drinnen. Lösche das bitte mal raus.

[zero K]

Danke Andreas

control=pid und die darauf folgenden PID-Einträge aus der Basisconfig gelöscht und dann nach dem ersten Extruder in der printer.cfg angefügt.

Die PIDs und deren save_config durchliefen dann ohne Fehlermeldung.

Gruß zero K

[mhier]

Nur mit dem Netzschalter konnte ich die Kiste wieder starten.

RESTART_FIRMWARE sollte immer funktionieren.

[zero K]

Mh - ob es einen Unterschied macht, wenn ich den Button im Klipper-Menü des Plugins in Octoprint klicke oder tatsächlich RESTART_FIRMWARE in der Kommandozeile eingebe, kann ich erst am Wochenende testen.

Gruß, zero K

[zero K]

...
RESTART_FIRMWARE sollte immer funktionieren.

Guten Abend

Sorry, erst jetzt habe ich es mal testen können.

Im Octoprintplugin für Klipper lautet der Befehl hinter dem Button "Firmware" FIRMWARE_RESTART, in der Konsole so eingegeben wird er auch ohne Befund quittiert.

Gruß, zero K

[mhier]

Sorry, ja ich hab's verdreht. FIRMWARE_RESTART ist richtig. Wenn das nichts tut, stimmt was mit deinem Setup nicht. Schau mal ins Log von Klipper. ob der vielleicht Fehler schmeißt. Ich starte immer folgenden Befehl:

Code: Alles auswählen

tail -f /tmp/klippy.log

und lasse den laufen. Dann siehst du permanent das Log in Echtzeit. Führe dann FIRMWARE_RESTART aus und beobachte, was da kommt. Evtl. musst du deutlich hochscrollen, um den eigentlichen Fehler zu finden. Es ist immer der erste Fehler, der entscheidend, es kommen gerne aber noch Folgefehler, die einen nur in die Irre führen!

Um die Stelle wiederzufinden, wo der Output losgeht, der mit FIRMWARE_RESTART zusammenhängt, drücke ich immer ein paar mal Return in dem Terminal, wo der Log-Output zu sehen ist (also der tail Befehl läuft). Dadurch entstehen Leerzeilen, die man beim zurückscrollen dann leicht wiederfinden kann (einfach so oft Return drücken, bis ein ganzer Bildschirm frei ist - das ist leicht zu finden). Wichtig ist auch, dass man das Terminal so konfiguriert, dass es einem ausreichend viele Zeilen im Scrollback-Puffer anzeigt. Wie das geht, hängt davon ab, welches Terminal du benutzt. (Evtl Putty, wenn du dich von Windows aus auf dem RasPi einloggst, Putty benutze ich nicht und kann dir daher damit nicht helfen, weil ich hab ja kein Windows )

Dann von dort aus wieder runterscrollen, bis ein Fehler (z.B. Python Crash) auftritt.