Error connecting to PLC: Error: read ECONNRESET when connecting to LOGO! 0BA7

[stagadet]

I'm trying to connect nodered to a Siemens LOGO! 0BA7 device with node-red-contrib-s7 library. I already connected it with some LOGO! 0BA8 without any problem. I'm simply trying to read first 16 bits of output (QW0), but it doesn't work and on the log file I read Error connecting to PLC: Error: read ECONNRESET (no more info even setting console level to debug) If I change the IP address of the configuration to that one of a 0BA8 device everything works seamlessly. I can connect with the 0BA7 device with other libraries (such as snap7). I'm using node-red V0.17.3 and node-red-contrib-s7 V1.3.0.

Can someone help me?

[gfcittolin]

Hi,

Some places (like here) say that the 0BA7 does not fully implement the S7 protocol. Others (like snap7) say it should work, so it's unclear for me whether it's supported or not. Unfortunately we don't have any Logo! PLCs here for testing.

Maybe you can record the communication of your 0BA7 with Snap7 using Wireshark and post here, so we can analyze what is different and what is preventing it to work. If the effort of the changes are not too big, we can propose a change to plcpeople/nodeS7, the library we're using for the communication.

[gfcittolin]

Just to make sure: you have used the TSAP connection mode, right?

[stagadet]

Yes, I'm using TSAP connection.

Here there is the communication sniffing of Snap7 (Moka7): the 0BA7 device has the IP address 192.168.7.202 (by the way there are also two connection being established with 0BA8 devices with IP 192.168.7.201 and 192.168.7.200).

I hope it can be useful. If I can help, please tell me.

[gfcittolin]

Thanks for sending the dump. Finally I had some time to analyze it.

Strangely the flow and format of messages seem to be the same of what the nodes7 library expects. Some parameters are indeed different, but it's part of the protocol to negotiate things like number of concurrent jobs, or the PDU size, therefore I see no problem there.

Perhaps could you try to do the same dump, but this time trying to connect with Node-Red, so we could search for any error code from the PLC? (Unfortunately nodes7 does not report the error it encounters when communicating with the PLC, but we're proposing to do some improvements like this at plcpeople/nodeS7#41)

[stagadet]

Hello Guilherme,

thank you for looking at the dump. Here there is the dump of Node-Red communicating with the two 0BA8 (192.168.7.200 and 201) and trying to communicate with the 0BA7 (192.168.7.202). The TSAP may be different from the previous dump, but the devices have the server connection open for both.

Thank you in advance if you can look at it.

[gfcittolin]

From your last dump, I can see the PLC does not even reply to the ISO-on-TCP connection request:

I've compared with the working example you've sent previously and, considering that the TSAP settings are indeed correct, then the only thing I see is the source reference that nodeS7 sends 0x0002, where the samples from snap7 have it with 0x0001 instead.

So, could you maybe try to change it to 0x0001 to see if it works? You should have the file nodes7/nodeS7.js inside your Node-RED installation. Inside it, at line 48 you should have:

self.connectReq = new Buffer([0x03, 0x00, 0x00, 0x16, 0x11, 0xe0, 0x00, 0x00, 0x00, 0x02, 0x00, 0xc0, 0x01, 0x0a, 0xc1, 0x02, 0x01, 0x00, 0xc2, 0x02, 0x01, 0x02]);

could you change it to this instead?

self.connectReq = new Buffer([0x03, 0x00, 0x00, 0x16, 0x11, 0xe0, 0x00, 0x00, 0x00, 0x01, 0x00, 0xc0, 0x01, 0x0a, 0xc1, 0x02, 0x01, 0x00, 0xc2, 0x02, 0x01, 0x02]);

(note the tenth byte only has been changed to 0x01)

Would appreciate if you can test it :) Please let me know if it works, or if you have any other problem

[stagadet]

Hello Guilherme,

thank you for looking at my problem and for pointing out the packet to analyze. I tried modifying the 'source reference' from 0x02 to 0x01, but that didn't change anything. Then I looked at the TSAPs in the packet and I noticed that node-red sent 0x18:00 as src.tsap and 0x0a:00 as dst.tsap, while snap7 sent 0x10:00 as src.tsap and 0x27:00 as dst.tsap. On the LOGO! I have 4 server connections, all of them have the remote tsap set to 0x10:00 and the local tsap that spans from 0x24:00 to 0x27:00, so the snap7 packet uses a connection that is enabled, while the node-red one uses unconfigured connections. Probably LOGO! 0BA8 ignores these connection parameters, while 0BA7 needs them. To be able to connect node-red I have to set (on the node UI) the local tsap to 16:00 (=0x10:00) and the remote tsap to 36:00 (=0x24:00). Probably the TSAPs on the node should be interpreted as hex numbers, then the remote tsap is the tsap of the LOGO as you can see it on the LogoSoft, while the local tsap is that one of the remote device on the LogoSoft. I also tried to set the 'source reference' back to 0x02 and with the correct TSAPs it communicates anyway.

I thank you again for helping me and if I didn't explain something well, please let me know. Also please inform me if you plan to change how TSAPs are interpreted on the node configuration.

[gfcittolin]

Hey stagadet,

Excellent catch! I completely ignored the TSAP when you said that the values could be different from the previous dump, and there was the problem. The field verification was already correct, only the actual parse was wrong.

I've just published version 1.4.1 with the fix for it. Now the fields are correctly interpreted as hex values, exactly as we configure at the PLC side. Ideally we should have a major version bump, but as the field verification was already right, this shouldn't be a big deal. Just remember to fix them at your config when upgrading.

Thanks so much for the report and the analysis!

[stagadet]

Hi,

thank you for updating the node and for the support. I finally managed to install it (I don't know why, but the new version wasn't available on the "manage palette" until today). The connection with the LOGO! now works with the correct TSAPs, and I can read and write values, but sometimes (every few seconds) I get errors like "Error connecting to PLC: Error: read ECONNRESET" or "Error connecting to PLC: Error: write after end".

Do you have any idea on why this happens? I think it didn't happen with 1.4.0 version and the modified TSAPs (although I'm not 100% sure of that and I don't know how to try with the older version). If you want to have a look on what happens on the ethernet communication, here there are the packets exchanged between the Pi and the LOGO (192.168.7.202).