Hi,
regarding your questions, I apologize but I haven’t concrete answers to that.
I just can give some common background information.
Q1.
Here’s some background about the TCP protocol (independent of the device): it’s a protocol designed for flow control and data consistency. That means, that TCP has some connection + data flow control mechanisms to manage different streams and to detect if data was sent in the right order and completeness. It is designed even to hold a stream consistent and not starting data transfer from scratch, even if the underlying connection is instable, has hugh jitter, is temporary breaking down, a.s.o.
Therefore, the TCP protocol also has some dedicated mechanisms for enabling and disabling a stream (3-way handshake). So if a connection is not ended in the right way (by sending / receiving the so-called FIN packet from the partner who wants to end the stream + leaving the stream open and keep receiving data, until the communication partner acknowledges the closing of the stream), the TCP stack has to handle the stream as it’s still needed.
So: if one communication partner does not finish the stream as it’s defined by protocol, the other one just don’t know that the stream or even the partner itself is not longer available (in TCP definition, this is a so-called half-open stream).
Of course the’re are things like timeout, wether in the TCP stack or in the application protocol, but there’s no strict definition in the TCP protocol itself, how such timeouts have to be handled (for example how long they should are, a.s.o.)
And: if the B&R PLC is the TCP server (I think so, because I assume you’re a ModbusTCP slave, which means that the device is a TCP server), which makes it even more complicated to really know wether a stream should be closed or not. The TCP server definition, together with the ModbusTCP protocol, defines the servers as the communication part that has to “wait until a request is coming in, then response with the wanted data, then wait for the next request” - so the ModbusTCP server does never send data to a client from it’s own but just on request, which makes it on TCP flow control level very difficult / almost impossible for a server to detect, if a client is still active or not, and therefore if the stream has to kept active or not.
Q2: I’m sorry, I’m not aware of such warning or something similar (as described in Q1, I don’t think that the blocking is active by policy, but just by too much already opened but not right closed sockets to the TCP server).
So if you’re a ModbusTCP slave (I think so), a few things you could monitor are the datapoints in the slave IOmapping like “TimeSinceLastRequest” to get an idea if a communication is still active.
Q3: same as Q2, sorry.
About Q2 + Q3, I assume you’re using the ModbusTCP functionality that is embedded into Automation Runtime, and you’re acting as a ModbusTCP Slave (which is a TCP server), am I right? As I’m as automation engineer don’t have insights into / sources of Automation Runtime or B&R standard libary functions, unfortunately I don’t know the implementation and the limitations behind those functionality.
Have you already checked the PLCs fieldbus logger? Is there any warning / error inside about ModbusTCP protocol or the ModbusTCP interface?
So I just can recommend that you contact the support team from your local B&R office for official assistance and support, so that they can get in touch with the headquarter and define how to proceed.
If doing so, please reference to this B&R Community post so that the colleguages are aware of what we already figured out.
Best regards!
