# Modbus Server Driver **URL:** \ **Category:** 3rd Party Modules\ **Created:** [September 3, 2024, 1:46pm UTC](https://forum.inductiveautomation.com/t/modbus-server-driver/95481 "2024-09-03T13:46:18Z")\ **Posts on this page:** 9\ **Page:** 3
**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 29, 2026, 2:10pm UTC](https://forum.inductiveautomation.com/t/modbus-server-driver/95481/42 "2026-05-29T14:10:33Z")
I considered making it a configurable option, but I don't even know if this driver even has users, so I figured I'd keep it simple at first šŸ™ƒ ---
**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 29, 2026, 2:21pm UTC](https://forum.inductiveautomation.com/t/modbus-server-driver/95481/43 "2026-05-29T14:21:06Z")
> [@Kevin.Herron](#): > > even has users, Changing the address formats probably is hurting adoption. I made a point to make my alternates function as drop-in replacements for the old driver (so long as they are zero-based). ---
**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 29, 2026, 2:26pm UTC](https://forum.inductiveautomation.com/t/modbus-server-driver/95481/44 "2026-05-29T14:26:26Z")
This driver is a server only, and the IA driver is a client only. There's nothing to drop in and replace. I have not yet built a Modbus client driver that would compete with yours. I probably won't, at least not as a free / open source option like this, instead of as an official IA driver. ---
**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 29, 2026, 2:30pm UTC](https://forum.inductiveautomation.com/t/modbus-server-driver/95481/45 "2026-05-29T14:30:49Z")
> [@Kevin.Herron](#): > > There's nothing to drop in and replace. Well, many users have both ends of the connection, and consistent naming is a win. Plus it enables dropping in a server instance during development with the name of an intended client instance. So you can develop against it with proper node IDs. ---
**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 29, 2026, 2:34pm UTC](https://forum.inductiveautomation.com/t/modbus-server-driver/95481/46 "2026-05-29T14:34:20Z")
Ah I see. Well fwiw it uses the address syntax that a future client driver _would_ use šŸ™‚ (a future client driver would also support the existing IA driver syntax) ---
**Author:** ![nader.chinichian](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/nader.chinichian/32/9261_2.png) [@nader.chinichian](https://forum.inductiveautomation.com/u/nader.chinichian)\ **Post date:** [June 1, 2026, 5:53pm UTC](https://forum.inductiveautomation.com/t/modbus-server-driver/95481/47 "2026-06-01T17:53:48Z")
> [@pturmel](#): > > My alternate Modbus driver has slave RTU support, directly and via ethernet-to-serial devices. Do you have any plans to add a dedicated Modbus Master driver for polling devices on a multidrop RS-485 network? As you may know, the current Ignition Modbus Serial driver does not appear to wait for a device timeout before moving on to the next request. Instead, it can queue and poll devices in rapid succession. In situations where a device responds slightly later than expected, one or more subsequent devices may start transmitting at nearly the same time, resulting in packet collisions on the RS-485 bus. This behavior can make communication unreliable on larger or slower multidrop networks and often forces us to use external OPC servers such as Kepware, which provide more robust request scheduling, inter-request delays, and timeout handling for serial Modbus communications. It would be valuable if Ignition offered a Modbus Master driver with configurable polling behavior, including options such as per-device timeouts, inter-request delays, bus turnaround delays, and stricter request/response sequencing. This would eliminate the need for third-party software in many RS-485 deployments and improve reliability when communicating with devices that have slower response times. ---
**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:** [June 1, 2026, 6:23pm UTC](https://forum.inductiveautomation.com/t/modbus-server-driver/95481/48 "2026-06-01T18:23:38Z")
It already supports that, either via a gateway serial port, or via a remote ethernet-to-serial converter. I have clients using it specifically because it has sane multi-drop behaviors and very predictable slave interleaving. Perhaps you should try it? See this comment and the question above it: > [@Automation Professionals' Advanced Modbus Driver](https://forum.inductiveautomation.com/t/automation-professionals-advanced-modbus-driver/41312/164): > > There is no 1:1 equivalent. But the driver does round-robin scheduling of requests to units, and has per-unit rate limits. If, in a single poll rate, you have multiple requests to each of four units, they'll be executed like so: Unit 1 Req 1 Unit 2 Req 1 Unit 3 Req 1 Unit 4 Req 1 Unit 1 Req 2 Unit 2 Req 2 .... If the each set of requests takes longer than the per-unit rate limit, then the poll will smoothly run through all of the requests from start to finish, then wait for the next poll sā€¦ ---
**Author:** ![nader.chinichian](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/nader.chinichian/32/9261_2.png) [@nader.chinichian](https://forum.inductiveautomation.com/u/nader.chinichian)\ **Post date:** [June 1, 2026, 6:41pm UTC](https://forum.inductiveautomation.com/t/modbus-server-driver/95481/49 "2026-06-01T18:41:09Z")
Good to know perfect. It should be new because I remembered that you told me, you don't support it yet. ---
**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:** [June 1, 2026, 7:01pm UTC](https://forum.inductiveautomation.com/t/modbus-server-driver/95481/50 "2026-06-01T19:01:55Z")
I don't remember precisely what feature you specifically needed. The driver has always had client RTU and RTU over TCP support. Git Blame says I implemented the queue discard optimization for execution timeouts in December of 2020. That marks all pending requests for a specific unit as timed out immediately on any timeout for that unit. (The tag poll cycle will requeue to retry.) So a single missing device in the string will not have any more than one execution timeout of impact per poll. [Previous page](https://forum.inductiveautomation.com/t/modbus-server-driver/95481.md?page=2)