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.
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.
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.
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.
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.
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.
What do you exactly mean by "spotted an incorrect addressing"? I'm having the same problem with my PFC200. I tried almost everything without no luck, the Modbus TCP connection is being consistently dropped.
