Background:
- L72/EN2TR
- No continuous task
- 20% system overhead time-slice, reserved for system tasks
- Max concurrent requests = 2
- CIP connection size = 500
- Tags are a mixture of UDTs and AOI datatypes (legacy code that hasn’t been rewriten)
I’ve got an L72/EN2TR that’s maxing out on CPU usage due to comms, but still communicating great with Ignition. Studio 5000 runs extremely slowly when online but the response times for Ignition’s communications seems normal.
The bad:
The good?:
This is after disabling the device connection in Ignition:
Anyone seen anything like this before/have any suggestions? I’ve tried playing with the max concurrent connections and CIP connection size (up to 8 concurrent connections and up to 4000 CIP connection) size, but any change only seems to hurt the response times in Ignition and doesn’t seem to provide any relief for the processor.
If you can’t refactor the program’s tag structure or increase the overhead timeslice I don’t think there’s anything you can do but request less tags at a slower rate from Ignition.
Not using AOIs and ensuring UDTs read by the HMI contain just tags actually needed by the HMI so you aren’t reading things you don’t need would meet the “less tags” advice but it doesn’t sound like you can do that.
1 Like
Don’t use a 100ms poll rate. That is the vast majority of your load. Probably shouldn’t use a 250ms poll rate, either.
(That kind of thing is why my EtherNet/IP module exists. Rockwell’s I/O comms is way less CPU load. You can also get around the AOI problem by CPS’ing those tags into the I/O buffers.)
1 Like
If there’s no magic bullet here with lowering the scan class rates then we’ll probably just end up refactoring the tag structure. I’ve seen this issue before but only at much higher tag counts.
Since there’s quite a lot of instances of these “legacy” AOIs (but relatively few types), I’m mulling over the idea of creating instructions to map the parameters to/from the legacy AOI into a new UDT type for use in Ignition, with the new UDTs organized into arrays.
Pseudo code/AOI:
Instruction: AOI_to_UDT
InOut: Old_AOI
InOut: New_UDT
Map input parameters from New_UDT into Old_AOI
Map output parameters from Old_AOI into New_UDT
Super frustrating that this still exists... we also are experiencing this on multiple projects for clients... I don't understand how RSLinx/FTLinx can effectively read tags embedded within AOIs/UDTs without causing the CPU to run up to 100% while the IA Logix driver cannot... Our CPU load is minimal without connecting to Ignition -- even with only 1s and 10s tag groups (and relatively small tag counts). We've seen this on L75 and L85 controllers.Really don't like the idea of the headache of adding another AOI for mapping AOI tags to InOut DINT arrays, then unpacking in Ignition...
Please, please just make this go away... it makes the system almost unusable...
We've discussed this elsewhere, but it's very simple.
- Rockwell explicitly states that the rules for interpreting AOIs are different than they are for UDTs, and that those rules are not documented for 3rd parties. See 1756-pm020.
- In addition to his, RSLinx/FTLinx uses "proprietary" and undocumented CIP services to create and read "Optimized Packets" for as much of the data as size allows. This gives it another speed advantage over all 3rd parties who read using the standard documented tag read services.
Phil's been working for some time now to reverse engineer the AOI rules and figure out all the little corner cases and intends to implement what he has found in his Ethernet/IP driver. At the moment we have no plans to follow suit and try to do that reverse engineering, but who knows.
I really cannot wait lol... plant is running... brains are being boiled... questions as to "why we didn't just go with FTView"
Thanks @pturmel 
for taking this on as a third party (?)
At current status... I don't think it's fair to propose/suppose that the IA OPC Logix driver works effectively with any modern clx controller (given that the industry has moved towards AOIs for almost everything -- for fairly obvious reasons...). i.e. suggesting that it works just fine without AOIs just does not cut it at this point...
It simply does not make sense HMI/OPC communications can monopolize ALL available cpu space in 2022 on a high-end controller (~$30k for L85)... It is painful to even make edits in Studio5000, or even open the controller webpage while Ignition is trying to extract any data at all.
Perhaps IA should be upfront in suggesting purchasing the Rockwell OPC UA server for all clx devices until this is resolved? It's just generally disappointing... I know this has been an issue for a while, it's turning people/entire companies away (and I really like the Ignition platform!) -- need to fix asap. Entire key function of the platform is to connect PLCs to HMIs -- if the basics aren't achieved, all the bells and whistles are meaningless...
If we just bought FTLinx in the first place because it was understood as necessary, everyone would be happy
Still a fanboy... just annoyed this is still an issue!
1 Like
