LOGO! and Node-RED communications about node-red-contrib-s7

[tsangiotis]

I observed the same issue with the Modbus node red module so I believe it has something to do with an underlying library.

I ended up using the node red daemon module along with https://github.com/riptideio/pymodbus in a simple script.

[marioishikawa]

What exactly is the error you're reporting? As far as I understood, there's the first issue with the node not being able to reconnect. and another one that crashed node-red.
The first one should be fixed, while the second one has a partial fix, preventing Node-RED to crash, but still dropping the connection (and connecting again automatically thereafter.

If possible, please send the whole logs of node-red with the issue, as I unfortunately don't have a Logo here for testing. Thanks!

Hi, my last message was regarding the first issue, with Node-Red not reconnecting. I'll repeat the test and see what other logs I can send you. Thank you!

[marioishikawa]

I am seeing the same issue. It stays on failure state for an undetermined time. Did you get any solution to this @tsangiotis ?

[gfcittolin]

Hi guys,

The node should always reconnect automatically. There's currently another open issue (#26) regarding a connection being kept open, that is caused by the underlying communication library.
In the case of the S7 family, this shouldn't be an issue, as long as there are enough resources available on the PLC. In the case of Logo!, as we manually set the TSAP values, it may reject the connection because there's already one with the same parameters.

To confirm this hypothesis, could one of you please simulate the issue with the "Debug" option set to "On", and then post here the Node-RED logs of it?

[marioishikawa]

Hi guys,

The node should always reconnect automatically. There's currently another open issue (#26) regarding a connection being kept open, that is caused by the underlying communication library.
In the case of the S7 family, this shouldn't be an issue, as long as there are enough resources available on the PLC. In the case of Logo!, as we manually set the TSAP values, it may reject the connection because there's already one with the same parameters.

To confirm this hypothesis, could one of you please simulate the issue with the "Debug" option set to "On", and then post here the Node-RED logs of it?

I don't have access to one now but I'll do the test in probably 3 weeks.

[nymJ]

I run Node-Red in a docker container. After I few times I got an error with my LOGO! connection:

`[200704,681450500 192.168.178.222 S2] Address DB1,X1106.3 has value false and quality OK
[200704,681467400 192.168.178.222 S2] We are calling back our readDoneCallback.
[200704,864147100 192.168.178.222 S2] Preparing to WRITE M01 to value true
[200704,864490500 192.168.178.222 S2] Clearing write PacketTimeouts
[200704,864864800 192.168.178.222 S2] Sending Write Packet With Sequence Number 621
[200704,867190500 192.168.178.222 S2] Received 1 bytes of S7-data from PLC. Sequence number is 621
[200704,867406600 192.168.178.222 S2] Time is 0 seconds and 2.8 ms.
[200704,867516500 192.168.178.222 S2] DB1,X1104.0 write completed with quality OK
[200705,176608600 192.168.178.222 S2] Reading All Items (readAllItems was called)
[200705,176914600 192.168.178.222 S2] Calling SRP from RAI
[200705,177003100 192.168.178.222 S2] SendReadPacket called
[200705,177913800 192.168.178.222 S2] Sending Read Packet
[200705,181274400] INVALID READ RESPONSE - DISCONNECTING
[200705,181492500] TPKT Length From Header is 42 and RCV buffer length is 41 and COTP length is 2 and data[6] is 128
[200705,181527700] <Buffer 03 00 00 2a 02 f0 80 32 03 00 00 00 03 00 02 00 15 00 00 04 03 ff 04 00 20 08 43 16 16 ff 04 00 08 00 00 ff 04 00 18 01 00>
[200705,181703700] ConnectionReset is happening
27 Dec 00:12:08 - [red] Uncaught Exception:
27 Dec 00:12:08 - RangeError: Index out of range
at checkOffset (buffer.js:831:11)
at Buffer.readInt16BE (buffer.js:975:5)
at checkRFCData (/data/node_modules/nodes7/nodeS7.js:1448:27)
at NodeS7.onResponse (/data/node_modules/nodes7/nodeS7.js:1094:11)
at Socket. (/data/node_modules/nodes7/nodeS7.js:370:20)
at emitOne (events.js:96:13)
at Socket.emit (events.js:188:7)
at readableAddChunk (_stream_readable.js:176:18)
at Socket.Readable.push (_stream_readable.js:134:10)
at TCP.onread (net.js:559:20)

npm ERR! Linux 4.9.125-linuxkit
npm ERR! argv "/usr/local/bin/node" "/usr/local/bin/npm" "start" "--" "--userDir" "/data"
npm ERR! node v6.14.4
npm ERR! npm v3.10.10
npm ERR! code ELIFECYCLE
npm ERR! [email protected] start: node $NODE_OPTIONS node_modules/node-red/red.js -v $FLOWS "--userDir" "/data"npm ERR! Exit status 1
npm ERR!
npm ERR! Failed at the [email protected] start script 'node $NODE_OPTIONS node_modules/node-red/red.js -v $FLOWS "--userDir" "/data"'.
npm ERR! Make sure you have the latest version of node.js and npm installed.
npm ERR! If you do, this is most likely a problem with the node-red-docker package,
npm ERR! not with npm itself.
npm ERR! Tell the author that this fails on your system:
npm ERR! node $NODE_OPTIONS node_modules/node-red/red.js -v $FLOWS "--userDir" "/data"
npm ERR! You can get information on how to open an issue for this project with:
npm ERR! npm bugs node-red-docker
npm ERR! Or if that isn't available, you can get their info via:
npm ERR! npm owner ls node-red-docker
npm ERR! There is likely additional logging output above.

npm ERR! Please include the following file with any support request:
npm ERR! /usr/src/node-red/npm-debug.log`

[marioishikawa]

@gfcittolin on Debug panel, it comes only:
Failure (Bad values)

[gfcittolin]

Hi guys,
Just published version 1.5.4 pointing to a fresh version of nodes7 where a connection issue has been resolved. Hope it will fix this issue. Could you try it out?

[Sascha-Leadbetter]

We are using the 1.6.0 and also get the same error:

nodered_1 | [106045,280937200 192.168.0.1 S2] ReadResponse called
nodered_1 | [106045,281001000 192.168.0.1 S2] Time is 0 seconds and 261.5 ms.
nodered_1 | [106045,281056100 192.168.0.1 S2] Address DB61,INT42 has value 1 and quality OK
nodered_1 | [106045,281076100 192.168.0.1 S2] Address DB61,INT44 has value 9 and quality OK
nodered_1 | [106045,281085900 192.168.0.1 S2] Address DB61,INT46 has value 36 and quality OK
nodered_1 | [106045,281101600 192.168.0.1 S2] Address DB61,CHAR48.72 has value LS 44.2 1.WT nicht vorhanden(3x schlecht) and quality OK
nodered_1 | [106045,281111400 192.168.0.1 S2] Address DB61,DINT134 has value 0 and quality OK
nodered_1 | [106045,281134700 192.168.0.1 S2] We are calling back our readDoneCallback.
nodered_1 | [106045,338518300 192.168.0.3 S2] Reading All Items (readAllItems was called)
nodered_1 | [106045,338623500 192.168.0.3 S2] Calling SRP from RAI
nodered_1 | [106045,338637500 192.168.0.3 S2] SendReadPacket called
nodered_1 | [106045,338720500 192.168.0.3 S2] Sending Read Packet
nodered_1 | [106045,338735700 192.168.0.1 S2] Reading All Items (readAllItems was called)
nodered_1 | [106045,338758000 192.168.0.1 S2] Calling SRP from RAI
nodered_1 | [106045,338765000 192.168.0.1 S2] SendReadPacket called
nodered_1 | [106045,338811900 192.168.0.1 S2] Sending Read Packet
nodered_1 | [106045,596579600] INVALID READ RESPONSE - DISCONNECTING
nodered_1 | [106045,596628000] TPKT Length From Header is 39 and RCV buffer length is 38 and COTP length is 2 and data[6] is 128
nodered_1 | [106045,596656600] <Buffer 03 00 00 27 02 f0 80 32 03 00 00 00 02 00 02 00 12 00 00 04 02 ff 04 00 30 00 01 00 09 00 24 ff 04 00 20 00 00 00>
nodered_1 | [106045,596692800] ConnectionReset is happening
nodered_1 | 16 May 15:57:58 - [red] Uncaught Exception:
nodered_1 | 16 May 15:57:58 - RangeError: Index out of range
nodered_1 | at checkOffset (buffer.js:977:11)
nodered_1 | at Uint8Array.Buffer.readInt16BE (buffer.js:1121:5)
nodered_1 | at checkRFCData (/usr/src/node-red/node_modules/nodes7/nodeS7.js:1474:27)
nodered_1 | at NodeS7.onResponse (/usr/src/node-red/node_modules/nodes7/nodeS7.js:1120:11)
nodered_1 | at Socket. (/usr/src/node-red/node_modules/nodes7/nodeS7.js:390:20)
nodered_1 | at emitOne (events.js:116:13)
nodered_1 | at Socket.emit (events.js:211:7)
nodered_1 | at addChunk (_stream_readable.js:263:12)
nodered_1 | at readableAddChunk (_stream_readable.js:250:11)
nodered_1 | at Socket.Readable.push (_stream_readable.js:208:10)
nodered_1 | at TCP.onread (net.js:601:20)
nodered_1 | npm ERR! code ELIFECYCLE
nodered_1 | npm ERR! errno 1
nodered_1 | npm ERR! [email protected] start: node $DEBUG_OPTIONS $NODE_OPTIONS node_modules/node-red/red.js -v $FLOWS "--userDir" "/data" "--settings" "/usr/src/node-red/settings.js"
nodered_1 | npm ERR! Exit status 1
nodered_1 | npm ERR!
nodered_1 | npm ERR! Failed at the [email protected] start script.
nodered_1 | npm ERR! This is probably not a problem with npm. There is likely additional logging output above.
nodered_1 | at readableAddChunk (_stream_readable.js:250:11)
nodered_1 | at Socket.Readable.push (_stream_readable.js:208:10)
nodered_1 | at TCP.onread (net.js:601:20)

We could also provide wireshark logs. But for us it would be best if in case of an error this exception is catched and our system doesn't crash.

[gfcittolin]

I don't know how I missed that on the logs of @nymJ, but there's indeed another issue, not related to the connection problem we had before v.1.6.0. This one is also, albeit a different one, is also caused by the underlying library.

On the Buffer printed out, we can calculate that the last byte is missing, and that's why it drops the connection in the first place. The bigger issue then happens when we receive the missing byte in another packet, that is, a single byte telegram. The nodeS7 library is definitely not prepared for such a case, and an exception is thrown there.

I'm opening an issue there, so we can work on a fix for it.

[gfcittolin]

@Sascha-Leadbetter could you please post here (or send me privately if you prefer) the wireshark dumps, so I can confirm that we're receiving a single-byte telegram, and then test with the fixes?

[marioishikawa]

Hi guys,
Just published version 1.5.4 pointing to a fresh version of nodes7 where a connection issue has been resolved. Hope it will fix this issue. Could you try it out?

Hi. I just tested with 1.6.0 and I still get the same error:

[71307,665421342 172.22.105.30 S2] Reading All Items (readAllItems was called)
[71307,665725611 172.22.105.30 S2] Calling SRP from RAI
[71307,665833788 172.22.105.30 S2] SendReadPacket called
[71307,666134099 172.22.105.30 S2] Sending Read Packet
[71309,171022086 172.22.105.30 S2] PacketTimeout called with type read and seq 2
[71309,171467501 172.22.105.30 S2] READ TIMEOUT on sequence number 2
[71309,171726042 172.22.105.30 S2] ReadResponse called
[71309,171890885] Processing an undefined packet, likely due to timeout error
[71309,172094061] Timeout error - zero length packet
[71309,172262967 172.22.105.30 S2] Received a ZERO RESPONSE Processing Read Packet due to unrecoverable packet error
[71309,172448956 172.22.105.30 S2] Time is 1 seconds and 506.5 ms.
[71309,172737705 172.22.105.30 S2] Address DB50,DINT0 has value 0 and quality BAD 255
[71309,172937391 172.22.105.30 S2] Address DB50,DINT4 has value 0 and quality BAD 255
[71309,173141557 172.22.105.30 S2] Address DB50,DINT8 has value 0 and quality BAD 255
[71309,173316400 172.22.105.30 S2] Address DB50,DINT12 has value 0 and quality BAD 255
[71309,173488014 172.22.105.30 S2] Address DB50,DINT16 has value 0 and quality BAD 255
[71309,173677545 172.22.105.30 S2] Address DB50,DINT20 has value 0 and quality BAD 255
[71309,173830148 172.22.105.30 S2] We are calling back our readDoneCallback.
24 May 08:28:05 - [error] [s7 endpoint:1f492ce5.3a5b13] Failure (Bad values)

[gfcittolin]

What exactly is the error you're reporting? As far as I understood, there's the first issue with the node not being able to reconnect. and another one that crashed node-red.
The first one should be fixed, while the second one has a partial fix, preventing Node-RED to crash, but still dropping the connection (and connecting again automatically thereafter.

If possible, please send the whole logs of node-red with the issue, as I unfortunately don't have a Logo here for testing. Thanks!

[marioishikawa]

@gfcittolin We believe to have found a solution for this. It was actually on one dependency, nodes7, and I am not sure if this is really a bug on nodes7 for users that are not using Node-Red. We forked both repositories and you can see the fix here. We added bad quality as a condition for comm reset. For us it worked as expected.

[gfcittolin]

Is this still an issue after the improvements done on nodes7? I'm closing this issue for now since the last activity was almost one year ago, but feel free to reopen it and let me know if there's still any kind of connectivity issue.