Neuer Blogbeitrag: Monatsrückblick - Dezember 2025 🎄

[Wal]

@fu_zhou sagte in S7 mit Node Red (node-red-contrib-s7):

nachdem der S7 Adapter leider beim Übertragen von Daten hin und wieder "Fantasiewerte" an die S7 schickt

Kann ich nicht bestätigen und habe den Adapter schon 4 Jahre im Einsatz.

[fu_zhou]

@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...

[Wal]

@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.

[Wal]

@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.

[fu_zhou]

@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!

[fu_zhou]

@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

[Wal]

@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.

[fu_zhou]

@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...

[Wal]

@fu_zhou ,
nodes7 kann keine Logo, evtl. finde ich ja was.
Viel Zeit werde ich aber nicht verschwenden.

[Wal]

@fu_zhou ,
habe das jetzt eine halbe Stunde mit 1000 und -1000 laufen lassen und kein Fehler bekommen.

Kann ich das irgendwie nachstellen ?

[fu_zhou]

@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)

[fu_zhou]

@wal Geh vielleicht mit dem Trigger auch mal auf eine Sekunde runter

[Zero_two]

@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.

[Wal]

@fu_zhou ,
der poll ist auf 1sec.
Die Zufallszahl habe ich jede Sekunde erzeugt,sieht man im Log.

@Zero_two ,
das mit der Uhrzeit teste ich mal.

[Wal]

@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()));
});

[Zero_two]

[Wal]

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.

[Blockmove]

@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.

[Wal]

@blockmove ,
zu Glück habe ich das Problem nicht, aber danke für die Info, sollen die Jungs sich das mal reinziehen. ;-)

[fu_zhou]

@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?