Neuer Blogbeitrag: Monatsrückblick - Dezember 2025 🎄

[fu_zhou]

@wal ich habe

/opt/iobroker/node_modules/node-snap7

gefunden. Wenn ich hier "package.json" anschaue

{
  "name": "node-snap7",
  "main": "./lib/node-snap7.js",
  "version": "1.0.7",

ist die aktuellste Version (1.0.7) installiert. Kannst du im S7-Adapter erkennen, ob da bei einem Adapter-Update (war kürzlich) immer der aktuelle Wrapper installiert wird?

Wenn ich allerdings Snap7 anschaue

/opt/iobroker/node_modules/node-snap7/deps/snap7

steht da in der " HISTORY.txt"

======================================================================[2015-06-14]
Version 1.4.0 - release for gourmets (fully compatible with 1.0.0)
----------------------------------------------------------------------------------

Version 1.4.0, während die 1.4.2 die aktuelle Version ist. Auf die verweist auch der Wrapper:

Current node-snap7 version: 1.0.7
Current snap7 version: 1.4.2

Kann da die Problematik herrühren? Hättest du eine Idee, wie man Snap7 in dieser Konstellation upgraden kann? Würde eine Neuinstallation des Adapters die aktuellen Versionen ziehen?

[Wal]

@fu_zhou ,
die Version 1.0.7 ist die aktuellste, die ist für Nodejs 20 gemacht worden und ca. 2 Wochen aktiv.
In nutze Node20 ist also das Neuste, siehst du auch unter"/opt/iobroker/node.../node-snap7".
Die Snap7 1.4.2 ist von 2017 und wie ich sehe auch das neuste Paket.

[fu_zhou]

@wal Ich habe aktuell das Gefühl, dass eine alte Snap7 Version installiert ist (Hinweis in HISTORY.txt auf die 1.4.0) oder ist das ein Überbleibsel aus alten Tagen und es ist tatsächlich die 1.4.2 aktiv? Kann man das irgenwo erkennen, ob sich node-snap7 die 1.4.2 gezogen hat?

[Thomas Braun]

@fu_zhou

cd /opt/iobroker
npm ls -a | grep snap7

mal versucht?

[fu_zhou]

@thomas-braun das Ergebnis ist:

│ └─┬ node-snap7@1.0.7

in

/opt/iobroker/node_modules/node-snap7

liefert der Befehl

npm ERR! code ELSPROBLEMS
npm ERR! missing: bindings@~1.5.0, required by node-snap7@1.0.7
npm ERR! missing: nan@~2.18.0, required by node-snap7@1.0.7
npm ERR! missing: prebuild-ci@^4.0.0, required by node-snap7@1.0.7
npm ERR! missing: prebuild-install@^7.1.1, required by node-snap7@1.0.7
npm ERR! missing: prebuild@^12.1.0, required by node-snap7@1.0.7
node-snap7@1.0.7 /opt/iobroker/node_modules/node-snap7

npm ERR! A complete log of this run can be found in: /home/iobroker/.npm/_logs/2023-12-13T18_38_17_761Z-debug-0.log

Hier das Logfile 2023-12-13T18_38_17_761Z-debug-0.log

Kein Hinweis auf die Version von Snap7

[Wal]

@fu_zhou ,
wenn du node-snap7 auf Github durchsuchst, siehst du das der Autor seinen eigenes Snap7 nutzt.
Wenn er in der Readme schreibt, das das 1.4.2 ist wird das auch stimmen.

[fu_zhou]

@wal okay... schaust du noch weiter in die Problematik, oder bist du erst mal durch? Wenn du durch wärst: In welche Richtung könnte ich weitermachen? Issue in node-snap7 eröffnen?

[Wal]

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

Issue in node-snap7 eröffnen?

Ja würde ich machen, aber alle Daten dazuschreiben. Pollzeit vom Adapter und Schreibzugriffe pro Sekunde.

[fu_zhou]

@wal done: https://github.com/mathiask88/node-snap7/issues/96

Schreibzugriffe pro Sekunde: Wie kriegt man die raus?

[Wal]

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

Schreibzugriffe pro Sekunde: Wie kriegt man die raus?

Du weist doch wie oft deine Skripte das Objekt beschreiben, oder ?

[fu_zhou]

@wal ja, das ist bei manchen Scripten aber auch abhängig von der Wertänderung. Im Adapter kann nirgendwo eingestellt werden "nur bei Änderung schreiben", daher gehe ich davon aus, dass Werte, die unter DBS auf "RW" gesetzt sind, alle 200ms (=mein Poll delay) zyklisch geschrieben werden, oder? Und zyklisch (Poll delay) gelesen werden alle Werte, die auf "Abfrage" stehen, denke ich. Wobei der Zeitstempel vom Objekt sich nicht alle 200ms ändert, sondern nur bei Änderung...

[Wal]

@fu_zhou ,
ich habe das Script gestern Morgen nochmal gestartet und bis heute Abend keinen Fehler mehr bekommen.
Edit: Ok, eben war er nach 1min da. ;-)

[fu_zhou]

@wal Also an node snap7 scheint es nicht zu liegen. Ich lasse aktuell folgende 4 Szenarien parallel laufen, wobei dabei immer die selbe S7 beschrieben wird.
1. Instanz S7.0: Poll delay eingestellt: 200 ms, gemessene s7.0.info.poll_time: zwischen 100 und 190 ms (ca. 750 Objekte), ich möchte aber nicht ausschließen, dass da hin und wieder mal > 200 ms auftaucht

Ich schreibe mit Blockly eine Zufallszahl von -99 bis +99 1x pro Sekunde als real in den DB23.DBD488. Hier kommt es zu den sporadischen Ausreißern:

2023-12-29 19:32:41.319  - S7_Komm_Test: Abweichung S7.0 488
2023-12-29 19:32:41.320  - S7_Komm_Test: -16127454208 (zurueckgelesener Wert)
2023-12-29 19:32:41.320  - S7_Komm_Test: 180 (poll_time)

2. Instanz S7.1: Poll delay eingestellt: 500 ms, gemessene s7.1.info.poll_time: zwischen 5 und 25 ms (nur der eine Wert zum Testen), beim Ausreißer wurde aber eine deutlich höhere poll_time geloggt, als "normal".

Ich schreibe mit Blockly eine Zufallszahl von -99 bis +99 1x pro Sekunde als real in den DB22.DBD92. Hier kommt es zu den sporadischen Ausreißern:

2023-12-29 19:50:19.460  - S7_Komm_Test: Abweichung S7.1 92
2023-12-29 19:50:19.461  - S7_Komm_Test: 228089394688736360000
2023-12-29 19:50:19.461  - S7_Komm_Test: 128

3. Instanz S7.0 in einer separaten VM mit einer neuen iobroker-Installation, in der so gut wie nichts läuft, außer dem Kommunikationstest. Poll delay eingestellt: 200 ms, gemessene s7.0.info.poll_time: zwischen 5 und 40 ms (nur die zwei Test-Objekte), beim Ausreißer wurde eine "normale" poll_time geloggt.

Ich schreibe mit Blockly eine Zufallszahl von -99 bis +99 1x pro Sekunde als real in den DB23.DBD612. Hier kommt es zu den sporadischen Ausreißern:

2023-12-29 22:11:12.237 - info: Test.S7_Komm_Test: Abweichung Dev 612
2023-12-29 22:11:12.239 - info: Test.S7_Komm_Test: -137543207092224
2023-12-29 22:11:12.239 - info: Test.S7_Komm_Test: 17

4. Umgehung des S7 Adapters: in der VM mit der neuen iobroker-Installation lasse ich in der iobroker-Umgebung dein Javascript laufen und schreibe alle 500ms einen real Wert in den DB23.DBD620:

var sleep = require('system-sleep');
var snap7 = require('node-snap7');

var s7client = new snap7.S7Client();
s7client.ConnectTo('1.1.1.1', 0, 2, function(err) {
    if(err)
        return console.log(' >> Connection failed. Code #' + err + ' - ' + s7client.ErrorText(err));
    let ende=true;

    do {
      sleep(500); 
      let buf;
      buf = Buffer.alloc(4);
      buf.writeFloatBE(parseInt(Math.floor(Math.random() * 198 - 99), 10), 0, 4);
              
      s7client.DBWrite(23, 620, 4, buf, function(err, res) {
        if(err)
            return console.log(' >> DBWrite failed. Code #' + err + ' - ' + s7client.ErrorText(err));

        //console.log(buf)
      });

      s7client.DBRead(23, 620, 4, function(err, res) {
        if(err)
            return console.log(' >> DBRead failed. Code #' + err + ' - ' + s7client.ErrorText(err));
      });
    } while (ende);
});

DB23.DBD620 lese ich im Blockly ein und übeprüfe auf Ausreißer (>99, < -99). Hier gibt es die Ausreißer nicht und ich frage mich, wie node snap7 die Zyklus-/ Poll-Zeit festlegt, die ist im Script ja nicht angegeben.

Kann also die im S7 Adapter angegebene Poll-Delay etwas mit den Ausreißern zu tun haben?

Noch ein interessanter Effekt: Wenn ich das Javascript in iobroker stoppe, wird es als "läuft nicht angezeigt", der Wert in DB23.DBD620 verändert sich aber munter weiter, also muss das Skript noch irgendwie laufen. Der Wert bleibt erst stehen, wenn ich die Javascript-Instanz stoppe...

[Wal]

@fu_zhou ,
zu 4.
Das Script habe ich direkt im Terminal laufen ohne iobroker und das bringt wie bei dir keine Fehler.
Der Pollwert macht nur der s7-Adapter, beim Script ist es der Sleep-Wert.
In Snap7 gibt es kein Poll-Wert.
Interessant das im iobroker im Javascript-Adapter laufen zu lassen, muss ich mal testen, ;-)
Fazit ist es liegt doch am s7-Adapter , leider reichen da meine nodejs Kenntnisse nicht mehr aus.

[Wal]

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

Noch ein interessanter Effekt: Wenn ich das Javascript in iobroker stoppe, wird es als "läuft nicht angezeigt", der Wert in DB23.DBD620 verändert sich aber munter weiter, also muss das Skript noch irgendwie laufen. Der Wert bleibt erst stehen, wenn ich die Javascript-Instanz stoppe...

Das Script ist in deiner Endlosschleife gefangen solange der Fehler nicht kommt und in deinem Script immer.

let ende=true;
do {
} while (ende);

ende wird bei dir nie false.
In meinem Script aber auch, da der Fehler nicht kommt. ;-)
Mein Script:

var snap7 = require('node-snap7');
var sleep = require('system-sleep');

var s7client = new snap7.S7Client();
s7client.ConnectTo('192.168.12.222', 0, 2, function(err) {
    if(err)
        return console.log(' >> Connection failed. Code #' + err + ' - ' + s7client.ErrorText(err));
    let ende=true;
    do {
      sleep(500); 
      let buf;
      buf = Buffer.alloc(4);
      buf.writeInt32BE(parseInt(Math.floor(Math.random() * 198 - 99), 10), 0, 4);

      s7client.DBWrite(2, 12, 4, buf, function(err, res) {
        if(err)
            return console.log(' >> DBWrite failed. Code #' + err + ' - ' + s7client.ErrorText(err));

        //console.log(buf)
      });

      s7client.DBRead(2, 16, 4, function(err, res) {
        if(err)
            return console.log(' >> DBRead failed. Code #' + err + ' - ' + s7client.ErrorText(err));

        //console.log(res);
        if (res.readInt32BE() != buf.readInt32BE()) {
          console.log('falsch');
          ende=false;
        }
      });   
    } while (ende);
});

edit:
hier noch ein Script das sich beenden lässt.

var snap7 = require('node-snap7');

var s7client = new snap7.S7Client();
s7client.ConnectTo('192.168.12.222', 0, 2, function(err) {
    if(err)
        return console.log(' >> Connection failed. Code #' + err + ' - ' + s7client.ErrorText(err));
});

schedule("* * * * * *", async () => {
    let buf;
    buf = Buffer.alloc(4);
    buf.writeInt32BE(parseInt(Math.floor(Math.random() * 198 - 99), 10), 0, 4);

    s7client.DBWrite(2, 12, 4, buf, function(err, res) {
    if(err)
        return console.log(' >> DBWrite failed. Code #' + err + ' - ' + s7client.ErrorText(err));
    });

    s7client.DBRead(2, 16, 4, function(err, res) {
        if(err)
            return console.log(' >> DBRead failed. Code #' + err + ' - ' + s7client.ErrorText(err));
            if (res.readInt32BE() != buf.readInt32BE()) console.log('falsch');
    });  
});

[Wal]

@fu_zhou ,
habe das Testscript so umgeschrieben das der Schreibbefehl direkt an snap7 und der Lesebefehl über den s7-Adapter getätigt wird. Es kommen keine falschen Werte mehr.
Kannst du die Schreibbefehle in deinen Scripten auch so umschreiben und testen ?

var snap7 = require('node-snap7');
let buf;

var s7client = new snap7.S7Client();
s7client.ConnectTo('192.168.12.222', 0, 2, function(err) {
    if(err)
        return console.log(' >> Connection failed. Code #' + err + ' - ' + s7client.ErrorText(err));
});

schedule("* * * * * *", async () => {
    buf = Buffer.alloc(4);
    buf.writeInt32BE(parseInt(Math.floor(Math.random() * 198 - 99), 10), 0, 4);

    s7client.DBWrite(2, 12, 4, buf, function(err, res) {
    if(err)
        return console.log(' >> DBWrite failed. Code #' + err + ' - ' + s7client.ErrorText(err));
    });
});

on({ id: 's7.0.DBs.DB2.test2', change: 'ne' }, async (obj) => {
  let value = obj.state.val;
  const valbuf = buf.readInt32BE();
  if (value != valbuf) {
    setState('javascript.0.scriptEnabled.Test.Zufall1', false);
    console.log('ungleich');
    console.log(getState('s7.0.DBs.DB2.test1').val);
    console.log(value);
    console.log(valbuf);
  }
});

[fu_zhou]

@wal So, habe das Script auf mein System angepasst (IP-Adresse S7, Adresse DB+Doppelwort, write/ read Float) und ich lasse es weiterlaufen, wenn eine Abweichung erkannt wird, so dass die nächste auch wieder geloggt wird. Ich bin gespannt, traue mich aber, vorherzusagen, dass es keine Ausreisser geben wird...

var snap7 = require('node-snap7');
let buf;
 
var s7client = new snap7.S7Client();
s7client.ConnectTo('1.1.1.1', 0, 2, function(err) {
    if(err)
        return console.log(' >> Connection failed. Code #' + err + ' - ' + s7client.ErrorText(err));
});
 
schedule("* * * * * *", async () => {
    buf = Buffer.alloc(4);
    buf.writeFloatBE(parseInt(Math.floor(Math.random() * 198 - 99), 10), 0, 4);
 
    s7client.DBWrite(22, 92, 4, buf, function(err, res) {
    if(err)
        return console.log(' >> DBWrite failed. Code #' + err + ' - ' + s7client.ErrorText(err));
    });
});
 
on({ id: 's7.0.DBs.DB22.Reserve92', change: 'ne' }, async (obj) => {
  let value = obj.state.val;
  const valbuf = buf.readFloatBE();
  if (value != valbuf) {
    //setState('javascript.0.scriptEnabled.Test.Zufall1', false);
    console.log('Abweichung S7.0 DB22.Reserve92');
    //console.log(getState('s7.0.DBs.DB2.test1').val);
    console.log(value);
    console.log(valbuf);
  }
});

Ich habe echt irgendwie "Poll-Delay" in Verdacht, ist aber nur ein Gefühl...

[fu_zhou]

@wal in der S7 Konfigration von Node Red muss man eine Zyklsuzeit angeben:

Warum kommt Snap7 da ohne aus? Wie werden dann Lese-/ Schreibzyklen organisiert, um den Bus und die CPU nicht zu überlasten?

[Wal]

@fu_zhou ,
wenn du dir die api von node snap7 anschaust gibt es das nicht.
Die Zykluszeit ist nur die Zeit in was für einen Abstand die Daten von der PLC geholt werden und das macht das Programm das node snap7 nutzt, in node red wird das nicht anders sein.

edit: habe mir nodes7 angeschaut was node-red-contrib-s7 nutzt, da ist es genauso das es kein poll gibt.
editedit: Der S7-Adapter und node-red-contrib-s7 machen und nutzen den Poll, nicht node-snap7 und nodes7.

[fu_zhou]

@wal Ah okay. Was passiert, wenn man aus dem S7-Adapter Poll-Delay einfach mal rauschmeißt? Wird dann eben so schnell kommuniziert, wie es die S7 gerade schafft? Steht in der snap7 API, dass man sich um den Kommunikationszyklus kümmern muss? Ich habe da nichts explizites gefunden in der API Beschreibung...