Blockly -> Logo (S7) Ansteuerung
-
Hallo zusammen,
ich habe mehrere SPS (Logo8), die einwandfrei mit ioBroker arbeiten. Die Anwendung ist bei PV Überschuss, den Heizstab im Boiler automatisch zu aktivieren nach Batterie ausreichend voll.
iobroker sendet alle 2 Sekunden ein true an die SPS übers Netzwerk. In der SPS ist eine Ausschaltverzögerung, die den Heizstab nach 5 Sekunden selbst wieder ausschaltet, sollte der iobroker oder was auch immer ein fehlverhalten zeigen, damit mir nicht im Fehlerfall die Batterie leer gelutscht wird.Es kommt aber ca. 1x im Monat vor, dass genau die "Sicherheitsschaltung" versagt. Das iobroker Objekt steht dann auf Dauerhaft true, der SPS Netzwerkeingang auch und der Boiler heizt und lutscht mir die Batterie unnötig leer. Begrenzung der Heizung habe ich glücklicherweise in der SPS eingebaut, die greift einwandfrei, auch wenn der die Ansteuerung dauerhaft ist.
Ich weiß nicht, wer der Verursacher ist, die Logo, also die S7, oder iobroker im Zusammenspiel mit einem Backup oder was auch immer.
Ich habe schon ein false gesendet (ohne und mit bestätigt) im Objektbaum, keine Chance, die SPS bleibt in Ihrem Verhalten drin, der Netzwerkeingang wird dauerhaft aktiviert. Ich kann diesen Netzwerkeingang nicht wieder zurücksetzen lassen, auch wenn ich iobroker neu starte oder ausschalte. Die SPS stoppen und starten bringt kein Erfolg, der Netzwerkeingang NI32 bleibt aktiv. Erst, wenn ich in der Logo das selbe Betriebsprogramm neu einspiele, wird dieser Netzwerkeingang zurückgesetzt.
Ich habe auch schon einen Reset Eingang NI46 in der SPS eingebaut, bringt aber die SPS trotzdem nicht aus dem Zustand wieder heraus.
Die SPS arbeitet ansonsten einwandfrei weiter.
Ich schätze es ist ein Zusammenspiel, zwischen r/w von iobroker und der SPS.Könnt ihr mir helfen, Hinweis geben, ob ich einen Fehler eingebaut habe oder wie ich das irgendwie verändern könnte?
Blockly:
Objekt:
S7 (Logo8) Einstellungen:
S7 Objekt:
Programmablauf:
-
@mika-0
Ich würde ein Nachlaufrelais statt Ausschaltverzögerung nehmen und nur auf die Flanke vom ioBroker reagieren. -
@peterfido Hi, das Problem ist nicht die das Objekt, was die Verzögerung macht. Wenn der Fehler auftritt sieht man, dass der Eingang dauerhaft aktiviert wird von außen, ohne dass ein Einschaltimpuls vom ioBroker kommt.
-
@mika-0 Nachlaufrelais und Ausschaltverzögerung könnte auch irgendwie das Gleiche sein
Auf die Flanke nur ein Impuls geben, könnte helfen, ein Dauersignal als Fehler zu erkennen. Irgendwas mus den NI32 setzen. Die Logo! Soft ist die 8.3?
Die Logo! macht doch bestimmt noch mehr. Evtl. gibt es Seiteneffekte von anderen Programmteilen.
-
@peterfido Den Impuls nutze ich ja. Daher die Ausschaltverzögerung oder welches Selbsthalterelais auch immer.
Logo Soft ist die V8.3.
Logo8 FS4 hat die FW 1.81.03
Ob das eine 8.1 oder 8.2 ist weiß ich nicht, müsste ich erst zerlegen, da die Erweiterungen dran montiert sind.Bei Ansteuerung aus Bockly gibt es alle 2 Sekunden einen Impuls, der 100ms lang sein sollte. Jedenfalls sehe ich das so (siehe erster Beitrag)
Hatte mal 50ms bei einer anderen Logo, da waren die Impulse beim Rolladen auf und zu mit Taste nicht zuverlässig. Mit 100 ms läuft es aber ohne Probleme.So sieht die Ansteuerung beim Impuls aus
B209 ist nur zur Sicherheit ein weiterer Temp. Fühler der die Aufheizzeit begrenzt auf 61°C
Wenn der Fehler auftritt, leuchtet NI32 dauerhaft rot. Auch die Logo stoppen und starten hilft nicht, es leuchtet sofort wieder rot, obwohl der iobroker vorher ausgeschaltet ist.So ist die Anlage netzwerkseitig verbunden:
Eine Idee? Wenn nicht, welche Einstellungen nutzt du denn im S7 Adapter? -
@mika-0 Wenn da die Logo! was macht, was sie nicht ohne ioBroker machen sollte, dann passt das Programm oder die Remanenz nicht. Als Type für die Impulse ioBroker >> Logo habe ich Button. Diese sollten sich von selbst wieder auf false stellen.
-
@peterfido Fehler heute wieder aufgetreten.
Netzwerkeingang wurde dauerhaft angesteuert. Habe live das Logo Schaltprogramm beobachtet und dann im ioBroker rotiert.Neustart ioBroker: NI32 wird weiterhin angesteuert.
Neustart Pi4 vom ioBroker: NI32 wird weiterhin angesteuert.
Händisch das Objekt im Objektbaum im S7 Adapter false und true,...
Ansteuerung konnte beendet werden. Somit kann ich die Logo als Fehlerquelle ausschließen.S7 Adapter: Abfrage deaktiviert:
Nun kann ich den NI32 mit false auch einschalten. Was ein Unsinn. Der NI32 reagiert also nun auf Veränderung aus dem S7 Adapter. Somit komplett undefiniert.Test wegen deinem Vorschlag Switch-Button im S7 Adapter.
Es ist also egal ob im S7 Adapter Button oder Switch steht. Das ist aus meiner Sicht nur zur Anzeige, bzw. Filterung. Ändert nichts an der Ansteuerung.Habe die Anfrage im S7 Objekt wieder aktiviert. Nun reagiert der NI32 wieder auf das, was er soll.
Also entweder ist es ein Timingproblem, oder der Javaskript Adapter verschluckt sich und vergisst kurzzeitig, dass der nur ein Puls schicken soll und schickt dann dauerhaft ein True.
Habe jetzt das Blockly angepasst. Schicke ein True, warte kurz und sende ein False.
Da kannst echt verzweifeln. Was hältst von der Blockly Idee?
-
@mika-0
Müsstest Du ausprobieren. Ich habe nur noch eine Logo!8 in Betrieb, welche für Tests nicht zur Verfügung steht. Allerdings macht die keine Probleme, sodass ich hier von einem Software-Problem ausgehe.[Die restlichen Aufgaben übernehmen mehrere Eaton Easy E4. Da gibt es die Software Updates ohne Siemens-Konto, welches auch noch zwischenzeitlich aktuell gehalten möchte, und es gibt recht einfach zu nutzende Nodes für Node-Red. Die Möglichkeit der Programmierung per Strukturietem Text finde ich für spezielle Fälle flexibler. Dass es die Easy-Soft nur für Windows unter Intel/AMD gibt, könnte für den ein oder anderen Anwender ein Ausschlusskriterium sein.]
Zum Thema: Ich würde generell einen Merker nutzen, welcher den Status der Kommunikation widerspiegelt. Also etwa alle 10 Sekunden ein Bit invertieren, welches auf einem anderen Datenpunkt wieder zurückkommt. (Watchdog) Ob der Watchdog Logo!-seitig, oder ioBroker-seitig initiiert wird, ist egal. Der muss auf der Gegenseite nur ein Timeout zurücksetzen und dann zurückgeschickt werden.
Diesen Merker dann bei "kritischen" Pfaden in der Logo!-Soft mit einbinden. ioBroker-seitig kann dieser für eine Warnung per Telegramm und Co. genutzt werden.
Wenn der Heizstab auch schon bei "false" getriggert wird, dann reagiert Dein Programm irgendwo nicht nur auf die steigende Flanke.
Blockly nutze ich nicht. Evtl. hilft es, den damit generierten Javascript-Code noch zu posten.
Generell nutze ich verschiedene Merker / Datenpunkte für Soll und Ist. So bekommt man schnell mit, wenn die Kommunikation unterbrochen ist, und man sieht in einer Visualisierung den Ist-Zustand.
