Befehl ausführen (Drucker ausschalten) nach Idle-Zeit X Minuten
Hallo,
leider vermisse ich bei Repetier eine Funktion, die ich bei Octoprint sehr zu schätzen wusste. Es war über ein Plugin möglich, Befehle auszuführen nach einer Wartezeit von X Minuten, sofern der Drucker im Idle-Zustand war. Ich glaube das funktionierte irgendwie in Kombination mit dem M105 Befehl und den Zeitangaben. Führte der Drucker in der Zeit keine anderen Gcodes aus etc., wurde dieses Event getriggert.
Ich hab das immer gern benutzt um meine Drucker auszuschalten in Verbindung mit den Sonoff-Steckdosen, über ein bash script (hat einfach die Sonoff/Tasmota Web-URLs gecurlt). Sofern 10 Minuten nach Druckende keine weitere Interaktion stattgefunden hat, wurden die Drucker ausgeschaltet. Andernfalls lief alles wie gewohnt weiter.
Nach meinem Kenntnisstand ist es momentan nur möglich mit der externen XML Datei zu bearbeiten, jedoch kann man damit die Drucker einfach nur ein/aus schalten und eben "erzwungermaßen" nach dem Druckende (bzw. nach sleeptime X im script) abschalten.
Das ist zwar so besser als nichts, aber irgendwie doch ein wenig unglücklich falls ich danach direkt weiterdrucken möchte und der Drucker einfach an bleiben soll.
Ich habe bereits gelesen, dass es bald die Möglichkeit geben soll, direkt http-requests zu senden. Wäre es da nicht mit wenig Aufwand möglich, so eine idle-funktion ebenfalls mit zu integrieren? Es müsste lediglich geschaut werden ob Im Zeitfenster X nur die M105 Befehle aufgeführt werden, falls ja, kann das Event getriggert werden.
Sofern die Funktion mit den http-requests kommt, könnte man dies ja auch super in den Druckereinstellungen definieren. 2 Felder wo man z.B. die URLS für Drucker An/Aus hinterlegen kann, die Menüpunkte erscheinen dann auch direkt beim Drucker ohne die XML bearbeitung.
leider vermisse ich bei Repetier eine Funktion, die ich bei Octoprint sehr zu schätzen wusste. Es war über ein Plugin möglich, Befehle auszuführen nach einer Wartezeit von X Minuten, sofern der Drucker im Idle-Zustand war. Ich glaube das funktionierte irgendwie in Kombination mit dem M105 Befehl und den Zeitangaben. Führte der Drucker in der Zeit keine anderen Gcodes aus etc., wurde dieses Event getriggert.
Ich hab das immer gern benutzt um meine Drucker auszuschalten in Verbindung mit den Sonoff-Steckdosen, über ein bash script (hat einfach die Sonoff/Tasmota Web-URLs gecurlt). Sofern 10 Minuten nach Druckende keine weitere Interaktion stattgefunden hat, wurden die Drucker ausgeschaltet. Andernfalls lief alles wie gewohnt weiter.
Nach meinem Kenntnisstand ist es momentan nur möglich mit der externen XML Datei zu bearbeiten, jedoch kann man damit die Drucker einfach nur ein/aus schalten und eben "erzwungermaßen" nach dem Druckende (bzw. nach sleeptime X im script) abschalten.
Das ist zwar so besser als nichts, aber irgendwie doch ein wenig unglücklich falls ich danach direkt weiterdrucken möchte und der Drucker einfach an bleiben soll.
Ich habe bereits gelesen, dass es bald die Möglichkeit geben soll, direkt http-requests zu senden. Wäre es da nicht mit wenig Aufwand möglich, so eine idle-funktion ebenfalls mit zu integrieren? Es müsste lediglich geschaut werden ob Im Zeitfenster X nur die M105 Befehle aufgeführt werden, falls ja, kann das Event getriggert werden.
Sofern die Funktion mit den http-requests kommt, könnte man dies ja auch super in den Druckereinstellungen definieren. 2 Felder wo man z.B. die URLS für Drucker An/Aus hinterlegen kann, die Menüpunkte erscheinen dann auch direkt beim Drucker ohne die XML bearbeitung.
Comments
Dann fehlt im Prinzip nur noch der Idle Modus. Dann müsste man sich nicht vorab entscheiden, ob es der letzte Druck ist. Man könnte prüfen ob im zeitraum X jeder blog Eintrag mit M105 anfängt, nur dann darf diese Aktion triggern.
Weiß man schon, wann das Update kommt? Ich hatte in einem anderen Beitrag April gelesen.
Gruß
Izzy
Was die nächste Version angeht - für Linux ist sie schon downloadbar wenn man den link in version 0.93.2 ändert - sind nur noch am testen und letzte bugs fixen. Läuft aber schon sehr stabil. Kommt daher denke ich noch diesen Monat.
Leider scheint es ja auch nicht möglich zu sein, den Output der seriellen Konsole in einer .LOG Datei auf dem Raspberry abzuspeichern. Dann könnte ich mir das irgendwie selber parsen und mit einem bash-script realisieren. Ich bin zwar nicht bei C++ zuhause, mit ein paar anderen Sprachen hatte ich jedoch schon zutun und stelle mir die Umsetzung nicht allzu kompliziert vor.
Da gäbe es ja mehrere Ansätze, ich hatte es mit dem Plugin "OctoPrint-PSUControl" realisiert. Es schaut eig. nur ob im Zeitraum X irgendwas im Log erscheint, dabei ignoriert es M105. Es triggert nur, wenn in dieser Zeit keine weiteren Einträge vorhanden sind und die Hotend-Temperatur unter Wert Y ist (Standard 50°).
Bietet sich nicht die connected.log optimal dafür an oder übersehe ich was?
Die Regel Temperatur kleiner x ist sicher wichtig weil sonst ohne Lüfter die Hitze hochsteigt was zu Problemen führen kann.
Die Frage ist was ist idle. Ist idle wenn wir nicht Drucken, also Zeit seit letzem Druckende oder soll jede Aktion ihn zurücksetzen. Ich denke jede Aktion abgesehen von temperaturabfrage macht hier am meisten Sinn. Dann kann man auch mal manuell was testen ohne das er zwischendurch immer ausgeht. Werde es daher als kein druck aktiv und kein Befehl sein x minuten definieren.
Connected log geht wenn man es aktiviert hat. Muss aber aufpassen ob da gerade überhaupt rein geschrieben wird und nicht in eine Drucklog.
Ich freu mich sehr zu hören das die Idee vielleicht doch Anklang findet Dann würde ich vollkommen auf Repetier umsteigen und auch die Vollversion kaufen, dann fehlt mir nichts mehr. Vieles ist schon intuitiver und gefällt mir besser, allein das Management mehrerer Geräte.
Das mit der Temperatur ist in 2 Richtungen z.b. gut, wenn man eine sehr geringe Idle-Zeit hat (z.B. 5 Minuten) aber den Drucker schon aufgeheizt hat und ggfs. noch ein paar Korrekturen am Modell macht, dann schaltet er sich nicht ab und man kann die Druckdatei in Ruhe fertig stellen. Andernfalls könnte man ihn danach immernoch manuell abschalten wenn man sich anders entscheidet. In die andere Richtung natürlich genauso interessant wie von Ihnen aufgeführt, damit Heatbreak/Heatblock genügend abgekühlt sind um keine Heatcreaps zu bekommen.
Idle wird so interepretiert, dass keine weiteren Befehle in der Log vorzufinden sind, M105 wird dabei ja ignoriert. Also wie von Ihnen vorgeschlagen, jede Aktion setzt den Idle-Timer zurück. Idle ist wirklich, wenn der Drucker einfach nur an ist und nichts weiter tut. Der Off-Befehl wird dann nur getriggert Wenn die Temp dabei auch unter Wert X liegt.
Das PSUControl Plugin (im Beispielbild von denen) hat zwar den Switching-Mopde Command mit den M81/M80 und dem Sense Pin, hab ich so aber nie benutzt. In diesem "Command" Dropdown-Feld hat man einfach mehrere Optionen, îch hatte da einfach "System" ausgewählt. PSUControl führt bei mir eig. nur bash-scripts aus, die ich erstellt habe. Ganz primitiv eigentlich Diese scripts haben dann die Funksteckdosen angesprochen. Die Möglichkeit, bash-scripts auszuführen oder gar direkt HTTP-Requests zu senden würde hier ja schon ganz viele Optionen erlauben, für mich auch absolut ausreichend sein.
Zitat dazu:
ich hab mich nun doch vorab entschieden auf Repetier umzusteigen und möchte diese Woche auch noch die Pro-Version kaufen Mir gefallen die Optionen und der Support soweit sehr gut, find ich Klasse.
Mich würde dabei aber noch interessieren, ob man mit diesem Feature in naher Zukunft rechnen darf oder ob ich mich da noch länger gedulden müsste? und wenn es wirklich nur die Möglichkeit ist, dass ich dem trigger entsprechend shell-scripts ausführen darf (also demanch noch keine "vollkommene" GUI-Integrierung).
Meine WLAN-Steckdosen (Sonoff-Tasmota) hab ich übrigens schon über die extcommands eingebunden, druckerspezifisch, ganz simpel über einen direkten curl-befehl in der extcommands, ohne weitere bash-scripts. Auch hab ich mir @execute commands konfiguriert und kann die Drucker zumindest schon einmal automatisch starten lassen. Eine Sache funktioniert allerdings noch nicht, dafür wollte ich aber ungern einen neuen Thread eröffnen.
Ich dachte mir, ich integriere noch einen Button um den Repetier-Dienst neustarten zu können. Leide wollte das nicht funktionieren. Ich hab es über die extcommands mit "sudo service RepetierServer restart" als auch "service RepetierServer restart" probiert, über die Konsole klappt das wunderbar. Der User Repetierserver hat über die sudoers.d daher die Erlaubnis "/usr/bin/curl", "/usr/bin/sudo" als auch "/usr/sbin/service" auszuführen. mit curl z.B. funktioniert das so ja auch, aber mit dem Dienst hat es nicht funktioniert. Hab ich hier einen groben Denkfehler?
Viele Dank
Ich hab es schon installiert und klappt wunderbar, allerdings nur beim ersten mal. Ich hab bei den Gcodes "Drucker herunterfahren" fürs erste meinen execute Befehl "@execute printer2_off" eingetragen. Idle-Zeit von 1 Min. Drucker geht automatisch aus (auch 2 probiert). Wenn ich ihn danach nochmal anmache mit @execute printer2_on dann triggert die 1 Min. nicht mehr. Ich hab gedacht, vllt. wird eine Art Reset mit G28 benötigt, bleibt aber unverändert. Oder gibt es hier eine Blockzeit nach dem ersten Trigger und das Problem löst sich bei einer längeren Offtime von allein? Die kurze Zeit ist natürlich nur für den Test gewählt.
Dann hab ich noch den Bug entdeckt, dass ich Web-Aktionen nicht anlegen kann. Ich komm zwar in die Maske wo man Anzeigename, Name, URL etc. eintippen kann, allerdings bleibt der Button "Web Aktion hinzufügen" ausgeraut. Wenn ich überall Test reinschreibe, wird der Button aktiv aber beim drücken passiert trotzdem nichts. Mit Test1 wird er schon wieder gräulich. Natürlich hab ich es vorab mit richtigen Daten, also der URL über GET probiert.
Ich dachte, vllt. liegt es daran weil ich noch keine PRO-Version hab. Das hat sich aber als falsch herausgestellt, da ich diese eben gekauft hab und auch schon aktiviert habe
Zu der Sache mit dem sich selbst neustarten:
Shutdown/Reboot ist ja schon im 0.93.1 integriert und funktioniert tadellos, das stimmt. Ich dachte, ich ergänze den service-restart einfach Das ist aber nicht so wichtig, war nur so eine Idee. Vom Gedanken her müsste sich dies dann aber mit einem bash script lösen lassen, oder? das könnte den Dienst neustarten bzw. ihn ggfs. beenden und dann neustarten.
Das 1. Problem scheint gelöst zu sein, sobald die 5V-Leitung am USB-Kabel unterbrochen ist und der Drucker wirklich seine Verbindung zu Repetier verliert. Da hatte ich die Tage ein USB-Kabel ersetzt und war zu Faul das Kabel abzukleben
Wenn die Verbindung wirklich unterbunden ist ist es kein Problem. Wenn es verbunden bleibt must du nach 120 Sekunden einen Befehle schicken und dann idle time abwarten. Vermute du warst da was schneller mit testen. Ist leider nicht anders lösbar da das powerdown script ja Befehle sendet und timer zurück setzt muss ich erst sicher sein das die abgearbeitet sind before ich den Mechanismus wieder aktiviere.
Das mit dem Idle ist so voll in Ordnung, die Drucker sollen sich ja eh komplett abschalten und es funktioniert bestens.
Ich habe heute auch noch einen SD Druck direkt lokal am Drucker gestartet. Die Dateien liegen da schon länger, brauch ich aber öfters. Also die Sonoff am Knopf eingeschaltet und einen Druck von der SD-Karte angeworfen. Die Druckererkennung bei Repetier funktioniert so klasse, innerhalb weniger Sekunden ist der Drucker über Repetier Online. Mit der Idle-Erkennung war der Drucker dann auch 15 Min. nach Ende des Druckauftrags ausgeschaltet, das funktioniert absolut genial auch wenn der Auftrag nicht aus Repetier gestartet wird, ist also ganz unabhängig. Egal, wie und wo ich nun einen Druck starte, Repetier sorgt dafür dass meine Geräte bei Nichtnutzung abgeschaltet werden. Klasse!
Bei Octoprint hatte ich oft das Problem dass Octoprint nicht automatisch neu verbindet, trotz manuellem Mapping der Drucker über die udev-Regeln und somit klarer Zuordnung. Deswegen hatten meine bash-scripts unter anderem die Funktion, einen reconnect über die Octo-API zu forcieren mit dem genauen Druckername der über die udev-Regeln definiert war. Das hat absolut zuverlässig funktioniert, WENN ich den Drucker über Octoprint (bzw. dem PSU-Plugin) eingeschaltet habe. Beim lokalen einschalten war es dann halt ne Überraschungskiste, ob Octo automatisch reconnected.
Was ich damit sagen will: Innerhalb einer Woche wurde eine für mich wichtige, zuerst fehlende Funktion weitaus besser integriert als ich es bei Octo je am laufen hatte Dafür möchte ich mich herzlichst Bedanken!
Die Druckdauer war ca. 2 Std.
In der Repetier-Konsole hab ich alle paar Sekunden folgende Zeilen:
Was aber vermutlich ein ganz wichtiger Faktor ist, dass das Gerät nicht abgeschaltet wird ist die Min. Temperatur für das Hotend. Repetier sendet zwar keine Befehle die den Idle-Timer zurücksetzen, aber für eine vollständige Bedingungserfüllung müsste ja die Hotend-Temp unter 50° fallen. Die Temps zeigt ja Repetier ja korrekt an trotz SD-Druck. Also das ist doch perfekt
Hab übrigens die Version aktualisiert. Web actions sollten jetzt auch funktionieren.
Und ich hab noch ein cooles feature hinzugefügt. Wenn du beim druck das usb kabel für weniger als 10 Sekunden trennst und wieder verbindest sollte er einfach weiter drucken. Damit simuliere ich wenn linux wegen spannungsabfall usb kurz trennt. Früher war das ein Druckabbruch - damit hoffe ich die Drucke retten zu können. Wäre cool wenn du das testen könntest an deinem Drucker (was hast du für einen). Bei unseren scheint es so weit zu klappen:-)
Das Update hab ich direkt mal drüber gejagt (0.93.2 überschrieben, korrekt?)
Bei der Installation kamen folgende Hinweise, falls das irgendwie interessant ist zu wissen:
Die Web-Actions kann ich immernoch nicht anlegen. Das scheint iwie Probleme mit Sonderzeichen zu haben.
Mein Befehl lautet wie folgt: http://sonoff-1/cm?cmnd=power off
Das Druckabbruch-Feature teste ich später und berichte. Drucker hab ich mehrere, meistens spiele ich an meiner stark modifizierten Bastelkiste, ursprünglich mal ein i3 Plus Einen Sapphire Core-XY mit einem Lerdge-Board hab ich auch noch, diesen hab ich aber noch nicht an Repetier angeschlossen.
Was mir auch aufgefallen ist und ich der Meinung bin, das war in der stable-version nicht:
Mir werden im Dashboard 3 wlan0 Netzwerke angezeigt. IP v4 und 2x anscheinend eine IP v6 Variante. Alle 3 die gleiche MAC-Adresse. Kein wirklich relevantes Problem aber ich meine halt, das war vorher nicht
Nach dem Update kommen gar keine M105 mehr rein. Der aktualisiert also gar nicht meine Temps.
2. Nachtrag:
Nach erneutem Downgrade auf 0.93.1 und anschließendem Upgrade auf 0.93.2 scheint das wieder zu klappen
Für web cations must du einmal reload im browser machen damit er die neue Version bekommt.
Die Meldungen bei der Installation sind normal.
Das mit den Webactions ist nach wie vor buggy, ich hab schon 2 Browser probiert.
Er nimmt z.B. "http://sonoff-1/cm?cmnd=power off" nicht an, aber "http://192.168.178.34/cm?cmnd=power off" akzeptiert er.
Wenn ich die Funktion dann speichere mit der IP funktioniert der execute auch. Wenn ich hinter das sonoff-1 noch ein .local oder .de etc. hinzufüge würde er es theoretisch auch nehmen.
Irgendwas will da nicht so richtig beim fieldcheck
Aus Testgründen hatte ich aber auch in Repetier-Server mal alle Sonderzeichen entfernt, inkl. dem %20 als auch dem ?=/
Sofern du uns zwingst, einen Domainnamen zu benutzen muss ich wohl auf "sonoff-1.fritz.box" gehen IPs will ich ungern nutzen, die Sonoffs beziehen Ihre IP über DHCP. Ist aufgrund der Leasetime eig. zwar immer gleich, kann man aber nicht ausschließen
Er triggert nach dem anmachen direkt den ausmachen Befehl. Wenn ich den @execute Befehl aus Drucker herunterfahren rausnehme, bleiben sie an.
Nach Downgrade auf die Version vorher klappts wieder.
Wenn er das bei dir sofort innerhalb von sekunden macht wäre es natürlich falsch.
Das einzige was ich hinzugefügt habe ist das hohe temperatur den time rauch zurück setzten, also wartet er bei sd druck auch idle time und geht nicht mehr sofort aus.
Ich kann gerade nicht genau sagen, ob er ausgeht bei unter 50° oder bei über 50° aber einer der Zustände spielte wohl eine Rolle. Die Idle-Zeit hab ich bei beiden getesteten Geräten auf 20 Min, daran kann es also nicht liegen.