Repetier-Server stürzt nach 48h ab
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?
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?
Comments
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.
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?
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.