@mhier Ich werde mir das mit Github ansehen. Account und so habe ich, aber code development ist nicht mein Hauptberuf, werde mich da mal einarbeiten.

Juifen hat geschrieben:Jetzt bin ich bei dir. Du beziehst dich auf die src/spicmds.c

Ganz genau. Seit ein paar Minuten hat sich das allerdings erübrigt. Der temporäre Commit existiert nicht mehr, stattdessen ist das jetzt sauber gelöst. Siehe der andere Klipper-Thread. Bitte testen!

Frage: ist es immer noch ein Ziel die load_cell (DMS) Änderungen in Klipper standard zu mergen?

Ja. Allerdings will ich jetzt doch erstmal die Reihenfolge ändern und die einfachen Änderungen wie invertiertes SPI und die Unterstützung der Stepper-Treiber einbringen. Das geht vielleicht etwas zügiger. War vielleicht nicht so schlau, mit diesem dicken Feature zu starten mehr oder weniger...

OConner ist eine SPI Lösung nicht abgeneigt. Geht vielleicht wirklich schneller.

af0815 hat geschrieben:OConner ist eine SPI Lösung nicht abgeneigt. Geht vielleicht wirklich schneller.

Er ist gar nicht abgeneigt. Mein Pull Request, der da seit ein paar Monaten rumsteht, ist einfach ziemlich groß und für jemanden, der keine Erfahrungen mit DMS in 3D-Druckern hat, schwer zu durchschauen. Ich habe immer damit gerechnet, dass das nicht einfach so durch geht. Vielleicht hätte ich mir gewünscht, dass es wenigstens eine Diskussion gibt, aber natürlich priorisieren die Entwickler auch danach, was die Klipper-Community am dringensten braucht. Tatsächlich sind in letzter Zeit viele Pull Requests aufgelaufen, weil Kevin da alleine nicht hinterher gekommen ist. Jetzt gibt es mehrere Maintainer und Reviewer und ein neues Verfahren - das aber erst seit ein paar Wochen. Ich werde beizeiten mal schauen, ob ich den Prozess noch etwas in Schwung bringen kann, denn es ist explizit erlaubt, dass auch nicht gelistete Reviewer mithelfen, sogar auch bei den eigenen Tickets. Letzteres geht natürlich nur in Grenzen, irgend jemand muss schon noch mal über den Code schauen und ihn verstehen.

@mhier Ich habe am WE das alles mal auf einem frischen Raspi aufgesetzt mit eigenem fork in github. Funktioniert alles soweit.
Ich musste nur in der cfg ein paar Einstellungen hinzufügen das Fehlermeldungen kamen.

Die RF1000.cfg wie sie im repo ist, läuft die so bei dir? Ich konnte bei extruder die rotation_distance nicht finden, und ohne die startet es bei mir nicht. Ich habe dann die Formel aus der Klipper doku genommen und es mit der vorhanden step_distance umgerechnet.
Ist das so richtig? Ich hab über die Stepper keine Details zum Datenblatt gefunden und einfach einen Nema17 angenommen.
Wo findet man für die RFx0000 serie denn genaue Werte? Ich hab was aus dem Conrad Slicer, Community usw.
Manche Werte passen zusammen, andere sind überall unterschiedlich.


[printer]
kinematics: cartesian
max_velocity: 200
max_accel: 1500
max_z_velocity: 50
max_z_accel: 70

Im Conrad Repetier und Slicer stehen ganz andere werte drin. Auch wenn man die mm/min auf Sekunden umrechnet.

Danke nochmal fürs Repo update, ich probiere dann noch den RP2040

Juifen hat geschrieben:Ich konnte bei extruder die rotation_distance nicht finden, und ohne die startet es bei mir nicht.

Ach mist. Sorry. Ich hatte nur im Fräsmodus getestet, da gibt's keinen Extruder
Das kann man übrigens weglassen, 200 ist standard und korrekt für unsere Stepper (wie für fast alle, es gibt noch welche mit 400).

Deine Zahl stimmt nicht ganz. Wir haben 8.75mm pro Vollschritt und 200 Vollschritte pro Umdrehung. Das ergibt ca. 22.86 mm pro Umdrehung, nicht 25. Ich habe die Config-Dateien im Repo gerade entsprechend korrigiert.

Wo findet man für die RFx0000 serie denn genaue Werte?

Ich kenne nur diesen Wert. 8.75 Vollschritte/mm kommen aus dem Durchmesser des Ritzels und den 200 Vollschritte pro Umdrehung. Der "neue" Wert 22.86mm/Umdrehung ist identisch (200/8.75 = 22.86), hängt allerdings nur vom Durchmesser des Ritzels ab und ist somit "fundamentaler" (daher auch diese Änderung Klipper). Einige Leute kalibrieren sich den Extruder noch mit einer eigenen Messung, dann steht dort natürlich eine ganz krumme Zahl. Ich habe das bei meinem Exemplar nie für nötig erachtet, vielleicht gibt es aber eine Serienstreuung beim Ritzel?

[printer]
kinematics: cartesian
max_velocity: 200
max_accel: 1500
max_z_velocity: 50
max_z_accel: 70

Im Conrad Repetier und Slicer stehen ganz andere werte drin. Auch wenn man die mm/min auf Sekunden umrechnet.

Mit Klipper lassen sich prinzipiell höhere Geschwindigkeiten fahren, ohne dass es gewisse Probleme gibt. Deshalb ist max_velocity 200 statt 150. In der Praxis spielt das aber eigentlich eh keine Rolle, da die Geschwindigkeiten gar nicht erreicht werden. Die Beschleunigung von 1500 ist gleich.

Martin, die 8,75 sind für den RF1000 denke ich.
Diese Werte unten hab ich aus der alten RF2000 Konfiguration übernommen

8.00 steps per mm, 32 microsteps: 1/(8.0*32)
step_distance: 0.00390625

Diese Formel ist aus der Klipper Doku.
rotation_distance = <full_steps_per_rotation> * <microsteps> * <step_distance>

rotation_distance = 200 * 32 * 0.00390625
rotation_distance = 20

Da kommt auch glatt die 20 raus. 8,00 vs 8,75steps per mm sind einfach RF2000 vs. RF1000

Ich werde auch mal Extruder Kalibrierung machen, mal sehen wo ich lande von den Werten.

Guten Abend

Ich weiß nicht, in wie weit es tragisch ist, in

klipper/config/printer-rf2000v2-single.cfg

ist konfiguriert,

[display]
lcd_type: hd44780
rs_pin: PK1
e_pin: PK3
d4_pin: PF5
d5_pin: PK2
d6_pin: PA1
d7_pin: PJ3
display_group: _default_16x4

"LCD Type" kann ich so nicht erkennen,
Ein Klebchen zeigt folgendes, Die Matrix an meinem RF 2000 v2 besteht aus 4 Zeilen mit je 20 Stellen,
möglicherweise muss es etwa wie "display_group: _default_20x4" lauten.

Gruß, zero K

Für mich zeigt das Display was vernünftiges an. Ob da vielleicht 4 Zeichen pro Zeile zu wenig waren/sind kann ich jetzt nicht festellen.

So nebenbei, habe ich für die SIngle Config am RF2000V2 verbrochen Und drucke damit seit langer Zeit.