# Cannot read some tags inside Rockwell AOI

**URL:** <https://forum.inductiveautomation.com/t/cannot-read-some-tags-inside-rockwell-aoi/38393>\
**Category:** Ignition Early Access\
**Created:** [September 4, 2020, 11:09am UTC](https://forum.inductiveautomation.com/t/cannot-read-some-tags-inside-rockwell-aoi/38393 "2020-09-04T11:09:49Z")\
**Posts on this page:** 20\
**Page:** 2

<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:** [December 5, 2020, 7:50pm UTC](https://forum.inductiveautomation.com/t/cannot-read-some-tags-inside-rockwell-aoi/38393/24 "2020-12-05T19:50:10Z")

</div>

Well, I usually use _three_ UDTs for my AOIs. The AOI gets the base name (`xyz`, perhaps) for its functionality. The others:

- `xyz_fbk` This is the collection of values that present the process variables, indicators, trigger integers, etc. Subscribed in Ignition with a fast pace, or mapped through my E/IP module from a PLC output buffer.

- `xyz_cmd` This is the collection of setpoints and command bits and handshake short integers. Subscribed as needed (slow/leased is fine), but usually mapped to a PLC input buffer with E/IP. If so, can contain momentary buttons driven from my custom component.

- `xyz_cfg` This is the collection of configuration items for the AOI, like process/alarm limits, tuning constants, operating modes, etc. Subscribed slow in a leased scan class, so the traffic is only present when the user has the corresponding configuration UI open.

Note that Ignition never writes into the `xyz_fbk` data, and the PLC never writes to `xyz_cmd`. This is crucial to avoid race conditions. And it fits well with E/IP I/O configurations.

---

<div class="post-metadata">

**Author:** ![jlandwerlen](https://avatars.discourse-cdn.com/v4/letter/j/bc8723/32.png) [@jlandwerlen](https://forum.inductiveautomation.com/u/jlandwerlen)\
**Post date:** [December 5, 2020, 8:20pm UTC](https://forum.inductiveautomation.com/t/cannot-read-some-tags-inside-rockwell-aoi/38393/25 "2020-12-05T20:20:47Z")

</div>

If someone were to have those 3 UDTs combined into one, but still use the scan classes you defined, what would be the main difference?

Also, do you sort your UDTs in alphabetical order, or in data type order to keep size down? Can I assume either way will have no impact on Ignition?

---

<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:** [December 5, 2020, 8:52pm UTC](https://forum.inductiveautomation.com/t/cannot-read-some-tags-inside-rockwell-aoi/38393/26 "2020-12-05T20:52:30Z")

</div>

There will be a big impact.

Aside from the problem with hidden elements, the other major win for optimization is to combine multiple UDTs into as few top-level tags as practical. Either arrays or as nested UDTs (I tend to do the latter, in I/O buffer chunks). This is because subscription optimization only works within a tag, not across multiple tags. If you mix my three into a single UDT, the fast subscription for the `_fbk` pieces within a larger tag will have big gaps and won’t optimize. The other parts will either go along for the ride (and be discarded every cycle) or will split the request into multiples. Similarly, when copying to/from I/O buffers, you’d need a CPS instruction for each instead of a single CPS for the whole buffer.

And yes, I carefully place elements in a PLC UDT to minimize total size by minimizing gaps. Not necessarily zealously, as that can be a pain on the maintenance side, but I at least put SINTs followed by booleans as a unit. I avoid the use of 64-bit types in newer firmware, as that makes even bigger internal gaps, and cause any UDT containing them to be 64-bit aligned, too.

If this level of complexity makes your head spin, keep in mind that your UDT _in Ignition_ can ignore the existence of the three sub-UDTs on the PLC side, and present them for UI development as if they were merged.

---

<div class="post-metadata">

**Author:** ![jlandwerlen](https://avatars.discourse-cdn.com/v4/letter/j/bc8723/32.png) [@jlandwerlen](https://forum.inductiveautomation.com/u/jlandwerlen)\
**Post date:** [December 6, 2020, 12:12am UTC](https://forum.inductiveautomation.com/t/cannot-read-some-tags-inside-rockwell-aoi/38393/27 "2020-12-06T00:12:25Z")

</div>

Using your example xyz\_fbk, if there were 10 tags, and I needed 2 of those to run at a fast pace vs default/normal, would you break them out into another UDT? Basically, all tags in a UDT should belong to the same scan class?

---

<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:** [December 6, 2020, 12:56am UTC](https://forum.inductiveautomation.com/t/cannot-read-some-tags-inside-rockwell-aoi/38393/28 "2020-12-06T00:56:40Z")

</div>

Yes. Or move it to the `xyz_cfg` UDT. The best optimization is for the fast subscribed items to boil down to a request for a single complex tag. Which yields a reply full of packed data. Since the driver browses all of the data types in the PLC, it knows how to unpack it.

---

<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:** [December 6, 2020, 1:06am UTC](https://forum.inductiveautomation.com/t/cannot-read-some-tags-inside-rockwell-aoi/38393/29 "2020-12-06T01:06:03Z")

</div>

Btw, if you struggle with allocating tags to fast/slow scan classes because there’s just too many to go fast, you might want to consider my E/IP module. I/O buffers simply cannot be beat for [snappy](http://forum.inductiveautomation.com/t/snappy-user-interfaces-with-the-ethernet-ip-module/12617) data transfer.

It can do thousands of tags at 100ms updates or faster.

---

<div class="post-metadata">

**Author:** ![jlandwerlen](https://avatars.discourse-cdn.com/v4/letter/j/bc8723/32.png) [@jlandwerlen](https://forum.inductiveautomation.com/u/jlandwerlen)\
**Post date:** [December 6, 2020, 1:40am UTC](https://forum.inductiveautomation.com/t/cannot-read-some-tags-inside-rockwell-aoi/38393/30 "2020-12-06T01:40:19Z")

</div>

Will do. Thanks for the great help.

---

<div class="post-metadata">

**Author:** ![Priceline](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/priceline/32/5261_2.png) [@Priceline](https://forum.inductiveautomation.com/u/Priceline)\
**Post date:** [May 24, 2022, 1:13am UTC](https://forum.inductiveautomation.com/t/cannot-read-some-tags-inside-rockwell-aoi/38393/31 "2022-05-24T01:13:10Z")

</div>

Thanks for these ideas; I really like the 3 UDT organizational structure and the improvements to overall tag scans.  
Also, for clarity, do you recommend FOR or AGAINST nesting these 3 UDT’s into a higher level UDT (ie: simply “xyz”… so we’d only submit the master UDT to the AOI, and inside it would have the 3 sub UDT’s for example “xyz.Cmd.StartPB” and “xyz.Fbk.StartLT” and “xyz.Cfg.TemperatureSP” )

I’m not clear about “E/IP modules”, “PLC output buffer” , “PLC input buffer”, “I/O buffer chunks”, or “E/IP I/O configurations” as eluded to in your text(s). Can you clarify the relationship between your 3 UDT’s and the terms listed above?  
\<EDIT 5/23/22; I found your website and the E/IP Module. VERY COOL! No need to reply about this.\>

---

<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:** [May 24, 2022, 2:12am UTC](https://forum.inductiveautomation.com/t/cannot-read-some-tags-inside-rockwell-aoi/38393/32 "2022-05-24T02:12:18Z")

</div>

> [@Priceline](#):
>
> do you recommend FOR or AGAINST nesting these 3 UDT’s into a higher level UDT

Against. These should be nested in arrays or UDTs of the same category (fbk, cmd, cfg), so that polling at the same pace happens with fewer outermost tags. That is the key to optimization.

---

<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:** [June 10, 2022, 1:49pm UTC](https://forum.inductiveautomation.com/t/cannot-read-some-tags-inside-rockwell-aoi/38393/33 "2022-06-10T13:49:06Z")

</div>

Just want to make sure that I’ve fully wrapped my head around this.

Say I have multiple devices in a system all set up with UDT’s. Then having a single `system_fbk` UDT where each device is nested beneath that UDT such that device1\_fbk would be called as `system_fbk.device1_fbk` and device2\_fbk would be called as `system_fbk.device2_fbk`. This would be acceptable?

In Ignition, I can Ignore the system\_fbk UDT and simply map each tag as needed and the driver will optimize the read to just the one `system_fbk` UDT tag, correct (assuming there are no forbidden elements defined)?

---

<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:** [June 10, 2022, 2:21pm UTC](https://forum.inductiveautomation.com/t/cannot-read-some-tags-inside-rockwell-aoi/38393/34 "2022-06-10T14:21:48Z")

</div>

> [@lrose](#):
>
> correct

Correct.

---

<div class="post-metadata">

**Author:** ![david.l](https://avatars.discourse-cdn.com/v4/letter/d/3d9bf3/32.png) [@david.l](https://forum.inductiveautomation.com/u/david.l)\
**Post date:** [September 30, 2022, 12:48am UTC](https://forum.inductiveautomation.com/t/cannot-read-some-tags-inside-rockwell-aoi/38393/35 "2022-09-30T00:48:44Z")

</div>

I know AOI's have been discussed frequently and I really didn't want to post this but there were times where it was unclear if people meant Ignition vs Rockwell UDT and whether AOI's were 100% not going to work OR if they worked under some scenarios. I also wanted to clarify the act of copying the data over which would be labor intensive from one tag to another tag.

I have an Ignition UDT that directly accesses individual elements of an AOI (let's use analog input P\_AIn from PlantPax).

It is my understanding that this is not acceptable and is not optimized even though I directly access the tags.

Is that correct?

Does this affect all AOIs or only certain AOI's?  
For example, if I created my own AOI, could I avoid the behavior?

Here are some screenshots.  
**Ignition UDT Example**  
 ![image](https://us1.discourse-cdn.com/inductiveautomation/original/3X/a/6/a68d21d0adfe0d62d914aef4b77a37583bdbeb63.png)

**PlantPax P\_AIn**

 ![image](https://us1.discourse-cdn.com/inductiveautomation/original/3X/5/c/5cc35d7ab508d643d4124930fdf705f904da4aee.jpeg)

**PLC Tag using P\_AIn**  
 ![image](https://us1.discourse-cdn.com/inductiveautomation/original/3X/9/b/9b6f1a2366511a11588c7c2cfe08e5bdb7834bc0.png)

**Resolution**  
**Option 1**  
It appears that one way of resolving this is by creating a custom Logix PLC UDT under Data Types...User-Defined

 ![image](https://us1.discourse-cdn.com/inductiveautomation/original/3X/3/2/32fb17adae5e166ba75731d4745d2335d6fea4ef.png)

After the UDT is created, I then need to COPY/MOV the files from the tag (P\_AIn) to a new tag (CUSTOM\_P\_AIN\_HMI) one at a time (Maybe there is an easier way to do this)

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

**Option 2**  
Create a new Logix PLC tag and alias the AOI value of interest.

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

**Conclusion**  
This seems time consuming and requires a lot of manual labor work for an AOI that was supposed to make things easier.  
If I have 100 devices that require 30 tags a piece, someone will need to manually enter all 300 tags at some point (even if a UDT is used).

Is there something else I'm missing that would make this easier?

---

<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:** [September 30, 2022, 1:07am UTC](https://forum.inductiveautomation.com/t/cannot-read-some-tags-inside-rockwell-aoi/38393/36 "2022-09-30T01:07:16Z")

</div>

It is access to AOI datatypes in the PLC that cannot be optimized. Doesn't matter if the tags in Ignition are Ignition UDT members or stand-alone tags. This entire topic is about UDTs in the PLC versus AOIs in the PLC.

Ignition's driver cannot bulk read the AOI like it would other UDTs (in the PLC). So every element that is requested (in an AOI, _any_ AOI) will be requested individually. They do **work** , just much slower. As others have benchmarked, this is about a 10:1 reduction in throughput.

---

<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:** [September 30, 2022, 1:12am UTC](https://forum.inductiveautomation.com/t/cannot-read-some-tags-inside-rockwell-aoi/38393/37 "2022-09-30T01:12:32Z")

</div>

> [@pturmel](#):
>
> They do **work** , just much slower

The thing to take home is that, if you're reading a large\* number of AOI tags from your PLC, you may have to reduce your scan rate to 2, 3, 5+ seconds which may or may not be acceptable for your application. Certainly for the applications I work on, operators expect 1s scan rates if not faster.

\*large means different things for different processors. For an L83, this is something like ~8000+, for an L320ER, it's more like 4-5000+, although don't quote me on these as I haven't specifically tested the limits!

---

<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:** [September 30, 2022, 1:13am UTC](https://forum.inductiveautomation.com/t/cannot-read-some-tags-inside-rockwell-aoi/38393/38 "2022-09-30T01:13:46Z")

</div>

I intend to fix this, BTW. Stay tuned...

---

<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:** [September 30, 2022, 1:21am UTC](https://forum.inductiveautomation.com/t/cannot-read-some-tags-inside-rockwell-aoi/38393/39 "2022-09-30T01:21:04Z")

</div>

> [@pturmel](#):
>
> fix this

when you say "this", what exactly do you mean? Fix the inefficient reading of AOI 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:** [September 30, 2022, 1:21am UTC](https://forum.inductiveautomation.com/t/cannot-read-some-tags-inside-rockwell-aoi/38393/40 "2022-09-30T01:21:59Z")

</div>

His driver is going to get support for reading AOIs in an optimized manner because he’s done the work to reverse engineer them.

---

<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:** [September 30, 2022, 1:23am UTC](https://forum.inductiveautomation.com/t/cannot-read-some-tags-inside-rockwell-aoi/38393/41 "2022-09-30T01:23:42Z")

</div>

ooooOOOooo! How different will addressing be compared to how we address AOI tags now?

> [@Kevin.Herron](#):
>
> reverse engineer

Your favourite thing 😄

---

<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:** [September 30, 2022, 1:24am UTC](https://forum.inductiveautomation.com/t/cannot-read-some-tags-inside-rockwell-aoi/38393/42 "2022-09-30T01:24:48Z")

</div>

> [@nminchin](#):
>
> How different will addressing be

No different. Superset of the native Logix driver.

---

<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:** [September 30, 2022, 1:26am UTC](https://forum.inductiveautomation.com/t/cannot-read-some-tags-inside-rockwell-aoi/38393/43 "2022-09-30T01:26:15Z")

</div>

That would _definitely_ help us at the moment, as we're actively looking to convert a massive PLC to using UDTs. What is the estimated timeframe if you have one? Actually, 5 large PLCs, and the PLC programmer would love _not_ to use UDTs as it reduces visibility of AOI values

[Previous page](https://forum.inductiveautomation.com/t/cannot-read-some-tags-inside-rockwell-aoi/38393.md?page=1)

[Next page](https://forum.inductiveautomation.com/t/cannot-read-some-tags-inside-rockwell-aoi/38393.md?page=3)
