# Automation Professionals' Advanced Modbus Driver **URL:** \ **Category:** 3rd Party Modules\ **Created:** [December 8, 2020, 8:45pm UTC](https://forum.inductiveautomation.com/t/automation-professionals-advanced-modbus-driver/41312 "2020-12-08T20:45:46Z")\ **Posts on this page:** 12\ **Page:** 10
**Author:** ![Andres\_Rossi](https://avatars.discourse-cdn.com/v4/letter/a/87869e/32.png) [@Andres\_Rossi](https://forum.inductiveautomation.com/u/Andres_Rossi)\ **Post date:** [July 6, 2026, 4:45pm UTC](https://forum.inductiveautomation.com/t/automation-professionals-advanced-modbus-driver/41312/181 "2026-07-06T16:45:40Z")
Hi Phil, We ran some more tests regarding the communication instability issue we're experiencing. We believe it might be a RequestDelay problem, but we're not sure. We compared it to the Kepserver driver, which is working perfectly, and I've sent you an email with the Wireshark screenshots and the Ignition wrapper.log file to see if we can determine what's happening and resolve it. Regards, Andrés ---
**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:** [July 6, 2026, 7:45pm UTC](https://forum.inductiveautomation.com/t/automation-professionals-advanced-modbus-driver/41312/182 "2026-07-06T19:45:50Z")
While I'm not @pturmel, I'd suggest actually sending the wireshark captures to him rather than screenshots of the captures. That would make it much easier to analyze rather than looking a pictures, and I'm guessing he'd also prefer it. ---
**Author:** ![Andres\_Rossi](https://avatars.discourse-cdn.com/v4/letter/a/87869e/32.png) [@Andres\_Rossi](https://forum.inductiveautomation.com/u/Andres_Rossi)\ **Post date:** [July 7, 2026, 2:21pm UTC](https://forum.inductiveautomation.com/t/automation-professionals-advanced-modbus-driver/41312/183 "2026-07-07T14:21:37Z")
Hi Michael, Yes, sorry, I meant captures, not screenshots. My mistake. ---
**Author:** ![tgish](https://avatars.discourse-cdn.com/v4/letter/t/34f0e0/32.png) [@tgish](https://forum.inductiveautomation.com/u/tgish)\ **Post date:** [July 20, 2026, 10:19pm UTC](https://forum.inductiveautomation.com/t/automation-professionals-advanced-modbus-driver/41312/184 "2026-07-20T22:19:51Z")
Hi @pturmel We ran in to an issue using tag scripting (UDT acquired from Ignition Exchange) to change the device IP when communications failed. With a major network outage, the constant device.hostname type changes seemed to overwhelm something config related (idb?) and our redundant gateway was very unhappy - tried several full pulls and then just stopped. Looking into third party alternatives now. I see in your manual that it supports two separate IP address connections for each device and that it will alternate polls if they are both good. Is it possible to make one the primary that it always uses? our two connections are hardwired (ADSL) and the second is a cell modem. the cell modems are typically much slower and much less reliable connection and we are trying to reduce data usage on them if possible, so I don't want it constantly using it if the hard-wired connection is good. Thanks ---
**Author:** ![woodsb02](https://avatars.discourse-cdn.com/v4/letter/w/6a8cbe/32.png) [@woodsb02](https://forum.inductiveautomation.com/u/woodsb02)\ **Post date:** [July 20, 2026, 11:36pm UTC](https://forum.inductiveautomation.com/t/automation-professionals-advanced-modbus-driver/41312/185 "2026-07-20T23:36:22Z")
Many modbus devices close the TCP session after inactivity (often 10seconds). This would mean the back would keep disconnecting and having to reconnect. I suspect this is why the advanced driver is configured to split the polling across the primary and secondary (to avoid this, by keeping the secondary alive and healthy). ---
**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:** [July 20, 2026, 11:50pm UTC](https://forum.inductiveautomation.com/t/automation-professionals-advanced-modbus-driver/41312/186 "2026-07-20T23:50:34Z")
> [@tgish](#): > > Is it possible to make one the primary that it always uses? Not practical, no. The only way to reliably tell that the connection is good is to route some of the traffic through it. Anything other than a 50-50 split is a nightmare. ---
**Author:** ![jespinmartin1](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/jespinmartin1/32/57175_2.png) [@jespinmartin1](https://forum.inductiveautomation.com/u/jespinmartin1)\ **Post date:** [August 28, 2026, 2:28pm UTC](https://forum.inductiveautomation.com/t/automation-professionals-advanced-modbus-driver/41312/187 "2026-08-28T14:28:48Z")
Hi @pturmel We are upgrading to Ignition 8.3.9 while using Advanced Modbus 1.2.3 (b262241428). Any concern? ---
**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:** [August 28, 2026, 2:47pm UTC](https://forum.inductiveautomation.com/t/automation-professionals-advanced-modbus-driver/41312/188 "2026-08-28T14:47:06Z")
There is a beta addressing connection breakage/stalls of Modbus TCP client connections on very lossy networks (wi-fi). You can snag it from my [common downloads folder](https://www.automation-pros.com/ignition/) if you wish to try that instead. Note that no build of v1.2.3 is officially a production release. ---
**Author:** ![jespinmartin1](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/jespinmartin1/32/57175_2.png) [@jespinmartin1](https://forum.inductiveautomation.com/u/jespinmartin1)\ **Post date:** [September 1, 2026, 5:04pm UTC](https://forum.inductiveautomation.com/t/automation-professionals-advanced-modbus-driver/41312/189 "2026-09-01T17:04:03Z")
Hi @pturmel Any documentation on differences between 1.2.3 versions ? ![image](https://us1.discourse-cdn.com/inductiveautomation/original/3X/6/8/6834132548a106ff088d191fcb626be4301d378b.jpeg) ---
**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:** [September 1, 2026, 7:11pm UTC](https://forum.inductiveautomation.com/t/automation-professionals-advanced-modbus-driver/41312/190 "2026-09-01T19:11:40Z")
No, use latest one. The others were buggy. ---
**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:** [September 18, 2026, 3:33pm UTC](https://forum.inductiveautomation.com/t/automation-professionals-advanced-modbus-driver/41312/191 "2026-09-18T15:33:57Z")
Automation Professionals is pleased to announce a new Production release of this module, fixing some bugs in v8.3, and moving the "Ignore TxID" feature to a separate, default false, configuration setting. For Ignition v8.3.x: [v1.2.3.262571909](https://www.automation-pros.com/ignition/Advanced%20Modbus%20Driver-1.2.3.262571909-v83.modl) **Breaking Change** : Users relying on the Ignore TxID feature will need to set that configuration boolean after upgrading. Concurrency=1 will default to Modbus TCP spec-compliant TxID handling going forward. ---
**Author:** ![Andres\_Rossi](https://avatars.discourse-cdn.com/v4/letter/a/87869e/32.png) [@Andres\_Rossi](https://forum.inductiveautomation.com/u/Andres_Rossi)\ **Post date:** [September 18, 2026, 4:08pm UTC](https://forum.inductiveautomation.com/t/automation-professionals-advanced-modbus-driver/41312/192 "2026-09-18T16:08:00Z")
Great news!! We’ll test it ASAP. Thanks Phil Regards, Andrés [Previous page](https://forum.inductiveautomation.com/t/automation-professionals-advanced-modbus-driver/41312.md?page=9)