Automation Professionals' Advanced Modbus Driver

[pturmel]

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.

[pturmel]

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.

[pturmel]

A minor update has been released:

For Ignition v8.1: v1.1.0.230811645

This fixes an embarrassing bug in File Record Writes.

[pturmel]

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

[woodsb02]

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:

Modbus client

Modbus advanced client:

Logs:

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

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

[woodsb02]

@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

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
3. Create a log entry when an idle session is dropped

[pturmel]

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.

[pturmel]

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

[pturmel]

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

[woodsb02]

Thank you!

[pturmel]

Note the beta announced over here:

Ignition OPC UA Server Redundancy (Modbus TCP)

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 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…

[pturmel]

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.

[hhbauss]

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!

[pturmel]

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.

[hhbauss]

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

[hhbauss]

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 (472.8 KB)

[pturmel]

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

[pturmel]

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

[Andres_Rossi]

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

Thanks