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.
The logs show exactly what happens: one TIMEOUT immediately forces the driver to disconnect.
Plaintext
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?
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.
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.
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.
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.
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.
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?
