Achso, naja ich weiß nicht ob ich das unterbringe im Moment... Hab eher wenig Zeit und im Moment keinen funktionierenden Drucker - das würde ich gerne möglichst schnell ändern....

So, also ich kann schon mal alle drei Achsen mit der Klipper-Firmware bewegen. Die Motoren laufen *sehr* viel ruhiger als mit Repetier. Mein Test-GCode, der mit Repetier zu Schrittverlusten/Stillständen geführt hat, läuft jetzt ohne Probleme durch. Ich bin mir noch nicht 100%ig sicher, ob ich mit dem gleichen Motor-Strom arbeite - ich werde nacher mal die Kraft, die nötig ist, um das Heizbett an der Bewegung zu hindern, händisch grob vergleichen zwischen den beiden Firmwares (die Y-Achse ist bei mir noch mit Zahnriemen angetrieben, die X-Achse mit der Spindel kann ich nicht mehr so leicht anhalten ). Ein niedrigerer Strom könnte die sehr viel leiseren Motoren erklären, allerdings würde ich dann auch eher Schrittverluste erwarten...

Der Motor-Strom scheint in der Größenordnung zu passen. Beim direkten Vergleich ist mir auch aufgefallen, dass die Motoren nicht leiser sind, z.T. sogar lauter. Das Geräusch ist aber deutlich anders, vor allem auf den Achsen mit Kugelumlaufspindeln: Das Geräusch ist viel mehr dem Motor selbst zuzuordnen und weniger der Mechanik. Meine X-Achse rasselt mit der Repetier-Firmware geradezu, während mit Kipper selbst sehr viel höhere Geschwindigkeiten einen deutlich ruhigeren Eindruck machen. Das hörbare Geräusch ist eben mehr das Piepen der Schritt-Frequenz, das ist mit der Repetier-Firmware nicht so ausgeprägt. Ich vermute, das liegt daran, dass die Frequenz jetzt viel besser gehalten wird. Klipper produziert einen klaren Ton, während Repetier mehr ein Rauschen produziert.

Ich habe die Klipper Firmware mal in unsere Github-Organisation geklont:
https://github.com/RF1000community/klipper

Achtung: Die Konfiguration ist zum Einen noch nicht gut getestet, zum anderen auf das E3Dv6 Hotend eingestellt!

Es geht schon eine ganze Menge: Alle Motoren, Endschalter (bis auf Z-Max), Heizungen, Temperatur-Sensoren und Lüfter (einschließlich dem E3Dv6 Lüfter, der an X19 hängt bei mir) funktionieren wie erwartet. Damit könnte man vermutlich schon theoretisch drucken. Ich werde als nächstes versuchen, ein manuelles Bed Leveling durchzuführen, um zu sehen, ob man damit auch wirklich drucken kann. Wenn das klappt, nehme ich mir die Wägezellen vor.

Die Software-Entwicklungszeit ist erheblich kürzer als mit der Repetier-Firmware. Ich denke, dass ich da in relativ kurzer Zeit (ein paar Wochen) was Benutzbares hinbekomme. Kritischer Punkt ist aber noch, wie schnell ich die Wägezellen auslesen kann während der Bewegung. Das dürfte aber vor allem für Features problematisch sein, die ein permanentes und schnelles Auslesen brauchen wie z.B. den Emergency Pause oder Emergency Stop. Das ist vielleicht nicht umsetzbar, aber m.E. ist das auch nicht so wichtig (andere 3D-Drucker kommen auch ohne aus).

Interessant, wie ist bei dir die Konfiguration ?

Ist es so geblieben wie im ersten Post ?

RasPi: Octoprint (Standardversion) + Klipper (Siehe dein Link zum Github)
RF1000: Spezielle Software als Interface zu Klipper

Beides über USB-Verbunden.

Ja genau, genau wie Klipper das im Original vorsieht. Die Firmware auf dem RF1000 Mainboard ist auch die von Klipper. Die ist eben nicht speziell für den RF1000, ich musste lediglich (wie im ersten Post des Threads beschrieben) das Chip Select Signal für die SPI-Kommunikation invertieren (allerdings noch an zwei weiteren Stellen). Das werde ich noch so weit verallgemeinern, dass es als Option über die Klipper-Konfiguration zur Verfügung steht, damit es in Klipper integriert werden kann. Ich möchte ja auf Dauer eben keinen eigenen Fork haben, sondern alle nötigen Änderungen als Beitrag in Klipper integrieren.

Du scheinst die USB/Serielle-Verbindung als kritisch anzusehen. Ich glaube nicht, dass das der Fall ist. Klipper ist um genau diese Kommunikation herum gestrickt, selbst sehr viel schnellere Microcontroller als unser 8-Bit-AVR (wir haben den langsamsten von Klipper unterstützten Kontroller!) werden über eine Serielle-Schnittstelle angebunden. Da schnellere Microcontroller sehr viel höhere Step-Frequenzen mit Klipper schaffen, düfte eher der Micocontroller die Performance begrenzen. Aber der Trick ist ja eben, dass zeitaufwändige Berechnungen auf dem Raspberry Pi stattfinden, damit wird der Micocontroller ja entlastet. Ich bekomme jedenfalls ein Vielfaches der Step-Frequenz gegenüber Repetier hin! 150mm/s sind auf meiner X-Achse mit Kugelumlaufspindel problemlos möglich bei 32 Microsteps, das sind 96000 Steps/Sekunde. Und das bei physikalisch korrekten Berechnungen statt des Bresenham-Algorithmus (der eigentlich für Pixel-Grafik gedacht ist).

Achja: Klipper hat eine größere Entwickler-Community als Repetier und sieht für mich ausgereifter aus. Klipper ist längst nicht mehr ein gewagtes Experiment sondern durchaus Alltagstauglich.

Wegen serieller Schnittstelle. Auf Raspi Seite haben vor kurzen ein paar Gelehrte versuche gemacht ob es noch mit 2Mbit geht oder doch nur 1.2Mbit. Ergebnis war von Radio Eriwan - im Prinzip ja. Nur 1.2 war da ausreichend stabil/möglich, soweit ich die Diskussion im Kopfe habe.

Ok, Klipper flashed also gleich den Mega richtig. Das heisst zurück, kann ich jederzeit in dem ich wieder die Communityversion flashe.

af0815 hat geschrieben:Wegen serieller Schnittstelle. Auf Raspi Seite haben vor kurzen ein paar Gelehrte versuche gemacht ob es noch mit 2Mbit geht oder doch nur 1.2Mbit. Ergebnis war von Radio Eriwan - im Prinzip ja. Nur 1.2 war da ausreichend stabil/möglich, soweit ich die Diskussion im Kopfe habe.

Nee 1 Mbit schafft man nicht, das geht nur mit SPI, also eine synchrone serielle Schnittstelle mit Taktsignal. Wir haben hier nur einen asynchronen UART ohne Takt. Da gehen max. 250kbaud. Reicht aber auch, weil es wird eben nicht jeder Step einzeln übertragen. Stattdessen haben die Macher von Klipper sich ein schlaues Protokoll überlegt, mit dem der Host-Teil der Firmware dem Microcontroller-Teil mitteilt, wann wie viele Steps mit welcher Frequenz er ausführen soll. Mit einem seriellen Befehl werden also gleich viele Steps definiert. Sonst wäre das natürlich chancenlos.

af0815 hat geschrieben:Ok, Klipper flashed also gleich den Mega richtig. Das heisst zurück, kann ich jederzeit in dem ich wieder die Communityversion flashe.

Man kann jederzeit hin und her wechseln, ist nicht wirklich mehr Aufwand, als die Repetier-Firmware upzudaten. Hinzu kommt nur noch, dass man den Host-Teil der Klipper-Firmware stoppen muss, damit der Port wieder frei wird, und OctoPrint auf den echten seriellen Port wieder umstellen muss. Das ist aber beides schnell erledigt. Da muss man wirklich keine Angst haben. Offensichtlich bleiben sogar die Repetier-Einstellungen im EEPROM erhalten, weil Klipper das nicht nutzt!

mhier hat geschrieben:Stattdessen haben die Macher von Klipper sich ein schlaues Protokoll überlegt, mit dem der Host-Teil der Firmware dem Microcontroller-Teil mitteilt, wann wie viele Steps mit welcher Frequenz er ausführen soll. Mit einem seriellen Befehl werden also gleich viele Steps definiert. Sonst wäre das natürlich chancenlos.

Die Grundlagen zu dem Protokoll, so wie es aussieht sind mir nicht ganz neu. Beckhoff hat das schon seit Jahrzehnten um Hochgeschwindigkeitsklenmmen mit den Wegen der Vielachsen-Bahnsteuerungen synchron zu halten. Damit konnten wir die Zeitpunkte der Bewegungen exakt mit den externen Schweiß Generatoren synchronisieren. Dort habe ich das erste mal mit vielen Achsen und G-Codes Bekanntschaft gemacht und mich am Anfang gewundert warum das trotzdem bei (fast) jeder Geschwindigkeit synchron wurde.

Was Beckhoff etc. vor Jahrzehnten entwickelt haben, gibt's dann irgendwann auch open source Früher oder später findet sich jemand, der so eine Idee umsetzt. Die Grundlagen dafür sind ja auch kein Geheimnis.

Ich habe jetzt den ersten Druck mit Klipper gemacht. Als Modell habe ich jenes genommen, welches ich mit Repetier nicht drucken konnte, weil der X-Achsen-Motor (Kugelumlaufspindel!) stehenbleibt und ich dann einen Versatz im Ergebnis habe, der das Teil unbrauchbar macht. Interessanterweise habe ich mit Klipper an exakt der selben Stelle wieder exakt den selben Versatz. :-/

Aber: immerhin kann ich mit sehr viel höherer Geschwindigkeit drucken, bei Repetier musste ich die Beschleunigung arg reduzieren, um mit dem Jerk weitgenug runterzukommen, dass ich nicht viel häufiger Motor-Stalls bekomme. Klipper hat eine Jerk-Ähnliche Einstellung (= Mindestgeschwindigkeit), die allerdings rein aus Geschwindigkeitsgründen existiert (Repetier braucht das auch zur nummerischen Stabilität der Berechnungen). Evtl. muss ich die auch bei Klipper runterstellen.

Erstmal muss ich aber jetzt aus dem Modell den problematischen G-Code extrahieren, sonst hab ich hier nachher zig unbrauchbare Plastikteile rumstehen

Ich kapier's nicht. Das Problem ist absolut reproduzierbar, wenn ich richtig drucke. Wenn ich den selben G-Code (ungefär +- 10 Layer um den Versatz herum aus dem G-Code herausgeschnitten) ohne zu drucken ausführe, gibt es keinen Versatz. Das ist doch irgendwie absurd langsam...

Aber immerhin sehe ich, dass die Kanten und Oberflächen mit Klipper deutlich besser werden. Ich denke, es lohnt sich so oder so auf Klipper umzusteigen!