# Ignition & Rockwell PlantPAx v5.0

**URL:** <https://forum.inductiveautomation.com/t/ignition-rockwell-plantpax-v5-0/94206>\
**Category:** Ignition\
**Tags:** rockwell\
**Created:** [August 6, 2024, 2:22am UTC](https://forum.inductiveautomation.com/t/ignition-rockwell-plantpax-v5-0/94206 "2024-08-06T02:22:27Z")\
**Posts on this page:** 20\
**Page:** 4

<div class="post-metadata">

**Author:** ![bmusson](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/bmusson/32/87530_2.png) [@bmusson](https://forum.inductiveautomation.com/u/bmusson)\
**Post date:** [May 8, 2025, 9:18pm UTC](https://forum.inductiveautomation.com/t/ignition-rockwell-plantpax-v5-0/94206/62 "2025-05-08T21:18:25Z")

</div>

> [@Brian\_Stilson](#):
>
> Is anybody offering an "Ignition-friendly" alternative? Like a suite of Rockwell AOIs/code blocks and Ignition templates that perform a lot of the same functions?

Every good integrator I know does this internally, but I don't know of any publicly available libraries

We've got a large library of AOI/UDTs; some of them directly mirror PlantPAX functions (CmdSrc, Intlk, Perm, etc.) while most are our own creations, but most are paired with Ignition resources.

---

<div class="post-metadata">

**Author:** ![Arnaud\_Declerck](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/arnaud_declerck/32/44872_2.png) [@Arnaud\_Declerck](https://forum.inductiveautomation.com/u/Arnaud_Declerck)\
**Post date:** [May 9, 2025, 5:25am UTC](https://forum.inductiveautomation.com/t/ignition-rockwell-plantpax-v5-0/94206/63 "2025-05-09T05:25:31Z")

</div>

Hi @Brian_Stilson,  
i've a start of a library with plc code and ignition faceplates.  
It's near off be polish like it should but at least some folks use it in project or to start the development of their own library.

> **[Ignition Exchange](https://inductiveautomation.com/exchange/2231/overview)**
>
> Discover, share, and download community made Ignition resources in collaboration with your organization or the Ignition community.

---

<div class="post-metadata">

**Author:** ![Brian\_Stilson](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/brian_stilson/32/73410_2.png) [@Brian\_Stilson](https://forum.inductiveautomation.com/u/Brian_Stilson)\
**Post date:** [May 9, 2025, 11:58am UTC](https://forum.inductiveautomation.com/t/ignition-rockwell-plantpax-v5-0/94206/64 "2025-05-09T11:58:32Z")

</div>

It would be nice. As much as we like to pile on FactoryTalk View and Panelviews, I will say that there is very little you can do to screw them up. More traditional HMIs like PVPlus, C-More, Weintek, etc. pretty much operate in a walled garden of sorts whereas anything the software _lets_ you do, it's okay to do it, and you almost never run into performance issues. If you want to accomplish something, there is one well-documented, prescribed way to do it.

The other side of that coin is that the manufacturer had to think of that feature and purposely give you the ability to do it. Ignition (and really, SCADA in general because these issues exist in Aveva, iFix, etc.) is more wide open, and being so script-reliant to expand functionality means there is no possible way IA engineers can imagine every single scenario their software can be used. They're also using a lot of industry standard functionality like python/jython, css, etc. that they don't have 100% control over.

So I can understand why every single possible programming scenario isn't covered in the manual. It can't be. It's the same reason Rockwell doesn't tell you _how_ to program absolutely everything. For every "here's how to do _x_," there's 1,000 other scenarios that will crop up they didn't cover. Learning how to program is easy. Learning how to program _well_ takes time, and making lots of mistakes.

---

<div class="post-metadata">

**Author:** ![bwhite](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/bwhite/32/7112_2.png) [@bwhite](https://forum.inductiveautomation.com/u/bwhite)\
**Post date:** [May 22, 2025, 1:55pm UTC](https://forum.inductiveautomation.com/t/ignition-rockwell-plantpax-v5-0/94206/65 "2025-05-22T13:55:52Z")

</div>

I have an existing Rockwell PLC program that uses PlantPAx 4.0. I need Ignition to connect to a few tags in each AOI. Would it be best to move the data from the AOI in Logix to either an AOI that I create or individual tags in order for Ignition to efficiently communicate to the PLC?

---

<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:** [May 22, 2025, 5:46pm UTC](https://forum.inductiveautomation.com/t/ignition-rockwell-plantpax-v5-0/94206/66 "2025-05-22T17:46:51Z")

</div>

> [@bwhite](#):
>
> to either an AOI that I create or individual tags in order for Ignition to efficiently communicate to the PLC?

not an AOI you create, but a UDT.

---

<div class="post-metadata">

**Author:** ![nminchin](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/nminchin/32/6911_2.png) [@nminchin](https://forum.inductiveautomation.com/u/nminchin)\
**Post date:** [May 23, 2025, 3:40am UTC](https://forum.inductiveautomation.com/t/ignition-rockwell-plantpax-v5-0/94206/67 "2025-05-23T03:40:09Z")

</div>

> [@bwhite](#):
>
> either an AOI that I create

I think it's important to get terminology correct. AOI _ **Parameters** _ can't be grouped into a single read due to the two EnableIn and EnableOut _parameters_ which _cannot_ be set to at least readOnly external access. However, AOI _ **Local tags** _ are perfectly fine to read and _can_ be read efficiently.

UDT type _ **members** _ similarly can also be read efficiently.

I found no significant difference between reading UDT members, members of aliased UDTs, members of UDTs within arrays, or nested UDTs' members.

I noticed a _very slight_ degredation in read speed of AOI Local tags, whether they were UDT types or basic types, but I would consider it negligible.

Reading AOI Parameters have _ **significant** _ impacts to PLC response time. On an L82 it was approximately 10x the response time compared to the other tests.

Note: all of these results were performed where _every_ tag/member/parameter in the structures read was set to at least readOnly external access. Setting just one to None destroyed performance to approximately AOI Parameter read levels, regardless if the item is read by SCADA or not

> [@Ignition & Logix Best Practice Tips for better communications](https://forum.inductiveautomation.com/t/ignition-logix-best-practice-tips-for-better-communications/60386/52):
>
> I always forget about this... Holy moly Edit: Updated results with tests using different CIP Connection sizes: Test Ext Access CIP Connection Size Tag Count Sample Rate (ms) Actual Sample Rate (ms) Request Count Overload UDTs All Read/Write 500 6787 10 45.48 14 355% UDTs All Read/Write 4000 6787 10 10.06 2 1% AOI Local Tags (UDT) All Read/Write 500 6787 10 50.86 14 409% AOI Local Tags (UDT) All Read/Write 4000 6787 10 10.08 2 1% AOI Parameter Tags All Rea…

> [@Ignition & Logix Best Practice Tips for better communications](https://forum.inductiveautomation.com/t/ignition-logix-best-practice-tips-for-better-communications/60386/42):
>
> I recently decided it was time to actually test the theories with scan rates for different structures in the PLC, and found the results below. What I found (obviously) backed Phil's recommendations to only read UDT tags and to ensure that all members of them are set to at least read access. However what I found was negligible difference in response rate at 100ms when reading the UDT tags from within different structures (e.g. individual UDT instances at the root/controller level, addressing UDT…

---

<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:** [June 6, 2025, 3:07am UTC](https://forum.inductiveautomation.com/t/ignition-rockwell-plantpax-v5-0/94206/68 "2025-06-06T03:07:02Z")

</div>

Was doing some digging on PlantPAx 5.0 and this is in the documentation for recommended tag limitations for HMI communications (what they call their data server):

 ![image](https://us1.discourse-cdn.com/inductiveautomation/original/3X/7/c/7c2f6c96516f93fd35bfe0236ec572b242983722.png)

The L8xP were on a different chart, but had the same limitation as the standard L8x processors.  
So while the L8x series more than doubles the tag count you can read, in PlantPAx, 50k tags doesn't get you very far.

---

<div class="post-metadata">

**Author:** ![nminchin](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/nminchin/32/6911_2.png) [@nminchin](https://forum.inductiveautomation.com/u/nminchin)\
**Post date:** [June 6, 2025, 8:19am UTC](https://forum.inductiveautomation.com/t/ignition-rockwell-plantpax-v5-0/94206/69 "2025-06-06T08:19:47Z")

</div>

> [@michael.flagler](#):
>
> in PlantPAx, 50k tags doesn't get you very far.

That's only a handful of devices, right? 😁

---

<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:** [June 6, 2025, 11:50am UTC](https://forum.inductiveautomation.com/t/ignition-rockwell-plantpax-v5-0/94206/70 "2025-06-06T11:50:03Z")

</div>

I guess it does say 50k per second, but I've seen in person other integrators just bring all the tags in for each datatype at the same 1000ms direct rate, then see it perform badly so they bumped it up to 100ms to try to make it faster. When I got involved, I immediately just set their only tag group to a leased 30000ms and 1000ms leased rate and responsiveness of the system went from 7-8 sec update rate to about 1.5 sec update rate. Their system still isn't fully optimized but with the amount of time I was given that one change helped them considerably.

I think a motor block has over 150 parameters and who knows how many local tags.

---

<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:** [January 9, 2026, 6:18pm UTC](https://forum.inductiveautomation.com/t/ignition-rockwell-plantpax-v5-0/94206/71 "2026-01-09T18:18:27Z")

</div>

Not sure if others have noticed this yet, but with the new L9x processors, the PIDE\_ENHANCED / PIDE instruction is no longer supported/allowed, and you're now required to use the P\_PID/PPID PlantPAx instruction. If you migrate/upgrade a program to use the new processor, the tags come over just fine, but you can't verify/download the program until you convert everything over (and it's not done for you). They really should have left the old PIDE block intact and let programmers decide if/when they want to switch to the PlantPAx version, but they're forcing the conversion now.

---

<div class="post-metadata">

**Author:** ![lrose](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/lrose/32/62724_2.png) [@lrose](https://forum.inductiveautomation.com/u/lrose)\
**Post date:** [January 9, 2026, 6:20pm UTC](https://forum.inductiveautomation.com/t/ignition-rockwell-plantpax-v5-0/94206/72 "2026-01-09T18:20:10Z")

</div>

> [@michael.flagler](#):
>
> but they're forcing the conversion now.

Ughhhh, Looks like I'm staying on L8x's for the forseeable future.

---

<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:** [January 9, 2026, 6:21pm UTC](https://forum.inductiveautomation.com/t/ignition-rockwell-plantpax-v5-0/94206/73 "2026-01-09T18:21:44Z")

</div>

Yeah, I wish I could say the same, but we already have a customer wanting to move to them on their next project so I don't have a choice. ☹

---

<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:** [January 9, 2026, 6:25pm UTC](https://forum.inductiveautomation.com/t/ignition-rockwell-plantpax-v5-0/94206/74 "2026-01-09T18:25:43Z")

</div>

Heh, as I noted to another client today, I don't use any of Rockwell's PID instructions. I have a pair of AOIs that (together) implement the necessary functionality, cleanly.

---

<div class="post-metadata">

**Author:** ![lrose](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/lrose/32/62724_2.png) [@lrose](https://forum.inductiveautomation.com/u/lrose)\
**Post date:** [January 9, 2026, 6:34pm UTC](https://forum.inductiveautomation.com/t/ignition-rockwell-plantpax-v5-0/94206/75 "2026-01-09T18:34:00Z")

</div>

> [@pturmel](#):
>
> I have a pair of AOIs that (together) implement the necessary functionality, cleanly.

I'm going to have to look into doing this. My company doesn't really have a standard set of AOI's similar to the PAX library, and we probably should. Pipe dream at the moment.

---

<div class="post-metadata">

**Author:** ![bmusson](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/bmusson/32/87530_2.png) [@bmusson](https://forum.inductiveautomation.com/u/bmusson)\
**Post date:** [January 10, 2026, 5:48am UTC](https://forum.inductiveautomation.com/t/ignition-rockwell-plantpax-v5-0/94206/76 "2026-01-10T05:48:30Z")

</div>

> [@michael.flagler](#):
>
> left the old PIDE block intact

We were told that this change was licensing related; they were previously licensing some of the code used in the PIDE instruction, and this change was necessary to avoid that.

---

<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:** [January 10, 2026, 5:59am UTC](https://forum.inductiveautomation.com/t/ignition-rockwell-plantpax-v5-0/94206/77 "2026-01-10T05:59:10Z")

</div>

What's odd about that is that the instruction exists in firmware v38 for L8x processors, so it had to be something with cutting it off when moving to the L9x processors so that they wouldn't have it in the first place (probably fewer complaints if they remove something from a new hardware model rather than it just disappearing from existing hardware on a firmware upgrade). Still frustrating.

---

<div class="post-metadata">

**Author:** ![Andres\_Gallardo](https://avatars.discourse-cdn.com/v4/letter/a/a8b319/32.png) [@Andres\_Gallardo](https://forum.inductiveautomation.com/u/Andres_Gallardo)\
**Post date:** [March 30, 2026, 3:13pm UTC](https://forum.inductiveautomation.com/t/ignition-rockwell-plantpax-v5-0/94206/78 "2026-03-30T15:13:58Z")

</div>

Hello all,

I know this is almost a 2-year-old thread, but I wanted to confirm that PlantPAx v5 does work with FactoryTalk Linx Gateway v6.6. It creates an OPC UA server that Ignition can read from.

With this setup, you can read those damn extended tag properties and work from there.

Just be aware that there is not much information available from Rockwell, and the licensing can be very confusing, but after some trial and error, you should be able to get it working.

Regards.

---

<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:** [March 30, 2026, 3:43pm UTC](https://forum.inductiveautomation.com/t/ignition-rockwell-plantpax-v5-0/94206/79 "2026-03-30T15:43:54Z")

</div>

> [@Andres\_Gallardo](#):
>
> read those damn extended tag properties

Yes, but you still cannot go fast. A little faster than my driver, and a lot faster than IA's driver, but the non-readable elements of PlantPax5 screw up even FTLinx.

Using PlantPax5 is unwise.

---

<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:** [March 30, 2026, 9:39pm UTC](https://forum.inductiveautomation.com/t/ignition-rockwell-plantpax-v5-0/94206/81 "2026-03-30T21:39:30Z")

</div>

At one time weren't they using PLC tags to control navigation also for tabs and the like. So if one user was navigating a faceplate and someone else also had it up, theirs would also switch tabs.

---

<div class="post-metadata">

**Author:** ![nminchin](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/nminchin/32/6911_2.png) [@nminchin](https://forum.inductiveautomation.com/u/nminchin)\
**Post date:** [March 31, 2026, 7:42am UTC](https://forum.inductiveautomation.com/t/ignition-rockwell-plantpax-v5-0/94206/82 "2026-03-31T07:42:35Z")

</div>

> [@michael.flagler](#):
>
> At one time weren't they using PLC tags to control navigation also for tabs and the like.

This was usually done on panel view hmis. Yuck

[Previous page](https://forum.inductiveautomation.com/t/ignition-rockwell-plantpax-v5-0/94206.md?page=3)

[Next page](https://forum.inductiveautomation.com/t/ignition-rockwell-plantpax-v5-0/94206.md?page=5)
