Why create Alias tags - RSLogix 5000

I have nowhere near the time I would like to get into the many points and queries you have presented in the above consecutive posts. So I'll just add this in here as a slight pause after your last post...

SoftwareJanitor said:
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.

What's important, and what I think you are alluding to, is clarity. Aliases are provided with the sole intention of providing clarity and removing obscurity for project tag nomenclature. Whether you think that using Nested, Multiple Aliasing or Double Aliasing is obscure, or not, is perhaps a somewhat premature conclusion, if you are not fully aware of, or considering their many uses and potential benefits.

While the following is not an exhaustive explanation of how, when, where and why they may be used, it, hopefully, may go some way in assisting you to draw a more informed conclusion on the matter. You may still feel the same after reading and digesting it, but at least you might feel a little more educated when forming your opinions...

Multiple & Double Aliasing...

Regards,
George
 
Sorry for the multiple posts, but so many people post so many things, and then that results in so many more questions (or comments) from a PLC newbie like me.

As for my comment about the poster's use of aliasing, the impression I got was that all the aliasing was being done at the same scope level - which would be redundant. Trying to trace a tag through the logic only to find that it has multiple names would drive me crazy!

But would it be any better if you did it by scope? It *sounds* more structured, but it's still just another name for another tag. And since there's no assignment statement (as there would be in C++ with a reference), where's the linkage in the logic for someone who's searching your source code trying to figure out how many names you might've given this one tag (or variable)?

Can you give a real-world example so I can better understand how you're using scope-based aliasing?
 
Last edited:
The issue I have run into when aliasing IO is that if a point fails, you cannot easily swap to a new point using online editing. The only way I have found is to do a search and replace on the aliased tag with a placeholder, then delete the alias tag and then recreate it with the new alias and do another search and replace to put the new tag back in service.

Am I off base here in saying that you cannot change the local IO that an alias tag points to during an online edit? I would love to know if there is a better way.

I usually just create a routine that couples my physical IO to the tag I will use in the program. That make it easy to change if needed.
 
The issue I have run into when aliasing IO is that if a point fails, you cannot easily swap to a new point using online editing. The only way I have found is to do a search and replace on the aliased tag with a placeholder, then delete the alias tag and then recreate it with the new alias and do another search and replace to put the new tag back in service.

Am I off base here in saying that you cannot change the local IO that an alias tag points to during an online edit? I would love to know if there is a better way.

I usually just create a routine that couples my physical IO to the tag I will use in the program. That make it easy to change if needed.

No, you are correct, you cannot change the base tag of an alias online. Neither can you do a Search/Replace operation online, only manually, one by one.

If you can go offline and re-download, the easiest solution is to change the base tag of the alias tag, but that will not pick up on any places where someone has addressed the base I/O tag and not used the alias.... yes, it does happen !

What I would do if an I/O point fails is change the I/O module, so there's no documentation changes to make.

But if I had to do a temporary "repair" online I would just edit any places in the ladder that reference the alias or the base address for the temporary fix-up. I would do the edits with AFI's and branches as needed so I can put it back to normal when the new module is put in. There's not going to be many references to a single I/O point, and the cross-reference will show where they are used - both directly and by alias.
 
diat150 said:
...The issue I have run into when aliasing IO is that if a point fails, you cannot easily swap to a new point using online editing...

Quick tangent on the above before getting back to SoftwareJanitor (who will probably have more questions or arguments on this, now that I'll have mentioned it, hehe)...

Map I/O...

While it is not the sole or main reason to Map I/O for asynchronous Logix projects, one of the benefits of using it is exactly the scenario above. If you have, for instance, a "Map_Inputs" routine where all of the Module-defined input tags are "mapped" to User-defined tags, using XIC or XIO instructions to OTE instructions...

Note: these User-defined tags are not Alias tags, but would normally be Controller-Scoped.

...and a physical input point fails, then you can simply online edit the XIC or XIO instruction's assigned Module-defined tag address in the mapping routine to an available spare input tag address, if one exists. Even though the mapped User-defined tag may have been used extensively throughout the project, this one edit is all that is required in the project to switch to the spare input. The same can be applied to mapped outputs.

As we know, you cannot edit an Alias tag's Base tag reference on a running processor, because it is resolved and locked in at compile time (someone earlier mentioned Aliases do not exist in the processor - they do).

Even if you had not thought that using Map I/O is of any benefit when designing your projects, this one advantage might be worth implementing instead when considering Aliasing Controller-Scoped User-defined tags directly to Module-defined tags.

Regards,
George
 
SoftwareJanitor,

Let's just go back and take a look at what you had read, or what you thought you had read...

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.

SoftwareJanitor said:
...the impression I got was that all the aliasing was being done at the same scope level - which would be redundant...

If we read it carfully we may see that they have not specified which scope the example Alias tag is, was or would be created at. Also, from what I am reading, there is only one Alias tag present in this scenario...

Base tag: Local:1:I.Data.0 <<< Module-defined tag - Controller-Scoped

Alias tag: PB101 <<< User-defined tag - could be Controller-Scoped or Program-Scoped

Alias tag: PB101 - Description: Start_PB

This is one Alias tag with a particular tag description.

What Timbert is most likely describing here is a typical usage of Aliasing at the same scope i.e. the Controller-Scope. As Module-defined tagnames are normally undesirable for clarity in programming, many of us may create a User-defined Alias tag at the Controller-Scope to reference the Module-defined Base tag.

An example naming convention, which can often be according to a specification for the project, may require a single tag contain a Base tag reference declaring the physical I/O point, an Alias tagname declaring the field device, and a tag description declaring the device's operation.

So...

The User-defined Alias tag references the physical I/O Base tag Local:1:I.Data.0 denoting input 0 on the input module in slot 1.

The Alias tagname is PB101, denoting assumedly the field device Push Button 101

The Alias tag description Start_PB denoting Start Push Button which is the operation of the field device.

When you see this Alias tag assigned to an instruction instance it is possible to view all three references at once, along with any rung comments that may be present.

A user can, of course, simply use Base tags directly assigned to instruction instances, with detailed tag descriptions so as to achieve similar results...

Base tag:

Local:1:I.Data.0

Tag Description:

PB101:
Start_PB

So why would a user possibly be better off using the Aliasing method?...

Besides adding a level of clarity, Alias tags can facilitate the use of reusable, template, generic, canned or boxed logical routines, however programmers like to call it.

If we create, say, a Program Routine for controlling a motor via a drive. The tags used within this Program will be referencing Controller-Scoped Module-defined tags for the drive in some way or another. The Program could be referencing the drive tags directly, or via Aliased Program-Scoped tags, either directly to the drive tags or even through Aliased Controller-Scoped tags and then to the drive tags. In all cases except when directly referencing the drive tags, the facility is there to assign different Base tags to the Alias Program-Scoped tags.

In this manner, it is possible that such routines' logic or code could be copied and used to control several motors, and not just within the one project. If we want to reuse this code with other physical devices and their Module-defined tags, then we simply assign the relevant Base tags at design time.

Another way users often "can" such logic is by using an Add-On Instruction (AOI) which contains similar logic to the above mentioned routine. Similarly, the AOI will have default User-defined tags created, often referred to as backing tags, which will need to reference the Base tags required by the user.

Each instance, where either a generic routine or canned AOI is used, the Base tags may be user selectable.

Another advantage, that was previously mentioned, is facilitating preprogramming where the hardware is not yet known. A user can create their program routines and define all Program-Scoped tags, not Aliases, and complete and test their logic. When the hardware is eventually present, and their Module-defined tags have been declared, the user can convert all the Program-Scoped tags to Alias tags and reference the actual Base tags for the hardware.

Another small example might be where the same signal, within the same project, may have different operational meaning to different stages of the process. An Aliased "EndStrokeProx01" signal may signify the end of one operation in one program, but the same signal may need to signify the beginning of another operation in another program - "EnablePhase02". Both these could be Program-Scoped Alias tags in different programs, within the same project, but both referencing the same Module-defined Base tag.

And so on...

Aliasing is there as an optional feature. If one does not feel it is of benefit to them, from a clarity, specification, segregation or reuseability point of view, then simply do not use it.

Note: Any use of the words "reference ", "pointer", "define", "declare", or the like, with regards to Rockwell Automation programming languages, by them or us, is not intended to mean the same as you are familiar with in C++. They are not the same in many respects. These terms are not exclusive to the object oriented C++ programming language and may be used in many languages with similar or dissimilar meaning.

I would, for your own benefit while trying to learn this new language and instruction set, try to put your C++ knowledge to one side and focus on understanding how this language works, as is, without constantly trying to understand why it does not seem to do what you would expect it to do in the C++ world. That's not easy, I know, but do try.

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



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?

There are 3 "types" of integer data in Logix5000 controllers, ControlLogix is just one of the family. All of them are signed integers!!

SINT : an 8-bit integer structure that can hold integers within the range -128 to +127. The lowest order 7 bits are the "value", and bit 7 is the sign bit.

INT : a 16-bit integer structure that can hold integers within the range -32,768 to +32,767, bit 15 is the sign bit.

DINT : a 32-bit integer structure that can hold integers within the range -2,147,483,648 to +2,147,483,647, bit 31 is the sign bit.

Before anyone shouts, I'm going to ignore the LINT data type, it has very limited use, and is not much use with the current instruction set.

It is worth noting that if you need to store or use a number that can only be, for example 0 to 10, you might think a SINT tag would be the best. Far from it... the processor has a 32-bit architecture, so processes numbers as 32-bit numbers. Anytime it sees a SINT or an INT it will convert it to a DINT for processing, then might have to convert the result back to a SINT or INT for storage. All these conversions take time. Keep your "Default Data-Type" in the options set to DINT, and create all integer tags as DINTs. The only time you need SINTs or INTs is if you are creating an array that is communicated with/to/by another device that only understands 8 or 16-bit data structures.

Your second question - the tag database view has many options for how the tags are presented. You can sort by tag-name, (A-Z or Z-A), by data-type (again, both ways), by "External Access" permissions, by Read/Write attributes. You can also limit the display to display only tags of your-choice data-types, or you can use filtering to display only tags that contain the characters in your filter criteria. The world is your oyster here.....
 
Last edited:
Geospark;735495I would said:
Well said George :(y)

Languages - even people who know two find some things hard to translate. There are some things better expressed by translating the meaning, rather than the wording, that is often the hardest part.
 
Geospark,

Nice reply, thanks! I'll put you on my list of trusted sources.

And don't mind me. You are right that I am still thinking about (wishing for?) other platforms to implement this upcoming (substantial) project on, but it's going to be a ControlLogix PLC, so I'll just have to deal with it.

I'll try to hide my frustrations and just stick to asking simple questions in the future.
 
I don't use aliasing on IO, I prefer to map IO in dedicated routines. I do this due to the a-sync IO updates as previously mentioned but also because electrical design may not be completed or started by the time software programming needs too. By mapping IO it's very easy to dump final IO mapping routines into the program once all electrical panels have been built and gone through a checkout process.

Aliasing is extremely powerful in software re-use as Geospark has mentioned, here is a simple example:

I have 4 batch tanks, each are identical in-terms of hardware and control required. However, they are independent and require instances of logic to independently control the equipment. To keep things simple, each tank has a recirculation loop. So a motor, flowmeter in the loop and associated valves.

In a previous post I mentioned I'll have base arrays of for all device control
MOTOR_ARRAY[X]
VALVE_ARRAY[X]
FLOWMETER_ARRAY[X]

These are controller scoped arrays and have advantages. Of course, for clarify this doesn't do much for us at all. As previously mentioned aliasing will give us that:

M101 - MOTOR_ARRAY[1]
M201 - MOTOR_ARRAY[2]
M301 - MOTOR_ARRAY[3]
M401 - MOTOR_ARRAY[4]

M101 - M401 are also controller scope tags. This gives a nice index and spot to cross reference if required. Also allows usage across all programs/phases in a controller (which may or may not be required pending the process). Usually if equipment must share resources you'll need this.

To program the control of the recirculation loop, once we create the logic for one tank, it's essentially "copy/paste", "find/replace" for all the rest BUT, it can be easier. Since this is a batching example, I will program separate phases for each recirculation loop.

Phase_Tank1_Recirculation
Phase_Tank2_Recirculation
Phase_Tank3_Recirculation
Phase_Tank4_Recirculation

Because I know I'll be reusing code, I'll create Program tags, which alias back to the associated devices for that tank I'm programming, for Phase_Tank1_Recirculation:

Recirc_Pump - M101

For Phase_Tank2_Recirculation:

Recirc_Pump - M201

Now I have tags that are the same for each recirculation phase, but the alias definition ensures I control the correct device. If I create Phase_Tank2_Recirculation logic by copy/pasting of the logic (or export/import), all I need to do is change the alias definition and I'm done, I have unique, proven code ready to go.

Scale this up to 10 tanks and it makes development really quick and reliable. Also it provides easier changes during the commissioning process. Say that recirculation logic needs some additional work once you're testing, you can easily just copy/paste from tank 1 logic into tank 2, 3, 4 and not do anything more as the program tag is the same, but the alias definition is already different.

Consider additional logic requirements beyond just the devices. Sequencing logic, fault logic, operator prompts/messages...etc. Program tags w/controller scoped alias tags provide a lot of flexibility, clarity, reduced development time. Most of the time, much of your logic is the same across the different programs and phases and the real task is coding for the different devices and process. 50% of your logic could be created 1 time, and proven out 1 time and deployed across 50/100/200+ programs/phases with only changing the alias. This makes it a very powerful tool.
 
I have 4 batch tanks, each are identical in-terms of hardware and control required. However, they are independent and require instances of logic to independently control the equipment. To keep things simple, each tank has a recirculation loop. So a motor, flowmeter in the loop and associated valves.

In a previous post I mentioned I'll have base arrays of for all device control
MOTOR_ARRAY[X]
VALVE_ARRAY[X]
FLOWMETER_ARRAY[X]

Could you also organize this by Tank cluster? In other words, you have your pump, valve(s), flowmeter, etc for a particular tank ... could you define a structure with these things as elements, and then turn *that* into an array? Is this where UDTs come in with PLCs (data types with .members)?

Scale this up to 10 tanks and it makes development really quick and reliable. Also it provides easier changes during the commissioning process. Say that recirculation logic needs some additional work once you're testing, you can easily just copy/paste from tank 1 logic into tank 2, 3, 4 and not do anything more as the program tag is the same, but the alias definition is already different.

Is it possible to *instance* this logic in the PLC so that you can make the change in one place and it just ripples through all the instances without having to cut/paste anything? Is this where AOIs come in?
 
Could you also organize this by Tank cluster? In other words, you have your pump, valve(s), flowmeter, etc for a particular tank ... could you define a structure with these things as elements, and then turn *that* into an array? Is this where UDTs come in with PLCs (data types with .members)?

You could yes, probably not my method simply because each and every project would then have different structures due to process/equipment differences. Keeping things at the simplest level - Valves/Motors/Analogs are the constants among all projects and fundamentals of what I need them to do don't change. You also start to cross into philosophies of what you are programming for (S-88 for batching as an example).


Is it possible to *instance* this logic in the PLC so that you can make the change in one place and it just ripples through all the instances without having to cut/paste anything? Is this where AOIs come in?

Yes but it's not recommended. AOIs are GREAT for device control, and another reason why I group things by device. Valve AOI - Valve Scada Faceplate. This logic is perfect for instantiation.

You start to box yourself in if you try to create AOI definitions for higher level control. AOIs cannot be changed online, and will result in everything coming to a screeching halt if you need to make an AOI logic change during commissioning. Creating multiple programs/phases gives you modularity, and flexibility at the expense of true instantiation. You also have to remember that the "real world" equipment may not be ideal. In my example, maybe my mix tanks are all the same, EXCEPT tanks 1 and 2 have a single cooling jacket, and tanks 3 and 4 have dual jackets....

See this post for a forum member's conclusion , read the thread for additional context.
 
Could you also organize this by Tank cluster? In other words, you have your pump, valve(s), flowmeter, etc for a particular tank ... could you define a structure with these things as elements, and then turn *that* into an array? Is this where UDTs come in with PLCs (data types with .members)?



Is it possible to *instance* this logic in the PLC so that you can make the change in one place and it just ripples through all the instances without having to cut/paste anything? Is this where AOIs come in?

Yes and Yes
 

Similar Topics

Hello, I've been trying to learn this a while now and still have not found out how this works. I have an Omron CJ2M PLC and an ABB ACS 355 VFD...
Replies
1
Views
190
Hello, I have to deal with iFix again and am looking at the most efficient way to create alarms to display in iFix, i.e. not creating an...
Replies
0
Views
138
Good morning to all, I have the following issue, I installed everything of intouch including the patch, it is the 2023 version. The...
Replies
0
Views
284
So, I finally got versioin 27 installed on my Windows 10 VM. However, now I can't upload a project from my lab controller. I have the above error...
Replies
0
Views
1,115
Hi all, I have few GB of logged data created by RS View 32 Works, it is all in .DBF format. At the moment, my company wants to shift all data to...
Replies
14
Views
1,393
Back
Top Bottom