@execute in 0.92
Hallo,
heute morgen das Update auf dem Raspberry zu Version 0.92 gemacht. Seit dem brechen @Anweisungen den GCode ab, also der GCode wird bis zu der @execute Anweisung ausgeführt, ab dem Aufruf (welcher da noch problemlos funktioniert) bleibt der Drucker stehen und reagiert auf nichts mehr, so dass nur noch ein Neustart des RasPi hilft. In den Logs wird nichts eingetragen, in der Serial Log ist ab dem @ Eintrag nichts mehr weiter geloggt, mittels "dmesg" ist auch nichts ungewöhnliches auffindbar. Nehme ich den @execute raus, läuft alles wunderbar, jedoch funktionierte es tadellos in den bisherigen Versionen.
Ich steuere meine Gehäuselüfter welches mittels @execute ausgeführt wird. Ich habe in den Druckereinstellungen das "Response To Event" entdeckt - jedoch noch keine Beschreibung dazu finden können, vielleicht ist dort ein Workaround mit machbar?
Könnte das "Response To Event" mal jemand kurz erklären?
Viele Grüße,
Sven
heute morgen das Update auf dem Raspberry zu Version 0.92 gemacht. Seit dem brechen @Anweisungen den GCode ab, also der GCode wird bis zu der @execute Anweisung ausgeführt, ab dem Aufruf (welcher da noch problemlos funktioniert) bleibt der Drucker stehen und reagiert auf nichts mehr, so dass nur noch ein Neustart des RasPi hilft. In den Logs wird nichts eingetragen, in der Serial Log ist ab dem @ Eintrag nichts mehr weiter geloggt, mittels "dmesg" ist auch nichts ungewöhnliches auffindbar. Nehme ich den @execute raus, läuft alles wunderbar, jedoch funktionierte es tadellos in den bisherigen Versionen.
Ich steuere meine Gehäuselüfter welches mittels @execute ausgeführt wird. Ich habe in den Druckereinstellungen das "Response To Event" entdeckt - jedoch noch keine Beschreibung dazu finden können, vielleicht ist dort ein Workaround mit machbar?
Könnte das "Response To Event" mal jemand kurz erklären?
Viele Grüße,
Sven
Comments
response to event ist für eigene erweiterungen. Wenn der Drucker einen String zurück gibt der der Regel entspricht wird ein Event mit dem Namen ausgelöst. Den können eigene erweiterungen dann abfangen und ensprechend reagieren.
exit 0
beenden. Bei windows batch dateien
exit /B 0
Damit sollte der Job nicht beendet werden.
Im server.log sollte "Executing: ..." stehen mit dem aufgerufenen Befehl.
Ist die Oberfläche noch bedienbar und nur die Kommunikation ist gestoppt oder hängt der ganze Server.
Kannst du mal deine extcommands.xml posten. Ich bring bald ein update raus und würde das gerne fixen wenn ich es reproduzieren kann.
Welches Betriebssystem?
Auf dem Raspberry läuft ein aktuelles Raspbian Buster
Meine extcommands:
https://www.repetier-server.com/knowledgebase/debugging-crashes-hangs-on-linux/
ausführen und mir das Backlog für alle threads schicken. Daran kann ich vermutlich sehen wo er genau hängt. Hab so einen für 0.92.4 schon behoben aber vielleicht ist es ja ein anderer den ich dann zusätzlich beheben kann.
Das ist echt komisch. Bis vor ein paar Tagen ging es hier ja auch noch, auch mit der 0.92.3. Ein Tag nach dem Upgrade auf 0.92.3 wollte ich einen erneuten Druck anstupsen - da wollte er schon nicht mehr, und das einzige was sich am System geändert hat ist SUDO, der aktualisiert wurde. Aber die Rechte bestehen, mein Script wird auch ausgeführt, aber Repetier bleibt stehen. Jedoch die beiden anderen Drucker lassen sich noch ansprechen während der eine eingefroren ist. Ich habe mal die logs dran gehangen, mehr konnte ich auch nicht grossartig loggen, bin auch noch nicht so gewand mit dem Gnu Debugger...
Edit: Als Datei Anhang will er nicht
Hast du das log erstellt nachdem die Blockade aufgetreten ist oder einfach so zwischendurch? Wichtig ist das du es erst macht, sobald ein Drucker nicht mehr reagiert. Am besten dazu die beiden anderen ausgeschaltet lassen, das weiß ich das der Fehler ja in dem aktiven ist.
Wenn alle 3 Drucker aktiv waren fehlt mir ein thread mit der Kommunikation. Dann wäre das vermutlich derjenige der nicht reagiert, weil der Thread der Fehlt ist die Kommunikation mit einem Drucker.
Hier der Auszug von den laufenden Threads:
zuerst mal hab ich herausgefunden das der Server synchronisierte Befehle nicht synchronisiert und umgekehrt. Das führt dazu das in deinem Fall auf die Beendigung des Skripts gewartet wird.
Das wäre jetzt eigentlich nicht so schlimm, aber er wird aus irgend welchen Gründen nicht fertig mit dem lesen des Fehlerstreams und hängt da fest. Ich hab schon einiges probiert in meinem Skript, kann den Fehler aber nicht reproduzieren. Kannst du das Skript mal posten das da aufgerufen wird. Ich vermute das es komplexer als meins ist und das timing oder was auch immer dazu führt das er hängen bleibt. Scheint wohl eine spezielle Bedingung erfüllt sein zu müssen damit er da hängenbleibt. Von der Position her denke ich das dass Skript durchgelaufen war. Hängen tut er beim aufräumen nach dem Skript wo er auf das Dateiende wartet.
In der nächsten version werde ich warten/nicht warten korrigieren, dann ist das auch kein Problem mehr außer du sagst er soll warten.
Aktuell kannst du in <execute noch sync="true" hinzufügen damit er nicht mehr wartet dann hängt er auch nicht mehr zumindest bis zur nächsten version wo es dann ja wieder anders herum ist. Allerdings würde ich das gerne reproduzieren um es Grundsätzlich zu verhindern.
Komplizierter sind die Scripts die von repetier.sh aufgerufen werden, in meinen Falle der watchdog für die Temperatur Überwachung welcher im Background den Dienst verrichtet und sich automatisch beendet sobald er von sämtlichen Sensoren sichere Temperaturen erreicht hat. Das heisst nach aufruf des scripts von repetier.sh wird unmittelbar danach ein Exit 0 ausgegeben, unabhängig ob es noch ausgeführt wird oder nicht. Im Trockentest hat es auch genau so funktioniert, und bisher eigentlich auch immer mit Repetier, bis aktuell eben ^^
Im groben sieht die repetier.sh so aus:
# Send Telegram Message
# Send Message
# Send Message with Cam Picture
# Power Devices ON/OFF
# Temp Watchdog
Ich hab das mal getestet mit einem Skript das nur sleep 60 macht. Ergebnis - mein testbefehl ist fertig aber weil die angeschlossenen kommandos den Ausgabestream noch halten, schließen diese erst wenn auch der letzte der mit & gestarteten Befehle fertig ist. Also bei mir geht der Drucker demnach 60 sekunden lang nicht und dann geht es wieder.
Ich vermute daher das alles bei mir in Ordnung ist abgesehen davon das sync/async vertauscht ist. Eines deiner Skripte ist einfach noch nicht fertig und blockiert den server, danach sollte es bei dir auch weiter gehen.
Oder du setzt aktuell sync="true" damit es aus ist, dann ist dem server das egal und er macht ja auch weiter wie früher.
Ja - richtig, der Watchdog der gestartet wird läuft permanent im Hintergrund und überwacht die Temperaturen bis im End-GCode der zweite Befehl ausgeführt wird, der dem Watchdog das Ende des Druckes signalisiert aber noch nachlaufen lässt bis die Temperaturen im sicheren Bereich sind.
Also die Option sync="true" geht schon in der aktuellen 0.92.3 ??? Oder erst ab der .4 ?