Are you using the native IA Logix driver?
Are all of your tag groups set to Subscribe (not polled)? - If so:
Can you post a screenshot of your device's aggregate statistics (Gateway Config --> Status --> Devices --> --> Details)? I'm curious about your overall monitored item count, also request count & overload % of problematic tag groups...
I am using the native IA Logix driver.
All groups are set to Subscribe.
This first device is for alarm tags. It's tag group is set to Direct with a 1,000 ms refresh. The overload jumps around at first, but eventually calms down:
Here's the main device status. All the leased tags use this one:
Here's my PLC comm load:
It will sometimes briefly jump to 100% and then drop back down to 20% or so, but stays around here most of the time. Usually when someone is changing screens and new tags are being leased.
So in this state I'm seeing it take extremely long periods of time for leased tags to start getting data.
Here is the setup that improved my response time:
Instead of having one device connection for all non-leased tags and one for all leased tags, I split it up by section. I have 10 sections. So I have a device configured for non-leased and leased for each section, plus another pair for overall system stuff.
Here's overall system direct tags:
Overall system leased tags:
Oddball section direct tags:
Oddball section leased tags:
Regular section direct tags (so, this times 9)
Regular section leased tags (also this times 9)
PLC comms when everything is calmed down:
Again, intermittent spikes to 100% but never sustained.
One thing to be aware of is optimization of UDTs and AOIs with AB PLCs. If you're reading tags from a common UDT at different rates, you're hurting yourself and you'll generally get better performance reading the entire structure of tags at the faster polling rate. All members of the UDT/AOI need to have external access set to at least ReadOnly but if any member has external access set to None this optimization won't work.
Also, make sure your CIP connection size is set to 4000 bytes under advanced and not the default of 500 bytes. This will make a big difference as well as more data can be packed into each poll/response query.
Yep. Ran into these as well. The faults are embedded in a lot of UDTs that I need to scan at a direct rate while everything else in the UDT i want leased, so I have mapping routines for all the faults going to special "Ignition Fault" UDTs that are just fault bits. My direct groups are reading those instead of from the main UDTs directly.
Also should I set my CIP connection size to 4000 on all 22 of my devices or should I stick with 500?
If they're all part of a larger UDT you might be better off having them all in the same direct tag group. Ignition can tell it to read the entire UDT at once rather than splitting it up.
I would use 4000 on all connections.
Oh they are. All my alarms are in a direct tag group, which all point to the same few UDTs and read the entire thing. My direct tag groups aren't posing any issues at all.
What I'm saying is that if your alarm UDT is embedded in a larger overall UDT that your leased tags may perform better if you put the entire UDT in the same direct tag group.
I did try that and it did not go well. The UDTs are pretty large. Those embedded alarm UDTs are not being read by ignition. I am mapping the fault bits from them over to another UDT that I set aside just for Ignition to read on a direct tag group. THAT is was Ignition is reading direct, not the embedded UDTs that share space with leased tags.
Every UDT in the PLC has its' elements being read by Ignition in the same tag group.