Device Load Factor

Wish I’d seen this suggestion a long time ago. I have an L71 which is doing very little work and even polling 130 tags at 500ms was unusable.
I changed the system overhead time slice from 20% to 50% and my device load went from 300% to 17%
Not only that, but studio 5000 online edits are much faster as well.
Thanks for the advice.

1 Like

Bringing this thread back to life because we recently set up a new Ignition server (new server hardware) to replace the current server. We have been running the new server in parallel with the old server and out of the 23 PLCs connected, only 1 LogixDriver has a high load (2 other LogixDriver PLCs occasionally have an overlay…NONE of the SLC or Micrologix have ever experienced an overlay issue). Over 300% and causes red overlays every 2-3 seconds…quite annoying. The strangest thing is that the old server isn’t seeing this overlay…but also has a similar load factor showing.


So, not having access to the PLC myself, is there anything I can do from an Ignition point of view? Or does this absolutely require calling in the guy who set up the PLC to check the system overhead time slice thing?

Your mean response times are astonishingly bad. Logix processors usually respond in single-digit milliseconds. For starters, make sure the PLC does not have a continuous task – convert it to a periodic task with the longest practical interval for your process.

1 Like

I’m happy to report that changing the continuous task to periodic at even 125ms has brought the device load factor down tremendously. Thanks Phil.

2 Likes

Hi Mbhagotra… was browsing around and noticed your post. For me, using a prime number based timing scheme seemed to really get the most out of my throughput and efficiency. For instance, if you have scan classes set up at 500ms, 1000ms, 2000ms and 10000ms, then you are causing these to frequently fire simultaneously because they are multiples of each other. I have used primes, like 401, 463, 773, 1123, ect. This assures that there will be very infrequent polling overlaps.

Cheers,
Steve

8 Likes

Hello all,

I just wanted to bring this back to life real quick because I have some questions regarding the newer L80 processors. I currently have 8,963 tags and I am using the Gb port on the front of the PLC solely for my Ignition server. My switch says I am hovering right around 2-2.1Mbps on the port for the PLC. My load factor is at 95%. Why is this so? Why am I not able to use at least half the bandwidth available to me? If this sounds like I don’t know what I am talking about, its because I don’t. That is why I am here. My IO comms on the L83E is only around 4-4.6% actual vs theoretical. The only thing I see is the MSG Class 3 at 97%. My CPU is idle 74% of the time… Is there anyway to allow more time for comms or to adjust this in any way to get more out of the PLC gigabit port?

Take your CIP connection size up to 4000 on an L8x processor.

Are your tags in AOIs or UDTs?

If in AOI’s you are going to have a bad time.

That dropped my Load Factor to 55-60%. But my MSG Class 3 is still around 88-90%. I wonder why that is?

The gigabit port is not the bottleneck. A 100mbit port would not be a bottleneck.

The bottleneck is the PLC.

Bumping concurrency and the CIP connection size can help but ultimately all of this is class 3 comms and the PLC can only do so much of it, as you’re seeing.

Yes, They are AOI’s. specifically the AB default P_Motor/P_VSD/. I made UDT’s in Ignition and only brought in the tags I needed the operators to use/see. I basically re-made the P-Motor faceplate in Ignition. It was a pain. We are migrating from standalone Panelviews running FactoryTalk ME. Why are AOI’s worse for the Load Factor?

AOIs can’t be read efficiently because even if you have made every normal tag inside it externally accessible there are still EnableIn and EnableOut tags locked to “hidden”. So the driver has to read all tags belonging to an AOI individually rather than as a whole structure.

More discussion of this phenomenon over here:

2 Likes

Thanks Phil I was looking for that post and quoting it from memory.

When you say bumping concurrency, what is that? I am going to assume class 3 comms are also sent to PanelViews? We have lots of those… Which I am also assuming that this class 3 comms is all of my class 3 comms including those going to other ENBT cards etc…from this PLC??

I searched for AOI plus myself… (:

It’s another setting on the driver along with the CIP connection size. It controls the number of CIP connections the driver makes and thus the number of concurrent requests the driver will issue to the PLC.

Yes, the utilization you’re seeing is from all the things talking to the PLC.

It may not make sense to increase concurrency and/or connection size if your PLC is already near full comms usage.

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.

9 Likes

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.