# Modbus TCP dropping connections **URL:** \ **Category:** Ignition\ **Tags:** perspective, ignition81\ **Created:** [July 21, 2022, 8:51am UTC](https://forum.inductiveautomation.com/t/modbus-tcp-dropping-connections/62153 "2022-07-21T08:51:45Z")\ **Posts on this page:** 14\ **Page:** 1
**Author:** ![tupanaster](https://avatars.discourse-cdn.com/v4/letter/t/5daacb/32.png) [@tupanaster](https://forum.inductiveautomation.com/u/tupanaster)\ **Post date:** [July 21, 2022, 8:51am UTC](https://forum.inductiveautomation.com/t/modbus-tcp-dropping-connections/62153/1 "2022-07-21T08:51:45Z")
Hi everyone, I’ve been researching on topics related to this question: [Modbus problem ReadHoldingRegisterRequest](https://forum.inductiveautomation.com/t/modbus-problem-readholdingregisterrequest/22414) [Modbus TCP disconnection and no reconnection [SOLVED]](https://forum.inductiveautomation.com/t/modbus-tcp-disconnection-and-no-reconnection-solved/15689) [Troubleshoot Modbus RTU device connection](https://forum.inductiveautomation.com/t/troubleshoot-modbus-rtu-device-connection/30170) [Modbus RTU over TCP Timeout Issue](https://forum.inductiveautomation.com/t/modbus-rtu-over-tcp-timeout-issue/25140) [Server keeps dropping modbus connections to all plc’s](https://forum.inductiveautomation.com/t/server-keeps-dropping-modbus-connections-to-all-plcs/34216) 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. ![image](https://us1.discourse-cdn.com/inductiveautomation/original/3X/a/0/a09fa24215cd277ba0af0e7963393d30598cd2bf.png) ![image](https://us1.discourse-cdn.com/inductiveautomation/original/3X/1/1/11df25ecfb406aead030ae33c91bc5d893590fc3.png) 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](https://forum.inductiveautomation.com/uploads/short-url/bLdm95MViBHutdQqjfLrOxad9ki.pcapng) (1.4 MB) ---
**Author:** ![pturmel](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/pturmel/32/3295_2.png) [@pturmel](https://forum.inductiveautomation.com/u/pturmel)\ **Post date:** [July 21, 2022, 11:55am UTC](https://forum.inductiveautomation.com/t/modbus-tcp-dropping-connections/62153/2 "2022-07-21T11:55:40Z")
What are your poll rates? Some modbus devices disconnect if idle for 10 seconds. ---
**Author:** ![tupanaster](https://avatars.discourse-cdn.com/v4/letter/t/5daacb/32.png) [@tupanaster](https://forum.inductiveautomation.com/u/tupanaster)\ **Post date:** [July 21, 2022, 11:58am UTC](https://forum.inductiveautomation.com/t/modbus-tcp-dropping-connections/62153/3 "2022-07-21T11:58:43Z")
I’m using default Tag Group configuration for now. ![image](https://us1.discourse-cdn.com/inductiveautomation/original/3X/e/8/e8c1c0f3c0f3d2067b5281bf388225bf0c3145bc.png) ---
**Author:** ![pturmel](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/pturmel/32/3295_2.png) [@pturmel](https://forum.inductiveautomation.com/u/pturmel)\ **Post date:** [July 21, 2022, 12:07pm UTC](https://forum.inductiveautomation.com/t/modbus-tcp-dropping-connections/62153/4 "2022-07-21T12:07:01Z")
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. ---
**Author:** ![tupanaster](https://avatars.discourse-cdn.com/v4/letter/t/5daacb/32.png) [@tupanaster](https://forum.inductiveautomation.com/u/tupanaster)\ **Post date:** [July 21, 2022, 12:35pm UTC](https://forum.inductiveautomation.com/t/modbus-tcp-dropping-connections/62153/5 "2022-07-21T12:35:33Z")
![image](https://us1.discourse-cdn.com/inductiveautomation/original/3X/c/d/cd13a992c4a94f69b870549d9ccfab144ddee270.png) ![image](https://us1.discourse-cdn.com/inductiveautomation/original/3X/b/7/b7148d31e7523e808c287726c315ab62a899457b.png) I was playing a bit with TCP port, TCP Timeout, and TCP Keepalive. But I get the same behavior. > [@pturmel](#): > > Ok, that’s not it. I'm not using the Gateway's Modbus addressing. It's empty ![image](https://us1.discourse-cdn.com/inductiveautomation/original/3X/2/7/279697d31991696a4aa1254354d44150306e8076.png) 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. ![image](https://us1.discourse-cdn.com/inductiveautomation/original/3X/9/3/93dcd6f5003a82cf77219a92a6f9e067b85b9aeb.png) ---
**Author:** ![pturmel](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/pturmel/32/3295_2.png) [@pturmel](https://forum.inductiveautomation.com/u/pturmel)\ **Post date:** [July 21, 2022, 12:57pm UTC](https://forum.inductiveautomation.com/t/modbus-tcp-dropping-connections/62153/6 "2022-07-21T12:57:00Z")
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](https://inductiveautomation.com/moduleshowcase/module/automation-professionals-llc-advanced-modbus) instead. I’m curious if there is any difference. ---
**Author:** ![tupanaster](https://avatars.discourse-cdn.com/v4/letter/t/5daacb/32.png) [@tupanaster](https://forum.inductiveautomation.com/u/tupanaster)\ **Post date:** [July 21, 2022, 1:12pm UTC](https://forum.inductiveautomation.com/t/modbus-tcp-dropping-connections/62153/7 "2022-07-21T13:12:38Z")
> [@pturmel](#): > > I don’t see an obvious problem. I presume all of your item paths are using a `100.` prefix, for slave unit 100. Yeap, unit ID is 100. I'll keep researching or else I'll get these messages forever ![image](https://us1.discourse-cdn.com/inductiveautomation/original/3X/a/6/a6adb497bdeac3c40899a6de82d8be65a03a413f.png) ---
**Author:** ![Kevin.Herron](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/kevin.herron/32/7259_2.png) [@Kevin.Herron](https://forum.inductiveautomation.com/u/Kevin.Herron)\ **Post date:** [July 21, 2022, 1:13pm UTC](https://forum.inductiveautomation.com/t/modbus-tcp-dropping-connections/62153/8 "2022-07-21T13:13:43Z")
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. ---
**Author:** ![tupanaster](https://avatars.discourse-cdn.com/v4/letter/t/5daacb/32.png) [@tupanaster](https://forum.inductiveautomation.com/u/tupanaster)\ **Post date:** [July 21, 2022, 2:51pm UTC](https://forum.inductiveautomation.com/t/modbus-tcp-dropping-connections/62153/9 "2022-07-21T14:51:45Z")
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! ---
**Author:** ![Kevin.Herron](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/kevin.herron/32/7259_2.png) [@Kevin.Herron](https://forum.inductiveautomation.com/u/Kevin.Herron)\ **Post date:** [July 21, 2022, 2:53pm UTC](https://forum.inductiveautomation.com/t/modbus-tcp-dropping-connections/62153/10 "2022-07-21T14:53:35Z")
> [@tupanaster](#): > > I re-enabled “Force a reconnect after 3 consecutive timeouts.” and the connection is still ok. 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. ---
**Author:** ![tupanaster](https://avatars.discourse-cdn.com/v4/letter/t/5daacb/32.png) [@tupanaster](https://forum.inductiveautomation.com/u/tupanaster)\ **Post date:** [July 22, 2022, 6:37am UTC](https://forum.inductiveautomation.com/t/modbus-tcp-dropping-connections/62153/11 "2022-07-22T06:37:44Z")
> [@Kevin.Herron](#): > > I think you can leave this disabled and I generally recommend it. 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! ---
**Author:** ![Dawid\_Rutkowski](https://avatars.discourse-cdn.com/v4/letter/d/22d042/32.png) [@Dawid\_Rutkowski](https://forum.inductiveautomation.com/u/Dawid_Rutkowski)\ **Post date:** [December 16, 2022, 9:24am UTC](https://forum.inductiveautomation.com/t/modbus-tcp-dropping-connections/62153/12 "2022-12-16T09:24:51Z")
Hi, 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. ---
**Author:** ![tupanaster](https://avatars.discourse-cdn.com/v4/letter/t/5daacb/32.png) [@tupanaster](https://forum.inductiveautomation.com/u/tupanaster)\ **Post date:** [December 19, 2022, 8:48am UTC](https://forum.inductiveautomation.com/t/modbus-tcp-dropping-connections/62153/13 "2022-12-19T08:48:07Z")
From that experience I would say just start by adding simple tags. Can you read one or two tags? ---
**Author:** ![Gomez](https://avatars.discourse-cdn.com/v4/letter/g/d78d45/32.png) [@Gomez](https://forum.inductiveautomation.com/u/Gomez)\ **Post date:** [August 6, 2025, 7:16am UTC](https://forum.inductiveautomation.com/t/modbus-tcp-dropping-connections/62153/14 "2025-08-06T07:16:00Z")
Hi, try to check the OMB\_Time or set al least 1 variable with a lower scanclass than 1 second ( ie. 250 ms ) > [@Modbus TCP disconnection and no reconnection \[SOLVED\]](https://forum.inductiveautomation.com/t/modbus-tcp-disconnection-and-no-reconnection-solved/15689): > > Hi, I’m experiencing a problem with ignition v. 7.9.1 ( also recreated on 7.9.4 ) regarding a Modbus TCP connection. I’m trying to estabilish a connection between Scada and an AC500 PM590 CPU from ABB ( also tested with a PM573 ). The onboard ethernet card support something called OMB\_Time, and after looking on internet and on ignition forum, I understood that is closing the tcp connection after a while when no data ( 1000 ms ) is sent from the Scada. So i declared some variables, without using…