' Connection timed out' after many successful reads

[Charles Staton]

I am using Snap7 under the Python wrapper, but I do not think this is a Python question. My application is a multi-threaded logger that is pulling data from multiple sources concurrently; an online database, a couple of AutomationDirect PLCs, a Siemens PLC (IPC427D), et. al. and the routines for each of those sources runs in a separate thread.

My issue is that my Siemens/Snap7 routine will run for a while and then it will stop working, raising this exception:

snap7.snap7exceptions.Snap7Exception: b' ISO : An error occurred during recv TCP : Connection timed out'

I'm not certain exact number of polls or time frame that it works, but I esitmate it's about half an hour, polling every 5 seconds. Once I start getting this exception, I keep getting it in perpetuity. The only way to get it communicating again is to cycle power to the PLC(IPC427D).

I suspect that the problem is that my application is creating a new TCP connection (in the PLC) every time it polls, and eventually the max concurrent TCP connections of the PLC is reached. No amount of waiting will reset this aparently.

Does that explanation sound correct?
If not, what might might be the problem?
If so, what is the solution? I tried implementing the "Disconnect" and "Destroy" functions after my data retrieval, but it did not help.

[Charles Staton]

I checked my logs and got some data that might be helpful. After resetting the PLC and starting my script, I got 1,150 successful responses, one every 5 seconds for 96 minutes, from the PLC before it started refusing to reply. I cannot find the maximum TCP connections of the IPC427D published anywhere from Siemens but if it's 1,150, I guess that would be meaningful.

[G.H.]

It sounds like the connection is not being closed the right way, to many open connections are existing and then it crashes.

I would recommened that you post your problem with some code snippets in the python-snap7 github and perhaps make a packet tracing e.g. via Wireshark. You can see as well if connections are closed or if he uses a different port for each request etc.
It sounds more like a program problem, not a library problem in general.

[Charles Staton]

I have remedied the problem. My logs ran all weekend and the PLC never quit responding. The way I had it programmed, I would create a snap7 object, fetch data from the PLC, close the connection, destroy the connection, and delete the snap7 object. 5 seconds later, do the same over again.

I modified my code to create the snap7 object and establish a connection on first run, and never destroy or close the connection. This fixed the issue.

I consider the solution to be a workaround achieved by modifying the program, but I'm not sure I'm convinced that it was actually a program problem. We should be able to do things the way I was doing it originally, correct? We should be able to open and close connections at will, without using up forever-thereafter reserved TCP connection slots in the PLC, correct?

I suspect the issue is in Snap7 or its python wrapper (not effectively closing and/or destroying the connection), or more likely in the Siemens PLC itself. Shouldn't the PLC have some sort of timeout on those TCP connection slots? If it hasn't seen any traffic in several hours I would expect it to free those up. But this is far from my field of expertise.

[G.H.]

Hmmm...I would have thought your solution would be even the wrong way, because I made the experience with other programs, that a never disconnecting client can cause issues (like still pending, but already done processes and similar).
E.g. if you try to get values with multiple Clients, this number would be limited.

This behaviour is interessting and good to know. I will investigate this behaviour, because I don't want to stuck on a similar problem like you have been.

The TCP timeout is at least on Client side, which is exactly the error you received: snap7.snap7exceptions.Snap7Exception: b' ISO : An error occurred during recv TCP : Connection timed out'

I can't imagine that the PLC cancels a task, as long as a connection is active, but I could imagine depending on your process, that a PLC may take a while longer (I mean seconds), since these requests are normally not priorised.