RPI mit Radds 1.5 und Due, Blobs vermeiden
Hallo
Ich habe das Problem dass mein Core XY Drucker während dem drucken häufig kurze aussetzer hat (0.2s bis 3s), dabei läuft natürlich die Düse aus, und es gibt unschöne Blobs im Druck. Zudem leidet die Layerhaftung, da nach dem Blob für einige Zeit zuwenig Material gefördert wird.
Was ich unter anderem versucht habe:
- Native und Programming Port getestet (native läuft etwas besser)
- verschiedene "Baud rate" getestet (Aktuell bei 230400)
- verschiedene "Move Cache Size" getestet (Aktuell bei 32, konnte zu 16 keinen Unterschied feststellen)
- verschiedene "Ensure minimum time per move when cache is
below" getestet (Aktuell bei 10, leichte verbesserung zu 0)
- Steps per mm beim Extruder von 3880 auf 1940 gestellt (keinen Unterschied)
- Die X und Y Achsen waren an E4 und E5 angeschlossen, die habe ich auf X und Y gewechselt (keine verbesserung)
- Die serielle Verbindung getestet (M111 S?? gesendet und dann einen Gcode ausgeführt. In 1 Minute 3 Sekunden wurden 112728 linien übertragen, was ja mit 1789 Linien pro Sekunde mehr als genug wäre.
- PingPong Modus war immer ausgeschaltet
Was könnte ich noch versuchen?
Ich verwende Repetier Server Pro 0.93.1 mit der Firmware 1.0.3 Am RPI3 ist neben dem Due nur ein Touch Display und eine Webcam angeschlossen. Die Probleme waren schon vor der Webcam vorhanden. Der RPI bekommt den Strom über einen aufgesattelten PIUSV.
Ich bin dankbar für jede Hilfe.
Gruss
Hansjürg
Comments
Zuerst würde ich logging einschalten und sehen ob es Kommunikationsfehler mit längeren aussetztern gibt, also wo er sich mehrmals hintereinander korrigieren muss. Ansonsten erzeugt das ja keine Blob.
Den gcode sollte man aber nicht außer acht lassen - wenn er zu fein wird gibt das Probleme weil die Firmware dann massiv abbremsen muss um jederzeit einen Stillstand garantieren zu können. Sieht dann fast aus wie stillstand je nachdem wie hoch jerk ist und kann dadurch evtl zu blobs führen.
Dann kann es noch die sd karte vom pi sein. Zumindest glaube ich das manche Karten zu einem einfrieren von Linux für kurze Zeit führen kann. Entweder um buffer zu schreiben oder weil wear leveling das schreiben kurz blockiert. Bei guten schnellen Karten sollte das aber kein Problem sein. Kann auch eine andere Software sein - wobei der server mit einem sehr hohen nice level läuft damit ihn eigentlich keine ausbremsen kann - vom Linux kernel mal abgesehen.
ist die Meldung der Temperaturen an server.
21:40:40.793: wait (2)
zeigt das da 2 Sekunden pause war.
Mit log meinte ich aktivieren von log im Druckermenu "Logs". Aber mit dem wait im Druck ist eindeutig das er ohne direkten Grund 2 sekunden still stand und erst dann die nächste Zeile gesendet hat, also ist es eine pause durch linux.
Hab den Kommentar wegen der 8gb Größe nicht verstanden. Unser image ist 4gb groß und expandiert automatisch zu jeder sd kartengröße. Das einzige wa sman wirklich sichern müsste wenn das der Kommentar meint ist /var/lib/Repetier-Server weil da alle Daten zum server stehen.
Große karten haben viele Vorteile, auch das sie länger leben und wear leveling besser verteilen können. Und schneller sind sie meist auch. Und nicht so schnell voll was auch zu Problemen führt.