Cannot read some tags inside Rockwell AOI

Thanks for the response Phil.

Yes, I know UDTs don't have default values. I was asking what you do, I'm assuming nothing?

I just came across the topic. We also use AOIs everywhere, and we do have issues with slowness in some PLCs. This seems like something that should definitely be added into the user manual and also perhaps into the gateway as a warning when configuring a “new” Logix device. Those of us who aren’t also software devs doing work with modules, specifically with PLC drivers, and have an in-depth knowledge of AB comms simply won’t know this (such as me).
Do you know the reason rockwell changed from efficient to inefficient AOI comms?

1 Like

Because they suck! :slight_smile:

Edit, on a serious note, I have noticed slowness on their own products, specifically ME, using AOIs.

2 Likes

That's just from the unholy alliance with Microsoft.

Because it was a security hole you could drive a truck through.

4 Likes

I use first scan rungs where applicable. Habit, as older Logix versions didn't have default values either, and I try to create AOIs for the least common denominator.

Just to be crystal clear: I am a big fan of Add-on Instructions. I just work around this particular gotcha by moving "public" data into a separate UDT that is passed to the AOI as an in/out parameter.

3 Likes

I guess that's a pretty good reason :slight_smile:

Thanks to @pturmel recommendations I can confirm that the order of magnitude is correct when moving away from reading AOIs and only reading UDT’s.

What we do is have an AOI that has an In/Out Parameter that is the HMI only UDT. All other tags that are needed in the program outside of the AOI originate from the AOI that way we can differentiate between the two when looking at the code. It has changed the load factor and mean response on logix PLC’s in some respects to a 10th of what they were before. Also being smart with tag groups on the tags. See: CLX performance for information on that.

For default values @jlandwerlen, we have an init bit in the AOI that is default low and when that init bit is high that we set default values in the HMI UDT within the AOI and then set that init bit low.

3 Likes

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.

2 Likes

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.

2 Likes

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.