# 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:** 3

<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, 2022, 7:14pm UTC](https://forum.inductiveautomation.com/t/automation-professionals-advanced-modbus-driver/41312/41 "2022-06-10T19:14:13Z")

</div>

Note, if you want to publish read-only information on the server side, write to `IR*` addresses and `DI*` addresses–those can only be read by the protocol over the wire, not written.

---

<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 26, 2023, 7:22pm UTC](https://forum.inductiveautomation.com/t/automation-professionals-advanced-modbus-driver/41312/42 "2023-01-26T19:22:55Z")

</div>

A minor update has been released:

For Ignition v8.1: ~~v1.1.0.230261903~~

This adds a work-around for non-compliant Modbus TCP devices that do not return the transaction ID per the protocol specification. If concurrency is set to one, the module will now ignore txID mismatch.

---

<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 22, 2023, 5:01pm UTC](https://forum.inductiveautomation.com/t/automation-professionals-advanced-modbus-driver/41312/43 "2023-03-22T17:01:40Z")

</div>

A minor update has been released:

For Ignition v8.1: ~~v1.1.0.230811645~~

This fixes an embarrassing bug in File Record Writes. 😐

---

<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 20, 2023, 7:54pm UTC](https://forum.inductiveautomation.com/t/automation-professionals-advanced-modbus-driver/41312/44 "2023-06-20T19:54:51Z")

</div>

A minor update has been released:

For Ignition v8.1: ~~v1.1.1.231711928~~

This enables browse for slave unit #0, which should have been addressed over a year ago....

---

<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:** [June 24, 2023, 12:29pm UTC](https://forum.inductiveautomation.com/t/automation-professionals-advanced-modbus-driver/41312/45 "2023-06-24T12:29:14Z")

</div>

I'm testing the advanced modbus driver (thank you for it) - its not licensed at this point. I have a redundant Ignition server - this isn't licensed yet either (testing). I'm running the version from 4 days ago: 1.1.1 (b231711928).

I have setup a Modbus server, and whilst it looks like its working, the modbus clients which connect to it keep disconnecting - I'm not sure why. I have allowed TCP:502 in the Windows firewall, but this shouldn't matter since I'm running the server and client on the same machine.

Any idea what this could be? Is this related to the missing licenses?

> **Screenshots - click arrow to left to expand**
>
> **Modbus server:**
> 
> ![image](https://us1.discourse-cdn.com/inductiveautomation/original/3X/5/a/5a2db6a495a872863fb183011e69966e7cda0df1.png)
> 
> **Modbus client**
> 
> ![image](https://us1.discourse-cdn.com/inductiveautomation/original/3X/a/7/a7345acd9371fbb80033b5dd26cf02d2ee2cc197.png)
> 
> **Modbus advanced client:**
> 
> ![image](https://us1.discourse-cdn.com/inductiveautomation/original/3X/2/9/290af3f72990c016a00c1608e3d1baf332f359ed.png)
> 
> **Logs:**
> 
> ![image](https://us1.discourse-cdn.com/inductiveautomation/original/3X/6/4/643a043e4ea755f34a750fbb4a9541539420eacd.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:** [June 24, 2023, 12:38pm UTC](https://forum.inductiveautomation.com/t/automation-professionals-advanced-modbus-driver/41312/46 "2023-06-24T12:38:37Z")

</div>

Do you have at least one subscription item on each driver that is polling faster than once per ten seconds? Like many Modbus TCP devices in the wild, my listening server drops idle connections after ten seconds.

(All of my commercial modules are fully functional in trial mode when unlicensed.)

---

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

</div>

> [@pturmel](#):
>
> Do you have at least one subscription item on each driver that is polling faster than once per ten seconds? Like many Modbus TCP devices in the wild, my listening server drops idle connections after ten seconds.

Yep - this was the issue.

I didn't have a tag configured on some of the drivers, because I was implementing the redundant modbus solution outlined here:

> [@Indirect OpcItemPath](https://forum.inductiveautomation.com/t/indirect-opcitempath/74957/14):
>
> Kevin beat me to it, here's a brief description on what to do. Your connection names can obviously be whatever you want. For communication between primary and secondary devices with different addresses/hostnames, create 3 device connections Device connection “A” Device connection “B” Device connection “Master” Connections “A” and “B” will only be used for reference to the diagnostics to determine a device connection Tags used throughout the project will reference the “Master” connection A G…

Thanks for the help.

If you're interested - some suggestions of how this dropping of idle connections could be made more user friendly:

1. Make this user configurable in the modbus server - enable/disable whether to drop idle connections or not, and configurable time after which they should be dropped.
2. Describe the feature in the [documentation](https://www.automation-pros.com/modbus/UserManual.pdf)
3. Create a log entry when an idle session is dropped

---

<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 24, 2023, 2:18pm UTC](https://forum.inductiveautomation.com/t/automation-professionals-advanced-modbus-driver/41312/48 "2023-06-24T14:18:48Z")

</div>

1. Not unreasonable. I'll put it on the to-do list.

2. Also not unreasonable, though it is a common behavior.

3. It does, but at debug level. Turn that on for my `ServerTCPChannel` logger.

---

<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, 2023, 5:06pm UTC](https://forum.inductiveautomation.com/t/automation-professionals-advanced-modbus-driver/41312/49 "2023-07-03T17:06:30Z")

</div>

Minor feature change for redundancy with the Client driver, permitting a separate target for the redundant backup. Similar functionality already exists for the Server driver.

For Ignition v8.1+: ~~v1.1.2.231841656~~

---

<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 6, 2023, 5:45pm UTC](https://forum.inductiveautomation.com/t/automation-professionals-advanced-modbus-driver/41312/50 "2023-07-06T17:45:20Z")

</div>

Made the Modbus TCP server mode idle timeout adjustable, as requested by @woodsb02. It cannot be disabled, but very large values are allowed.

For Ignition v8.1+: ~~v1.1.3.231871740~~

There's an update to the internationalization bundles, which requires a gateway restart (or you can tolerate the question marks if you cannot restart).

---

<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:** [July 6, 2023, 10:38pm UTC](https://forum.inductiveautomation.com/t/automation-professionals-advanced-modbus-driver/41312/51 "2023-07-06T22:38:40Z")

</div>

Thank you!

---

<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 12, 2023, 4:24pm UTC](https://forum.inductiveautomation.com/t/automation-professionals-advanced-modbus-driver/41312/52 "2023-07-12T16:24:33Z")

</div>

Note the **beta** announced over here:

> [@Ignition OPC UA Server Redundancy (Modbus TCP)](https://forum.inductiveautomation.com/t/ignition-opc-ua-server-redundancy-modbus-tcp/67123/10):
>
> It wasn't quite as easy as the last change, but relatively easy. Utterly untested, feedback welcome: BETA for Ignition 8.1: [v1.1.4.231931604](https://www.automation-pros.com/ignition/Advanced%20Modbus%20Driver-1.1.4.231931604-v81.modl) Some notes: When active, the driver alternates between the live connections on a per-batch basis. For this driver, a "batch" is a memory area subset of a single system.opc.readValues() request, system.opc.writeValues() request, or subscription poll. (Coils with coils, discrete inputs with discretes, et cetera.) This is effectively load-balancing bet…

---

<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:** [February 5, 2024, 10:24pm UTC](https://forum.inductiveautomation.com/t/automation-professionals-advanced-modbus-driver/41312/53 "2024-02-05T22:24:53Z")

</div>

Automation Professionals is pleased to announce the release of **Maker Edition** support. Also, the fallback/redundancy beta is now production-grade, after some bug fixes.

For Ignition v8.1+: ~~v1.1.5.240362152~~

Some changes were made to properties bundles, so a gateway restart is likely to be required for all upgrades.

---

<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:** [May 16, 2024, 9:45pm UTC](https://forum.inductiveautomation.com/t/automation-professionals-advanced-modbus-driver/41312/54 "2024-05-16T21:45:17Z")

</div>

I have been trying to test your module against a modbus device that Wonderware currently reads tags from without an issue or any special translation (ex. 601023 F). I have tried many variations using your driver to do the same thing with no luck:

- XRF01023
- XRF1023
- XRF401023  
-etc...

What am I doing wrong? Please help!

---

<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:** [May 16, 2024, 9:53pm UTC](https://forum.inductiveautomation.com/t/automation-professionals-advanced-modbus-driver/41312/55 "2024-05-16T21:53:54Z")

</div>

Try `0.XRF1022` and `0.XRF1023`.

If neither of those work, get a wireshark capture of what WW is doing so I can decipher it.

If you can post the user manual for the device, that might help, too.

---

<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:** [May 16, 2024, 9:56pm UTC](https://forum.inductiveautomation.com/t/automation-professionals-advanced-modbus-driver/41312/56 "2024-05-16T21:56:56Z")

</div>

Thanks for fast reply! I will send something tomorrow when I power back up.

---

<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:** [May 16, 2024, 10:13pm UTC](https://forum.inductiveautomation.com/t/automation-professionals-advanced-modbus-driver/41312/57 "2024-05-16T22:13:35Z")

</div>

Compressed just in case it didn't transfer. Tried to use a Red Lion DA10 with no luck...so I'm hoping you can crack this enigma.  
[PCC Blender Modbus Documentation.pdf](https://forum.inductiveautomation.com/uploads/short-url/xyMdxcBYFtPjyeznO49d2yA7z8f.pdf) (472.8 KB)

---

<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:** [May 18, 2024, 8:12pm UTC](https://forum.inductiveautomation.com/t/automation-professionals-advanced-modbus-driver/41312/58 "2024-05-18T20:12:10Z")

</div>

So, it is using zero-based addressing, unit #0, so `0.XRF1023` is the correct OPC Item Path. Try specifying word swapping in my driver's configuration for Unit #0.

(Only Unit #1 works out of the box in my driver. You **must** configure the driver instance to use 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:** [May 23, 2024, 7:23pm UTC](https://forum.inductiveautomation.com/t/automation-professionals-advanced-modbus-driver/41312/59 "2024-05-23T19:23:13Z")

</div>

Automation Professionals is pleased to announce a new production release of this module, containing a work-around for a particular type of broken Modbus implementation.

For Ignition v8.1+, as usual: ~~v1.1.6.241441839~~

A tester encountered a device that stops responding (broken TCP pipe) if a File Record (Extended Registers, area prefix "6") request includes more than one register group. I added a per-unit option to limit File Record requests to single register groups, for both function code 0x14 and 0x15.

For those struggling with this, the device in question was:

> Process Control Corporation  
> Guardian Series Gravimetric Blender  
> Model CM017BAT01

---

<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 6, 2024, 9:00pm UTC](https://forum.inductiveautomation.com/t/automation-professionals-advanced-modbus-driver/41312/60 "2024-06-06T21:00:15Z")

</div>

Hi Phil,  
Very interesting Module.  
Have you developed a similar module for Modbus Lufking for the LWM Controller?

Thanks

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

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