Are you using controllers that natively speak Ethernet/IP?
Is speed/reliability important?
If the answer to all these questions is “Yes”, then you should be using Phil’s Class1 driver.
Granted, it does take a bit of extra work (you can’t simply drag and drop tags into Ignition like you’re used to). But the benefits massively outweigh the PLC-side effort. If you’ve never seen 10ms HMI to PLC RPIs then you’re missing out.
That being said, the driver still benefits from segmented UDT/AOI’s (dedicated status/command UDT’s make copying in/out of the IO buffers so much less tedious).
I noticed performance on a PV+ was poor using AOIs. So that may mean their own stuff is effected as well. A PV+ isn’t known to be a speed demon, but I noticed a huge difference between AOIs vs UDTs.
This is the main programming reason that I've come to prefer Beckhoff (can download UDT and AOI changes online) to Allen-Bradley--though that wouldn't hold true for ladder logic where the Logix editor excels. We're using mainly structured text in TwinCAT 3.1 (Beckhoff).
I agree, but there is sometimes the need to add/modify features. Most of that work can be accomplished offline, but at some point you will need to download to the processor. That becomes cumbersome in a 24/7 production environment.
System over time slice makes every connection that is already established to transact data faster. This definitely helps in data collection, but at the expense of increasing scan times for PLCs.
On alternative is to increase the number of connections to the PLCs. This will start parallel data streams, hence splitting the load. For example, I had 176% usage at 100ms scan rates with 2 connections for an L71 processor. I went online with the PLCs using the Studio5k Task Monitor and found out that I was only using about 130 out of 512 total possible connections to my PLC+network card. I opened 10 more connections, going to 75% total load factor, and much faster scan times on other tags too.
This is most helpful when there is more network latency than PLC CPU comms load. If there is very little network lag, extra connections have diminishing returns. But yes, don't skimp on connections.
I just tested this myself as I was curious, and found the following:
Reading 10,0070 tags from an AB 5069-L320ER/A PLC, FW 32.14
Using AOI tags: 1533% load factor
Using UDT tags: 35% load factor
I should mention that it wasn't really a great test... I set Tag Group rate to 50ms and the PLC guy didn't want to write logic in the PLC to change the tag values, so I had valueChange scripts running to change the values from Ignition....... Maybe I'll just write the logic myself and test it properly
I’ve bench tested before with a program I wrote using direct AOI’s. I created UDT’s with the same tag structure and same tag count just to compare the metrics, and it is as others have reported. About a factor of 10 in communication overhead.
also, we have recently, updated a production system which involved replacing the AB L61 processors with L71’s. Both on our PLC and a Vendor’s PLC. Our PLC is talking to significantly fewer tags but directly to AOI’s (with 4 times the concurrent connections), while the vendor PLC is talking to UDT’s and more tags with fewer concurrent connections. This just re-affirms what we’ve witnessed. We’ve started overhauling our AOI’s to implement UDT’s instead of the base structure because of this and so far it has helped (even with as painful as it’s been).
It's really a shame that Rockwell chooses not to document AOI access.
From 1756-pm020:
The Predefined, Add-On-Defined, and Module-Defined types, and Booleans within these structures, are difficult to deal with for various reasons and are beyond the scope of this publication. For alternatives for working with Predefined, Add-On-Defined, and Module-Defined types, and Booleans within these structures see the following topics in this chapter.
and
To improve tag access performance and to simplify the task of accessing structured tags through a network, create UDTs for the data that needs to be accessed through the network with members of the types listed following only, and access the UDTs as a whole.
• Atomic tags
• Arrays of atomic tags
• Other UDTs of atomic tags
• Arrays of UDTs of atomic tags
And can you just describe the difference that caused the AOI craziness between firmware <21.x and >= 21.x that made them inefficient to read in the latter versions?
It’s not just AOI craziness, the v21+ firmware basically introduced an entirely different “API” for reading tags. The old driver was basically doing direct memory reads. The new one reads based on an instance ID and follows the rules laid out in the manual.
I’m not super familiar with the data format we got back from the direct memory reads, if there’s different rules for AOIs vs UDTs, or any other gotchas. It’s a bunch of legacy code that just works, ish, and nobody touches it. The developer who wrote it is long gone and it was all reverse engineered.
Yeah, for better or worse, at least what we have now is built against official documentation.
I did some reverse engineering for the Siemens driver. Never again, not going to be responsible for that kind of non-sense. I’ve instituted a “no reverse engineering” policy for drivers. The protocol is documented or we don’t do it.
Thanks!