# Allen Bradley Driver Overload

**URL:** <https://forum.inductiveautomation.com/t/allen-bradley-driver-overload/113702>\
**Category:** General Discussion\
**Created:** [February 2, 2026, 7:44pm UTC](https://forum.inductiveautomation.com/t/allen-bradley-driver-overload/113702 "2026-02-02T19:44:45Z")\
**Posts on this page:** 11\
**Page:** 1

<div class="post-metadata">

**Author:** ![felipemvcab](https://avatars.discourse-cdn.com/v4/letter/f/53a042/32.png) [@felipemvcab](https://forum.inductiveautomation.com/u/felipemvcab)\
**Post date:** [February 2, 2026, 7:44pm UTC](https://forum.inductiveautomation.com/t/allen-bradley-driver-overload/113702/1 "2026-02-02T19:44:45Z")

</div>

Hi,

Question, can an overload Allen Bradley driver cause gateway memory leak?

We been restarting the gateways once a week to deal with the side effect of memory leak. We believe the issues is coming from an overloaded allen bradley driver which is causing the PLC comms core to Max out.

With that said, I conducted the following test in a demo environment(Not in Production):

I am using Factory talk linx gateway OPC instead of the ignition OPC allen bradley driver.

When I simulate the max load on the ftlinx gateway i get the following results:

The comms core percetage is the orange spikes you see between the red and green.

 ![image](https://us1.discourse-cdn.com/inductiveautomation/original/3X/f/a/fa22d39d753b95debc45ee8b45804b3e7da14e2b.jpeg)

I did the same test using the ignition opc server(allen bradley driver) and the data looks very different for the PLC comms core. The PLC comms core hits 100%

 ![image](https://us1.discourse-cdn.com/inductiveautomation/original/3X/2/e/2ee9c8f8d034e9b6eec6e02020591b9f0e701682.jpeg)

Could this be the issue the memory leak?

---

<div class="post-metadata">

**Author:** ![Kevin.Herron](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/kevin.herron/32/7259_2.png) [@Kevin.Herron](https://forum.inductiveautomation.com/u/Kevin.Herron)\
**Post date:** [February 2, 2026, 7:48pm UTC](https://forum.inductiveautomation.com/t/allen-bradley-driver-overload/113702/2 "2026-02-02T19:48:37Z")

</div>

Well... I doubt it, since you'd be the first of many using the Logix driver to experience this.

Also - what memory leak? Work with support, they can help you with capturing and analyzing heap dumps to see if there's a leak and what might be leaking.

---

<div class="post-metadata">

**Author:** ![felipemvcab](https://avatars.discourse-cdn.com/v4/letter/f/53a042/32.png) [@felipemvcab](https://forum.inductiveautomation.com/u/felipemvcab)\
**Post date:** [February 2, 2026, 8:16pm UTC](https://forum.inductiveautomation.com/t/allen-bradley-driver-overload/113702/3 "2026-02-02T20:16:14Z")

</div>

Thanks Ill reach out to support.

However, I have seen before how using the ftlinx gateway drops the comms core from an allen bradley PLC, specially when not following best practices on how to prepare your plc tags.

---

<div class="post-metadata">

**Author:** ![Kevin.Herron](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/kevin.herron/32/7259_2.png) [@Kevin.Herron](https://forum.inductiveautomation.com/u/Kevin.Herron)\
**Post date:** [February 2, 2026, 8:21pm UTC](https://forum.inductiveautomation.com/t/allen-bradley-driver-overload/113702/4 "2026-02-02T20:21:19Z")

</div>

That's not surprising. They use proprietary and undocumented communication methods that our driver does not.

---

<div class="post-metadata">

**Author:** ![michael.flagler](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/michael.flagler/32/26272_2.png) [@michael.flagler](https://forum.inductiveautomation.com/u/michael.flagler)\
**Post date:** [February 3, 2026, 12:29pm UTC](https://forum.inductiveautomation.com/t/allen-bradley-driver-overload/113702/5 "2026-02-03T12:29:10Z")

</div>

Have you tried the driver @pturmel developed to see if there's any improvement with his driver? It's a fraction of the cost of FTLinx.

Also I'm curious how your pulling the CPU core loading from the PLC. I've tried figuring out how to do it with like a GSV but didn't find any way to.

---

<div class="post-metadata">

**Author:** ![felipemvcab](https://avatars.discourse-cdn.com/v4/letter/f/53a042/32.png) [@felipemvcab](https://forum.inductiveautomation.com/u/felipemvcab)\
**Post date:** [February 3, 2026, 12:45pm UTC](https://forum.inductiveautomation.com/t/allen-bradley-driver-overload/113702/6 "2026-02-03T12:45:22Z")

</div>

I have not tried his driver. Might be worth trying. Thanks.

If you want to get in tags all the data from your cpu, use this instruction fromt the plant PAX library _ **L\_CPU\_5x80.** _

Doing it with the GSV is possible, but a bit painful. THis AOI has all you need and separates the usage per core type. Just import the rung file and it works like magic.

---

<div class="post-metadata">

**Author:** ![michael.flagler](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/michael.flagler/32/26272_2.png) [@michael.flagler](https://forum.inductiveautomation.com/u/michael.flagler)\
**Post date:** [February 3, 2026, 1:11pm UTC](https://forum.inductiveautomation.com/t/allen-bradley-driver-overload/113702/7 "2026-02-03T13:11:23Z")

</div>

I might see if I can pull out the relevant code into my own AOI if it's overly bloated like the rest of the PlantPAx AOIs. I avoid PlantPAx like the plague if I can.

---

<div class="post-metadata">

**Author:** ![pturmel](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/pturmel/32/3295_2.png) [@pturmel](https://forum.inductiveautomation.com/u/pturmel)\
**Post date:** [February 3, 2026, 2:32pm UTC](https://forum.inductiveautomation.com/t/allen-bradley-driver-overload/113702/8 "2026-02-03T14:32:59Z")

</div>

> [@felipemvcab](#):
>
> plant PAX library

If you are using PlantPax 5, you are utterly screwed. If you are using earlier PlantPax, and have the source code, you can mitigate the problem if you are using my driver. PlantPax of any version utterly screws the IA native driver.

---

<div class="post-metadata">

**Author:** ![michael.flagler](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/michael.flagler/32/26272_2.png) [@michael.flagler](https://forum.inductiveautomation.com/u/michael.flagler)\
**Post date:** [February 3, 2026, 6:50pm UTC](https://forum.inductiveautomation.com/t/allen-bradley-driver-overload/113702/9 "2026-02-03T18:50:00Z")

</div>

Just downloaded the PlantPAx v4.10.06 to try to pull out what code they're using in the L\_CPU\_5x80 AOI and it's source protected, so nothing can make it more efficient and can't even see how they're reading it.

I did find in the manual for the processors some diagnostic CIP messages I can use to pull a lot of information, so will parse through it to see what is handy and what's not.

---

<div class="post-metadata">

**Author:** ![felipemvcab](https://avatars.discourse-cdn.com/v4/letter/f/53a042/32.png) [@felipemvcab](https://forum.inductiveautomation.com/u/felipemvcab)\
**Post date:** [February 3, 2026, 8:01pm UTC](https://forum.inductiveautomation.com/t/allen-bradley-driver-overload/113702/10 "2026-02-03T20:01:35Z")

</div>

Only using that one AOI to get the CPU. Hopefully just using one is not that big of a deal. Good to know, thanks.

---

<div class="post-metadata">

**Author:** ![pturmel](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/pturmel/32/3295_2.png) [@pturmel](https://forum.inductiveautomation.com/u/pturmel)\
**Post date:** [February 3, 2026, 9:22pm UTC](https://forum.inductiveautomation.com/t/allen-bradley-driver-overload/113702/11 "2026-02-03T21:22:09Z")

</div>

> [@felipemvcab](#):
>
> not that big of a deal

Consider making a UDT just to hold the results, and there won't be any negative impact at all.
