Why create Alias tags - RSLogix 5000

I want to Alias a dot members from a user defined to an array of different numbers. Since this can't happen what is more efficient a COP or MOV instruction.

Cop instruction for example COP Array[10].0 to Gen.Run or a MOV Array[10].0 to Gen.Run?

Ideally, one would start a new thread instead of appending to a three year old one...

You could do either if both the Source and Destination are the identical Data Types.

If they are not, MOV will convert the Source Data Type into the Destination Data Type while COP will just 'identically' start copying the Source into the Destination without any conversion.

Mstachura said:

Why do we create Alias tags? For example "PIT_190_I" for an input.

Can't you just use "PIT_190" for the input and logic?

What is the benefits to aliasing? I have read online but i am lacking to find the reason "Why".

Very beginner question here, and would appreciate any feedback on this.

Thanks

Click to expand...

So that it's much easier for you to decode your own program months or years later and of course it makes it easier for others two. But some software (Thinking CX Programmer) and some people make very poor use of this concept and end up looking like the attached snapshot.

Its in German, but I think the point is to comment. We design our tag object name descriptive so it's easy to tell the name of the Tag.

It's Dutch but the criticism I have is obviously not the language but the tag names as they are meaningless to anyone but the one who wrote the program. I had to plug into the machine for a couple of hours and activated every sensor and renamed the tags and changed the rung comments to something meaningful which helped a little but not a lot because it's CX programmer and the tag comments don't appear in full.

I use an alias to tie the hardware schematic into the program.

For example, Local:1:I.Data.0 is the physical tag, the alias is PB101, and the tag name is Start_PB. This way when it comes time to troubleshoot you can look for the physical I/O point, the device that is connected to that point, or the function of the device.

jrexrode said:

One advantage for me is that I can have multiple tag names and descriptions for a given input. We have presses that we exchange sometimes 4 or 5 dies, each die having multiple prox switches and photo eyes. The function of the sensor connected to an input for die 1, usually won't serve the same function as a sensor connected to the same input for die 2. The ability to alias the inputs allows me to give each input for each die a unique tag name as well as a unique description as to its function, all while "re-using" the same inputs.

Click to expand...

I'm just getting into PLCs (ControlLogix) for an upcoming project ... are you saying it's possible to define *multiple* aliases for the same I/O point in the *same program*?

Paully's5.0 said:

We put all of our tags into arrays.

PLC_Tag[0]
PLC_Tag[1]
PLC_Tag[2]
.
.
.
PLC_Tag[n]

This makes it easy to generate files/code for the PLC in another piece of software like Excel. This also aligns with how we do SCADA tags which make some scripting easier if we have a "fixed" format for a tag.

Of course this makes it harder to "decode" so we put aliases on our arrays.


PLC_Tag[0]: FT101
PLC_Tag[1]: LT901
PLC_Tag[2]: FV878
.
.
.
PLC_Tag[n]: FTxyz

Click to expand...

Is there such a thing as multi-dimensional arrays in PLCs, and what about arrays of structures? I remember back in my military software development days, that compiler had what was called an "Overlay Table", where you'd define your data segment however you wished, but then you could add a label at some point and then define this "Overlay Table" that would 'drop down on top of it' so you could read the data in a loop, or however you defined the structure of the "Overlay Table" (which did not have to match the data underneath). It was a pretty cool compiler feature, I thought...

CapinWinky said:

Interestingly, people coming from other platforms might think Aliases are pointers. They are not pointers, but are instead like the #define from C; a simple find and replace type of thing. That's also why they can't be added to user defined datatypes; they aren't actual locations in memory, so it would get weird.

Click to expand...

Not "pointers" .... "References". A pointer is a variable that holds a memory *address* (where the data you want to access is located). You can modify it, do arithmetic on it, and make it point to another variable. A Reference is an alias. The difference between C++ and these PLCs (I *think* ... I'm still a PLC novice), is you can only statically define the alias *once* in the PLC, whereas in C++ you can dynamically assign it.

Usireland said:

This is effectively what the PLC does aswell, it takes the alias and "replaces" it with the original tag. However inside C code you cannot modify the value of a #define where as you can modify the value of an Alias tag. To me its kind of neither of the two. Its not a true pointer but at the same time it is not like a #define either.

Click to expand...

It's a reference in C++

TConnolly said:

Another reason for creating Alias tags is that often the final IO address is unknown when program development is started. The programmer can go ahead and create the program using base tags, which can then be easily converted into an alias once the actual IO addresses are known.

Click to expand...

You meant the other way around, right? You may not know the actual *I/O Addresses* initially, so you code using the *alias*, and then later on you go back and change the base tag name to the actual I/O point.

TConnolly said:

Aliases also provide a layer of abstraction between a device and an HMI. You might have HMI screens that are designed to provide a consistent look and feel across the entire line and between lines, however the actual equipment may be different. For example, one line might have a drive from AB and the other might have a drive from ABB. Aliases are one tool that can allow the same HMI app to function with both.

Click to expand...

Not sure I follow you. The HMI has its *own* tags, right? And they reference some physical tag in the PLC unique to each line. So the HMI tag names are effectively the "aliases", aren't they?

Usireland said:

Donnchadh

In Logix 5000 the Inputs and outputs are updated Asynchronasly to the scan. They are updated at that particular modules RPI rate. This could potentially cause problems if say for instance you had an XIC of an input on one line and on the next line an XIO of the same input as in theory the PLC could update the inputs between the two lines so you could end up execuiting both or neither of the lines depending on the input states. Thats why generally people either specifically plan for this or else copy the Inputs into an input mask and then use those throughout the program.

Regards
Ian

Click to expand...

I'm new to PLCs (ControlLogix), so this post interests me. What do you mean by "copy the inputs into an input mask"? Are you saying you should copy all your inputs into a local buffer and *then* process (so that you have a static set of inputs for each scan)? I remember back in my military real-time software development days, even *instructions themselves* could be interrupted (at the micro-program level ... the lowest level, BTW, where the hardware is trying to execute a *single instruction*). I remember there was a special instruction called TSF (Test and Set Flag) which was "indivisible", and guaranteed to execute to completion without interruption.

Does anybody know if *instructions themselves* can be interrupted in a PLC? I mean - instructions can take several clock cycles to complete, and if I/O is running asynchronously and the CPU gets interrupted in the middle of an instruction .... Do PLCs have "indivisible" instructions?

CapinWinky said:

It's a little less than a pointer, as I mentioned. A pointer is a variable that stores a memory address. In the case of ControlLogix, a memory address would be a UDINT, so each pointer would actually consume 32bits of memory to store the address for the memory location it is pointing to.

Click to expand...

So an integer (even in a ControlLogix PLC) is only 16 bits?

CapinWinky said:

Any edit you are blocked from making online is because it would change the location of variable data in memory and rather than deal with this, AB has simply decided to block it from happening.

Click to expand...

What, exactly, IS the order of variable data in a ControlLogix PLC? The tag list always seems to be alphabetical, but I assume you can re-shuffle that, correct?

In a conventionally-programmed, structural text application, the order of your data segment is defined by *you*, by the very order you define each data variable or structure.

How is this done in the PLC? Is everything really stored alphabetically, like the tag list seems to imply?

kalabdel said:

So that it's much easier for you to decode your own program months or years later and of course it makes it easier for others two. But some software (Thinking CX Programmer) and some people make very poor use of this concept and end up looking like the attached snapshot.

Click to expand...

I'm still very new to PLCs, but isn't that logic simply testing a switch and then turning on an output? Those are two different things, but it looks to me like the programmer gave them very similar names to "bind" them together (because they were so closely related). I don't see anything wrong with that. As far as the names being hard to decipher, yeah ... that can be a double-edged sword. You really need to balance recognizability with name *length*. You don't want REALLY long names, but you want them to be readable. What's readable to one person may not be readable to the next. I try to learn the convention in place (as long as there IS one), rather than just blowing the program up and changing it because I don't like the convention. Remember that once you do that, you've also blown up the logic history (by making it much more difficult to track logic changes from version to version). One or two minor changes could now be lost in a sea of "cosmetic" variable name changes you just introduced! And that may not be the best thing...

But I have a related question - aren't those tag names going to end up detached in the tag list? To me, you'd want related tags blocked together in the tag list to maintain their connection. Is the only way to do that give them names prefixed the same way (so they end up next to each other in the list)?

Timbert said:

I use an alias to tie the hardware schematic into the program.

For example, Local:1:I.Data.0 is the physical tag, the alias is PB101, and the tag name is Start_PB. This way when it comes time to troubleshoot you can look for the physical I/O point, the device that is connected to that point, or the function of the device.

Click to expand...

I think you might just be adding a layer of unnecessary complexity. Rockwell's giving you an alias tag to abstract those God-awful I/O names. But now you're abstracting the alias *again*, and it's just not necessary. You can use comments to further explain. All you're doing is junking up your tag list with redundant names and obscuring what's important.