Device Load Factor

For anybody else following along… I just want to say that our Load Factor calculation is garbage and starts to fall apart under anything but the most basic scenario (e.g. tags subscribed @ 1000ms and no other rate groups).

We’re working on a replacement for it right now that should give you a better indication how each sampling group is performing or not performing vs. its ideal.

edit: the overhauled load factor calculation and diagnostics OPC tags are present starting in 8.1.7.


Thank you for the help and clarification. I am looking forward to an updated Load Factor calculation. I will try and work something out with the AOI with the 3 UDT’s like Phil suggested in the other topic. I have been wanting a reason to get rid of the P_Motor/P_VSD AOI anyway and writing my own that doesn’t have an obscene number of tags for functions we don’t use… maybe today is the day.

1 Like

Lets not be dramatic. I’ve got a large project w/40,000+ tags and ~ 60-70% of those are from Ignition UDTs pointing 1:1 with the AOI instances and performance is perfectly acceptable. The only fancy sauce involved is packing the PLC AOI tags into an array.

Yes, let’s. The system you describe must have relatively slow scan classes/tag group paces or you are using the built-in port of an L8x. Your comms performance would improve by a factor of ten or more if you separated the public parts of the AOIs as described in the linked post. Your application may be able to tolerate the difference but most applications cannot. Especially on older processors.

Putting AOIs into arrays does not mitigate the hidden member restrictions.

1 Like

Yea. I am in total agreement. I removed maybe 15 AOI UDT’s (about 120 tags in each) out of ignition that I pulled in for areas I haven’t started development on and my MSG Class 3 utilization dropped 8%. I really wish I knew this was going to be an issue on the front end. I am not even 1/3 of the way through this process. I spent a lot of time making that P_Motor faceplate. I hope someone sees this and catches it on the front end of their development. I’m sure most SI’s know about it, but its going to costs me a decent amount of time and effort to fix this.

I am a bit of a dummy. I had all of my tags in the default 1 second tag group. I leased all of my configuration and control tags for my UDT’s and everything dropped super low, less than 40% on my Class 3 connections. I still plan on creating new AOI’s though.

We fought everything trying to be stubborn and use AOIs. It wasn’t until I did some serious testing and reading across multiple scada systems and in depth study and testing with Ignition that we changed to a udt and aoi system. 95% of our base tags are now in udts. One one specific system that has 150k tags plus we went from 90-103% load factor down to 10%. That was enough for me to know that AOIs are going to give you a bad time. Do AOIs work? Yep. But it is a shakey foundation to build a large system on, in my opinion.


My PLC guy hates the idea of using UDTs with AOIs as you then can’t easily glance a look at the values going into the block. What about using FactoryTalk Linx as the OPC server to read these in? I read somewhere that because it’s all Rockwell, it’s still super efficient when reading with their software. I haven’t looked up the cost of Linx yet though I imagine it’s around the AUD $5K mark

I don’t know of RSLinx is faster with AOIs in particular but it’s worth a try. They are faster in general because they use an undocumented/proprietary method for reading tags instead of the method outlined in 1756-PM020.

If you’re going to spend, I’d recommend my Class1 driver. If the processor CPS’s the AOI into a I/O buffer, the hidden/locked bits go along for the ride. And you get blistering speed as a side benefit.

1 Like

I’m not a plc guy, but will this affect my scada tag addresses?

Yes it would. Generally when I do this, I arrange for the data to land in my module’s emulation in matching tag names & structures, so the OPC item path is identical except for the device name. Note that transmitting tags this way effective yields a read-only value in my module, so you’d use the standard driver with OPC writes to go the other way.

1 Like

Not disputing that inefficiencies exist, and that I could spend a bunch of time refactoring AOIs to better optimize. However a “Factor of ten” does not necessarily equate to 10x noticeable improvement user experience. Would I be better off refactoring for the sake of Ignition? Or investigating an alternate OPC comm driver?

meh, It’s the inability to make online-changes that deter me more than anything, that’s for AOI’s in general.

Approximately 3400 AUD (2,600 USD) from the last quote I had. For the Professional version.

Just my two cents:

  1. Do you have control over the PLC code?
  2. Are you using controllers that natively speak Ethernet/IP?
  3. 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).

1 Like

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).

If you need to make constant changes in AOIs then in my opinion you aren’t using them for their intended purpose.


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.

1 Like

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.