# Modbus RTU timing issues **URL:** \ **Category:** Ignition\ **Created:** [March 21, 2024, 2:56am UTC](https://forum.inductiveautomation.com/t/modbus-rtu-timing-issues/87672 "2024-03-21T02:56:58Z")\ **Posts on this page:** 13\ **Page:** 1
**Author:** ![ryanastiefes](https://avatars.discourse-cdn.com/v4/letter/r/47e85d/32.png) [@ryanastiefes](https://forum.inductiveautomation.com/u/ryanastiefes)\ **Post date:** [March 21, 2024, 2:56am UTC](https://forum.inductiveautomation.com/t/modbus-rtu-timing-issues/87672/1 "2024-03-21T02:56:58Z")
Ignition Version: 8.1.38 I have a system that has been running for about a year now using the Modbus TCP protocol and being converted to Modbus RTU over RS232. This particular system communicates over radio to 8 devices with a baud rate of 9600, I understand that comms arent always 100% over RF. The TCP to RTU comms were terrible and I tried every possible setting I could to get the comms to be somewhat reliable but failed. The legacy system that was in use prior to Ignition was using Modbus RTU over it's local Serial Port and had around \>=90% success rate on all devices. Today I tried moving all my devices over to Modbus RTU since the server has a Serial Com Port. I moved over one device to see if it would work and had a relaible connection, so I moved over the rest of the devices but only one device stays connected the others flip from Connecting to Disconnected. If I disable the Connected device another enabled device will connect while the others flip from Connecting to Disconnected.Every once in a while the Connected device will disconnect and another will automatically connect. I would assume I would see a device connect than disconnect, move to the next device Connect than Disconnect. Why is only one device staying connected for a long period of time and the others wont connect? I've tried putting the tags in different tag groups to pull at different frequencies, with no success. I have my timeouts in the Device and OPC settings up as high as 16 seconds. Is there any way to monitor these serial connections further? The logs shows Request Failed. FailureType==DISCONNECTED If I change the Communication Timeout to around 16000msecs and hit save changes the device shows connecting for about two seconds than shows Disconnected, shouldn't it try for the 16 seconds before saying disconnected? ---
**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:** [March 21, 2024, 3:25am UTC](https://forum.inductiveautomation.com/t/modbus-rtu-timing-issues/87672/2 "2024-03-21T03:25:54Z")
How many devices do you have configured in Ignition and how many serial ports do you have? Each serial port can only be used by one device. Multiple devices sharing a single port would need to be handled by addressing multiple unit/slave IDs on the same device instance. ---
**Author:** ![ryanastiefes](https://avatars.discourse-cdn.com/v4/letter/r/47e85d/32.png) [@ryanastiefes](https://forum.inductiveautomation.com/u/ryanastiefes)\ **Post date:** [March 21, 2024, 3:42am UTC](https://forum.inductiveautomation.com/t/modbus-rtu-timing-issues/87672/3 "2024-03-21T03:42:11Z")
I have one serial port that is connected to a MDS Transnet 900 Spread Spectrum radio. So I need to setup all devices (8) in one Device Connection? If that is correct how do I go about handling Reverse Word order on half the devices while the other half do not require it? If I switched over to RS485 and checked the RS-485 Mode would it let me multidrop, ie.. use more than one Device Connection per com port? ---
**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:** [March 21, 2024, 6:22am UTC](https://forum.inductiveautomation.com/t/modbus-rtu-timing-issues/87672/4 "2024-03-21T06:22:01Z")
We have this problem several years before. The Ignition Serial communication has a big bug. It is developed based on Ethernet with handling collision detection on the ethernet layer. So in Serial media, it doesn't wait until the previous request finishes this causes time to time when Ignition sends a new request to the next device in the queue before the previous one sends its response so both messages collide. Workaround: - Your device should be very fast(No delay for response, so if you use PLC the modbus code should be handle in interrupt instead of the main loop) - Use Higher buadrate to minimum transmit time on the bus - Use smaller packet size to min the traveling time on the bus (not good for efficiency but good for this one) - Use multiple serial line on the Ignition Gateway and load balance devices on them - Use kepware Modbus driver or Node red instead - May be @pturmel modbus driver handle this one. ---
**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:** [March 21, 2024, 10:58am UTC](https://forum.inductiveautomation.com/t/modbus-rtu-timing-issues/87672/5 "2024-03-21T10:58:47Z")
> [@ryanastiefes](#): > > If that is correct how do I go about handling Reverse Word order on half the devices while the other half do not require it? My alternate driver allows these settings to be per-unit-address. It also has a number of timing tweaks that IA's driver does not. If converting, note that it **only** does zero-based addressing, does **not** use address mappings, and defaults to unit #1 instead of unit #0. > [@Automation Professionals' Advanced Modbus Driver](https://forum.inductiveautomation.com/t/automation-professionals-advanced-modbus-driver/41312): > > Automation Professionals is pleased to announce the first beta for its Advanced Modbus Driver, for Ignition version 7.9. Key features: Server mode, emulating one or more slave [devices](https://www.automation-pros.com/modbus/UserManual.pdf), using any of the three typical connection types, including simultaneous connections of multiple types. Client mode, incorporating all three connection modes in one driver. Support for Modbus Function Codes 20 and 21, File Records. Configure protocol tweaks for troublesome devices per slave unit, enabling suppor… ---
**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:** [March 21, 2024, 12:15pm UTC](https://forum.inductiveautomation.com/t/modbus-rtu-timing-issues/87672/6 "2024-03-21T12:15:27Z")
The IA Modbus RTU driver is not going to work for you in this scenario. ---
**Author:** ![Matthew\_Love](https://avatars.discourse-cdn.com/v4/letter/m/858c86/32.png) [@Matthew\_Love](https://forum.inductiveautomation.com/u/Matthew_Love)\ **Post date:** [March 21, 2024, 1:26pm UTC](https://forum.inductiveautomation.com/t/modbus-rtu-timing-issues/87672/7 "2024-03-21T13:26:07Z")
I'm having some trouble mentally picturing your network topology from your post. Naturally, I would assume it's RTU (you say RS-232) to a TCP/IP converter/gateway, then your server connects to it that way. I guess the other end of the RS-232 connection is an RF modem that routes comms to the 8 RF devices? Then you say "today I tried moving all my devices over to Modbus RTU..." well, what was it before...? Either way, the fundamental issue seems to be the locking of the serial com port (which you've stated is in the server itself). As far as I understand it, when an application makes a 'connection' to a COM port, it is locked out and cannot be used by other applications/connections. This is even true for virtual COM port connections made via serial-to-USB dongles. @Kevin.Herron alludes to this in his first post. The solution would be to either have multiple COM ports (likely requiring multiple physical serial cards in the server) or to use multi-drop comms via RS-485 or similar. ---
**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:** [March 21, 2024, 1:28pm UTC](https://forum.inductiveautomation.com/t/modbus-rtu-timing-issues/87672/8 "2024-03-21T13:28:59Z")
> [@Matthew\_Love](#): > > either have multiple COM ports Not possible with a single radio. > [@Matthew\_Love](#): > > use multi-drop comms Already working that way over the one radio. With different settings required per unit address, only my module will serve this application from within Ignition. Other OPC servers might be able to as well, but I've not seen any specs to say so. ---
**Author:** ![OkiePC](https://avatars.discourse-cdn.com/v4/letter/o/f6c823/32.png) [@OkiePC](https://forum.inductiveautomation.com/u/OkiePC)\ **Post date:** [March 21, 2024, 4:52pm UTC](https://forum.inductiveautomation.com/t/modbus-rtu-timing-issues/87672/9 "2024-03-21T16:52:58Z")
I would recommend using a single PLC with Ethernet and serial Modbus RTU capability to poll the radio network, and let Ignition interact with it using Ethernet. We use the Click Plus and Micrologix1400 frequently for this sort of application. Your PLC program can implement the polling, inter-message timing, skipping of disabled nodes, etc. and all of that can be custom programmed for your situation. ---
**Author:** ![ryanastiefes](https://avatars.discourse-cdn.com/v4/letter/r/47e85d/32.png) [@ryanastiefes](https://forum.inductiveautomation.com/u/ryanastiefes)\ **Post date:** [March 21, 2024, 7:39pm UTC](https://forum.inductiveautomation.com/t/modbus-rtu-timing-issues/87672/10 "2024-03-21T19:39:18Z")
Thanks for the replies. I have decided to go the Kepware route. I initially went with the Ignition route to reduce setup time but in the end costed me a full day. It would be nice if Inductive Automation had a little more documentation on the Modbus RTU driver providing some of the behind the scenes facts, such as: \*\*\*It is developed based on Ethernet with handling collision detection on the ethernet layer. So in Serial media, it doesn't wait until the previous request finishes this causes time to time when Ignition sends a new request to the next device in the queue before the previous one sends its response so both messages collide. , \*\*\* Or I failed at finding any such documentation. Kepware Modbus Suite works fantastic for all Modbus protocols (TCP or RTU) ---
**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:** [March 21, 2024, 7:48pm UTC](https://forum.inductiveautomation.com/t/modbus-rtu-timing-issues/87672/11 "2024-03-21T19:48:56Z")
> [@ryanastiefes](#): > > Or I failed at finding any such documentation. Because that quote is not from IA. And I'm not so sure it accurately reflects the behavior of IA's driver. (But I never use it, having my own.) ---
**Author:** ![ryanastiefes](https://avatars.discourse-cdn.com/v4/letter/r/47e85d/32.png) [@ryanastiefes](https://forum.inductiveautomation.com/u/ryanastiefes)\ **Post date:** [March 21, 2024, 7:59pm UTC](https://forum.inductiveautomation.com/t/modbus-rtu-timing-issues/87672/12 "2024-03-21T19:59:54Z")
Sorry, didn't mean it like that, I meant more like the inner workings of the driver. ---
**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:** [March 21, 2024, 8:28pm UTC](https://forum.inductiveautomation.com/t/modbus-rtu-timing-issues/87672/13 "2024-03-21T20:28:42Z")
> [@ryanastiefes](#): > > It is developed based on Ethernet with handling collision detection on the ethernet layer. So in Serial media, it doesn't wait until the previous request finishes this causes time to time when Ignition sends a new request to the next device in the queue before the previous one sends its response so both messages collide. Where'd this come from? It's simply not true. There are some obvious shortcomings with the Serial/RTU driver, but it's not this fundamentally broken.