Cannot read some tags inside Rockwell AOI

Yes, thanks Phil.

Good thing is making these changes shouldn’t take very long.

1 Like

Changing things over was easier than I though, even needing to write a little code for default values. But, losing the ability to change values from the AOI faceplate in Studio is a bummer. Not a huge deal to drill into the InOut tag, but it was nice seeing specific tags right there.

Curious what everyone does for naming when using AOI and UDT together. For example, before on a motor AOI I would name it M1000. Now I need an instance tag for the AOI and one for InOut UDT. In the past and currently I’m naming the InOut M1000 and the AOI M1000_AOI. Thoughts??

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.

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?

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.

1 Like

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?

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.

1 Like

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 data transfer.

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


Will do. Thanks for the great help.

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.>

1 Like

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.

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)?


1 Like