[SOLVED] Is my Load Factor on a PLC connection(s) too high?

Good morning,

Periodically my company is seeing a spike in the load factor on two of our connections to our PLCs. The effects are visible on the HMI and things slow down and sometimes database queries fail. Is a load factor higher than 100% a strong indicator of a problem?

PLC1 <–> Gateway 268% Load Factor

PLC2 <—> Switch1 <—> Switch2 <—> Gateway 106% Load Factor

Below are pictures of the load factor.

what speed NIC / network is between your system and these PLC’s? I think (someone please correct me if I’m wrong, not terribly experienced with this) that your load factor shows high because your requests vs your actual throughput is very high. Is there a network bandwidth bottleneck here possibly?

100 mega bytes per second I believe… the killer I think is this: the gateway is running on a windows 10 PC. I think the customer is just reaching the point where the gateway (windows 10 PC) can no longer keep up but thought I’d get some second opinions.


And since it doesn’t account for the bandwidth needed for writes nor for any scripted system.opc.* functions, I would suggest that a load factor in the 80s or 90s isn’t good, either.

Your mean response time is rather high, like one might expect from a really old processor technology. Single-digit milliseconds is good. What brand/model processor is this? What network topology? (OPC drivers are extremely sensitive to ping time…)

Not a likely factor. Though I will admit that I avoid deploying gateways on any flavor of Windows.

It’s an Advantech PPC-4211W-P5AE.

Windows 7 Pro soon to be upgraded to Windows 10.

Intel Core i5-4300U CPU @ 1.90GHz

8 GB ram

I think @pturmel was referring to your PLC not the gateway hardware.

1 Like

Agreed, although I’m curious what else is running on it. Gateway + 1 client at the very least.

1 Like

Yeah, gateway + designer + client + DB on a wimpy dual-core i5 would be a bit much.

1 Like

Is there a way to track the load factor? Would I look in the system tags?

Not in the version you’re using. Starting in 8.1.6 the diagnostics were overhauled a bit and also made available as OPC tags under the device’s [diagnostics] folder.



The code in that post will only work in 8.x, not 7.9.

Maybe my memory deceives me, screenshots look like v8 to me, but it’s 3:49am here so… yeah :anguished:

Is there any advantage to making my scan classes prime numbers? 499 ms or 503 ms instead of 500 ms? We are noticing a group of tags are periodically being called to scan at 500 ms and creating a large amount of the load factor.

This system is running 7.9.10.

No, I cringe when I see this because the strategy is nonsense. It doesn’t matter, the requests eventually “smooth out” and each polls as close to its assigned sampling interval as possible, your prime number scheme is irrelevant. It’s not a realtime system doing a precise scan of some fixed overhead logic.

1 Like

Might be worth inspecting the PLC’s and see how loaded they are. possibly not enough overhead time for the connections on the PLC? Not sure of brand or model obviously.

Just an update… on the 1769-L33ERM PLC we changed the continuous task running at 10 ms to a periodic task that runs at 100 ms and the load factor went from 106% to 10%.

Tomorrow morning we will try a similar change on the other PLC at this site.


Yep. Avoid continuous tasks at all costs.