S7 mit Node Red (node-red-contrib-s7)
-
@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? -
@mickym Die Idee war schon, hier die Anwendungsfälle von Node-Red mit S7 zusammenzutragen, das hat jetzt ein Eigenleben entwickelt. Ich würde gerne den initialen Post lassen und den Rest vielleicht nach "S7 Adapter" verschieben?
-
@fu_zhou sagte in S7 mit Node Red (node-red-contrib-s7):
@mickym Die Idee war schon, hier die Anwendungsfälle von Node-Red mit S7 zusammenzutragen, das hat jetzt ein Eigenleben entwickelt. Ich würde gerne den initialen Post lassen und den Rest vielleicht nach "S7 Adapter" verschieben?
Gut wenn Du allgemeine Fragen zu Node Red hast, kann ich Dir helfen. Zu S7 und auch der entsprechenden Node kann ich Dir nicht helfen.
Zu den einzelnen Punkten.
sinnvolle Erstellung/ Strukturierung von Flows (z.B. an S7 senden, von S7 lesen)
ich würde erst mal alles in einen Flow packen - ich kann aber nicht beurteilen wie umfangreich das wird, kann man aber auch im Nachhinein noch aufteilen mit etwas Nacharbeit.
Spreadsheet-Engineering (z.B. Anlegen der S7 Variablen über Excel und Import in Node Red)
habe ich persönlich noch nicht gemacht. Aber es gibt wohl eine Node, die mächtig ist und auch gepflegt wird. Kannst Du Dir hier mal anschauen: https://flows.nodered.org/node/node-red-contrib-spreadsheet-in
Das könnte ich mit einem einfachen Excelsheet mal in einer Testumgebung mit nachvollziehen.
automatisiertes Verknüpfen der Variablen (z.B. über JSON Import)
Weiß zwar nicht was das bedeutet. Grundsätzlich werden alle Javascript Objekte über JSON ausgetauscht und das beherrscht NodeRed von sich aus, sehr gut - jedenfalls besser als Blockly. Kommt halt darauf an, wo was gespeichert ist und ob bereits im JSON-Format.
Funktionen in Node Red (z.B. Signalverarbeitung als Alternative zu Blockly/ Java-Script)
Man kann in function Nodes komplettes Javascript schreiben. Ich würde Dir jedoch empfehlen, solange wie möglich darauf zu verzichten und ggf. lieber Subflows verwenden, damit Du die Vorteile der grafischen Programmierung nicht verlierst und wieder ins Codieren verfällst.
-
@fu_zhou ,
nur zur Info, habe jetzt einen Negativen Wert geloggt und der kommt vom S7 Adapter, ihr hattet recht. -
@wal danke für die Info... eigentlich gut oder auch schade. Coole Antwort wäre gewesen: Ihr Blinden, das liegt nicht am Adapter, sondern an...
Hast du eine Idee, wo du nachschauen kannst?
-
@fu_zhou ,
bin dabei mir logs in den Adapter einzubauen.
Viel Hoffnung habe ich jetzt erst einmal nicht, aber "schaun wir mal". -
@wal wenn was zeitaufwändiges zu testen wäre, übernehme ich gerne Aufgaben! (so dass sich deine Verschwendung minimiert)
-
@fu_zhou ,
habe direkt vor dem Senden an die PLC im S7-Adapter ein Info Log eingefügt und festgestellt das die Daten korrekt an die Node Snap7 Erweiterung übergeben wird, damit wäre der S7-Adapter wieder raus.
Evtl. kann @apollon77 noch dazu was sagen.adapter.log.info(data.native.dbId + ' - ' + data.native.address + ' - ' + buf.readInt32BE(0)); s7client.DBWrite(data.native.dbId, data.native.address, getByteSize(type, data.native.len), buf, err => next(err)); -
@wal hieße aber, dass ggf. Snap7 doch das Problem ist?
-
@fu_zhou sagte in S7 mit Node Red (node-red-contrib-s7):
@wal hieße aber, dass ggf. Snap7 doch das Problem ist?
Ich würde sagen die node-snap7 Anbindung, da Snap7 sehr oft genutzt wird mit verschiedenen Hochsprachen und da wäre es bestimmt schon aufgefallen.
-
@wal ich habe
/opt/iobroker/node_modules/node-snap7gefunden. 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/snap7steht 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.2Kann 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?
-
@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.
