# Modbus RTU over TCP: Single slave timeout causes driver to drop entire TCP connection (FailureType==DISCONNECTED) **URL:** \ **Category:** Ignition\ **Tags:** ignition83, modbus\ **Created:** [May 26, 2026, 12:17pm UTC](https://forum.inductiveautomation.com/t/modbus-rtu-over-tcp-single-slave-timeout-causes-driver-to-drop-entire-tcp-connection-failuretype-disconnected/115707 "2026-05-26T12:17:02Z")\ **Posts on this page:** 18\ **Page:** 1
**Author:** ![piperra](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/piperra/32/85541_2.png) [@piperra](https://forum.inductiveautomation.com/u/piperra)\ **Post date:** [May 26, 2026, 12:17pm UTC](https://forum.inductiveautomation.com/t/modbus-rtu-over-tcp-single-slave-timeout-causes-driver-to-drop-entire-tcp-connection-failuretype-disconnected/115707/1 "2026-05-26T12:17:02Z")
Hi everyone, I'm running into a frustrating issue with the Modbus driver in Ignition 8.3, and I'm hoping someone can point me in the right direction. **The Architecture:** - **Gateway:** Ignition 8.3 - **Hardware:** 6 Modbus RTU sensors connected via a 2-wire RS-485 bus to a MOXA NPort 5250A. - **MOXA Setup:** Configured as a transparent TCP Server (no Modbus routing intelligence, just passing TCP packets to the serial line). - **Ignition Setup:** A single Modbus TCP device connection pointing to the MOXA's IP and port. **The Problem:** Everything works perfectly when all 6 sensors are online. However, if one single slave loses power or dies (in my case, the sensor for DCM 129), the Ignition Modbus driver drops the _entire_ TCP connection. Instead of just marking the tags for that specific Unit ID as "Bad" and moving on to poll the next healthy slave, the driver waits for the timeout, throws a `TimeoutDaemon` error, and immediately resets the socket. This triggers a cascade of `FailureType==DISCONNECTED` errors for all the other healthy slaves on the same bus, interrupting their data flow. ![image](https://us1.discourse-cdn.com/inductiveautomation/original/3X/d/6/d67da26632b3a5da354462c743ac4730808adbbf.png) As you can see in the Tag Browser, DCM 129 goes `Bad`, but it disrupts the connection to the MOXA. ![image](https://us1.discourse-cdn.com/inductiveautomation/original/3X/c/3/c311c6ac325878d5503ee30cb7cc1d2271e6449f.png) The logs show exactly what happens: one `TIMEOUT` immediately forces the driver to disconnect. Plaintext ```python java.lang.Exception: Request failed by TimeoutDaemon due to timeout: ScheduledRequest[com.inductiveautomation.xopc.drivers.modbus2.requests.ReadHoldingRegistersRequest...] ... Request failed. FailureType==DISCONNECTED java.lang.Exception: Driver is disconnected. ``` **What I have tried so far:** - Lowered the device **Timeout** in Ignition to `500ms`. - Set **Max Concurrent Requests** to `1` (since it's a half-duplex RS-485 bus). - Set **Retries** to `0` to avoid locking up the serial line. - Unchecked **Reconnect After Consecutive Timeouts** in the advanced device properties. Despite unchecking "Reconnect After Consecutive Timeouts", the driver still forces a socket disconnection upon a timeout. **My Question:** Is there any hidden setting or specific configuration in the Modbus driver to prevent it from resetting the TCP socket when a single RTU slave times out? I just want it to skip the dead slave and keep polling the rest. Or is my only option to create 6 separate Modbus device connections in Ignition (one for each Unit ID) pointing to the same IP/Port to isolate the TCP threads? Thanks in advance for the help! Best regards, ---
**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:** [May 26, 2026, 12:30pm UTC](https://forum.inductiveautomation.com/t/modbus-rtu-over-tcp-single-slave-timeout-causes-driver-to-drop-entire-tcp-connection-failuretype-disconnected/115707/2 "2026-05-26T12:30:48Z")
> [@piperra](#): > > any hidden setting Not that I'm aware of. > [@piperra](#): > > create 6 separate Modbus device connections Not possible with ethernet-to-serial conversions. RTU is a single-master technology. Unless I misunderstood your setup: are you using the RTU over TCP driver with a Moxa serial device, or an actual Modbus TCP gateway (Modbus TCP driver)? If remote serial with RTU over TCP, you probably want to switch to my alternate driver. I handle timeouts per your desire. ---
**Author:** ![piperra](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/piperra/32/85541_2.png) [@piperra](https://forum.inductiveautomation.com/u/piperra)\ **Post date:** [May 26, 2026, 12:47pm UTC](https://forum.inductiveautomation.com/t/modbus-rtu-over-tcp-single-slave-timeout-causes-driver-to-drop-entire-tcp-connection-failuretype-disconnected/115707/3 "2026-05-26T12:47:50Z")
Hi Phil, thanks a lot for jumping in! To answer your question: Yes, you understood it perfectly. I am using the native **Modbus RTU over TCP** driver in Ignition, pointing to a transparent Moxa serial device (NPort 5250A), which is connected to a 2-wire RS-485 bus. The Moxa is not doing any Modbus routing or queuing, just acting as a transparent TCP server. And you are absolutely right about the 6 separate device connections. Since it's a transparent NPort on a half-duplex RS-485 line, multiplexing TCP connections would just cause packet collisions on the serial side. I've scrapped that idea. It's a bummer that the native driver resets the entire socket upon a single slave timeout, especially since this bus is critical for us and a single offline sensor shouldn't bring down the rest. I've heard great things about your Advanced Modbus driver. Could you point me to where I can get it and try it out? If it handles these per-slave timeouts gracefully without dropping the TCP socket, it sounds exactly like what we need to solve this. Thanks again! ---
**Author:** ![Matrix\_Engineering](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/matrix_engineering/32/19781_2.png) [@Matrix\_Engineering](https://forum.inductiveautomation.com/u/Matrix_Engineering)\ **Post date:** [May 26, 2026, 12:51pm UTC](https://forum.inductiveautomation.com/t/modbus-rtu-over-tcp-single-slave-timeout-causes-driver-to-drop-entire-tcp-connection-failuretype-disconnected/115707/4 "2026-05-26T12:51:41Z")
> [@piperra](#): > > Could you point me to where I can get it and try it out? > **[Automation Professionals](https://www.automation-pros.com/modulesales.html)** ---
**Author:** ![michael.flagler](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/michael.flagler/32/26272_2.png) [@michael.flagler](https://forum.inductiveautomation.com/u/michael.flagler)\ **Post date:** [May 26, 2026, 12:59pm UTC](https://forum.inductiveautomation.com/t/modbus-rtu-over-tcp-single-slave-timeout-causes-driver-to-drop-entire-tcp-connection-failuretype-disconnected/115707/5 "2026-05-26T12:59:38Z")
I've had the same issue myself in 8.1 and with the Moxa MB3270 device I just created 2 connections since we only ever have a single RTU device per physical serial port. I agree though that a single device going offline shouldn't take down the entire connection. ---
**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:** [May 26, 2026, 1:01pm UTC](https://forum.inductiveautomation.com/t/modbus-rtu-over-tcp-single-slave-timeout-causes-driver-to-drop-entire-tcp-connection-failuretype-disconnected/115707/6 "2026-05-26T13:01:22Z")
It’s not supposed to reconnect if the “reconnect after consecutive…” setting is turned off, but it’s still disruptive because there’s no demotion, and no way around that. It’s an old driver and that’s one of the main things a future new Modbus driver will address. ---
**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:** [May 26, 2026, 2:09pm UTC](https://forum.inductiveautomation.com/t/modbus-rtu-over-tcp-single-slave-timeout-causes-driver-to-drop-entire-tcp-connection-failuretype-disconnected/115707/7 "2026-05-26T14:09:30Z")
> [@Kevin.Herron](#): > > future new Modbus driver will address Darn! 😇 ---
**Author:** ![michael.flagler](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/michael.flagler/32/26272_2.png) [@michael.flagler](https://forum.inductiveautomation.com/u/michael.flagler)\ **Post date:** [May 26, 2026, 3:16pm UTC](https://forum.inductiveautomation.com/t/modbus-rtu-over-tcp-single-slave-timeout-causes-driver-to-drop-entire-tcp-connection-failuretype-disconnected/115707/8 "2026-05-26T15:16:43Z")
Hopefully it also removes the mapping pages everyone tries to use then gets told here on the forums not to use. ---
**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:** [May 26, 2026, 3:27pm UTC](https://forum.inductiveautomation.com/t/modbus-rtu-over-tcp-single-slave-timeout-causes-driver-to-drop-entire-tcp-connection-failuretype-disconnected/115707/9 "2026-05-26T15:27:01Z")
People use the mapping pages because that's what gets them target addresses they can use in the quick client. Until the quick client accepts keyed-in item paths, the mapping pages are an unfortunate troubleshooting necessity. Or the new modbus driver simply populates a tree of addresses for users the way mine does. ---
**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:** [May 26, 2026, 3:40pm UTC](https://forum.inductiveautomation.com/t/modbus-rtu-over-tcp-single-slave-timeout-causes-driver-to-drop-entire-tcp-connection-failuretype-disconnected/115707/10 "2026-05-26T15:40:30Z")
> [@michael.flagler](#): > > Hopefully it also removes the mapping pages It will. If it has a page to define tags, it will be more like the other drivers, and won't redefine NodeId / OPC Item Path at the same time. > [@pturmel](#): > > Or the new modbus driver simply populates a tree of addresses for users the way mine does. Leaning towards this, but gated behind a configuration setting that implies it's for debug/development, and disabled by default. ---
**Author:** ![piperra](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/piperra/32/85541_2.png) [@piperra](https://forum.inductiveautomation.com/u/piperra)\ **Post date:** [May 26, 2026, 3:56pm UTC](https://forum.inductiveautomation.com/t/modbus-rtu-over-tcp-single-slave-timeout-causes-driver-to-drop-entire-tcp-connection-failuretype-disconnected/115707/11 "2026-05-26T15:56:09Z")
**Kevin.Herron:** Given the roadmap for a new native Modbus driver, is this a near-term or long-term objective for Ignition? **pturmel:** The module is connected and rock solid, but I’m struggling with the addressing syntax. I’m trying to read a float at offset 1008 for Unit 128 (previously `{128}.HRF1008`). Since I'm seeing the error attached below when trying to address it, could you provide the correct syntax for a float register with your driver? Is there a specific prefix I should use, or should I be targeting the address differently from the OPC tree? ![image](https://us1.discourse-cdn.com/inductiveautomation/original/3X/8/b/8b40b4b3fa11a209cd67c91dc69b12df89eb8137.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:** [May 26, 2026, 4:09pm UTC](https://forum.inductiveautomation.com/t/modbus-rtu-over-tcp-single-slave-timeout-causes-driver-to-drop-entire-tcp-connection-failuretype-disconnected/115707/12 "2026-05-26T16:09:42Z")
The syntax is the same as IA's manual addressing. (The curly braces around the unit do not belong there.) There is extended syntax, described in the user manual, for features not offered by IA's driver. Do note the requirement to use zero-based addressing. Also note the requirement to supply per-node configuration for any nodes other than node #1. ---
**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:** [May 26, 2026, 4:26pm UTC](https://forum.inductiveautomation.com/t/modbus-rtu-over-tcp-single-slave-timeout-causes-driver-to-drop-entire-tcp-connection-failuretype-disconnected/115707/13 "2026-05-26T16:26:08Z")
Depends on your definition of short-term/long-term, but I would guess not this year or next. ---
**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:** [May 26, 2026, 4:55pm UTC](https://forum.inductiveautomation.com/t/modbus-rtu-over-tcp-single-slave-timeout-causes-driver-to-drop-entire-tcp-connection-failuretype-disconnected/115707/14 "2026-05-26T16:55:45Z")
> [@Kevin.Herron](#): > > but gated behind a configuration setting that implies it's for debug/development I didn't bother because it only populates on-demand. 🤷‍♂️ ---
**Author:** ![piperra](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/piperra/32/85541_2.png) [@piperra](https://forum.inductiveautomation.com/u/piperra)\ **Post date:** [May 27, 2026, 7:48am UTC](https://forum.inductiveautomation.com/t/modbus-rtu-over-tcp-single-slave-timeout-causes-driver-to-drop-entire-tcp-connection-failuretype-disconnected/115707/15 "2026-05-27T07:48:33Z")
> [@pturmel](#): > > (The curly braces around the unit do not belong there.) Curly braces are because its defined as UDT with the UID as parameter. I am trying to use the standard manual addressing, but I'm still not getting valid readings. ![image](https://us1.discourse-cdn.com/inductiveautomation/original/3X/0/5/0542df4f4cdf7a363cda3af387beb4de05979dbf.png) > [@Kevin.Herron](#): > > Depends on your definition of short-term/long-term, but I would guess not this year or next. This is definitely long-term for my current project. Good to know, thanks for the transparency! ---
**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:** [May 27, 2026, 12:02pm UTC](https://forum.inductiveautomation.com/t/modbus-rtu-over-tcp-single-slave-timeout-causes-driver-to-drop-entire-tcp-connection-failuretype-disconnected/115707/16 "2026-05-27T12:02:42Z")
> [@piperra](#): > > still not getting valid readings. Did you load a units.csv with a line defining the register ranges for each slave unit ID? ---
**Author:** ![Chris\_Bingham](https://avatars.discourse-cdn.com/v4/letter/c/e5b9ba/32.png) [@Chris\_Bingham](https://forum.inductiveautomation.com/u/Chris_Bingham)\ **Post date:** [May 27, 2026, 12:23pm UTC](https://forum.inductiveautomation.com/t/modbus-rtu-over-tcp-single-slave-timeout-causes-driver-to-drop-entire-tcp-connection-failuretype-disconnected/115707/17 "2026-05-27T12:23:40Z")
> [@pturmel](#): > > Until the quick client accepts keyed-in item paths +1 for this option. Would be useful for all drivers. Picking from a list is a good syntactical _starting_ point, modifying to suit (via copy-paste to the manual entry field) would be a massive time-save over current option. ---
**Author:** ![piperra](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/piperra/32/85541_2.png) [@piperra](https://forum.inductiveautomation.com/u/piperra)\ **Post date:** [May 27, 2026, 12:45pm UTC](https://forum.inductiveautomation.com/t/modbus-rtu-over-tcp-single-slave-timeout-causes-driver-to-drop-entire-tcp-connection-failuretype-disconnected/115707/18 "2026-05-27T12:45:27Z")
> [@pturmel](#): > > Did you load a units.csv with a line defining the register ranges for each slave unit ID? Yes, but probably I missconfigured something, I'll keep trying later.