Rockwell Alias tag performance

Ignition
1

I’m currently working on a system that I don’t have any issues with, bit I’m just trying to make sure that I don’t in the future.

All of our aois have two tags. A udt for the him and an internal PLC tag. In ignition we address the hmi tag directly.

Now I know that we can improve performance by moving to arrays of hmi tags and addressing those in ignition. My question is, do I get the same performance increase by creating aliases of the array members and addressing those directly? Or do we need to address the individual member of the array to get the performance increase?

2

Optimization of access to Logix data depends on data being laid out consecutively (or nearly so) in single top-level tags. So a single read-tags-fragmented service can grab the consecutive bytes. Nothing else matters. Aliases are more likely to hurt rather than help, IMNSHO.

3

10-4. I kinda figured that. I was just thinking about a way to keep friendly names everywhere without having to address into arrays.

4

Then use UDTs to name the elements instead of using arrays. It also has the advantage that the individual elements can be different types.

5

I guess I didn’t explain.

We use udts… Id like to make arrays of those udts and then alias an array member in the PLC to the customer tag name. Ie CV101 would be an alias of valves[2]. Then on the ignition side my question is would it be better to address the CV101 UDT tag, or the member in the UDT array, say valves[2].

6

I guess I didn’t explain.

Wrap another UDT around the UDT that would have been the array. So you have instances of that UDT inside another, with the various names for each. Member names instead of alias names. And definitely do not point Ignition at aliases of the array elements–that would prevent Ignition from grabbing multiples together.

So your OPC items would end up like [someDevice]HMI.someName.someHMItag. The “HMI” tag is a structure of structures, instead of an array of structures. So you get names instead of subscripts, but it is nicely optimizable. No compromise needed.

1 Like
7

Ahhh gotcha.

I’ll take a look. Biggest issue with that would be adding things later on the fly. This particular system is a glass furnace and can’t go down except in extreme occasions

Btw one of these days I’ll get down to the south side and get you a beer.

8

You can’t change arrays on the run, either, so no loss there. Beer is good. (:

9

Yeah but I can make a big array. :grin: Especially in an L84.

1 Like
10

Ah, yes. Well, arrays might be better, then. Ignition can have its side carry the friendly names. Tag comments in the arrays to keep the PLC programmer happy.

No aliases into the array, though. Aliases look like single tags, so can only be optimized by themselves.

2 Likes
11

Thanks @pturmel and @bschroeder. I've been watching this as it will be relevant on an upcoming project where we have to use Allen-Bradley.

While there are other things I've come to prefer about Beckhoff, this is the single biggest pain point going back to Allen-Bradley. If Allen-Bradley enabled changing AOIs, UDTs, and arrays on the fly like Beckhoff, I wouldn't miss Beckhoff so badly.

12

I understand. AB does allow creating new UDTs & AOIs & tags on the fly, and deleting unused. So it can be done, with a careful series of edits. I've been in situations where it was necessary. But, ugly.

3 Likes
13

That’s what I thought. I’m going to do some test and see just how much of an improvement I’ll get.

Thanks for the help!

1 Like