Automation Professionals' EtherNet/IP Communication Suite V2

Automation Professionals is pleased to announce its latest EtherNet/IP Communications Suite driver module, a major upgrade to its EtherNet/IP Class1 Communications module, as a Public Beta.

As of April 15, 2023, this is now a Production Release.

The primary new feature is its new Generic EtherNet/IP Client Driver, a drop-in replacement for IA's Logix V21+ driver and its Omron NJ/NX driver. It does work with older Logix processors, and also works with Rockwell's MicroLogix 8xx family (ethernet models).

The motivation was (and remains) speed, using Automation Professionals' intimate knowledge of ODVA's EtherNet/IP specification, the underlying Common Industrial Protocol ("CIP"), and how various brands use the specification in their products. It also offered a convenient path to offer features of related products that Inductive Automation has not yet chosen to implement.

v2.0.0.223162257

Visit my Module Sales page where the Latest Production Release is posted.

User Manual

This is a Major Version Upgrade--prior licenses will not work. If you purchased your license in the past year, you are entitled to a free upgrade of those features--contact us. Other upgrades may be discounted.

Key features and changes:

  • Fixes the optimization problem for Logix Add-on Instructions, as described in this topic. The performance difference for small AOI types is around 3x. One alpha tester reported greater than 25x improvement. My testing with some large PlantPAX™ AOIs exceeded even that. Do note that typical AOIs will require permissions changes in the definition to obtain any speed-up.

  • Fixes the near total lack of optimization for Omron NJ/NX processors. Substantial performance gains are likely.

  • Supports all modern Logix and Omron data types (using their CIP names, for the most part).

  • Eliminates the requirement to export Omron NJ/NX tags from Sysmac Studio. With this driver, Omron global tags that are published are fully browsable. New tags added online will be auto-browsed.

  • One driver handles all target device types and brands that use symbolic addressing. If you change brands or models or firmware versions, and manage to maintain the same tag hierarchy, this client driver will keep working. Lightly tested all the way back to Logix firmware version 10 in a 1756-L55M13 processor.

  • Auto-determines the largest CIP connection buffer size from the configuration value supplied. The default starting point is 4000 bytes, the max allowed in most modern processors. A new diagnostic value reports the actual buffer size determined for a connection.

  • Full support for one-dimensional arrays of primitive numeric types. Reads deliver the actual length in the PLC. Writes (of numeric lists) are automatically zero-extended or truncated to the PLC's length.

  • Data types extracted from the target processor during browse/probe are turned into Ignition UDT JSON files, organized by device. Use the button for "More... Configuration" in the device configuration list to get to them. They are also placed in the device's home folder in the gateway filesystem, if you prefer to get them that way.

  • Support for browsing MicroLogix 8xx global tags to the same extent that they are browsable from Rockwell's RSLinx Classic.

  • The Host Driver now supports many more data types and structure layouts, encompassing nearly everything Automation Professionals has encountered in Logix processors, Omron processors, and many brands of EtherNet/IP I/O devices.

The driver has a new licensing model, currently with five combinations:

  • $1,000 New Client driver only.

  • $2,000 New Client driver, plus Host Driver in adapter mode.

  • $3,000 New Client driver, plus Host Driver in adapter and scanner modes.

  • $1,000 Host driver in adapter mode, equivalent to version 1.x "Base Features".

  • $2,000 Host driver in adapter and scanner modes, a superset of the version 1.x "Premium Features".

That last option is a superset because scanner mode no longer has a subnet count limit. If you purchase Scanner mode, you may now deploy it on however many subnets for which your gateway has network interfaces. (Many I/O modules use UDP multicast for input packets--those cannot escape its subnet.) This is now embedded in the license, not a per-device feature code.

Usage notes and known problems:

  • The driver will not automatically look to slot 0 for chassis-based controllers. The default connection is to a built-in processor ethernet port. Put slot 0 in the route path if you are hopping through a chassis ethernet module. Or some other slot number, as applicable.

  • The buffer size algorithm has gotten stuck on very old Logix processors. Set it to 500 if that happens to you.

  • IA's driver is faster than this one on multi-dimensional array tags unless the last dimension is large. This driver only optimizes the last subscript.

  • Within AOI definitions, all parameters and local tags must have at least read-only external access. Beware! Local tags default to no external access, and the definition editor doesn't show their access column by default.

  • The AOI optimizations can be further enhanced by collecting multiple instances of particular AOI tags into single array tags. If necessary, use aliases iin program scope n your code to maintain the look, but point Ignition at the array elements. (Particularly for small AOIs, where many would fit in a communication buffer.)

  • Both IA's driver and this driver are pathologically slow when accessing alias tags. From Ignition, access the base tag they point at instead, which permits optimization with everything else.

  • This driver doesn't handle alias parameters in Add-on Instructions at all. Point Ignition at the base tag (an AOI local tag, typically) instead. (Please don't report this--it is on the to-do list already.) Fixed in v2.0.2.

  • If you delete a Logix or Omron device to replace with this one, using the same name, be prepared to restart your gateway. Shouldn't be necessary, but often is. Don't know why--not sure it's this driver's fault.

  • If you install this driver over any earlier version, you must restart the gateway to pick up changes to localization files. Also check any prior Host Driver instances to ensure their XML configuration was interpreted correctly. (There were regressions fixed, but the possibility of more is part of why this is a beta release.)

Future plans:

  • Browsing and polling of parameterized devices, like drives and configurable I/O devices, is planned. Much of the infrastructure is in place--it just doesn't work yet.

  • Support for reading and writing unbrowsed tags and objects is planned, using datatype annotations in the OPC item path. For ML8xx and Omron tags that aren't exposed by their browse protocol but are accessible if you know their names.

  • A limited license at a reduced price is likely in some form. Tentatively allowing just ML8xx access. Will be a limited device count.

19 Likes

I suppose I should warn everyone except @Kevin.Herron to avert their eyes from the User Manual's chapter seven.

Dang it, now I gotta look!

1 Like

Alright, on to 7.3.2 and....
cross-eyed

3 Likes

{ Time for an adult beverage... }

1 Like

This was originally @nminchin's post in the alpha testing discussion:

Just FYI for all, in my tests, the results look impressive :slight_smile:

Below are the results comparing Phil's driver with the IA Logix driver.
One note: Phil's reports the old "Load Factor" rather than the new "Overload".

Check that request count and sampling interval of the Logix 1500ms :exploding_head:
Edit: Load factors (equivalent):
Phil's @1000ms: 11%
Logix @ 1500ms: 249% :open_mouth:

Phil's:

Logix:

5 Likes

Another snip from alpha testing (from my lab):

Sample of what's possible with an NJ501 processor, with the default concurrency of 2, and the auto-detected max message size of 1994:

{ 60k tags absolutely crushes IA's Omron driver. }

6 Likes

I tried installing and using this driver in our PROD environment and did not have success. When I installed it I renamed the existing LogixDriver to a different name and disabled it. Then I created a Generic Client Device and used the same name. When the driver started it got stuck on “ProbeLogix”.

Using the OPC Quick Client it looked like the tags in the PLC were browsed. But reading or subscribing to tags fail. Then on the Gateway status page I saw that were threads that were being blocked from running.

Since we had down time I also pointed our DEV environment to the PROD PLC and it was working as expected. Our DEV environment is not a 1:1 system. DEV is a vanilla install of the same Ignition version, but I only import tags and objects that I want to use for testing.

Any ideas on where to begin troubleshooting the driver when stuck on “ProbeLogix”? I did take the thread dump as the Gateway Status page suggested.

There should be several loggers created that have the device name in brackets. Set all of those to debug and send me the wrapper log after it gets stuck. Note: Replacing an IA Logix driver with my driver under the same name likely needs a gateway restart to clear out stale OPC nodes. This is probably not practical on a production system unless you have a large enough downtime window to restart the gateway both to test and to stop testing.

If you can, it would be helpful if you could send me your dev environment's probe results. (The ProbeLogix.gz and .json files.)

We should move the balance of this discussion to private messages or email.

I'm very ignorant of the intricacies of the drivers, so please forgive me. If your driver is significantly better in the way it operates, why wouldn't IA do the same with their logix driver? Is there something that the IA driver does that yours doesn't do that might be important for healthy system operation? Not trying to poke holes, just genuinely curious.

It is complicated, and required reverse engineering. IA has a policy against using non-public techniques in their drivers. So it isn't a question of "could". The other features of the driver are more niche, and IA hasn't been interested in the investment required to replicate my module. They simply point interested parties my way. (That is the point of the module showcase, after all.)

2 Likes

I should note: There is a bug noted in the announcement above regarding aliases within AOIs not being supported. AOIs that have such, where they serve as permission bypasses for hidden/read-only elements, and are locked to prevent edits to those permissions, cannot currently be supported.

Work is in progress to support that case with fallback to unoptimized access, and is the blocker for a release candidate.

In the samples I have from testers, there are a number of affected PlantPax AOIs. And I've seen a couple ProSoft AOIs that show source, but do not permit edits. Those could be recreated from scratch if you had to (or want to optimize them).

Fixed in v2.0.2.

1 Like

At our facility, we'd like to obtain the Ethernet/IP scanner module so that we can monitor/control Ethernet/IP enabled devices without a PLC.

Would you recommend the beta for this application in production, or should we stick to v1 for the time being?

Stick to v1 for production until v2 is officially released. While I'd like feedback on actual scanner use with v2, I don't recommend betas in production. If you purchase a license, it will cover v1 & v2 for the features you chose.

1 Like

That makes sense, thank you.

My main concern was with the license but if it's backwards-compatible, that's great!

Updates for all:

  1. Alias support is close to release in another beta. Aliases within AOIs will silently expand for optimization with non-alias access to peer structure data. Optimization of AOIs still depends on all member tags having at least read-only external access.

  2. Alias optimization support for tags is likely to be included. (Trying to nail down some corner cases across versions.) When tag internal addresses are included in the driver's advanced options (on by default), all tag addresses will be correlated to determine which are aliases of others, and to which inner element. This permits optimization of the alias with other access its base tag.

  3. The JSON generation for imports into Ignition's Tag Browser has been expanded to include an import for all tags in a controller, using the types JSON. This has greatly accelerated my testing, and likely will help y'all, but I highly recommend pruning and re-organizing before production use.

  4. Other future features mentioned above are being deferred to v2.1 or later.

1 Like

I am so excited for this.. we literally had to upgrade our NJ's to NX's to deal with the bad device loading.
Got a couple more lines / plants that may be built so will watch this with great interest.

And auto browsing of omron published tags?!
:innocent:

1 Like

I don't have an NX in my lab. A report from the field would be helpful... as long as you don't risk production yet.



Tested driver with Omron NX102-1100, almost 4000 tags:

  • Ignition NX driver: Sampling interval 13 600 ms
  • This driver v2 (EthernetIP Class 1 Communications-2.0.1.230022328-v81), sampling interval less than 1000 ms, load factor 21%
3 Likes

Thanks for testing an NX for me!

So, 13600ms / 282ms => 48x speedup. (:

Edit: Same concurrency settings? I did the math assuming concurrency == 1.