Klipper mit dem RF1000

[mhier]

TeamSpeak ist ja schön und gut, interessanter wären Konfigurations-Dateien o.ä.

[AtlonXP]

Hallo zusammen,
leider muss ich die Hoffnungen hier etwas trüben.

Zenox und Timo waren seit Juni /Juli nicht mehr hier.

Ein weiteres Manko unserer Boards ist, dass unsere Stepper sehr rau laufen.
Zenox hat hier ein paar vielversprechende Versuche gemacht.

viewtopic.php?p=26999#p26999

Später hat er jedoch das gemodete Bord hier zum Verkauf angeboten.
viewtopic.php?p=29453#p29453


Ich habe keine Ahnung wie weit das Ganze gereift war.

Ein Problem könnte ich mir vorstellen,
dass die TCM Treiber nicht genügend Strom für unsere RFX000 Kisten zur Verfügung stellen können.

Bei uns sind die MOSFET separat auf der Platine verlötet.
Ich glaube man nennt dies H- Schaltung.

Haben wir nicht auch noch einen Zusätzlichen ROM Speicher auf der Platine?
Im Schaltplan ist davon jedoch nichts zu finden.

Auf der Clipper Seite hatte ich ein paar originale Konfiguration Dateien gesehen.
Weiter kann ich leider nicht helfen.

LG AtlonXP

[mhier]

Ein weiteres Manko unserer Boards ist, dass unsere Stepper sehr rau laufen.

Mit Klipper, odere generell? Ich denke ja, dass die Repetier-Firmware da einen recht großen Anteil dran hat. Die Steps kommen einfach nicht zur richtigen Zeit, vor allem an den Übergängen zwischen den Bewegungen nicht. Außerdem ist die Firmware recht fundamental auf eine für meine Zwecke (Kugelumlaufspindel auf X/Y) zu niedrige Stepfrequenz beschränkt, weil es dann Überläufe bei den Berechnungen gibt (und die Berechnungen sind aus Geschwindigkeitsgründen in Assembler und mit Tabellen - sehr häßliche und schwer verständliche Sache, zumal mir die Berechnungsformel nicht überall klar ist).

Zenox hat hier ein paar vielversprechende Versuche gemacht.
viewtopic.php?p=26999#p26999

Ich bin mir nicht sicher, ob die TCM Treiber überhaupt besser sind. Die Beschreibung ließt sich zwar ganz toll, weil sie mit zahllosen Trademarks um sich werfen, dahinter stecken aber vermutlich auch nur relativ einfache Features, die unser DRV8711 zumindest zT. auch kann. Ich finde in dem Thread leider auch keinen Bericht, ob die ganze Aktion was gebracht hat (und nehme daher eher an, dass nicht).

Haben wir nicht auch noch einen Zusätzlichen ROM Speicher auf der Platine?
Im Schaltplan ist davon jedoch nichts zu finden.

Wir habe ein EEPROM, in dem z.B. die HBS-Matrizen abgelegt werden. Das findet sich auch im Schaltplan vom RF1000 (erste Seite genau mittig). Das wäre mit Klipper dann einfach unbenutzt, denn die MCU-Firmware ist dann relativ dumm und die komplette Intelligenz steckt im Host (Rasberry Pi oder was auch immer).

Ich erhoffe mir von Klipper eine bessere Berechnung der Bewegungen und damit ein ruhigeres Laufen der Motoren. Mit meinem Kugelumlaufspindel-Mod (bisher nur X-Achse) habe ich nämlich leider das Problem, dass bestimmter G-Code zum Stall des Motors führt (also Stillstand für einen Bewegungsabschnitt). Ich vermute, das ist eine Kombination aus Resonanzen/Schwingungen und unsauberer Ansteuerung der Motoren. Bei dem extrem weich gekoppelten Zahnriemenantrieb fällt das schlicht nicht auf, weil da der X-Schlitten dann nicht unbedingt exakt die Bewegung des Motors mitmachen muss (und umgekehrt). Dann wird der Druck nur unsauber, aber der Motor bleibt nicht stehen (was den Druck natürlich gleich ganz versaut).

Ich habe einen Bug in der Firmware in der Richtung schon beseitigt. Die Z-Kompensation hat unter bestimmten Bedingungen zu einem gewissen Stillstand in X/Y zwischen zwei Bewegungs-Teilstücken geführt. Das verletzt dann ggf. die eingestellte Beschleunigung und/oder den Jerk. Der Stillstand war kurz genug, dass er wohl mit den Zahnriemen nicht auffällt (und für einen Beobachter ohnehin nicht sichbar ist), aber ein starr gekoppelter Motor mag das nicht.

Inzwischen habe ich mir einen deutlich stärkeren NEMA23 Motor besorgt, das hilft leider auch nicht wirklich. Mein letzter Strohhalm ist gerade, mit dem NEMA23 und extrem langsamen Beschleunigungen und Geschwindigkeiten das noch mal zu testen. Ich fürchte aber, mit der Repetier-Firmware komm ich da nicht wirklich weiter...

Mich nervt aber ohnehin, wie schlecht die Code-Qualität in der RF1000-Repetier-Firmware ist. Das bremst mich doch erheblich aus, da weitere Ideen auszuprobieren. Hinzu kommt, dass einem bei jedem Versuch die Zähne lang werden, weil man ja immer erst den MCU programmieren muss. Da wäre Klipper doch sehr viel entwicklungs-freundlicher, da alles in Python (na gut, da kann man auch drüber streiten) vorliegt, deutlich besser strukturiert ist und einfach direkt editiert werden kann.

[AtlonXP]

Hallo mhier,
ich bastele gerade an einem TronXY SA 500 Pro rum.
Es ist so ein richtiger Reiskocher, der nicht kochen kann!

Es wird noch eine Ewigkeit dauern bis das Ding richtig läuft.
Auch muss noch einiges reingesteckt werden.

Was aber an dem Ding positiv auffällt:
ARM 32 Bit Prozessor verbaut.
TMC 2209 Driver verbaut.
Die Motoren laufen so leise, man hört diese nicht!
Vermutlich wird die Kraft (Leistung) für Fräszwecke zu gering sein.

Ich muss hier die Frage in den Raum stellen:
Wäre ein aktuelles Board mit Modifikationen für unsere RF Klasse nicht die besser Lösung?

Ich weiß der Programmieraufwand ist beträchtlich.
Aber das Ergebnis wäre Zukunftssicher.

LG AtlonXP

[af0815]

Ich lese den Thread interessiert mit. Ich arbeite tagtäglich mit RasPi und Programmierung.

Für mich stellt sich eine Frage generell - wie soll der Mega aka MCU mit dem RasPi effizient bidirektional kommunizieren ? Die serielle USB Emulation möge für GCode ausreichen, aber für das diskutierte, inklusive DMS und anderer Parameter, da habe ich meine Zweifel.

Das geht doch nur mit einem spezialisierten Board.

[mhier]

Wäre ein aktuelles Board mit Modifikationen für unsere RF Klasse nicht die besser Lösung?

Ja da habe ich durchaus drüber nachgedacht. Allerdings ist auch das nicht so einfach: Ich möchte die DMS nicht verlieren, d.h. ein neues Board müsste entweder ein eigenes Design (bzw. modifiziertes Design eines open source Boards) sein, oder das Board müsste erweiterbar sein, so dass man den Teil dort anschließen kann. Das ist aber noch der einfachere Teil. Wenn man hardwaremäßig in der Lage ist, die DMS auszulesen, muss die Firmware das auch noch können. Die Situation ist dann am Ende wieder nicht unbedingt viel besser als aktuell: ich müsste eine Menge Features im MCU-Code nachpflegen, die Firmware muss dafür open source sein, und ich muss mich erstmal mühsam einarbeiten. Mit Klipper geht das alles viel schneller, zumal dort auch schon eine Menge der nötigen Features in ausreichend modularer und flexibler Form vorhanden ist, so dass man die ohne häßliche Hacks nutzen kann.

Für mich stellt sich eine Frage generell - wie soll der Mega aka MCU mit dem RasPi effizient bidirektional kommunizieren ? Die serielle USB Emulation möge für GCode ausreichen, aber für das diskutierte, inklusive DMS und anderer Parameter, da habe ich meine Zweifel.

Da ist viel Entwicklungsarbeit in Klipper reingegangen. Das Problem ist im Prinzip gelöst, zumindest erstmal ohne DMS. Die Kommunikation erfolgt mit einem speziellen Binärprotokoll, in dem z.B. die Anzahl und Frequenz der Schritte eines Steppers zu einem bestimmten Zeitpunkt übertragen wird. Auch werden die Uhren exakt synchronisiert, um Probleme durch Drifts der Uhren zu vermeiden. Auf der Webseite ist ein Benchmark veröffentlicht mit der maximal möglichen Schrittfrequenz (https://www.klipper3d.org/Features.html ganz unten). Wir haben einen 16MHz AVR, damit sollten demnach 100000 Schritte pro Sekunde auf 3 Achsen gleichzeitig möglich sein. Bei Repetier ist deutlich früher Schluss, schon alleine weil 16 Bit Berechnungen benutzt werden und dann spätestens bei 65000 ein Überauf passiert - aber lange vorher schon passieren unsaubere Dinge. (Ganz zu schweigen davon, dass selbst langsame Bewegungen nicht korrekt berechnet werden, das ist aktuell mein Hauptproblem).

Klipper benutzt physikalisch korrekte Berechnungen für die Bewegungen, das dürfte bei den meisten (wenn nicht allen) anderen Firmwares nicht der Fall sein. Es gibt haufenweise Features, die einem Helfen, dass die Bewegungen korrekt und schnell ausgeführt werden können, bis hin zu einer Unterdrückung von Resonanzen.

Für mich sieht das erstmal ziemlich beeindruckend aus, dass ich es auf jeden Fall probieren werden. Erster Schritt wird sein, die Stepper-Motoren ans laufen zu bringen und dann meinen Test-Gcode auszuführen, bei dem ich die aktuellen Probleme sehe. Dazu brauche ich erstmal keine DMS, nicht mal die Heizungen. Wenn das klappt, schau ich mal weiter.

[AtlonXP]

Danke mhier für deine ausgiebige Antwort.

Wenn du von MCU schreibst, da weiß ich nicht genau was da gemeint ist.
Ist das die Hauptschleifen in unserer Firmware?

Ich würde dich gerne unterstützen bei deiner Arbeit.
Programmieren kann ich leider nicht.

In der Elektronik kenne ich mich ein wenig aus.
Auch kann ich dir Hilfe als Beta Tester anbieten.
Ich glaube, dass war es aber dann schon…

Was ich mir wünsche bevor du anfängst:
Kannst du vorher noch nach dem HBS schauen?

Was ich mir wünsche, wenn du soweit bist:
Eine Riemenschlupf Kompensation und ein ruhiger lauf der Motoren und und und…

LG AtlonXP

[af0815]

MCU ist grob skizziert das aktuelle Board, das unter Klipper genaugenommen nur noch die Berechnungen von Klipper umsetzt.

[mhier]

MCU = Micro Controller Unit = unsere ATMega CPU

Klipper hat schon einen HBS integriert. Nennt sich dort Mesh Bed Leveling. Das erlaubt sogar ganz ohne Sensor ein Mesh Bed Leveling, bei dem man dann von Hand an mehreren Rasterpunkten mit einem Blatt Papier die Z-Höhe ausmisst. Ist dann tierisch umständlich bestimmt, aber für erste Tests wird es reichen. Es werden schon alle möglichen Sensoren unterstützt für automatische Scans, deswegen gehe ich davon aus, dass es nicht sonderlich schwierig sein wird, unsere DMS zu integrieren. Vorzugsweise kriege ich das sogar in die offizielle Version integriert, dann hat man es leichter mit Updates auf die neueste Version.

Selbst wenn die aktuelle Mesh Bed Leveling Prozedur aus irgendwelchen Gründen nicht geeignet ist, oder wenn wir unsere weiteren Features aus der Community-Firmware portieren wollen: Es ist relativ einfach, mit Python Modulen neue G-Code-Befehle zu erstellen. Ich sehe da überhaupt kein Problem. Natürlich wird das eine Weile dauern, aber erstmal müssen ja auch die Grundfunktionen funktionieren

[AtlonXP]

Danke für die Aufklärung.

@mhier,
bitte vorher noch den HBS Fehler in unserer Community FW beheben.
Für mich ist der Sau störend.

Es würde mich freuen.

LG AtlonXP