Modbus TCP dropping connections

Hi everyone,

I’ve been researching on topics related to this question:

Modbus problem ReadHoldingRegisterRequest
Modbus TCP disconnection and no reconnection [SOLVED]
Troubleshoot Modbus RTU device connection
Modbus RTU over TCP Timeout Issue
Server keeps dropping modbus connections to all plc’s

Although Modbus TCP is not my first pick to communicate with a PLC, it’s still what many clients ask for.

How could these constant disconnections be solved?

After setting “Force a reconnect after 3 consecutive timeouts.” to false I stopped getting periodical bad values. But I still think that something is not correctly configured.

I can see that TCP port is 505 but if a set that in the Gateway then communication fails. It is set to the default 502. Another thing I was looking at is “Keepalive TCP”, I wonder if that would make things better or worse.

From Wireshark:
Wago troubleshoot2.pcapng (1.4 MB)

What are your poll rates? Some modbus devices disconnect if idle for 10 seconds.

I’m using default Tag Group configuration for now.

Ok, that’s not it. What are your other options in the device for “Behavior on PLC stop” and “Behavior on fieldbus error” ? I suspect “No data exchange” isn’t the best answer.


I was playing a bit with TCP port, TCP Timeout, and TCP Keepalive. But I get the same behavior.

I’m not using the Gateway’s Modbus addressing. It’s empty

I prefer to use UDT definitions.

I’m not sure where to look for a polling rate other than in Tag Groups.

I only have a timeout here.

By “that’s not it”, I meant “that’s not the problem”. I don’t recommend using the addressing table either, which is why my alternate driver doesn’t support it at all.

I don’t see an obvious problem. I presume all of your item paths are using a 100. prefix, for slave unit 100.

Consider trying my Advanced Modbus Module instead. I’m curious if there is any difference.

Yeap, unit ID is 100.

I’ll keep researching or else I’ll get these messages forever

If you have another Modbus client (Simply Modbus, modpoll, etc…) that can successfully communicate then it often helps to compare Wireshark captures and spot the difference.

1 Like

While using CAS Modbus Scanner I spotted an incorrect addressing in a nested UDT. After fixing it and checking the rest I don’t see errors anymore.

I re-enabled “Force a reconnect after 3 consecutive timeouts.” and the connection is still ok. So, in my case it was bad addressing. In other cases it could’ve been: reading too many tags at the same time, PLC dropping connection due to idle state, Timeout on any side being too short.

With this Wago PLC this problem showed up but with a Schneider PLC it did not drop connections even with bad addressing. Also, I did mess around with the client’s setup so I’m guessing I will get these errors again. I’ll drop posts in this thread if that’s the case.

Thank you!

I think you can leave this disabled and I generally recommend it. It’s only enabled by default for historical reasons that I can no longer remember. Maybe for the “RTU over TCP” driver it makes more sense.

I was thinking the same. If by any reason 3 timeouts occur then the whole device will go down instead of just having problems with X readings.

Thanks again!