Hi Andres,
No, I have not, and have no prospects to do so. I have no access to a specification for it.
BTW, I have now replied twice to your email inquiries. You should look for them in your mail system. (A few minutes ago, and back on May 3rd. My email server says your email server accepted the messages.)
Phil
Thanks for the response Phil.
Unfortunately my email system is blocking your emails and I can't see them. Would you mind resending them to arossi.aci@gmail.com?
Thanks in advance.
Regards, Andres
@pturmel , while testing this advanced modbus driver configured as an advanced client connected with redundant slave devices. The problem is when i disconnect both the redundant devices the driver status on the device connection shows "Connected" and the status remains "Connected" until figured out.
In the second test, If one link is up out of the redundant client devices, it shows "Connected Recovering", and if i disconnect the live single link, the status remains "Connected Recovering", which is not an ideal scenario.
Is there a fix for this one ? thanks.
Thanks for the report. Will investigate.
Does Automation Professional's Modbus driver allows for multiple Modbus TCP servers/slaves on different tcp ports simultaneously?
Yes. Multiple server instances are supported. A single instance can also listen on multiple ports.
Automation Professionals is pleased to announce that this Advanced Modbus driver is now available for purchase for Ignition Edge, with a steep discount. See Automation Professionals' updated Module Sales Policy here:
https://www.automation-pros.com/Module%20Sales-2024-11-05.pdf
Automation Professionals is pleased to announce a new production release of the Advanced Modbus Module.
For Ignition v8.1.x: v1.1.7.242701819
This includes a bugfix for the driver status problem mentioned in comment #63 above.
This includes the constrained Transaction ID feature requested in this topic:
Automation Professionals is pleased to announce a new production release of the Advanced Modbus Module.
For Ignition v8.1.x: v1.1.8.242731956
This release fixes a client driver bug in holding register Masked Write operations, as reported by @woodsb02 over here, long ago:
I couldn't reproduce with the designer tag browser or with fire-and-forget writes, because the actual write worked. The breakthrough came when I scripted my testing with system.opc.writeValue(). Boom!
This bug goes all the way back to the beta. All users should upgrade.
Sigh.
Hi @pturmel, can I please ask how your driver behaves on the non-active backup server configured in warm mode?
In the manual it says “only the active server will open the given ports” - does this mean it ignores the “warm mode” setting?
Does this change when an alternate target/port is configured for modbus redundancy?
Yes, this. My drivers are always cold.
Ok, thanks for confirming 
Automation Professionals is pleased to announce a new production release of this driver:
For Ignition v8.1+: v1.1.9.242811552
This provides a better fix for the device connection status information, and fixes a potential bug in the Modbus TCP transaction ID limit feature recently introduced.
Hi Phil,
Sorry if someone already asked this,
Does the driver have any practical limitations regarding the maximum number of devices that can be connected? Or regarding the maximum number of TAGs between all devices? Or regarding the number of updates/sec that it can process?
In my case I have around +2500 Modbus TCP devices and +2000 Modbus RTU over TCP with an average of 200 TAGs each at a scan rate of 1min (only 20% of the TAGs change in each scan) and I want to have an idea of the size or amount of I/O gateways I need.
Thanks!
I don't have any users with such an extreme workload, but I would expect it to be possible with enough CPU cores and RAM. There's no hard-coded limits in the software.
Automation Professionals is pleased to announce a BETA release of this Advanced Modbus driver module, with one bugfix and two features.
For Ignition v8.1+: v1.1.10.243132114
Fixed a bug in diagnostics that breaks device diagnostics for all devices in the gateway--that page then looks like no devices are configured. Due to RateStats losing its Comparable<> interface somewhere along the way. (And me not noticing.)
Added [Diagnostics] folder to OPC browsing--basically a port of the code from the EtherNet/IP driver's Driver implementation. While in that mess, added separate diagnostic booleans for ConnectedA and ConnectedB when using live redundant connections.
Altered the OPC browse to fan out the tree of OPC Item Paths in smaller increments, to dramatically reduce the amount of scrolling needed to browse to specific points.
The bugfix has been cooking for a couple weeks, so that is solid, but the new diagnostics are only lightly tested, and the new OPC fanout is barely tested.
Automation Professionals is pleased to announce a new production release of this module, with a number of bugfixes, and the new support for scripted device creation (as mentioned over here):
For Ignition v8.1+: v1.1.11.250071612
Notable fixes:
This version also includes BETA support for Extended Lufkin Address Mode ("ELAM"), which expands the range of unit addresses to 0-2295. This support is only in the client driver. The client driver does not use this protocol extension's large packet functionality.
Corresponding support for the Server driver type, excluding large packet functionality, is planned. (If only for my own QA purposes.)
All users should upgrade.
Automation Professionals is pleased to announce a new production release of this module, with one more RTU bugfix and an implementation of Schneider's "Mod10" totalizer data format.
For Ignition v8.1+: v1.1.12.250132149
The Lufkin ELAM support is still a BETA.
Automation Professionals is pleased to announce a new BETA release of this module. It is functionally identical to v1.1.12, but has been completely refactored to run through the Device interface instead of the Driver interface. The only functional change is a switch to SamplingMetrics instead of PollingMetrics. That moves the minimum supported platform version to 8.1.7.
I think I've wrapped my head around this monster, and I can see the many functional opportunities this enables. But it just--finally--passed my internal QA this afternoon. 
This conversion is a blocker for v8.3 support, so I've been cracking my skull to get this done. Feedback is greatly appreciated.
For Ignition v8.1+: v1.1.13.250282248
{FWIW, I implemented Device. I did not extend ManagedDevice.}
For the extra curious:
git diff --stat 5fd6ecd250ed67..d9198670b521 Gateway/src
Gateway/src/com/automation_pros/modbus/DeviceGwHook.java | 113 ++++++
Gateway/src/com/automation_pros/modbus/address/ModbusAddress.java | 27 +-
Gateway/src/com/automation_pros/modbus/address/ModbusBitAddress.java | 324 ++++++++--------
Gateway/src/com/automation_pros/modbus/address/ModbusFieldAddress.java | 219 +++++------
Gateway/src/com/automation_pros/modbus/address/ModbusNumericAddress.java | 48 +--
Gateway/src/com/automation_pros/modbus/address/ModbusStringAddress.java | 260 ++++++-------
Gateway/src/com/automation_pros/modbus/client/AbstractClientReadReq.java | 178 +++++----
Gateway/src/com/automation_pros/modbus/client/AbstractClientReq.java | 2 +-
Gateway/src/com/automation_pros/modbus/client/AbstractClientWriteReq.java | 158 ++++----
Gateway/src/com/automation_pros/modbus/client/ReadBitsReq.java | 3 +-
Gateway/src/com/automation_pros/modbus/client/ReadFileReq.java | 9 +-
Gateway/src/com/automation_pros/modbus/client/ReadRegsReq.java | 3 +-
Gateway/src/com/automation_pros/modbus/client/WriteCoilReq.java | 163 ++++----
Gateway/src/com/automation_pros/modbus/client/WriteCoilsReq.java | 187 +++++----
Gateway/src/com/automation_pros/modbus/client/WriteFileReq.java | 31 +-
Gateway/src/com/automation_pros/modbus/client/WriteMaskedReq.java | 180 +++++----
Gateway/src/com/automation_pros/modbus/client/WriteRegReq.java | 170 ++++-----
Gateway/src/com/automation_pros/modbus/client/WriteRegsReq.java | 196 +++++-----
Gateway/src/com/automation_pros/modbus/config/DeviceConfigAction.java | 80 ++++
Gateway/src/com/automation_pros/modbus/config/ModbusClientDeviceType.java | 51 +++
Gateway/src/com/automation_pros/modbus/config/ModbusClientDriverType.java | 33 +-
Gateway/src/com/automation_pros/modbus/config/ModbusConfigLink.java | 31 ++
Gateway/src/com/automation_pros/modbus/config/ModbusServerDeviceType.java | 51 +++
Gateway/src/com/automation_pros/modbus/config/ModbusServerDriverType.java | 88 ++---
Gateway/src/com/automation_pros/modbus/config/settings/AbstractModbusSettings.java | 4 +-
Gateway/src/com/automation_pros/modbus/config/web/ModbusDriverSummary.java | 145 ++++---
Gateway/src/com/automation_pros/modbus/config/web/ModbusUnitEdit.java | 3 +-
Gateway/src/com/automation_pros/modbus/config/web/ModbusUnitsConfig.java | 560 ++++++++++++++-------------
Gateway/src/com/automation_pros/modbus/driver/GenericBase.java | 1410 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Gateway/src/com/automation_pros/modbus/driver/GenericDevice.java | 599 +++++++++++++++++++++++++++++
Gateway/src/com/automation_pros/modbus/driver/GenericDriver.java | 1485 ++++++-----------------------------------------------------------------
Gateway/src/com/automation_pros/modbus/driver/GenericModbusDriver.java | 63 ++-
Gateway/src/com/automation_pros/modbus/driver/ModbusClient.java | 75 ++--
Gateway/src/com/automation_pros/modbus/driver/ModbusServer.java | 698 ++++++++++++++++-----------------
Gateway/src/com/automation_pros/modbus/driver/RedundancyHandler.java | 391 +++++++++----------
Gateway/src/com/automation_pros/modbus/handlers/DoubleHandler.java | 150 ++++----
Gateway/src/com/automation_pros/modbus/handlers/FloatHandler.java | 94 ++---
Gateway/src/com/automation_pros/modbus/handlers/IntBcdHandler.java | 94 ++---
Gateway/src/com/automation_pros/modbus/handlers/IntHandler.java | 92 ++---
Gateway/src/com/automation_pros/modbus/handlers/LongHandler.java | 150 ++++----
Gateway/src/com/automation_pros/modbus/handlers/Mod10Handler.java | 14 +-
Gateway/src/com/automation_pros/modbus/handlers/ModbusHandler.java | 68 ++--
Gateway/src/com/automation_pros/modbus/handlers/ModbusOpcHandler.java | 66 ++--
Gateway/src/com/automation_pros/modbus/handlers/ShortBcdHandler.java | 58 +--
Gateway/src/com/automation_pros/modbus/handlers/ShortHandler.java | 58 +--
Gateway/src/com/automation_pros/modbus/server/MaskWriteRegCmd.java | 89 ++---
Gateway/src/com/automation_pros/modbus/server/ReadBitsCmd.java | 17 +-
Gateway/src/com/automation_pros/modbus/server/ReadFileCmd.java | 201 +++++-----
Gateway/src/com/automation_pros/modbus/server/ReadRegsCmd.java | 121 +++---
Gateway/src/com/automation_pros/modbus/server/WriteCoilCmd.java | 113 +++---
Gateway/src/com/automation_pros/modbus/server/WriteCoilsCmd.java | 11 +-
Gateway/src/com/automation_pros/modbus/server/WriteFileCmd.java | 201 +++++-----
Gateway/src/com/automation_pros/modbus/server/WriteReadRegsCmd.java | 127 +++---
Gateway/src/com/automation_pros/modbus/server/WriteRegCmd.java | 89 ++---
Gateway/src/com/automation_pros/modbus/server/WriteRegsCmd.java | 113 +++---
55 files changed, 5507 insertions(+), 4457 deletions(-)
Another BETA. Fixed sampling stats, as well as possible.
For Ignition v8.1+: v1.1.13.250292153
With the standard Device Status graphics, I cannot make "Actual Sampling Interval" show up properly. That display adds the Queue Duration to the desired Sampling Interval, assuming that queue timing adds to the sampling time.
But that isn't true in my driver architecture. At the start of each poll interval for a given pace, my architecture generates optimized requests for all monitored items at that pace and queues them. Which means there is always some time in queue, averaging a little less than the actual time needed to get all the responses.
So, to get actual sampling time with my driver, ignore the Device Status page, and get it from the OPC diagnostic item for that pace.
Also note that I deliver a proper overload percentage that accurately reflects the relationship between the actual sampling interval and the desired sampling interval. When overload is zero, that pace is just keeping up.
Unlike IA's driver, I report a negative overload when there is spare bandwidth.