Hallo,

ich melde mich im Forum auch mal wieder:

@mhier:
Ich habe hier vor ein paar Tagen mal reingesehen und finde das sehr interessant, dass du mit Klipper die Motortreiber des RFX000 zum Laufen gebracht hast.

Hatte Klipper vor längerer Zeit in einem RepRap benutzt und war eigentlich ganz zufrieden damit. Jetzt hab' ich das heute auch auf meinem RF1000 probiert und dazu deinen Fork installiert:
Als Host-Computer dient ein Intel-NUC + Ubuntu. (Bin kein so ein Freund mehr von diesen Raspberrys, etc...)

Der erste Druck ist auch schon geglückt. Ich muß sagen der Drucker läuft eine ganze Ecke ruhiger. Mit nur 1000 mm/s² Acceleration und 15 Jerk hat der Tisch unter Repetier bei 150 mm/s Travel ordentlich gewackelt.
Jetzt druckt meine Kiste bei 1500 mm/s² Accel auch ohne Probleme. Höher habe ich es jetzt noch nicht eingestellt.
Wirklich leiser ist der Drucker - finde ich - nicht geworden.

Mußte das Bett für den Druck erst manuell ausrichten und den Auslöser der Z-Lichtschranke nachjustieren.
Mit SET_GCODE_OFFSET dann in Klipper noch Z fein nachstellen.

(Hab' mit Klipper noch eine Idee für eine Verbesserung am RF1000 und schreibe dazu vielleicht noch einen Beitrag.)

Grüße,
anwofis

Ja ich hab auch erstmal einfach ein recht kleines Objekt gedruckt und nur per Schraube justiert, so dass z=0 direkt auf dem Heizbett ist. Mit der relativ ebenen Dauerdruckplatze geht das ganz gut.

Mein Problem mit dem Versatz ist immer noch da. So langsam glaube ich nicht mehr an einen Motor-Stall. Ich habe mir eine Position am X-Schlitten markiert bei x=150. Wenn ich den Druck unmittelbar nachdem der Versatz auftritt unterbreche und nach x=150 fahre (per Gcode), dann stimmt die Markierung überein. Der Versatz ist exakt 1mm, und das kann ich locker sehen mit der Markierung. Der Drucker kennt also noch die Position korrekt, druckt aber trotzdem versetzt. Ich habe dann gehomed in X und weiter gedruckt, dann ist der Versatz wieder weg.

Ich kapier echt nicht, was da passiert. Es kann nicht an Klipper liegen, mit Repetier war das auch.

Tritt der Versatz auch auf, wenn das Objekt mit 150% Grösse gedruckt wird ? Ist der Versatz dann weg, kleiner oder grösser ?

Hallo mhier.

Ich hoffe doch du slicst nicht mit CraftWare?
Wenn ja, dann würde ich einen anderen Slicer probieren.

LG AtlonXP

af0815 hat geschrieben:Tritt der Versatz auch auf, wenn das Objekt mit 150% Grösse gedruckt wird ? Ist der Versatz dann weg, kleiner oder grösser ?

Das habe ich noch nicht probiert. Meinst du, im Slicer skalieren oder erst beim Ausdruck in der Firmware?

AtlonXP hat geschrieben:Ich hoffe doch du slicst nicht mit CraftWare?

Nein, Cura.

Ich glaub ich versteh das Problem so langsam. Mein Hotend (E3Dv6) ist nicht ganz fest in seiner Halterung. Es kann etwas verkippen, so dass die Düse in X-Richtung sich recht genau um 1mm bewegt. Wenn ich die X-Achse home, stößt der Heizblock (bzw. die Silikonsocke) an die Alu-X-Platte an, wodurch das Hotend wieder in die Original-Stellung gedrückt wird. Vermutlich bleibt die Düse an etwas hochstehendem Material hängen und verkippt damit das Hotend. Da kann ich natürlich Motoren austauschen und die Beschleunigung runterstellen wie ich will, das ändert nichts. Mich wundert nur, wie reproduzierbar das passiert. Ob meine Theorie stimmt, müsste ich ja leicht feststellen, wenn ich das Hotend richtig festmache...

mhier hat geschrieben:

af0815 hat geschrieben:Tritt der Versatz auch auf, wenn das Objekt mit 150% Grösse gedruckt wird ? Ist der Versatz dann weg, kleiner oder grösser ?

Das habe ich noch nicht probiert. Meinst du, im Slicer skalieren oder erst beim Ausdruck in der Firmware?

In der Firmware wenn möglich. Skaliert der Fehler entsprechend mit, so muss man weiter vorne nochmals suchen.

----
Wenn das mit dem kippen stimmen würde, dann wäre auch erklärt, warum die Markierung auf der Achse gestimmt hat und nach dem Homen alles wieder Ok war.
Wäre ein saublöder Effekt.

Jupp. Mal zurück zum eigentlichen Thema: Ich habe den Klipper-Fork gerade geupdated. Die Stepper sind jetzt besser und einzeln konfigurierbar (Strom, Microsteps).

Außerdem kann ich die Dehnungsmessstreifen schon auslesen und zum Testen mit 8 Hz ins Log schreiben. Mir ist dabei aufgefallen, dass wir zumindest in der Community-Firmware (vielleicht sogar im Conrad-Original) gar nicht beachtet haben, dass der ADC nur 8 Samples pro Sekunde auslesen kann, wenn er mit 16 Bit betrieben wird. Das ist eine so niedrige Frequenz, dass es überhaupt kein Problem ist, die kontinuierlich auszulesen. Damit sollten sich im Prinzip alle Features realisieren lassen, selbst ein Emergency Stop (der ja auch im Original dann offensichtlich mit bis zu 125 ms Verzögerung reagiert).

Nächster Schritt ist dann ein Probe-Modul zu schreiben, dass einen Punkt des Mesh Bed Level Scans messen kann. Der Mesh Bed Level Scan ist so modular, dass man den Rest das Algorithmus behalten kann.

Ich habe gesehen auch das Display wird angesteuert, laut config. Es sit also das es grundlegend auch eine Anzeige am Gerät gibt und ev. ein wenig von den Tasten arbeiten.

Ich habe mit Python leider (noch) keine Erfahrung. Wie ist der Workflow wenn du etwas schreibst und testest am RF 1000. Logikfehler sind klar, aber wie geht Syntaxprüfen nur über das Kompilieren mit Klipper ?

af0815 hat geschrieben:Ich habe gesehen auch das Display wird angesteuert, laut config. Es sit also das es grundlegend auch eine Anzeige am Gerät gibt und ev. ein wenig von den Tasten arbeiten.

Ja, es gibt eine konfigurierbare Status-Anzeige und ein konfigurierbares Menü. Ich bin noch nicht ganz zufrieden damit, hauptsächlich weil es auf unserem recht kleinen Display Probleme mit zu langen Zeilen gibt. Da alles aber konfigurierbar ist, sollte sich das relativ leicht beheben lassen. Für die Status-Anzeige gibt es eine vorgefertigte Konfiguration für 16x4er Displays, für das Menü aber nicht.

af0815 hat geschrieben:Ich habe mit Python leider (noch) keine Erfahrung. Wie ist der Workflow wenn du etwas schreibst und testest am RF 1000. Logikfehler sind klar, aber wie geht Syntaxprüfen nur über das Kompilieren mit Klipper ?

Python ist eine interpretierte Sprache, d.h. da wird nichts kompiliert (jedenfalls nicht spürpar, es gibt einen "just in time" compiler, der beim Laden der Datei kompiliert, das ist aber nur eine Geschwindigkeitsoptimierung und passiert komplett automatisch im Hintergrund). Entsprechend fallen Fehler auch erst auf, wenn der fehlerhafte Code benutzt wird.

Das ist manchmal etwas nergiv. Aber im Vergleich mit Microcontroller-Code ist es immer noch 1000 mal angenehmer. Man kann zum Debuggen beliebig Text ins Log schreiben, dann kann man leicht sehen welcher Code in welcher Reihenfolge abgearbeitet wird und was da für Werte berechnet/gemessen werden. Das geht zwar irgendwie auch mit der Microcontroller-Repetier-Firmware, aber nicht an zeitkritischen Stellen (weil die serielle Schnittstelle viel zu langsam ist). Außerdem ist jede Änderung am Klipper-Code durch ein einfaches Neustarten von Klipper sofort aktiv. Da muss ich nicht erst eine Minute oder so warten, bis der Microcontroller programmiert ist.

Ganz zu schweigen natürlich davon, dass man sich einen ganz anderen Programmierstil leisten kann. Im Atmega verbieten sich schon Integer-Divisionen an zeitkritischen Stellen, weil sie einfach zu lange dauern. Selbst ein vergleichsweise langsamer Raspberry Pi ist nahezu unendlich viel schneller, da macht man sich über Floatingpoint-Divisionen oder auch komplexere Operationen wie Wurzelziehen erstmal keine Gedanken.

Python ist eine sehr anfängerfreundliche Sprache. Der Klipper-Code ist natürlich schon recht komplex und auch nicht unbedingt sehr gut dokumentiert. Aber es gibt eine Dokumentation, die einem eine Übersicht verschafft, was wo im Code passiert, das hilft schon mal enorm. Der Code ist sehr modular, so dass man nicht in fremdem Code rumwerkeln muss. Man schreibt einfach neue Module, die man per Konfiguration einschalten kann. Das Erleichtert die Arbeit auch enorm, und erhöht auch die Chancen, dass man den Anschluss an den Hauptentwicklungszweig nicht verliert, selbst wenn man den Code nicht zeitnah dort integriert bekommt.