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

[MaReKA]

So here it is...

I just recently started thinking about when and why to use alias tags in RSLogix 5000. It is my understanding that an alias tag doesn't reserve the full memory that it's base tag would need. I'm thinking of them as pointers but could be totally wrong. I assume that each alias takes up 32 bit of memory which would be helpful if I wanted to create a duplicate of a UDT. But why would I want to do that?
As of now I came up with only one reason (that is questionable...), and that would be to create an interface to a tag that is created in the scope of a different program. That is not possible...

 

[proof]

Alias tag would be great if they were implemented appropriately. By this, I mean that if I search for the base tag, I can find the base and its alias easily and tell if either is being used. If you want to change the alias to use a different base tag (with on online program), it can't be done. The only benefit that I see for the alias, is you can make a descriptive tag name and use it instead of an obtuse I/O tag name. Tag descriptions of course, do the same, but they don't get saved with the program on the PLC (although I think that has changed with some of the later versions/processors). I'd rather see the base tag with a description, or use a copy of (or copy to) the base tag (with description).

 

[nhatsen]

It is my understanding that an alias tag doesn't reserve the full memory that it's base tag would need. I'm thinking of them as pointers ...

Yes, an alias is like a pointer and uses enough memory for the name and "some overhead".

I use aliases in my projects when I want to recycle programs. For example, in a pump station project, I declare all the instruments tags in the controller (controller scope); then I write the logic for Pump #1 using aliases, in a program (program scope).

When Pump #1 is ready, I duplicate the program and update the aliases for Pump #2, #3 and so on. If the logic is not too big, or the customer can live without online editions, maybe I'd use AOIs.


TN7317 - General Information on Alias Tags (Access Level: TechConnect)

 

[MaReKA]

If you want to change the alias to use a different base tag (with on online program), it can't be done.

Ran into that one before, had to change the program on 13 different locations because of one faulted output and a shift leader that would not allow me to stop the machine.

I use aliases in my projects when I want to recycle programs.

Have to try that out, I'm using AIO's for repetitive logic (after copy & pasting and all the errors that come with that) , but they have to be well tested because of the inability to change them online. Used subroutine calls with input and output parameters as well but only when I can't test the logic and cant stop the controller.

Thank you both, after posting this thread I did a quick search (trap for young players...) and found this thread:

http://www.plctalk.net/qanda/showthread.php?t=79890

 

[Paullys50]

...By this, I mean that if I search for the base tag, I can find the base and its alias easily and tell if either is being used.

I think part of that is programming discipline. If you create an alias, it should be used everywhere in the program, except in specific instances where the alias tag simply won't work. Best example of this is having a base tag which is an array, and some specialized logic which processes the array with indexing. This section of logic has to use the base array, where as everywhere else in the program the alias tag (which is hopefully better named for the process) should used. If programmers mix and match, it's a discipline issue.

Another example would be using a base array for packing data for messaging to PLCs, as well as read/write for SCADA communications.

I also have used alias tags to re-use "generic" code but customize based on specific tags/descriptors of equipment. Example would be multi-staged filtration systems. The logic in each program that controls an individual stage is identical, the only differences are the physical devices that logic needs to control. If you use generic program tags within the stage logic such as "RecircPump, InletValve, OutletValve, LowerStageTemp, UpperStageTemp...etc" you simply have to change the alias in the program tag definition to change the functionality. Plus any edits are copy/paste from one program to the next as the alias updates automatically due to the program tag definition. Makes duplicating a multi-stage system much much easier, and reliable. You could argue "find and replace", but say you have 10+ programs which you need to do this, it's still tedious and runs the risk of human error (fat finger typo).

At the end of the day, my argument will always be that a programmer must have good structure/style, a formal naming convention and be disciplined with the implementation of the previous two. Without this, it leaves a sour taste in one's mouth due to the freedom of a plaform like Logix/Studio/Designer5000

 

[robertmee]

I hate aliasing. I much prefer organized UDTs and the appropriate i/o mapped into the UDT member. UDTs make repetitive programming so simple...just replace one tag. For example take a simple valve with open close limits. Using aliasing you'll have at least three tags for io...solenoid open switch and close switch. Then you might have tags for open close timers, alarms, auto/manual, etc. With a UDT I have one tag...XYZValve...it contains all the members I need to control that valve and the tags stay with the parent UDT tag making the tag repository easy to browse and troubleshoot.

 

[Paullys50]

I hate aliasing. I much prefer organized UDTs and the appropriate i/o mapped into the UDT member.

Agree on not aliasing directly to IO points, I never do it and simply map it to my AOI udt member as well.

...if I wanted to create a duplicate of a UDT. But why would I want to do that?

Well it's not exactly duplicated, but to demonstrate why it's beneficial say for example you had a Valve AOI, and that valve AOI had functionality to activate the valve, and provide open and closed feedback as robertmee suggests. Expanding on that functionality, lets add some fault detection. If a valve is commanded to open, and the open FB is not achieved for xx time create a fault. Same with the closed state. A valve tag with this functionality might have this udt definition:

FV101.cmdOpen
FV101.fbOpened
FV101.fbClosed
FV101.faultOpen
FV101.faultClose

Now, say our system has over 300 valves. Well, how do you efficiently detect a faulted valve and interlock subsequent process logic when a valve fault occurs? Brute force? Seems prone to typos and tedious work. I hate both of those.

Lets change our fault detection in our valve AOI and introduce a fault code.

FV101.faultCode

The fault code could be a combination of the tag number and arbitrary number representing an open fault or closed fault. For this example, 01 = Open Fault, 02 = Close Fault.

If valve FV101 were to have a fault condition our FV101.faultCode tag would populate with 10101,= or 10102 which can be decoded to determine the type of fault at which valve (might be useful on SCADA). It's also an integer value.

Another change, instead of FV101 being the AOI tag for the valve, change it to a generic array: VALVE_CONTROL[0]..[300]

In all the process logic, use the tag FV101 and ALIAS it to a member of the VALVE_CONTROL array. FV101 := VALVE_CONTROL[101] We now have the benefit of a tag that makes sense in our system plus we can use the array for indexed purposes. For general fault detection, we can perform a simple loop to run through ALL members of the VALVE_CONTROL array looking for faults.

IF VALVE_CONTROL[loopIndex].faultCode > 0 THEN
SystemFault = TRUE

This logic really isn't adding much to the process, I'd call it "background logic" meaning the likely hood of it causing any type of problem is minimal and can be ignored when troubleshooting.

 

[brendan.buchan]

I use aliasing for all my IO.

Example, digital IO point Local:1:I.Data.0 aliased to diM2002_MCB, or analog IO point Local:4:I.Ch0Data aliased to aiTT01_PV.

I would then map the aliased IO tag to the UDT or AOI in the program logic where required.

 

[robertmee]

I use aliasing for all my IO.

Example, digital IO point Local:1:I.Data.0 aliased to diM2002_MCB, or analog IO point Local:4:I.Ch0Data aliased to aiTT01_PV.

I would then map the aliased IO tag to the UDT or AOI in the program logic where required.

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 create routines for each io base and in module/point order map each point where it goes...makes it easy to troubleshoot the direct io point if necessary. If the point is unused input it gets a placeholder NOP...if unused output it gets turned off with an always false rung for safety purposes....no spurious unused outputs left on by careless technician.

In a large system with a 1000 io points you'd have to wade through 1000 tags in your tag database to find what you're looking for.

 

[Epy]

My quick 2 cents:
I'll use aliases to give something a more meaningful name, or to avoid repeated array dereferences (i.e. an alias for A[5] references that memory address directly, instead of behind the scenes having to add 5 data sizes to the memory address of A[0]).

 

[JoseM]

My difficulty is with knowing what information do I need when creating members on an UDT. For example if I'm creating an UDT for a Valve, what kind of information do I want to create members for or what if I have a motor.

 

[Paullys50]

My difficulty is with knowing what information do I need when creating members on an UDT. For example if I'm creating an UDT for a Valve, what kind of information do I want to create members for or what if I have a motor.

I'd argue this is a design philosophy the individual/OEM/SI have to determine. When someone buys a system programmed by you or your company what features do you want to include as your defacto standard? What features help your customer understand the equipment/process? What features may help your development time? Put it on paper and come up with a standard deliverable that's applicable across all projects.

You can derive plenty of functionality from a simple input, for example an analog input:

- Needs to be scaled for human consumption
- Hard coded scaling? Or better to have the ability to input min/max ranges and let the PLC do the math?
- Calibration, useful to allow zero/span adjustment in software?
- Faults, how do I know if my signal is valid? Can I always rely directly on the IO card status?
- Simulation, when developing and I don't have everything connected electrically, would it be nice to allow for simulation (Ether manual input of PV value or some other automatic adjustment of the PV) to prevent faults from interrupting the testing.
- Filtering? Perhaps the ability to add filtering to the input would be a benefit?

You really just have to be creative in what makes sense for your ability and your "general" client/industry needs. This is the beauty of an AOI, build and test all the features 1 time, all feature are now available for every device.

 

[kamenges]

Originally posted by robertmee/b]:

In a large system with a 1000 io points you'd have to wade through 1000 tags in your tag database to find what you're looking for.

Only if you are REALLY careless and undisciplined when it comes to tag naming convention. Granted, I probably can't get to a given free tag quite as quickly as I could get to it with a UDT. But if a decent tag naming convention were used it would be pretty close.

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. But just like a hard tool, if you don't know how to use it DO NOT pick it up until you talk to someone who does know how to use it. Best case you will be disillusioned with the tool. Worst case, you will end up with a system that is FUBAR.

Keith

 

[jstolaruk]

Aliasing is another tool in the box of tools. You can use it or leave it alone. I use them mostly for "pointing" at those h/w I/O points that have real long names but sparingly. I do miss them when working with Step 7 sometimes.

 

[MaReKA]

@ Jose:

I'm self-taught, never had the luxury of a mentor that would keep me from doing stupid things, I had to work on technical debts for some time now...That being said, take all of my writing with a grain of salt
If you get the chance to look at other peoples programs do it, if you think of a dumb question ask it. I'm silently reading along here for a long time and learned from other peoples problems as well. I also spent some time maintaining and troubleshooting machines and had the chance to look at some nice programs as well as at some FUBAR (courtesy of kamenges) programs. What all the nice programs had in common was that you could see that someone sat down for a long time and thoughtfully laid out everything before even starting his computer.
In addition to what Pauly wrote you might consider the following:
- start simple, define the basic functions. e.g you have a pneumatic cylinder, it can extend and retract when the safety is ok.
- add feedback, you might want to see where the piston is at the moment
- add diagnostic, what can go wrong? How do you want to use this data?

@Pauly:

I've read a programming standard for a machine that I had to maintain. It had two PLC5s acting as the masters and 5 SLCs controlling the hardware and looking at all the data files and programs made your head spin. After reading the program documentation it made perfect sense , everything was descibed and broken down from build components to assamblies and finally the actual devices like servo axis and even the tiniest cylinder...paper, good stuff


I've seen a few useful cases of aliasing here that I might give a try on future projects. As we are always buffering IO in our programs, aliasing single IO points doesn't make sense for me. Also most of the machines I'm working on are running 24/7, with no chance to perform a download when something has to be changed.