Usage of Alias tags in RSLogix 5000 - when and why?

[JoseM]

I'm trying to integrate the control valve into an existing system. I want to use this application to learn a few things like UDT, AOI, Aliases, PID, etc.

I need the PID to control the modulation of the valve base on a predetermine set point and the feedback from the level sensor in the bottom.

 

[ELake20]

My .02

I alias I/O because honestly I don't care what "Local:1:I.Data.0" is. I only care that it is Pump1_Running for example.

When used in a UDT I will create a SBR for these IO moves and move the alias'd tag I/O tag to the UDT like Pump[1].Running and then use the UDT in my AOI libraries.

In S7 it was easy. In symbol table you define these and do your aliasing that way so I0.0 is Pump1_Running. You still need to create the pointer for real world to the UDT though.

Generation of an I/O list is always first step to doing any project so the information already exists, using excel it's easy enough to manipulate and sort it out.

One thing I didn't like about RSL5K when I started using it full time was drilling down to the modules to find the bits for input/output cards. Aliasing does a good job of this for me.

 

[nhatsen]

I'm trying to integrate the control valve into an existing system. I want to use this application to learn a few things like UDT, AOI, Aliases, PID, etc.

I need the PID to control the modulation of the valve base on a predetermine set point and the feedback from the level sensor in the bottom.

Nice diagram but I think it'd be better if you start a new thread.

 

[kamenges]

Originally posted by ELake20:

When used in a UDT I will create a SBR for these IO moves and move the alias'd tag I/O tag to the UDT like Pump[1].Running and then use the UDT in my AOI libraries.

In this case I am in agreement with robertmee in post #9 when he stated:

Originally posted by robertmee:

Why? If you're mapping the io to a UDT what's to be gained by aliasing to a tag? Just map the local directly to the udt.

I don't see the value of creating an alias if you intend to map the I/O point into a UDT. The alias won't be generally visible anyway.

Keith

 

[jstolaruk]

In S7 it was easy. In symbol table you define these and do your aliasing that way so I0.0 is Pump1_Running.

Sure, but you can only have one symbol assigned to I0.0. Can't create two.

 

[brendan.buchan]

I don't see the value of creating an alias if you intend to map the I/O point into a UDT. The alias won't be generally visible anyway.

Keith

I do this because in my opinion it helps with diagnostics.

My aliased IO tags generally match my wire numbers, so when trying to fault-find an IO point what you see on the drawing is what you look for in the PLC. This is not as straight forward with straight UDT/AOI's tags though.

Here is a real world example from a recent project I did. I have a lifting table on a machine, and for the cylinder position sensors I have wire tags L1_LFT_RET and L1_LFT_EXT.

I alias these local IO points as follows:

diL1_LFT_RET is an alias for Local:1:I.Data.3
diL1_LFT_EXT is an alias for Local:1:I.Data.4

The AOI that these points are mapped to is the P_ValveMO object from the PlantPAx library. The AOI tags for these two inputs are L1_LFT.Inp_OpenLS and L1_LFT.Inp_ClosedLS.

Now when someone comes along later down the track and is having issues with the position sensors on this device, it makes much more sense for them to look at the drawings, then look at the program for the same tag L1_LFT_RET as opposed to L1_LFT.Inp_OpenLS.

You could argue that it is not necessary, but for me when designing a program I make an IO list either way, and it is super easy to assign tag names / aliases my local IO points in this spreadsheet and import straight into Studio5000.

 

[Paullys50]

Only if you are REALLY careless and undisciplined when it comes to tag naming convention...

From my experience, this is more often the case than not with Logix controllers. I've had a number of debates over the years with maintenance people about their displeasure in working with a Logix controller, all the while I'm trying to educate them that their displeasure is from poor programming practices and not the Logix platform itself.

The first Logix program I had to support was a complete mess, so I can sympathize with maintenance.

I look at most of this like I look at most other tools. If you like them, use them. If you don't, don't.

On one hand I agree, then on the other with so many complaining about the price of Rockwell why spend the money on the platform if you aren't going to get educated as use the tools? Sort of like having a Snap-On tool chest loaded with high-end tools, and all you ever use is the adjustable wrench, a multi-purpose screw driver and a single hammer.

 

[robertmee]

I do this because in my opinion it helps with diagnostics.

My aliased IO tags generally match my wire numbers, so when trying to fault-find an IO point what you see on the drawing is what you look for in the PLC. This is not as straight forward with straight UDT/AOI's tags though.

Here is a real world example from a recent project I did. I have a lifting table on a machine, and for the cylinder position sensors I have wire tags L1_LFT_RET and L1_LFT_EXT.

I alias these local IO points as follows:

diL1_LFT_RET is an alias for Local:1:I.Data.3
diL1_LFT_EXT is an alias for Local:1:I.Data.4

The AOI that these points are mapped to is the P_ValveMO object from the PlantPAx library. The AOI tags for these two inputs are L1_LFT.Inp_OpenLS and L1_LFT.Inp_ClosedLS.

Now when someone comes along later down the track and is having issues with the position sensors on this device, it makes much more sense for them to look at the drawings, then look at the program for the same tag L1_LFT_RET as opposed to L1_LFT.Inp_OpenLS.

You could argue that it is not necessary, but for me when designing a program I make an IO list either way, and it is super easy to assign tag names / aliases my local IO points in this spreadsheet and import straight into Studio5000.

If they're looking at the drawing then they know what rack and slot it's in so in my case they'd go to the routine associated with that rack and each module is in order mapped to a udt. The local:x.y tag would have the description with the wire number in it. Usually we generate wire #s that tell them which rack module and pt so even the drawing isn't necessary. I see the value of how you do it too so I guess two ways to skin a cat. Difference is my tag database is very compact and easy to search.

 

[DSMR]

One way that I use Aliasing is with physical I/O like was mentioned before but with a twist.

On physical I/O I have 3 things to identify it. Description, Tag, Base. Ex:

Description: Widget B Cylinder clamp Extended
Tag: PRS_99912
Base: Local:1:I:blah blah blah...

The Tag name is very specific and matches the electrical drawing for the actual device name. It follows this format:

XXX_YYYZZ

XXX: Device type. Proximity Sensor would be PRS. Photo Eye PEC. Solenoid Valve SV.. or SOL... ECT ECT ECT. I include legends for all symbol names with all drawings packages.

YYY: Sheet number. All sheet numbers are broke out into individual areas. Series 100 deals with layouts while series 700's would deal with servos and much much more in between. It is rigid organization that is implemented that is very important to be efficient.

ZZ: Line Number on that particular sheet

So now when I look at a Tag, I know what the heck it does by the description, Can look at it in the drawings quickly by using the Tag name, and know exactly which hardware address it is all at one glance.

 

[proof]

I do this because in my opinion it helps with diagnostics.

My aliased IO tags generally match my wire numbers, so when trying to fault-find an IO point what you see on the drawing is what you look for in the PLC. This is not as straight forward with straight UDT/AOI's tags though.

You could use tag descriptions to hold the wire numbers. You can also copy to a new tag rather that use the alias. You'd get all the benefits of using the alias, but none of the drawbacks.

 

[diat150]

am I missing something or do alias really screw you if you are doing online edits? If you alias and have that alias in logic, you cannot change the alias tag online. the only option would be to go and change the alias in the logic to a different tag, delete the old alias tag, then recreate it with the new reference, then go back and put it back where it belongs. so am I missing something?

 

[MaReKA]

No, that is what you have to do.
The main reason for me to not use it to give IO addresses a usefull name.

 

[proof]

am I missing something or do alias really screw you if you are doing online edits? If you alias and have that alias in logic, you cannot change the alias tag online. the only option would be to go and change the alias in the logic to a different tag, delete the old alias tag, then recreate it with the new reference, then go back and put it back where it belongs. so am I missing something?

Yes, except many times this can't be done. You can't delete the alias if your HMI is using the tag. If you had used a second tag instead of the alias tag, then all you would need to do is change the copy to use the new source.

It seems like everyone that likes using aliases are people writing code that they do not support. The people that hate aliases are the people that are maintaining that code.

 

[robertmee]

Yes, except many times this can't be done. You can't delete the alias if your HMI is using the tag. If you had used a second tag instead of the alias tag, then all you would need to do is change the copy to use the new source.

It seems like everyone that likes using aliases are people writing code that they do not support. The people that hate aliases are the people that are maintaining that code.

I hate aliases and I write code strictly on contract basis for others. However 50% of my work lately is doing rewrites of either PLC5 or CLX programs by people that haven't a clue. The ROI is based on their technicians can't troubleshoot spaghetti code and having to untie their code and chase aliases and double in directs and routines written in one giant main routine I've come to appreciate how organized and efficient and repeatable code is to the end customer. Usually a project starts with a needed additional function and ends with a complete rewrite.