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 
1 Like
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).
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.
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.
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)
3 Likes
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.
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:
Good to know perfect. It should be new because I remembered that you told me, you don't support it yet.
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.