S7 mit Node Red (node-red-contrib-s7)
-
@wal Schau mal hier: https://github.com/ioBroker/ioBroker.s7/issues/13
Das Problem ist leider wirklich da und wir haben bisher niemanden finden können, der den S7-Adapter korrigieren kann... -
@fu_zhou ,
ich lese meine Zisterne mit Real ein, ich schau mir das Problem mal an.
Ich nutze eine 300 CPU mit Simatic Manager, wie es mit neueren CPUs und TIA oder Logo aussieht kann ich nicht beurteilen/testen. -
@fu_zhou ,
ok ihr sendet Realwerte an die S7 was ich nicht mache, ich schaue es mir trotzdem mal an.Edit:
Als Notbehelf kannst du den Realwert mal 100 nehmen bei 2-Stellen nach dem Komma und ein Word an die S7 senden und dort den Wert durch 100 wieder teilen. -
@wal Lesen ist wohl nicht das Problem, aber das Schreiben sporadisch schon. Ich habe eine S7-315PN im Einsatz (seit 7 Jahren, der Issue in Github ist ja auch schon 5 Jahre alt - und immer noch aktuell). Es geht hier im Moment um 300er CPUs mit Step 7...
Wäre klasse, wenn du da was findest und beheben kannst!
-
@wal Das Thema in Github bezieht sich zwar auf real, wir haben aber festgestellt, dass das auch bei CHAR und INT der Fall ist...
Hier der entsprechende Kommentar dazu:
https://github.com/ioBroker/ioBroker.s7/issues/13#issuecomment-1782649439 -
@fu_zhou sagte in S7 mit Node Red (node-red-contrib-s7):
@wal Das Thema in Github bezieht sich zwar auf real, wir haben aber festgestellt, dass das auch bei CHAR und INT der Fall ist...
Das ist komisch da ich ein Javascript für die Autokalibration der Zisterne am laufen habe, das auch ohne Probleme funktioniert.
Der Node-Red-Adapter basiert nicht auf Snap7 sondern auf Nodes7 da wird der Hund begraben sein, es kann sein das es gar nicht am S7-Adapter liegt.
-
@wal zeichnest du den gesteuerten Wert "s7.0.DBs.DB2.zisterne_offset_voll" auf (z.B. SQL) und hast dir die Werte mal angeschaut? Ich bin mir fast sicher, dass du da Ausreißer wie im Issue beschrieben finden wirst. Snap7 ist ja auch schon viele Jahre etabliert, ich kann mir nicht vorstellen, dass das Verhalten übersehen wurde und ein Snap7-Problem ist. Aber die Frage wäre, ob jemand (du?) den Adapter mal auf nodes7 umbaut? Ich teste dann gerne...
-
@fu_zhou ,
nodes7 kann keine Logo, evtl. finde ich ja was.
Viel Zeit werde ich aber nicht verschwenden. -
@fu_zhou ,
habe das jetzt eine halbe Stunde mit 1000 und -1000 laufen lassen und kein Fehler bekommen.
Kann ich das irgendwie nachstellen ?
-
@wal das Verhalten ist leider hoch sporadisch und wir haben noch keinen Weg gefunden, das zu reproduzieren.
Kannst du mit einem Vergleicher in der S7 mal einen Ausreißer fangen.: Wenn IN <> der Grenzen von der Zufallszahl => schreibe den Wert in einen DB. Und damit mal ein paar Stunden laufen lassen? Oder alternativ den Wert mit SQL loggen (s. Screenshot oben). Was hast du für eine Poll Delay im Adapter eingetragen? (bei mir sind es 200ms bei einer durchschnittlichen Zykluszeit von 15ms)
-
@wal Geh vielleicht mit dem Trigger auch mal auf eine Sekunde runter
-
@Wal der Fehler läst sich schnell reproduzieren wenn du dir einfach die aktuelle Uhrzeit vom iobroker als dint wert in die s7 schreibst dabei entsteht der Fehler Recht schnell.
-
-
@zero_two ,
jetzt musst du mir nur noch zeigen wie du die Uhrzeit in DInt umrechnest.
Mein Script erzeigt ein Überlauf, da die Zahl anscheinend zu groß ist.schedule("* * * * * *", async () => { setState('s7.0.DBs.DB2.test1', (new Date().getTime())); }); -
-
So, ich habe den Poll auf 200ms gestellt und das Script von @Zero_two erweitert.
Nach 10 Minuten hatte ich einen Objektunterschied festgestellt.
Wenn ich das aber auswerte, liegt der Fehler nicht am S7 Adapter, sondern am Javascript ?
Wie zu sehen lese ich das Objekt vom S7 Adapter wieder aus das ich mit Javascript beschrieben habe und es ist 0.Edit: In der S7 habe ich den DB1.DBD8 (real_test1) auf den DB1.DBD12 (real_test2) geschrieben.
-
@wal said in S7 mit Node Red (node-red-contrib-s7):
Wenn ich das aber auswerte, liegt der Fehler nicht am S7 Adapter, sondern am Javascript ?
Wie zu sehen lese ich das Objekt vom S7 Adapter wieder aus das ich mit Javascript beschrieben habe und es ist 0.Ohne jetzt im Detail dein Problem nachvollziehen zu wollen, aber schau dir mal bei Javascript / Node.js das Thema async / await an.
-
@blockmove ,
zu Glück habe ich das Problem nicht, aber danke für die Info, sollen die Jungs sich das mal reinziehen.
-
@blockmove hmh... im Issue wurde "postuliert", dass das Verhalten nicht auf Werte beschränkt ist, die vom Script kommen:
Es ist dabei auch egal ob es sich um einen Wert aus der Vis oder Javascript handelt. Über VIS fällt das natürlich weniger auf, da hier wesentlich seltener Werte gesendet werden (s. Link oben zum entsprechenden Kommentar).
Ich bin leider nur Anwender, kein Programmierer, d.h. ein bisschen Blockly kriege ich noch hin, aber Codezeilen übersteigen meine Fantasie und Fähigkeiten. Wenn ich mir jetzt async/await anschaue, verstehe ich da erst mal nur Bahnhof, aber: Meinst du dass async/await im Adapter oder in unseren Scripten zum Einsatz kommen sollte, um das Problem der sporadischen, fehlerhaften Datenübertragung zu beheben? Warum hat Node-Red das Problem nicht? -
Mit dem Eingangspost hat das alles nichts mehr zu tun. Sobald jemand NodeRed nutzen will, weil vielleicht ein Adapter Probleme macht, dann wird daraus sofort ein Supportthread für den Adapter gemacht.
Warum gibt es eigentlich die NodeRed Integration im iobroker, wenn man genau damit die Probleme eines Adapters umgehen kann?
Vielleicht lässt man den Threadersteller einfach mal mit dem Tool arbeiten und diskutiert den Rest parallel
Ich nutze mal die iobroker Adapter, mal die NodeRed Nodes. Ich kann zwar nichts zu S7 beitragen, aber der Harmony-Adapter im iobroker oder der snmp v1 Adapter waren auch schlechter, als die entsprechenden Nodes.
Wenn der Adapter Vorteile bringt kann man ja wieder umsteigen. Außerdem kann der Threadersteller so auch die Logik von NodeRed verstehen lernen und muss sich nicht mehr puzzeln rumschlagen, noch zu codieren anfangen.
@Homoran
Vielleicht verschiebt man den Thread hier mal aus dem NodeRed Bereich?
