AtlonXP hat geschrieben: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).
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).
AtlonXP hat geschrieben:
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.
