search

st-one-io / node-red-contrib-s7

A Node-RED node to interact with Siemens S7 PLCs
GNU General Public License v3.0
108 stars 58 forks source link

connect to two S7-300 one is fine but the other show Error: read ECONNRESET #34

Closed ccy527 closed 5 years ago

ccy527 commented 5 years ago

Hi All,

I need to connect with two S7-300.(IP Address is 192.168.0.100, and 192.168.0.200) in my device. The strange thing is I can get data successfully from 192.169.0.200, but 192.168.0.100 showed "Error connecting to PLC: Error: read ECONNRESET". All the setting are the same. The only different thing is there is only one PC used WinCC Explorer connect with 192.168.0.200, but two PC used WinCC Explorer connect with 192.168.0.100. I don't know is it anything related with connection resource or not. Please kindly gibe me some suggestion. Thank you very much for your help

marcgeld commented 5 years ago

I have a simular problem. I have two LOGO!8 230RCE with ip 10.0.0.90 and ip 10.0.0.91. The one with ip 10.0.0.90 works well but the second one has problem connecting and I keep getting: "Error connecting to PLC: Error: connect EHOSTUNREACH 10.0.0.91:102" in node-red.

When I use curl to connect I don't se any connection problems (curl telnet://10.0.0.91:102).

Is there possibly a problem handling two devices simultaneously?

gfcittolin commented 5 years ago

@ccy527 ECONNRESET usually means the PLC rejected the connection. Unfortunately we currently can't tell why (there's a major refactor going on in the underlying library which will allow us to do so). Maybe you can verify the diagnosis either at Step7 or at TIA Portal and check the used/free resources. Which PLC do you have?

gfcittolin commented 5 years ago

@marcgeld Unfortunately, I don't have two different PLCs to simulate here in the office, but I tried two connections to the same device without a problem. I also remember to have already connected to 2 different PLCs in the field without a problem.

Despite everything, I'd say EHOSTUNREACH would indicate a network/routing problem (even though it seems to be pretty unlikely given your setup). Dumb question, but have you tried to curl from the same machine where Node-RED was installed? I'm out of ideas why this may be happening :( Maybe you can try to sniff the communication with Wireshark or try another tool to investigate the issue. I'll let you know if I have any idea to debug this

marcgeld commented 5 years ago

I’ll try debug using Wireshark. And yes I have tried the connectivity from inside the Node-red Docker image. The thing is that I am quite sure that this has been working well earlier.

Anyway, thanks for your node-red plug-in!!

ccy527 commented 5 years ago

I’ll try debug using Wireshark. And yes I have tried the connectivity from inside the Node-red Docker image. The thing is that I am quite sure that this has been working well earlier.

Anyway, thanks for your node-red plug-in!!

@marcgeld Did you solve your problem ? If you solved, could you please share your solution to me ? Thank you very much for your help.

ccy527 commented 5 years ago

@ccy527 ECONNRESET usually means the PLC rejected the connection. Unfortunately we currently can't tell why (there's a major refactor going on in the underlying library which will allow us to do so). Maybe you can verify the diagnosis either at Step7 or at TIA Portal and check the used/free resources. Which PLC do you have?

@gfcittolin It's S7-317. I am still checking is it the connection resource problem. Thank you very much for your help.

ccy527 commented 5 years ago

@gfcittolin I got interesting result. When I power up, 2 S7 node show online both, and can read data. BUT, after I do some modification in node-red and click "Deploy". 192.168.0.100 changed to offline, 192.168.0.200 keep online. I need to restart node-red then 192.168.0.100 go to online again. Any idea ? Thanks.

gfcittolin commented 5 years ago

There's a chance that what you're experiencing is being caused by a connection leakage of the nodes7 library when dropping the connection. I've just worked on a fix for it, and as soon as we have a new release I'll kindly ask you guys to try it out. If the problem still persists, maybe we can try to investigate a bit more with logs and wireshark captures

MaFoB commented 5 years ago

Thank you for node-red-contrib-s7, Guilherme ! I have experienced a behaviour similar to ccy527's comment on 31 Jan with more than 1 S7 currently using 1.6.0 @ node-red v0.20.5 <=> Should it be fixed there, already?

gfcittolin commented 5 years ago

There shouldn't be connection problems anymore. :confused: Does the issue happens only when two connections are made to different PLCs at the same time? If possible, could you please enable the debug mode, simulate the issue, and then post the logs here?

MaFoB commented 5 years ago

The issue happens when connections are made to more than 1 different PLCs at the same time. By now, I could not reproduce it significantly. Additionally, a SIEMENS OPC UA Server is reading variables out of all those PLCs at the same time. After having excluded this influence next week I will come up with logs in case the issue will not be solved then.

By the way: Do you have some hints for choosing an adequate node-s7 setup for connection cycle time (default 500ms) and timeout (default 1500ms) depending on the number of variables or other relevant boundary conditions ?

gfcittolin commented 5 years ago

It depends a lot on the type/amount of variables you're reading, how sparse they are, and on the network you're in. The bigger/wider the variables (e.g BOOL vs DWORD), the sparser they are (e.g. all in a contiguous DB vs scattered around multiple memory areas) and the slower your network is (mainly regarding ping times, not throughput) , the more it will cost you to perform a read cycle, and therefore the less often you can read them. The actual values will of course depend you your environment.

Let me know then if you can simulate the connection issue.

MaFoB commented 5 years ago

Good news: OPC UA Server disabled => the connections work fine :) For the test, I have chosen a cycle time of 5000ms (with timeout 1500ms) and will keep the setup like that. OPC UA Server enabled again => most connections still stable, some not. - Well, just good to know.

MaFoB commented 5 years ago

More good news: We found and disabled another visualisation agent which was looking into the PLCs. After that, connections remain stable now. My part of this issue is supposed to be solved then.

gfcittolin commented 5 years ago

Thanks for sharing your findings. Looks like there's no issue with the Node anymore, therefore I'm closing the issue.

Feel free to continue any discussion related to the topic or reopen it in case of other issues.