Repetier-Server stürzt nach 48h ab

Legion23

Verehrte Gemeinde

Auf meinem Großraumdrucker lief vor kurzem ein >100h-Druckauftrag.
Nach etwa 48 h ist der Drucker auf einer Stelle stehen geblieben und an der Düse hatte sich sich bereits einige an Material angesammelt. Mit einiger Frickelei konnte ich den PLA-Klumpen sauber entfernen und den Druck an der selben Stelle neu ansetzen, indem ich den bereits abgearbeiteten G-Code gelöscht und dann neu gestartet habe, so konnte ich den Druck noch einigermaßen retten.

Da dieses Problem schon mal aufgetreten ist, versuche ich nun die Ursache zu ergründen und hoffentlich zu beseitigen.



Folgendes ist im Detail passiert:

- Repetier-Server zeigt mir an, der Druck sei fertig ("kein laufender Druckauftrag")
- Der Drucker reagiert kaum noch auf manuelle Befehle (eine Bewegung wird erst nach 10 Sekunden Verzögerung ausgeführt)
- Die Repetier-FIRMWARE auf dem Arduino Due lief noch, die Temperaturregelung aller Heizelemente war noch aktiv
- In der Konsole werden ziemlich wirre Befehle angezeigt ("awti"; "k01 4201"; "2o"; "3T", usw. )
- Des weiteren wird in der Konsole die Warnung "Communication Timeout - resettingcommunication buffer" ausgegeben





Eine Wiederbelebung des Druckers war nur möglich, in dem der Repetier-Server auf dem Tablet gestoppt und neu gestartet wurde. Im Anschluss konnte ich wie beschrieben den Druck fortsetzen und die Kommunikation lief wieder problemlos.

Da ein einfacher Software-Reset von Repetier-Server ausgereicht hat, kann man einen Hardware-Fehler vermutlich ausschließen.
Ich habe vor dem aktuellen Druckauftrag schon ein anderes sehr großes Teil gedruckt (G-Codegröße ca. 300mb), auch der aktuelle Auftrag ist mit 300mb sehr groß. Insgesamt war der Drucker also bis zum Auftreten des Fehlers >100h im Einsatz.
Der beschriebene Fehler ist bisher immer erst nach mehreren Tagen Druckzeit aufgetreten. Ich habe daher die Vermutung, dass im Repetier-Server irgendein Speicher oder Puffer überläuft, der zu den Problemen führt.
Laut Task-Manager ist die Ressourcenauslastung im Rahmen (CPU und Ram <50%) und es sind noch 13gb freier Festplattenspeicher vorhanden.

Meine Hardware dieses tablet (One Xcellent 10.3) in Kombination mit einem Arduino Due und einem RADDS 1.5.
Das Tablet ist keines der Leistungsstärksten oder Besten, aber das einzige bezahlbare, welches man gleichzeitg laden und per USB am Arduino anschließen kann. Das Tablet ist nicht per WLAN mit dem Netzwerk verbunden, weshalb ein Update oder dergleichen als Fehlerursache ausgeschlossen werden kann. Es läuft außer Firefox und Windows-Diensten keine Software auf dem Gerät.

Ich verwende zurzeit die Repetier-Server-Verion 0.701, weil ich mit neueren Versionen (zuletzt habe ich 0.8 getestet) auch schon Probleme gehabt habe.
Ist das vielleicht ein bekanntes Problem, welches mit neueren Versionen gefixt wurde? In den Release-Notes von Repetier steht zwar was von "Reduced number of communication errors", aber damit ist sicher kein Totalausfall gemeint.
Wo können hier sonst noch die Ursachen liegen?

Repetier

Merkwürdiger Fehler. Sieht aus als ob die Reihenfolge der Buchstaben verwürfelt wird.
awti = wait
ko1 4201 = ok 14201
Das dies den server verwirrt ist klar, nur warum das passiert kann ich nicht sagen. Ist mir ehrlich gesagt noch nicht passiert. Ein Versuch wäre auf 0.86.2 upzudaten. Die version läuft sehr stabil und hat die Probleme mit anderen 0.8x versionen gelöst.

Das der Job beendet wurde liegt vermutlich an zu vielen Fehlern die nicht mehr behoben wurden.

Hardware defekt denke ich auch nicht wirklich, aber mit dem restart wird auch der Drucker neu gestartet und damit ist unklar wer auf dem Weg plötzlich anfängt die Reihenfolge zu drehen. falls es an der Datenmenge liegt sollte sich das immer an ungefähr der gleichen Stelle wiederholen. In dem Fall könnte man mit
M111 S20
testen ob sich das wiederholt. Mit dem Debug Befehl wird die Firmware in debug Kommunikationsmodus gesetzt, heist sie druckt nicht sondern bestätigt nur die Befehle. Das geht deutlich schneller als Drucken und verbraucht kein Filament.

Legion23

So, ich bin nun endlich dazu gekommen, den Server wie beschrieben zu testen.
Ich habe eine große Menge an G-Code im Debug-Modus abarbeiten lassen, mindestens die gleiche Menge, die vor Auftreten des Fehlers bearbeitet wurde. Das Tablet habe ich selbst im Debug-modus über einen Tag lang rechnen lassen. Allerdings lässt sich der Fehler so scheinbar nicht reproduzieren. Zumindest werden in der Konsole keine durcheinandergewürfelten Befehle angezeigt.

Nebenbei bemerkt funktioniert (zumindest in der Server-Version 0.701) der Debug-Modus per M111 S20 nicht ganz sauber: Werkzeugwechselbefehle (T0, T1, etc) werden auch in diesem Modus ausgeführt und an das Arduino-Board übertragen.

Ich habe die neueste Repetier-Server-Version (0.86.2) getestet. Der Fehler trat damit bisher noch nicht auf, allerdings hat sich nach einer Weile Windows selber (Windows 10) komplett aufgehangen, sodass das Tablet resettet werden musste. Das ist inzwischen mit dieser Version 2 mal aufgetreten, mit der 0.701er Version allerdings noch nie. Ich weiß nicht, woran das genau liegen kann. Vielleicht benötigt die aktuelle Repetier-Version mehr Ressourcen, sodass die Hardware des Tablets an die Grenzen stößt.

Da die Tablets offline genutzt werden, sind alle peripheren Programme (z.B Webbrowser) nicht auf den neuesten Stand.
Zurzeit nutze ich Firefox. Kann da vielleicht die Ursache liegen? Welcher Browser ist am besten für Repetier-Server geeignet?

Repetier

Der Server selbst braucht vergleichsweise wenig Resourcen, da er nur die Daten weiterleitet. Browser hingegen verwenden sehr viel RAM wegen der dynamischen Inhalte. Kommt auch darauf an welche Seite gerade gerade sichtbar ist. Es wäre sicher sinnvoll mit dem Taskmanager zu sehen wer den Speicher belegt. Da beide Programme von Windows kontrolliert werden, sollten sie eigentlich nicht in der Lage sein Windows zum absturz zu bringen. Schlimmstenfalls verlangsamen wenn der Speicher ausgelagert wird.
Wir selbst entwickeln unter Chrome was dann auch unser präferierter Webbrowser ist, aber aktuelle Firefox versionen sollten eigentlich auch klappen. Aber wie gesagt parallel task manager öffnen und sehen ob der Speicherbedarf wächst. Server sollte ziemlich stabil bleiben.

Legion23

Ich habe jetzt seit etwa 2 Wochen anstelle von Firefox die aktuellste Chrome-Version zusammen mit Repetier-Server 0.86.2 auf dem Tablet laufen. Windows und Chrome sind soweit bsiher stabil und ich konnte etwa 10 Tage ohne Störung drucken.

Heute ist allerdings wieder ein Druck abgebrochen, allerdings anders als sonst. Ich war gerade zufällig im Raum und hab gesehen, dass der Drucker gerade noch lief, aber das Verbindungssymbol für den Drucker nicht grün, sondern kurz gelb war, Sekunden später aber wieder grün. Kurz darauf fährt der Drucker langsam (ca. 60mm/s) in Richtung X+ und Y+, bis die Achse mechanisch durch den Rahmen zwangsgestoppt werden und die Servos wegen Überlast sogar abschalten.

Der Druck wurde automatisch abgebrochen (Druckfortschritt : 0%)

Repetier zeigt mir jetzt als letzten die Meldung "Response while unconnected: wait", gefolgt von der kompletten Konfig des Druckers (FIRMWARE NAME: REPETIER_0.92.9  FIRMWARE_URL ....) wie bei einem Neustart.

Ich habe daraufhin Probehalber den Druck neu gestartet und kurz das USB-Kabel getrennt und sofort wieder eingesteckt, danach kam eine ähnliche, aber leicht abweichende Meldung "Response while unconnected: ok 779".

Daher vermute ich jetzt, dass die Ursache des Problem womöglich eine Störung der USB-Verbindung ist. Das USB-Kabel ist mit >2m recht lang und wurde auch verlängert. Daher muss ich jetzt schauen, ob ich irgendwo ein besser geschirmtes, durchgehendes USB-Kabel mit 3m Länge her bekomme.

Der beschriebene Crash (die beiden Motoren fahren über die Endlage hinaus) kommt wahrscheinlich daher, dass nach dem Reconnect die Repetier-Firmware resettet wurde (interne Position X/Y/Z = 0) und trotzdem der letzte Fahrbefehl irgendwie noch ausgeführt wurde. Das war jetzt zum Glück nicht dramatisch, aber schon etwas unschön, weil die verbauten Motoren nach einer Überlast auch neu gestartet werden müssen und so ein Crash der Mechanik auch nicht gut tut.

Repetier

Ja gelb ist er wenn er versucht den Drucker zu verbinden. Also muss er vorher getrennt worden sein. Normalerweise kommt das vom Betriebssystem. Und dann sendet er die start gcodes weshalb du die Daten gesehen hast. Ich frage mich allerdings ob dein Drucker resetet wenn du ihn verbindest. Und welches Board hast du? Das mit dem letzte befehle weiter senden hab ich schon mal gehört, konnte es aber selber nie replizieren. Vielleicht sollte ich nach dem disconnect erst mal was warten. Ich vermute das ging hier so schnell das der writer noch geschrieben hat weil er schon wieder am verbinden war. Grundsätzlich stoppt er ja, aber es scheint das 1-2 Befehle noch unter ungünstigen umständen durch kommen können.

Legion23

Ich denke, ich habe endlich die Wurzel allen Übels gefunden: Nach dem die Verbindungsabbrüche in letzter Zeit immer häufiger aufgetreten sind, habe ich etwas recherchiert und bin in einem anderen Forum auf deinen Kommentar bezüglich der USB-Ports des Arduino Due gestoßen: Offensichtlich werden die beiden USB-Anschlüsse (Native - und Programming-Port) von unterschiedlichen Chips angesprochen.

Daraufhin habe ich mir die Verkabelung des Großraumdruckers mit meinem anderen älteren Drucker, welcher ebenfalls mit einem Tablet betrieben werden, allerdings seit Jahren stabil läuft, verglichen:

Beim großen Drucker habe ich das Due am Native-Port angeschlossen, bei dem Älteren am Programming-Port.

Daraufhin habe ich auch beim großen Drucker das Due ebenfalls am Programming-Port angeschlossen, seit dem läuft die Verbindung störungsfrei und ich habe auch den Eindruck, dass die Geschwindigkeit der Kommunikation seit dem höher ist. Hoch aufgelöste Radien werden seit der Änderung subjektiv sauberer und vor allem leiser gedruckt als vorher.

Daher vermute ich, dass es irgendein Problem mit der Kommunikation des Native-Ports gegeben hat und dadurch gelegentlich Verbindungsfehler aufgetreten sind. 

Repetier

Ich nutze auch immer den programming port. Der native port wird von einer arduino bibliothek in der Firmware angesteuert, die kommt aber von Arduino als nichts selbst geschriebenes. Am programming port mag ich hauptsächlich das er beim verbinden ein Reset erlaubt und beim upload einer firmware den port nicht wechselt.