One limitation of legacy programmable controllers like the PLC-5, SLC-500, and MicroLogix, was the inability to save “address names,” known as “symbols” in the aforementioned products, directly to the controller.
And since these “symbols” could only be saved with the offline project, in order to display them while online required that you match-up the correct offline file with the one already in the controller.
But thankfully for Allen-Bradley users, with the release of the ControlLogix in 1999 Rockwell switched from using “Data Tables” to a user created Tag Database that was also downloaded to the controller along with the user's program.
This change enabled programmers to create their own custom named Tags for any supported data type, which resulted in what Rockwell called “self documenting” code.
That said, Logix controllers still automatically assigned Tag names to Physical I/O based on the module type and slot.
With this in mind, Rockwell included a feature known as Tag Aliasing which allows users to assign their own Tags as “aliases” to the Physical I/O Tags (or to any other Tag for that matter.)
And while many find using Alias Tags to be quite useful, they do have one fairly big limitation, which is that a Tag's alias definition can't be edited online.
That's not to say you can't create new Tags online, or rename Tags online, or even alias new Tags to I/O online. You can do all three, even in older versions of RSLogix 5000.
But what you can't do is change or edit a Tag's Alias online.
For most this isn't an issue because you typically don't change which I/O terminals your I/O devices are wired to while your system is running.
And even if you did, you can still rename old Alias Tags and replace them with new Alias Tags while your online and in run mode.
But that said, I recently found out that quite a few of my connections don't use Tag Aliases at all.
Actively Avoiding Aliases
I received this feedback when I asked my connections how they were handling migrating programs from the 5370 to 5380, which I discuss in a previous article here.
The response wasn't at all what I was expecting, as nearly all of the respondents said they've been avoiding Alias Tags completely.
Many shared that instead of using Alias Tags, they used a dedicated Routine to “map” Physical I/O Tags to user created Tags.
The thought process being that, while Tag Aliases can't be edited online, Routines can be.
Now as you might imagine, creating a “one to one” relationship in code for hundreds of I/O points can be quite a task.
So I wasn't surprised to hear that for many Structured Text was the language of choice to accomplish the mapping.
But there is a downside to that approach; many end users don't have a version of RSLogix/Studio 5000 that can view Structured Text routines.
And if you can't view the routine that does the I/O to Tag mapping, you're at a huge disadvantage when it comes time to troubleshoot the system.
In fact, this was one of the major issues using ControlNet and DeviceNet with some legacy PLCs, as you couldn't tell where each node's I/O was mapped without first purchasing an expensive copy of RSNetworxs.
It is possible to avoid the Structure Text licensing issue by mapping your I/O to Tags using Ladder Logic.
But in all but the most basic systems you'll end up with a rung (or branch) for every Discrete I/O Point in your system.
So while I do see the wisdom and flexibility of using a routine to map I/O to Tags, at the same time it seems like there should be a better solution twenty years after the Logix controller came out.
What do you think?
Should features which don't support online edits, like Alias Tags, Produced and Consumed Tags, and Add-On Instructions, be avoided?
Or do you use these features with the foreknowledge that like rewiring physical I/O you'll need to take the system offline to make changes to Alias Tags, AOIs, and Produced and Consumed Tags?
I'd love to hear your thoughts on this, and you can share with us by clicking on the “comment” link below.
Enjoy the benifits of membership! Insider news, rewards, & more: Patreon.com/automation
If you enjoyed my article, you may like my courses at TheAutomationSchool.com
Have a question on this topic? Click here to scroll down to the comment link
Have a news tip? Share it with us here
Latest posts by Shawn Tierney (see all)
- Automation Q & A for February 25, 2020 (Video QA4) - February 28, 2020
- My Manufacturing In America 2020 Session Picks - February 27, 2020
- Automate In Sci-Fi Style With These New T-Shirts! - February 24, 2020
Click HERE to scroll down to view or leave comments
- I advocate for IO Mapping, and I advocate using alias tags. However my interpretations of pros and cons seems to be a bit different than most.
IO Mapping allows me to continue with software development before electrical design is completed. On larger projects it's inevitable the electrical design will change as the project evolves. As long as I have a current list of devices the control system will use I can write a functional program. Once we are ready to commission and I have the electrical "as-built" drawing set I can quickly generate IO mapping ladder logic (Excel is very powerful). This also ensures my development environment isn't limited in testing. I can move the program to a different type of controller for testing, and avoid any conflicts which might be introduced should physical IO references be present in the program but missing from the hardware tree.
Alias tags are great for program replication, or for providing a readable reference to an element in an array.
An extremely simple example is a program to control tanks within a tank farm (don't let the simple example equate to an AOI, keep a program reference in mind). I might have a program for tank control, which would essentially be the same across all tanks. Alias tags allow for extremely quick replication.
InletValve - V101
OutletValve - V102
Agitator - M102
Level - LT110
InletValve - V201
OutletValve - V202
Agitator - M202
Level - LT210
InletValve, OutletValve, Agitator, and Level are all PROGRAM scoped tags, aliased to CONTROLLER scoped tags.
The alias allows the program logic to be identical between Tank 1 and Tank 2 programs, but provides for control of the different devices associated with each tank. You can make logic changes in one program, and copy them to another program without changing any tag references. If you need to add an additional tank, you can duplicate the program and simply update the program alias references to the new devices.I always use Alias tags for everything. Luckily I developed that habit of using symbols in SLCs & PLC5s and I have encouraged every new controls engineer to do the same. Online editing of tags has always been a pain. If I can't take the processor offline then I often rename the bad tag with a "zzz_" prefix and re-create the correct/new tag. So if you ever are in my programs - delete all of the zzz tags.Good afternoon @Paul Warning,
Thanks for sharing your example - it's excellent! Very much appreciated!
Instructor at The Automation SchoolGood afternoon @tspisak,
Yeah, I've definitely used that strategy too! Thanks for commenting!
Instructor at The Automation School