Allen-Bradley Driver Load: Saturation Is Not a Leak

Allen-Bradley driver load shows up first as a communications problem: the PLC communications core reaches 100%, tag updates slow, and the gateway may become unstable enough that operators restart it. A restart once per week may hide the symptom, but communications-core saturation alone does not prove a gateway memory leak. Treat CPU load and memory retention as separate faults until measurements connect them.

Separate saturation from memory growth

Start here. Record what changes before the restart: PLC communications-core load, gateway process memory, tag update quality, request latency, and pending-request or timeout counts exposed by the OPC server.

Symptom	Probable cause	Next reading
Communications core stays at 100%	The request workload exceeds the PLC communication service capacity	OPC request rate, tag groups, scan classes, and timeout counts
Memory rises during load, then stabilizes	Active subscriptions, caches, queues, or buffers expanded to serve the workload	Memory baseline after load returns to normal
Memory baseline rises after every identical test	Objects or buffers may remain retained	Comparable heap dumps or process-memory captures
Memory grows while PLC load remains low	The PLC driver may not be the controlling variable	Other gateway modules, clients, histories, scripts, and connections
A restart restores performance	Restarting cleared runtime state	Pre-restart diagnostics; recovery does not identify the cause

High CPU load can increase queues and memory temporarily. It can also expose timeouts, retries, or slow consumers. That is not automatically a leak. A leak requires retained memory that continues to grow under repeatable conditions and does not return to a stable baseline after the workload subsides.

Read the PLC communications core first

Take the core reading while the fault is active. The decisive branch is whether the communications core only spikes or remains pinned at 100%.

1. If it spikes and falls, correlate each spike with polling, browsing, client startup, or subscription changes. Continue to the gateway-memory check.
2. If it remains at 100%, reduce the offered communication load before investigating memory. A saturated service path cannot process new requests predictably, so response times lengthen and upstream queues may expand.
3. If it stays below saturation while gateway memory rises, move directly to process-memory and heap analysis. The PLC core is not the immediate bottleneck.

You can collect controller load through supported diagnostic CIP messages. The PlantPAx library also includes the L_CPU_5x80 AOI, which separates usage by core type. In PlantPAx v4.10.06, that AOI was source protected, so you can use its outputs but cannot inspect or optimize its internal reads. A GSV-based implementation is possible, but collecting and organizing all required values is more involved.

If you use the AOI only for diagnostics, place its results in a dedicated UDT. Do not increase diagnostic polling while troubleshooting a communications bottleneck; that adds load to the path you are measuring.

Compare one driver path at a time

The demo comparison produced different PLC behavior: FactoryTalk Linx Gateway OPC caused orange communications-core spikes, while the Ignition OPC Allen-Bradley driver drove that core to 100% under the simulated maximum load. That proves the driver paths imposed different controller workloads in that test. It does not prove which gateway component retained memory.

Different drivers can group reads, discover tags, maintain subscriptions, and schedule requests differently. Tag organization also affects how efficiently a driver can combine requests. A workload that is acceptable through one OPC path can saturate the controller through another even when both expose the same application tags.

1. Use the same controller program and diagnostic method for both tests.
2. Hold the requested tag set, update rates, client count, and test duration constant.
3. Start each run from a comparable gateway and controller state.
4. Record communications-core load and gateway memory on the same timeline.
5. Change only the OPC driver path, then repeat the run.

Do not compare an active production workload with a differently configured demo workload. Also avoid changing tag rates, driver path, and PLC code in one run; that makes the result unusable for root-cause isolation.

Prove or reject the memory leak

Next, test whether memory is retained after the communication demand is removed. Watch the gateway process, not the PLC CPU percentage alone.

1. Capture the idle memory baseline before applying load.
2. Apply the same maximum-load test and log both memory and communications-core utilization.
3. Return the tag demand to the original idle condition without restarting the gateway.
4. Wait for active requests, retries, and queued work to drain.
5. Repeat the same load-and-idle cycle. Compare the idle baseline after each cycle.

If memory reaches a plateau appropriate to the active workload and returns near a repeatable idle baseline, you are seeing workload-related allocation or caching. If the idle baseline climbs after each identical cycle, capture heap dumps or the platform’s equivalent memory diagnostics before restarting. Official support can compare retained object types and identify the owning module.

A weekly restart is a containment action. It also erases the runtime state needed to diagnose retention. Schedule diagnostic capture just before the usual failure window, while the abnormal memory level and communication workload are both present.

Reduce the request demand

If the resolving branch is communications-core saturation, lower the work sent to the controller. Start with the largest and fastest tag groups.

1. Inventory every requested PLC tag and its update rate.
2. Remove unused subscriptions and duplicate reads from multiple clients.
3. Slow updates for values that do not require the fastest scan class.
4. Group related application data in controller structures where the chosen driver can read it efficiently.
5. Stagger client startup, browsing, and bulk subscription creation so they do not arrive as one burst.
6. Reapply load in increments while watching the communications core.

Do not begin by rewriting the protected L_CPU_5x80 AOI or replacing unrelated gateway modules. Those changes waste time unless measurements show that diagnostic collection or another module materially contributes to the load. The first useful fix is the one that reduces controller requests while preserving required update performance.

Verify the resolving branch

Run the same test that previously drove the communications core to 100%. Verification requires more than seeing a lower peak.

1. Confirm the core no longer remains saturated during steady load.
2. Confirm required tags update at their configured rates without increasing bad quality, timeouts, or stale values.
3. Remove the load and verify that gateway memory settles to a repeatable baseline.
4. Repeat the cycle long enough to cover the operating pattern that previously led to the weekly restart.
5. Record the final tag set, update rates, driver path, controller load, and memory baseline as the acceptance reference.

If core load improves but memory still ratchets upward, the saturation fix is valid and a second memory-retention fault remains. Capture diagnostics before any restart and follow that second branch independently.

FAQ