# Automation Professionals' Advanced Modbus Driver

**URL:** <https://forum.inductiveautomation.com/t/automation-professionals-advanced-modbus-driver/41312>\
**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:** 20\
**Page:** 9

<div class="post-metadata">

**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:** [June 10, 2025, 2:35pm UTC](https://forum.inductiveautomation.com/t/automation-professionals-advanced-modbus-driver/41312/161 "2025-06-10T14:35:59Z")

</div>

> [@pturmel](#):
>
> For any practical purpose, use unit #0 only with Modbus TCP devices that expect it to behave like any other unit number.

Sure, I've testing over TCP and the broadcast unit and the device disconnects and only recovers manual on save again on the gateway.

> [@pturmel](#):
>
> Don't use `rawModbus()` for operations on Modbus addresses that have proper OPC Item support in the driver

Sure, I was using the function for bulks HR writes with codes 16/23.

> [@pturmel](#):
>
> Also do not use `rawModbus()` for any packet exchange where you cannot **exactly** predict the response payload size. (After the echoed function code, not including the CRC.)

When using RTU over TCP the CRC is not important after all, right? So, the payload size should be always be expected.

@pturmel, would you verify on your code if the device crashes when using unit = 0?

---

<div class="post-metadata">

**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 10, 2025, 2:55pm UTC](https://forum.inductiveautomation.com/t/automation-professionals-advanced-modbus-driver/41312/162 "2025-06-10T14:55:37Z")

</div>

> [@jespinmartin1](#):
>
> When using RTU over TCP the CRC is not important after all, right?

Not correct. RTU over TCP simply means the actual serial port is remote, but all other serial semantics apply, including the CRC.

> [@jespinmartin1](#):
>
> if the device crashes when using unit = 0?

Not supported on RTU. I might have time to experiment with unsupported functionality in July or August. Getting my modules ready for v8.3 is second only to bugfixes now.

---

<div class="post-metadata">

**Author:** ![patrixmith](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/patrixmith/32/75926_2.png) [@patrixmith](https://forum.inductiveautomation.com/u/patrixmith)\
**Post date:** [September 29, 2025, 10:12pm UTC](https://forum.inductiveautomation.com/t/automation-professionals-advanced-modbus-driver/41312/163 "2025-09-29T22:12:05Z")

</div>

Hey @pturmel! The module looks awesome! I am currently using KepServerEX/TopServer or ACM for Modbus communication, specifically for Lufkin controllers (and more specifically for ELAM support). Reading through this (impressively long) thread, it looks like your module supports ELAM; thank you and well done! One of the other reasons I am using tools like KepServer/ACM is for their “scheduling” service, to manage the synchronous polling of a slave device via a single master. Does your module do anything to support scheduling one slave device at a time? Based on the thread, it sounds like it, but I wanted to ping you to be sure.

I would LOVE to have a native Ignition solution to be able to jump that hurdle, because those 3rd party tools are never cheap, especially at scale.

---

<div class="post-metadata">

**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 29, 2025, 10:24pm UTC](https://forum.inductiveautomation.com/t/automation-professionals-advanced-modbus-driver/41312/164 "2025-09-29T22:24:23Z")

</div>

> [@patrixmith](#):
>
> their “scheduling” service

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 start.

If the four units' requests are quicker than the rate limit, then there will be pauses and/or re-ordering inserted to fit the constraints.

Perhaps you should test with your application? (All of my non-free modules honor Ignition's two-hours-at-a-time trial mode.)

---

<div class="post-metadata">

**Author:** ![patrixmith](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/patrixmith/32/75926_2.png) [@patrixmith](https://forum.inductiveautomation.com/u/patrixmith)\
**Post date:** [September 29, 2025, 10:33pm UTC](https://forum.inductiveautomation.com/t/automation-professionals-advanced-modbus-driver/41312/165 "2025-09-29T22:33:08Z")

</div>

Huge! I am going to test it immediately. I’ll reach out if I have any questions.

---

<div class="post-metadata">

**Author:** ![woodsb02](https://avatars.discourse-cdn.com/v4/letter/w/6a8cbe/32.png) [@woodsb02](https://forum.inductiveautomation.com/u/woodsb02)\
**Post date:** [October 17, 2025, 11:11pm UTC](https://forum.inductiveautomation.com/t/automation-professionals-advanced-modbus-driver/41312/166 "2025-10-17T23:11:52Z")

</div>

Hi @pturmel - hope you’re going well.

I just wanted to say we’ve now finished commissioning our application with your advanced modbus driver, where we use redundant servers each with redundant modbus links to the safety PLC, and the system is now in production. This included various failure mode tests (single network link failure, dual link failure, redundant server failover, reboots). Your driver has been robust to all, in that it either recovered once reconnected or correctly showed it was connected to 1 of the 2 redundant PLC addresses.

Thanks for putting in the effort to add redundancy to your driver - it works a treat!

---

<div class="post-metadata">

**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:** [November 26, 2025, 2:46pm UTC](https://forum.inductiveautomation.com/t/automation-professionals-advanced-modbus-driver/41312/167 "2025-11-26T14:46:56Z")

</div>

Hi

Is this the module for Ignition 8.3?

> [@pturmel](#):
>
> Automation Professionals is pleased to announce a new production release of its Advanced Modbus Module, which fixes a minor bug in redundant connection path support in the client driver.
> 
> For Ignition v8.1+: [v1.1.14.251401929](https://www.automation-pros.com/ignition/Advanced%20Modbus%20Driver-1.1.14.251401929-v81.modl)
> 
> All users should upgrade.

 ![image](https://us1.discourse-cdn.com/inductiveautomation/original/3X/4/a/4a635ed9b5ef1d8844f987fda9cc24e5b68dbb7c.png)

---

<div class="post-metadata">

**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:** [November 26, 2025, 3:11pm UTC](https://forum.inductiveautomation.com/t/automation-professionals-advanced-modbus-driver/41312/168 "2025-11-26T15:11:18Z")

</div>

No, over here:

> [@Automation Professionals v8.3 Modules](https://forum.inductiveautomation.com/t/automation-professionals-v8-3-modules/109152):
>
> Automation Professionals is pleased to announce the availability of several of its 3rd party modules as BETAs for the v8.3 beta, hosted here: The following modules are currently available: EtherNet/IP Class1 Communications Suite Advanced Modbus Driver Image and Video Streaming Driver Integration Toolkit Blob Server Known Issues: All modules are currently incompatible with v8.3 module update procedure, apparently due to my module file names including version and build information. You mu…

A fresh beta of this module with a web UI for node CSV import/export is coming soon, with a production release in December.

---

<div class="post-metadata">

**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:** [December 9, 2025, 10:27pm UTC](https://forum.inductiveautomation.com/t/automation-professionals-advanced-modbus-driver/41312/169 "2025-12-09T22:27:43Z")

</div>

Automation Professionals is pleased to announce a Ignition v8.3 release candidate for this module:

For Ignition 8.3: ~~v1.2.0.253432205~~

Notes:

- The old Wicket editor for per-node settings is gone. The import/export options have been supplemented with an "Effective" export option.
- The documentation is updated to match the new WebUI, and the CSV format details added.
- Importing a units configuration CSV immediately restarts the affected device.

---

<div class="post-metadata">

**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:** [January 9, 2026, 9:53pm UTC](https://forum.inductiveautomation.com/t/automation-professionals-advanced-modbus-driver/41312/170 "2026-01-09T21:53:24Z")

</div>

Automation Professionals is pleased to announce the Production release of this module for Ignition v8.3. A bug in redundancy synchronization was fixed.

For Ignition v8.3: [v1.2.1.260092138](https://www.automation-pros.com/ignition/Advanced%20Modbus%20Driver-1.2.1.260092138-v83.modl)

---

<div class="post-metadata">

**Author:** ![hhbauss](https://avatars.discourse-cdn.com/v4/letter/h/ecae2f/32.png) [@hhbauss](https://forum.inductiveautomation.com/u/hhbauss)\
**Post date:** [March 31, 2026, 1:18pm UTC](https://forum.inductiveautomation.com/t/automation-professionals-advanced-modbus-driver/41312/171 "2026-03-31T13:18:58Z")

</div>

Is this module compatible with the newest release of Ignition 8.3.4? You used to have a list of tested minor revisions on your releases, but all I see is 8.3 currently.

Thank you sir.

---

<div class="post-metadata">

**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 31, 2026, 5:51pm UTC](https://forum.inductiveautomation.com/t/automation-professionals-advanced-modbus-driver/41312/172 "2026-03-31T17:51:57Z")

</div>

I'm still running QA on 8.3.2, but I expect all v8.3.x to work. I add notes on minor version variants only when necessary.

---

<div class="post-metadata">

**Author:** ![hhbauss](https://avatars.discourse-cdn.com/v4/letter/h/ecae2f/32.png) [@hhbauss](https://forum.inductiveautomation.com/u/hhbauss)\
**Post date:** [April 1, 2026, 8:07pm UTC](https://forum.inductiveautomation.com/t/automation-professionals-advanced-modbus-driver/41312/173 "2026-04-01T20:07:15Z")

</div>

Thanks for the update Phil

---

<div class="post-metadata">

**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:** [June 18, 2026, 2:56pm UTC](https://forum.inductiveautomation.com/t/automation-professionals-advanced-modbus-driver/41312/174 "2026-06-18T14:56:58Z")

</div>

Hi Phil,  
We are testing the driver in MODBUS\_TCP mode and we noticed that the "Request delay" parameter (the last parameter in the .csv config) is not working not matter which value we use.

Any idea?

Regards, Andres

---

<div class="post-metadata">

**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 18, 2026, 4:35pm UTC](https://forum.inductiveautomation.com/t/automation-professionals-advanced-modbus-driver/41312/175 "2026-06-18T16:35:26Z")

</div>

Hmm. Only used in the RTU and RTU over TCP channel implementation.

Let me see if I can add it to the TCP implementation without disrupting its concurrency capabilities.

---

<div class="post-metadata">

**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 18, 2026, 5:04pm UTC](https://forum.inductiveautomation.com/t/automation-professionals-advanced-modbus-driver/41312/176 "2026-06-18T17:04:58Z")

</div>

Well, that looked trivial. Care to test this **beta** for me? (I haven't run QA on it...)

For Ignition v8.3+: ~~v1.2.2.261691701~~

_Pulled. Not trivial after all._

---

<div class="post-metadata">

**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:** [June 26, 2026, 7:38pm UTC](https://forum.inductiveautomation.com/t/automation-professionals-advanced-modbus-driver/41312/177 "2026-06-26T19:38:38Z")

</div>

Hi Phil,  
we tested it and it worked fine using values ​​between 0 and 14 ms. With values ​​between 15 and 16 ms, it sometimes works and sometimes doesn't. With higher values, it doesn't work and waits 1 minute before timing out.

---

<div class="post-metadata">

**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 26, 2026, 8:42pm UTC](https://forum.inductiveautomation.com/t/automation-professionals-advanced-modbus-driver/41312/178 "2026-06-26T20:42:17Z")

</div>

Darn. That is not what I expected. Will investigate.

---

<div class="post-metadata">

**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 3, 2026, 4:06pm UTC](https://forum.inductiveautomation.com/t/automation-professionals-advanced-modbus-driver/41312/179 "2026-07-03T16:06:13Z")

</div>

Hi Phil, any developments in that regard?

---

<div class="post-metadata">

**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 3, 2026, 4:19pm UTC](https://forum.inductiveautomation.com/t/automation-professionals-advanced-modbus-driver/41312/180 "2026-07-03T16:19:21Z")

</div>

Sorry. Swamped preparing for travel next week. (SBDD San Diego, fwiw.)

[Previous page](https://forum.inductiveautomation.com/t/automation-professionals-advanced-modbus-driver/41312.md?page=8)

[Next page](https://forum.inductiveautomation.com/t/automation-professionals-advanced-modbus-driver/41312.md?page=10)
