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

<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:** [April 17, 2025, 4:54pm UTC](https://forum.inductiveautomation.com/t/automation-professionals-advanced-modbus-driver/41312/141 "2025-04-17T16:54:05Z")

</div>

Hi Phil,  
I've been running some tests and have been able to read HR, IR, C, and Di without any problems.  
Now I'm trying to write a single coil (C) and I see that the driver uses function 15 (0x0F) to execute it when it should normally use function 05 (0x05). Is there a driver setting to correct this?

![imagen](https://us1.discourse-cdn.com/inductiveautomation/original/3X/f/5/f51f6e985f59183d865222dd2db2191a7101a2c3.png)

Regards, Andrés

---

<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:** [April 17, 2025, 4:59pm UTC](https://forum.inductiveautomation.com/t/automation-professionals-advanced-modbus-driver/41312/142 "2025-04-17T16:59:58Z")

</div>

There is a setting to disable the use of function 15 entirely. Then all coil writes are one-by-one with function 5. (Set the node write option "Max Coils" to zero.)

(The modbus spec seems pretty clear that function 15, if supported at all, needs to support writing single bits.)

~~This setting applies to the whole channel. It cannot be set per unit address.~~

---

<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:** [April 17, 2025, 5:07pm UTC](https://forum.inductiveautomation.com/t/automation-professionals-advanced-modbus-driver/41312/143 "2025-04-17T17:07:52Z")

</div>

I tried this:

 ![imagen](https://us1.discourse-cdn.com/inductiveautomation/original/3X/7/d/7ddf9350e1d9956c260ba60a44c4770539617c50.png)

But then I get this when I write the Coil

 ![imagen](https://us1.discourse-cdn.com/inductiveautomation/original/3X/c/5/c57ef791b83fc9c1712e113f0c075e26dd70d02e.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:** [April 17, 2025, 5:09pm UTC](https://forum.inductiveautomation.com/t/automation-professionals-advanced-modbus-driver/41312/144 "2025-04-17T17:09:08Z")

</div>

I'll need logs for that.

---

<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:** [April 17, 2025, 5:15pm UTC](https://forum.inductiveautomation.com/t/automation-professionals-advanced-modbus-driver/41312/145 "2025-04-17T17:15:51Z")

</div>

I sent it to you by email.

---

<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:** [April 17, 2025, 5:40pm UTC](https://forum.inductiveautomation.com/t/automation-professionals-advanced-modbus-driver/41312/146 "2025-04-17T17:40:00Z")

</div>

Sigh. Broken RTU implementation for functions 5 and 6.

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

---

<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:** [April 17, 2025, 9:56pm UTC](https://forum.inductiveautomation.com/t/automation-professionals-advanced-modbus-driver/41312/147 "2025-04-17T21:56:00Z")

</div>

Well, the function 5 is now working fine, thanks.

I continued trying other things and had trouble using the rawModbus function via scripting.  
I get this error when I run it:

 ![imagen](https://us1.discourse-cdn.com/inductiveautomation/original/3X/8/4/843138d90b22983cb2e8a6aaa697227a92133451.png)

When I run it using ID=2 for my device, it works fine, but as soon as I change it to 300, it starts to fail.

I sent you an email with the logs in case it helps.

---

<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:** [April 18, 2025, 12:19am UTC](https://forum.inductiveautomation.com/t/automation-professionals-advanced-modbus-driver/41312/148 "2025-04-18T00:19:30Z")

</div>

That is a gateway scope function only.

---

<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:** [April 18, 2025, 12:20am UTC](https://forum.inductiveautomation.com/t/automation-professionals-advanced-modbus-driver/41312/149 "2025-04-18T00:20:42Z")

</div>

Oh, that one doesn't accept units above 255 anyways. You will have to lie to it, and put the second byte of the unit in the payload.

---

<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:** [April 18, 2025, 12:24am UTC](https://forum.inductiveautomation.com/t/automation-professionals-advanced-modbus-driver/41312/150 "2025-04-18T00:24:59Z")

</div>

> [@pturmel](#):
>
> have to lie to it

Hmmm. No, that won't work. ☹

Unanticipated lack of support for ELAM on the rawModbus function. Will have add that to my to-do list. It won't be soon. I have travels interfering.

---

<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:** [April 18, 2025, 12:43am UTC](https://forum.inductiveautomation.com/t/automation-professionals-advanced-modbus-driver/41312/151 "2025-04-18T00:43:30Z")

</div>

Yeah, I know. I used the message handler you recommended a few years ago when you added the rawModbus function. In fact, I used it with ID:2 and it worked fine.

---

<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:** [April 18, 2025, 1:10am UTC](https://forum.inductiveautomation.com/t/automation-professionals-advanced-modbus-driver/41312/152 "2025-04-18T01:10:23Z")

</div>

More. Hmmm. It should have worked. I see in the logs where you used `rawModbus()` to run function code 4, and the log message suggests you supplied an expected response length of 5 when that function returns 6 (16-bit bytes to follow, not 8).

Please test with something other than functions 3 and 4, or compute the response length for your tests using Lufkin expectations.

I don't see any reason the `rawModbus` function won't work with ELAM.

---

<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:** [April 18, 2025, 1:39am UTC](https://forum.inductiveautomation.com/t/automation-professionals-advanced-modbus-driver/41312/153 "2025-04-18T01:39:41Z")

</div>

Oh, I see. I don't really understand how to calculate the expected response length. I used that size because I took it from an example where two HR were read, and I assumed it was the same for two IR. Is there a formula or function I can use to calculate the expected response length depending on the Modbus function and the number of registers to be read?

---

<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:** [April 18, 2025, 12:24pm UTC](https://forum.inductiveautomation.com/t/automation-professionals-advanced-modbus-driver/41312/154 "2025-04-18T12:24:31Z")

</div>

The modbus specification describes all of the packet formats, with examples.

The format of function code 4 is identical to function code 3, so your expected response length for reading two registers of either type is five. But not for ELAM.

---

<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:** [April 18, 2025, 9:51pm UTC](https://forum.inductiveautomation.com/t/automation-professionals-advanced-modbus-driver/41312/155 "2025-04-18T21:51:28Z")

</div>

You were right!  
I computed the response length (6 for 2 registers or 4 for 1 register), and it works.  
The only downside is that using this code, I can't extract the values ​​from the read registers (I get "Bytes to follow=0"),

```python

from java.io import ByteArrayInputStream, ByteArrayOutputStream, DataInputStream, DataOutputStream
from com.inductiveautomation.ignition.common.model.values import QualifiedValue

baos = ByteArrayOutputStream()
dos = DataOutputStream(baos)
#Read start address and quantity
dos.writeShort(1)
dos.writeShort(1)

#Ensure data is in the byte stream
dos.flush()

rpcPayload = {'devName': 'POFF-LABO', 'unit': 300, 'functionCode': 4, 'payload': baos.toByteArray(), 'responseLen': 4}
retv = system.util.sendRequest('Test', 'RawModbus', rpcPayload)

if isinstance(retv, QualifiedValue):
	if retv.quality.good:
		bais = ByteArrayInputStream(retv.value)		
		dis = DataInputStream(bais)
		bCount = dis.readByte()		
		print "Bytes to follow=%d" % bCount
		while bCount > 0:
			bCount -= 2
			register = dis.readShort()
			print "Register = %d" % register
	else:
		print repr(retv)
else:
	print retv

```

but I know it's working because I can see it in Wireshark.

Unfortunately, I don't have enough programming experience to debug this code. 😔

---

<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 20, 2025, 9:37pm UTC](https://forum.inductiveautomation.com/t/automation-professionals-advanced-modbus-driver/41312/156 "2025-05-20T21:37:58Z")

</div>

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.

---

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

</div>

Hi @pturmel.

For some reason when I'm using broadcast unit 0, function 16. the Device Connection on the Gateway Fails and is not auto re connecting. Is there a reason for these?

```python
retv = system.opc.rawModbus("ModSimAdvanced", 0, 16, baos.toByteArray(), 3).get()

```

---

<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 9, 2025, 10:28pm UTC](https://forum.inductiveautomation.com/t/automation-professionals-advanced-modbus-driver/41312/158 "2025-06-09T22:28:38Z")

</div>

That doesn't look like a valid response payload length for function 16. (Should be 4, not 3.)

Also, make sure you are using v1.1.14. There was a reconnect bug fixed in the v1.1.13 betas.

Be aware that actual "broadcast" use is not supported by my driver.

Also, why are you using `.rawModbus` for a supported function code?

---

<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, 12:41am UTC](https://forum.inductiveautomation.com/t/automation-professionals-advanced-modbus-driver/41312/159 "2025-06-10T00:41:57Z")

</div>

I see.  
I was following and old example:

> [@pturmel](#):
>
> ```python
> # Ensure data is in the byte stream
> dos.flush()
> 
> rpcPayload = {'devName': 'P540Rack485', 'unit': 1, 'functionCode': 23, 'payload': baos.toByteArray(), 'responseLen': 3}
> retv = system.util.sendRequest('ModbusTest', 'RawModbus', rpcPayload)
> 
> ```

Sure I'm using the latest release:

 ![image](https://us1.discourse-cdn.com/inductiveautomation/original/3X/6/e/6ef892cdfed243baa156d6956173d602a1f7f281.png)

> [@pturmel](#):
>
> Also, why are you using `.rawModbus` for a supported function code?

How is supported? You mean by the core modbus module? The intention is to later use it for Elam Message Frame.

> [@pturmel](#):
>
> Be aware that actual "broadcast" use is not supported by my driver.

Ok, however when testing on unit zero as mentioned here:

 ![image](https://us1.discourse-cdn.com/inductiveautomation/original/3X/2/6/26d9f6f9862bb166695b56bdd252888b468e6774.png)  
The device connection crashes. I'm testing using ModSim.

---

<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, 1:55am UTC](https://forum.inductiveautomation.com/t/automation-professionals-advanced-modbus-driver/41312/160 "2025-06-10T01:55:45Z")

</div>

With Modbus RTU, unit #0 is not allowed to be treated as real node, and will not produce replies. My driver does not support non-replies. For any practical purpose, use unit #0 only with Modbus TCP devices that expect it to behave like any other unit number.

ELAM handling only happens when elam support is turned on, **and** the unit number is ≥248. What little is present in the ELAM documentation suggests that it does not work for Modbus TCP, only for RTU. If you are connecting to ModSim via Modbus TCP, expect bad behavior.

> [@jespinmartin1](#):
>
> How is supported?

Don't use `rawModbus()` for operations on Modbus addresses that have proper OPC Item support in the driver. In other words, avoid using any function codes with `rawModbus()` that are listed in the supported function codes of the driver.

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

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

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