Anyone worked with TCP/Modbus? Can haz question

envo

Expert Member
Joined
Jan 14, 2014
Messages
3,265
Reaction score
437
So I connect with a TCP client and read a modbus from a TCP Server (arduino unit), if the arduino restarts, it looks like there's no FIN sent to any connected TCP clients to end the connection gracefully.

When this happens I'm in a half-open state, so the tcp client doesn't properly detect it's disconnected. No data or requests to read the modbus is visible on wireshark. I currently am not able to test with the arduino itself, so just getting feedback from the tester (yay covid), and the tester hasn't really been forthcoming with any errors they may see (or the error logs) and my own sneaky error logs being synced to the cloud isn't showing up, so wondering how the hell I'm able to detect a failure anywhere in the pipeline if nothing happens.

The modbus, when it tries to read, gets a 0 byte back if unsuccessful, retries 3 times and then throws an exception, but the 0 byte read only comes back if the tcp server connection is severed gracefully. I think Windows has like a 2 hour timeout on TCP sitting there retrying until it eventually times out, and I'm really not in the mood to go to unmanaged code and write something like that to override the timeout nor change registry settings on the machine the service sits on.

Done in c# but any advice would be great!
 
I would suggest implementing a heartbeat mechanism one network layer up. Eg. Your server could periodically send heartbeat messages out (say, every second). Then if your client goes for longer than 2 secs without seeing a heartbeat, it can assume the connection has been lost.
 
I would suggest implementing a heartbeat mechanism one network layer up. Eg. Your server could periodically send heartbeat messages out (say, every second). Then if your client goes for longer than 2 secs without seeing a heartbeat, it can assume the connection has been lost.
Thanks, that was the first thing I thought of as well, but the engineer who implemented the server itself writes the heartbeat to the Modbus :rolleyes: Kind of a catch 22 and I don't think I'll be able to convince them anytime soon to change it
 
Thanks, that was the first thing I thought of as well, but the engineer who implemented the server itself writes the heartbeat to the Modbus :rolleyes: Kind of a catch 22 and I don't think I'll be able to convince them anytime soon to change it
Tcp keepalives enabled on the connection? But that would be in code too.

Does the arduino send any data unsolicited or is it polled only?
 
Tcp keepalives enabled on the connection? But that would be in code too.

Does the arduino send any data unsolicited or is it polled only?
It's polled only. According to the person who implemented the software, they're unable to send a FIN when the he does a restart (it resets the software on flash, if that makes any sense, my adruino experience is minimal)

When the device is unplugged / ethernet cable plugged out, my software reacts as expected and retries the connection until success.

RE: Keepalives, I believe TCP times out after 1 keep alive message doesn't respond for 2 hours, which in this case isn't acceptable.

There should be an error on Modbus read though, and I'm trying to coax the tester to send me something to confirm this. I could probably then setup my own keep-alive check on Modbus failed to read and reset the TCP connection, but without any evidence (or way to test this specific scenario, and very minimal feedback/screenshots/anything from the tester), it's hard to say if I were to implement something like this, that it will actually work.
 
I think I'm just going to yolo it and set a read timeout on my tcp client and see what the tester comes back with. I hate working with clients' testers...
 
Tell the guy to open a new connection for each poll and immediately close it after each response. No need to keep it open.
 
Top
Sign up to the MyBroadband newsletter
X