Connection-Timeouts nach langen drucken
Moin,
mir ist aufgefallen das lange Drucke dazu führen das Repetier die "Verbindung" zum Drucker verliert. Lustiger weise verliert er sie nicht richtig. Ich kriege nach wie vor Daten, seien es Temperaturmeldungen in der Konsole oder Rückmeldungen von Flow/Lüfter/Temperaturen im oberen Bereich.
Habs bisher bei Drucken über 6 Stunden festgestellt. In der Anzeige zeigt er mir an das noch ein paar Sekunden Restzeit sind (99,XX%). Der Druck steht aber schon seit Stunden fertig da und auch das Endscript wurde ausgeführt, nur die Software beendet den Druck scheinbar nicht. Im Terminal stehen dann ettliche Connection-Timeouts.
Die Drucker-Steuerung geht dann nicht mehr und zwar solange bis ich meinen Microserver neustarte auf dem Repetier läuft (Gelegentlich reagiert nach 20-30s auf Befehle, drucken geht aber nicht mehr). Egal wie oft ich den Drucker neustarte. Auch erneuter Marlin-Flash hat nichts gebracht. Das Problem tritt bei bisher bei meinen Melzi Druckern auf (Ender2/Ender3), am Tornado mit Duetwifi hab ichs noch nicht getestet.
Sieht für mich stark nach nem Software Problem aus da ich egal was mit dem Drucker machen kann, lediglich neustart des Servers behebt das Problem. Ist aber keine Lösung da ich keine neustarts machen kann während andere Drucker noch am drucken sind.
mir ist aufgefallen das lange Drucke dazu führen das Repetier die "Verbindung" zum Drucker verliert. Lustiger weise verliert er sie nicht richtig. Ich kriege nach wie vor Daten, seien es Temperaturmeldungen in der Konsole oder Rückmeldungen von Flow/Lüfter/Temperaturen im oberen Bereich.
Habs bisher bei Drucken über 6 Stunden festgestellt. In der Anzeige zeigt er mir an das noch ein paar Sekunden Restzeit sind (99,XX%). Der Druck steht aber schon seit Stunden fertig da und auch das Endscript wurde ausgeführt, nur die Software beendet den Druck scheinbar nicht. Im Terminal stehen dann ettliche Connection-Timeouts.
Die Drucker-Steuerung geht dann nicht mehr und zwar solange bis ich meinen Microserver neustarte auf dem Repetier läuft (Gelegentlich reagiert nach 20-30s auf Befehle, drucken geht aber nicht mehr). Egal wie oft ich den Drucker neustarte. Auch erneuter Marlin-Flash hat nichts gebracht. Das Problem tritt bei bisher bei meinen Melzi Druckern auf (Ender2/Ender3), am Tornado mit Duetwifi hab ichs noch nicht getestet.
Sieht für mich stark nach nem Software Problem aus da ich egal was mit dem Drucker machen kann, lediglich neustart des Servers behebt das Problem. Ist aber keine Lösung da ich keine neustarts machen kann während andere Drucker noch am drucken sind.
Comments
https://forum.repetier.com/discussion/5157/prints-long-then-8-hours-will-not-finish-with-repetier-server-on-pi
Leider gabs auch hier bisher keine Lösung
Install gdb
If it happens log in to pi
remember the process id from server here 972 but that is always a different one
Then start gdb
Anhand der ausgabe kann ich sehen ob es ein Deadlock ist und ihn vermutlich beheben.
Alternativ antwortet die firmware aus irgendwelchen Gründen nicht mehr, auch da sist schon vorgekommen. Aber immer am Ende eines Drucks ist schon verdächtig.
In den nächsten Tagen gibt es ein Update, wenn es also zufällig die nächsten Tage auftritt bitte sofort melden, sonst könnte das Update lange dauern.
Was ist mit dem anderen Drucker? Passiert das dort auch?
Welche Firmware nutzt der Drucker. Bei Repetier-Firmware könntest du mit M111 S24 nur die Kommunikation testen. geht recht schnell und braucht kein Filament.
Passiert immer erst ab 8 Stunden, bei 7 Stunden war noch alles okay...
Und manchmal funktionieren Befehle über die Konsole noch, sind dann aber 20-30 Sekunden Zeitverzögert. Ist aber eher Glück das es noch geht. Der Drucker wird auch noch als verfügbar angezeigt.
Aber worin könnten sich die Drucke 7 zu 8 Stunden unterscheiden? Ich vermute am Ende steht der gleiche Code zum beenden und parken und abschalten der Extruder. Was man tun könnte wäre logging aktivieren und manuell bei einem langen Druck kurz vor ende (500 Zeilen) mit M111 echo aktivieren, damit man sieht was Marlin noch bekommen hat und was es ausführt und was server gesendet hat. Vielleicht kann man sich dann zusammenreimen an welcher stelle was schief geht. Wenn möglich Marlin mit Zeilennummern in "ok" aktivieren und auch "wait". Kann man in der advanced Konfiguration machen. Selbst wenn der Server nichts mehr sendet sollte die Firmware mit "wait" auf sich aufmerksam machen. Aber es hört sich an als ob da irgendwas anfängt die Kommunikation zu stören, auch wenn ich keine Idee habe warum. Selber Server unter Windows oder Linux PC wird vermutlich klappen.
Snapshots sind deaktiviert. Er zeigt immer 6-8 Sekunden rest an, Druckt aber Problemlos zu Ende. Im Verlauf sieht das dann so aus:
Temperaturen werden automatisch von Marlin gesendet, was zumindest zeigt das Marlin nicht abgestürzt ist und die Verbindung noch steht. Du solltest unbeding Zeilennummern nach ok und wait in Marlin aktivieren. Das verbssert die Kommunikations im Fehlerfall. Ist allerdings nicht das Problem. Aber durch die fehlenden Zeilennummern kann man nicht sehen welcher Befehl noch entgegen genommen wurde.
Werte ich so das die M117 noch bestätigt wurde. Für mich sieht es aus als ob entweder keine Befehle gesendet werden, was ich aber nicht so glaube, oder das die Befehle nicht mehr ankommen. Das kann am serial-USB wandler in Linux oder dem Drucker liegen oder in der Firmware. Passiert schon mal bei elektischen Störungen, aber so regelmäßig und immer beim Ende.
Mit Linux PC meine ich nicht den PI. Der hat leider gerne auch mal Probleme mit der Stromversorgung, daher die Frage ob es mit einem echten PC auch passiert.
Server rebooten ist mehrdeutig. Den Pi rebooten oder repetier-server? Schon mal deaktivieren und aktivieren probiert? Danach wird die Verbindung ja zwangsweise getrennt. Wenn das nicht hilft und wirklich der pi rebooten muss, deutet das auf den Treiber hin, der dadurch ja auch neu gestartet wird. Aber sowas ist nicht wirklich zu debuggen, zumindest weiß ich nicht wie.
Das war einer von 3 Druckerthreads. Ich nehme daher an du hast 3 Drucker konfiguriert?
Das hier der thread, der gerade Daten zum Drucker schicken will. Eine Blockade ist nirgends auszumachen. Aber fassen wir kurz zusammen was der Stand ist, bitte korrigieren wenn ich was falsch habe:
1. Es passiert nur nach langem Druck. Das sollte eigentlich egal sein, da eh nur ein Teil geladen wird. Aber die dateien werden länger und brauchen vielleicht mehr Zeit zum löschen.
2. Der Druck selber wird immer zu 100% gedruckt, also die letzten Befehle sind noch im log zu sehen.
3. Server meldet den Druck aber als noch nicht fertig.
4. Danach ist die Kommunikation nicht mehr ganz möglich. Empfangen geht, aber senden ist nicht mehr möglich oder vielleicht noch ein paar Befehle bis es nicht mehr geht.
5. Nur Neustart des Servers hilft.
6. Der Job erscheint in der History als abgebrochen. Aber warum erscheint er dort überhaupt. Hast du ihn manuell abgebrochen? Ich vermute das mal.
7.
Zeigt das der Job eigentlich fertig gedruckt ist (Job Commands: 0). Frag mich aber warum er einen timeout generiert, wo doch nichts gesendet werden muss.
Jedenfalls scheint es, als ob der Fehler genau am Ende der Datei passiert, was natürlich die gleiche Funktions und Procedur ist wie bei kurzen drucken. Es muss also ein Fehler sein, der nur bei ungünstigem Timing passiert und der lange Druck erzeugt bei deinem Rechner genau dieses Timing.
Ich werde die relevanten Codeteile noch mal analysieren mit diesem Hintergrund. bitte lass mich wissen wenn es noch mal passiert. In dem Fall wäre ein weiteres backtrace super, um es weiter einzugrenzen. Wenn möglich mehrfach, also nach dem backtrace mit
c
weiter machen und noch mal wiederholen um zu sehen wo er dann steckt. Bitte dann auch parallel sagen ob nur der eine Drucker verbunden ist, weil ich sonst dem falschen Thread hinterherjagen könnte.
Mit backtrace meinste Debug mit gdb? Werd ich dann nochma machen und nur einen Drucker währenddessen betreiben, dann fällt die Zuordnung leichter und man kann herausfinden ob das der "Abgestürzte" Drucker ist wo er versucht Daten zu schicken. Hab einen mit 0.2mm nozzle der macht eh nur lange Drucke. Werd dann nächste Woche weiter die gdb logs posten.
Hab mir den code angesehen und ein paar stellen optimiert, aber nichts gesehen wo ich sagen würde das ist es wo er hängt.