Repetier Firmware hängt sich auf

Ich könnte gerade echt heulen

Seit 4 Tagen habe ich ein Druck auf meinem großen Perseus am laufen, schon gut 2,5 kg an PLA verdruckt. Dann komme ich heute von der Arbeit nach Hause und es ist verdächtig still im Haus und stelle fest, dass der Drucker steht. Repetier-server auf dem angeschlossenem Tablet läuft, Druckbett ist kalt, Düse extrem heiß (>300°C laut Anzeige nach Reset), weißes PLA in der Düse schon schwarz gekocht, Druckteil schon halb vom Druckbett gelöst.

Der Drucker reagiert nicht mehr auf Befehle, nicht mal Notaus per Repetier-Server oder Ab - und Anstecken vom USB-Kabel helfen. Einzig ein Druck auf den roten RESET-Knopf am RADDS bringen den Arduino Due wieder aus der Lethargie....
Da Repetier-Server nicht eingefroren war und die Temperaturregelung durch den Controller offensichtlich nicht mehr stattfand (Die Ausgangssignale waren eingefroren), hat sich definitiv der Arduino aufgehangen

Wie zur Hölle kann das passieren???
Verbaut ist ein original RADDS v1.5 auf einem original Arduino Due, auf dem die neueste stable-Version von Repetier-Firmware (0.92.9) läuft, angesteuert mit einem Windows 10-Tablet.

Der Repetier-Watchdog war natürlich per Config eingeschaltet, hat aber keinen Effekt gezeigt. Wofür ist der überhaupt da, wenn der sowas nicht verhindert und die Heizelemente einfach angeschaltet bleiben?
Ich hatte wohl nur Glück, dass nicht zufällig im Moment des Aufhängens das Heizbett angesteuert wurde, sonst könnte ich den Druck jetzt vom Boden kratzen und vermutlich die Heizmatten austauschen.

Das selbe Teil habe ich vorher schon mal erfolgreich gedruckt, am G-Code kann es also nicht liegen.

Woran kann sowas liegen? Spannungsspitze? Dann müsste das Netzteil doch ausgehen oder der Controller resetten.

An liebsten würde ich das Teil in seine EInzelteile zerlegen und verkaufen... 10.000 € investiert und dann scheitert es am Controller.
Gibts irgendwas betriebssicheres als einen Arduino?

2-mal bearbeitet. Zuletzt am 20.11.17 13:13.

Du kannst eher von Glück reden, dass sich die Bude nicht in Rauch aufgelöst hat ...

Einen Absturz eines Computers, den kann man nicht voraus sagen, 3D-Drucker zu Hause, das kann eben auch zu versicherungstechnischen Fällen führen. Du müsstest selbst einen Notaus einbauen, der z.B. auf Grund fehlender Druckgeräusche den Drucker nach z.B. 10 Minuten ausschaltet.

---

liebe Grüße

Minihawk

*** In Wirklichkeit ist die Realität ganz anders ***

Wenn der Watchdog aktiviert ist und nicht auslöst muss er von der Firmware resetet worden sein.

Es gibt einen Gcode bei Repetier der den Watchdog künstlich auslöst. Vielleicht einmal checken ob das läuft.

Quote

##How to test Watchdog ?

Connect repetier host and send M281 command.
This will generate a timeout after showing "Triggering watchdog. If activated, the printer will reset." in serial terminal.
If watchdog is enabled properly and working the printer will reset and restart.
If not, you should have "Watchdog feature was not compiled into this version!" in serial terminal and printer will not automaticaly restart.

---

Triffid Hunter's Calibration Guide

--> X <-- Drill for new Monitor

Most important Gcode.

Der Drucker ist thermisch eigentlich abgesichert: Der Extruder heizt selbst bei dauer-100% nie über 400°C, da fängt noch nichts zu brennen an. Ich habe mal versucht, PEEK mit 400°C zu drucken, das schafft der Extruder nur so gerade eben. Die Heizmatte ist mit Siliprotect abgesichert, wodurch bei >180°C die Stromversorgung unterbrochen wird (Kann man die Temperatursicherung eigentlich austauschen?)
Von daher kann nichts anfangen zu brennen, es entsteht im schlimmsten Fall ein Materialschaden am Drucker.

@ Wurstnase:

Danke für den Tipp.

Leider verursacht der Watchdog bei diesem Test genau das, was er eigentlich verhindern soll: Der Arduino hängt sich auf:



Nachdem der Befehl eingegeben wurde, friert der Arduino ein, es findet keine Kommunikation mehr statt und die Ausgänge, sprich Heizelemente, Lüfter usw. frieren ebenfalls ein. Es tritt also genau das ein, was bei meinem 4 - Tagesdruck passiert ist.

Kann es sein, dass der Watchdog in Repetier verbuggt ist oder kann man den irgendwie falsch konfigurieren? Der Watchdog kann doch nur aktiviert oder deaktiviert sein, mehr Parameter gibt es nicht, oder?
Da kann ich den Watchdog eigentlich besser ganz abschalten.

Welche Arduino IDE hast du?
Es hat fast eine Ewigkeit gedauert bis das bei Arduino ordentlich implementiert war.

---

Triffid Hunter's Calibration Guide

--> X <-- Drill for new Monitor

Most important Gcode.

Ich habe die Firmware mit Arduino 1.5.8. kompiliert und übertragen. Laut Webseite gibt es inzwischen die Version 1.8.5.

Hat die Kompilierungssoftware Auswirkungen auf die Funktionsweise des Watchdogs?

Zumindest die eingesetzte Due Library.
Der Watchdog muss während der Initialisierung eingeschaltet werden. Das wurde damals immer ausgeschaltet. Bobc hat da vor ein paar Jahren Mal einen Patch zu geschrieben der noch über ein Jahr bräuchte bis er dann eingebaut wurde. 1.5.8 klingt nach uralt. Da solltest du definitiv Mal ein Update machen. Danach müsste der Watchdog laufen.

---

Triffid Hunter's Calibration Guide

--> X <-- Drill for new Monitor

Most important Gcode.

Ich habe dir Firmware jetzt mit Arduino 1.8.4 compiliert und übertragen, jetzt funktioniert zumindest M281 wie erwartet (Controller wird resettet und ist nach dem Reset wieder ansprechbar).
So sind jetzt hoffentlich zumindest die Heizelemente abgesichert.

Jetzt stelle ich mir nur noch die Frage, was den Watchdog überhaupt ausgelöst hat.
Wenn der Drucker vorher über 15 Tage nahezu pausenlos ohne Fehler gedruckt hat, liegt sicher kein grundsätzliches Problem vor. Ich kann mir auch nicht vorstellen, dass irgendein Gerät im Hausnetz die Elektronik gestört haben könnte: Erstens war ich zum Zeitpunkt des Fehlers garnicht im Haus und dementsprechend wurden keine Geräte an - oder abgeschaltet und zweitens waren zeitgleich zwei weitere Drucker mit der gleichen Elektronik mit gleicher Firmware aktiv, die unbeeindruckt weiter gearbeitet haben und an der gleichen Sicherung hängen.
Kann die fehlerhafte Initialisierung des Watchdog durch die alte Arduino-IDE auch ein verfrühtes oder fehlerhaftes Auslösen des Watchdogs auslösen?

Nein. Wenn der Watchdog aus ist, ist er aus.


Nach vier Tagen kann da ne Menge das Problem sein. Stack-Überlauf oder Variablen die nicht überlaufen sollten und das dann doch tun. Da kann man nur raten wenn man nicht einen Debugger mitlaufen lässt. Der Watchdog war es aber sicher nicht.


Watchdog ist so was wie ein Totmannschalter. Wenn also der Watchdog an ist und man eine gewisse Zeit nicht den Watchdog zurück setzt (grob alle 2 bis 8 Sekunden), bellt der los und setzt dein System zurück.

---

Triffid Hunter's Calibration Guide

--> X <-- Drill for new Monitor

Most important Gcode.

Kann man einen Debugger über mehrere Tage mitlaufen lassen und parallel den Drucker per Repetier-Server ansteuern?

Macht das überhaupt Sinn? Ich müsste ja theoretisch sämtliche Variablen mitloggen, sind ja sicher hunderte bei so einem komplexen Programm wie Repetier und ich habe ehrlich gesagt kaum eine Ahnung, wie die Firmware genau funktioniert.
Nur wie soll man der Ursache sonst auf die Schliche kommen?

Nen Hardware Debugger kann man immer mitlaufen lassen. Da kann man dann quasi auf Pause drücken und sich den Stackbund ähnliche Geschichten angucken und ggf. sehen wo er nun hängt. Aber dazu braucht man für den Due noch extra Hardware. Beim SAM3X ist das glaube ich ICE oder so ähnlich. Arbeite mit dem Due jetzt schon lange nicht mehr.

Wenn du den gleichen Gcode woanders stabil laufen hast kann das aber alles mögliche zufällige sein. Ne Gravitationswelle?

Wenn der Gcode anders ist dann könnte man ja mal den Code ohne Extruder laufen lassen und testen. Ist leider alles nicht so einfach.

---

Triffid Hunter's Calibration Guide

--> X <-- Drill for new Monitor

Most important Gcode.