Mapping vs Aliasing

rootcon

Lifetime Supporting Member
Join Date
Aug 2011
Location
Western Mass
Posts
26
Out of curiosity should you Map bits and words or Alias where it could go either way? I'm using RSLogix 5000.
Example:

--|\|--------------------( )---|
Start ...... .......Running
..... .... Local:1:O.Data.0


or



---| |--------------------( )---|
Running Local:1:O.Data.0
 
Plenty of threads on this, so do a search if you haven't already.

From a functionality standpoint, generally speaking either method will work. It usually comes down to preference, how the development process is for someone, possibly some considerations due to the asynchronous IO update of a Logix controller.

I always map, advantages:

1 - Software development can begin if the IO List/Electrical design isn't finalized
2 - I can use SoftLogix for development testing '
3 - I derive additional functionality of an input/output within an AOI. So the result of my AOI is my preferred logic control rather than direct IO.
4 - I have some automated tools that will map my finalized IO list to my previously mentioned AOIs which make mapping IO logic easy.

EDIT: To Add...
I just went through a project where we updated someone else's system (it was a mess). Everything was aliased IO OR, direct IO in the logic. As a result, you cannot do any bench/simulation testing without the physical IO!!!! Took a few days to remove the aliased/direct IO references back to an AOI reference so I could create a simulation environment. With all the changes being made to both the electrical design and the customers process requirements, mapping IO is a clear advantage.
 
Last edited:
If you don’t want someone cursing your name in the future, don’t use aliases. They about the worst thing you can use as a programmer. If you need i/o updates faster than a program scan rate then you shouldn’t be using a PLC.
 
If you don’t want someone cursing your name in the future, don’t use aliases. They about the worst thing you can use as a programmer.


I disagree. Aliases are the greatest thing in the PLC since sliced bread (although what sliced bread is dong in a PLC, I can't say.)

Granted, there isn't much value in creating an alias for an I/O point that'll probably just be referenced once in the program anyway. You do better by annotating the I/O point rather creating an alias to help give the point context. But then again, prior to v24, annotation wasn't stored in the PLC, but aliases were. Instead of cursing you, people would bless you if they needed to upload from the PLC and didn't have the original file.

The more complex your program, however, the more useful aliases become.

For example, in building an AOI, I'll create a Local DINT "HMI_CMDs", and have Input BOOLs "ManStart", "ManStop", "GoToAuto", "GoToMan" which are aliases to unique bits in the DINT. Similarly, I'll create "InOff" InHand" , "InAuto", BOOL aliases to bist 0,1, & 2 a "ModeStatus" DINT.

In doing so, what I've now done is recreated what we used to do in the PLC-5 & SLC: manipulate bits at the word level. If I MOV a 1 into ModeStatus, I automatically have set "InHand" and reset "InOff" and "InAuto". No need for convoluted sealing coils, or Latch/Unlatch instructions. The HMI has an easier time animating off of the single tag ModeStatus, while ladder in the PLC is referring to bits.

The HMI sets all the command bits, and the PLC resets them all after 1 scan with a simple, single XOR + MOV instruction.

Anytime I have an array of anything, I can know that I haven't fat-fingered the array pointer ( [2] when I meant [3] ) by creating a meaningful name for that one element in the array via alias, and then programming using the name instead of the array.

Another useful trick: Say I have two identical line, Line1 & Line2. I'll create two separate Programs, and have identical local aliases pointing to different controller-scoped tags. (I.e., in Line1 I'll have an alias "FeedValve" pointing to YV101, in Line 2 "FeedValve" will be aliased to YV201).

Now I program Line 1 using the alias name. When I'm done, I copy the whole code to the Line 2 program, and I'm done. No search/replace or anything. Because every rung refers to a local tag, there is no conflict, even though the names are the same. But because the aliases are different, different devices are used by the different code.

When I make changes to one program, I can just copy the whole shebang back on top of the other, without having to check for which lines changed and which didn't.

The way I use them, aliases cut down on the number of dumb mistakes that I'm capable of making (leaving me free to make more creative mistakes.)


If you need i/o updates faster than a program scan rate then you shouldn’t be using a PLC.

Huh? I/O scanning rates have nothing to do with aliasing. I/O mapping is often used because the I/O scans (and HMI communication, for that matter) happens OUTSIDE of ControlLogix program scans, and some code can suffer if both -| |- and -|/|- are true on the same logic scan.

That's not to say that your statement is incorrect: there are things out there that perform I/O scans faster than a PLC does, and every situation needs the appropriate application. Your statement appears to me to be a non-sequitur.
 
If you don’t want someone cursing your name in the future, don’t use aliases. They about the worst thing you can use as a programmer. If you need i/o updates faster than a program scan rate then you shouldn’t be using a PLC.

Exactly how do you back that up?
I'll go the other way. If you deliver a system to me, with raw IO addresses scattered throughout the program, you can take it back and forget getting paid.

Aliases are descriptive.
Aliases can be relatively easily re-assigned if IO has to change for any reason.
Aliases have absolutely 0 performance penalty.
Aliases need be done once, reducing the chance of programming errors.

But, you know better. Okay.
 
EDIT: To Add...
I just went through a project where we updated someone else's system (it was a mess). Everything was aliased IO OR, direct IO in the logic. As a result, you cannot do any bench/simulation testing without the physical IO!!!!

Yes you can, you just "inhibit" the connections to the I/O modules (they don't need to be there), and let your simulation package read & write the I/O tags, or the aliases. I do this all the time when testing applications.

As regards the pros & cons for "mapping"....

+ It effectively synchronises the I/O to the program scan.
+ It is easy to change an I/O point with an online edit.
- You miss the benefit of fast I/O updates, which might be critical in high-speed motion control, or even flow-meter pulse counting.

I would suggest that it's not a case of "all or nothing", go ahead and "map" your "standard" I/O, and alias anything that needs a faster response than one Continuous Task scan rate. Don't forget that you can trigger EVENT tasks from change of state of inputs. Those inputs, if "mapped", lose their credibility
 
RE: the OP's question as to whether it is better to use an alias or mapping:

(1) They are not mutually exclusive.
(2) In the example of the two rungs of logic, neither is particularly helpful., as "Running" is not terribly descriptive
(3) While one can create a bunch of stand-alone tags (Motor1_Running, Motor1_StartPB, Motor1_StopPB, etc.), IMO, it is better to make a UDT or AOI, with .Running, .StartPB, etc being elements of the one Motor1 tag.

Doing this somewhat ends the debate of the OP's question, because (as has been much groused about over the years) a sub-element of a tag cannot be an alias to a different tag. Thus to use UDTs / AOIs, one inherently maps.

Whether one maps via raw address or alias of raw address is up to the programmer's style and taste. Having an alias adds more "clutter" to the Tag folder; but it allows for a quick search if you're only interested in monitoring the point, without having to find the code where the mapping takes place to see the raw signal.

Flip a coin. If you find yourself hoping for a particular outcome while the coin is in the air, go with that. Otherwise, wait for the all-knowing coin to tell you what to do.
 
Yes you can, you just "inhibit" the connections to the I/O modules (they don't need to be there), and let your simulation package read & write the I/O tags, or the aliases. I do this all the time when testing applications.

Assuming you have the correct physical controller to run the logic. RSEmulate has it's flaws.
 
Assuming you have the correct physical controller to run the logic. RSEmulate has it's flaws.

Which is why we always bought whatever controller, chassis, and powers supply that were going to be used on the final installations. Many of our clients insisted on it for their Simulation Testing and F.A.T.

In the early days we looked at RSEmulate, but discovered that it isn't even an emulator - it doesn't "emulate" a hardware controller at all.

In those days, pre-AOIs, we had standard software subroutines for our plant item handlers. We would JSR the subroutine, passing into it the plant item UDT (e.g. VA123), then the open and closed feedback inputs. These would be "mapped" into the plant item UDT by the corresponding SBR of the subroutines.

When we ran this on RSEmulate, it didn't work, and I discovered that RSEmulate passes JSR parameters in Reverse Order !!

When I brought this up with RA, I got the response "RSEmulate is a cut-down version of SoftLogix, and the developers of SoftLogix were not given a specification to work to, so were not wrong". Go figure.....

The net result of this was that we would have had so many changes to make to the code after testing/simulation and FAT, to make it work in a controller, that our clients said it would invalidate the FAT. At that point we gave up with RSEmulate completely, and never even looked at it again

RSEmulate has it's flaws.

Like I said, its biggest flaw is that it is not an emulator for a controller....
 
Which is why we always bought whatever controller, chassis, and powers supply that were going to be used on the final installations. Many of our clients insisted on it for their Simulation Testing and F.A.T.

There are many projects and situations where you simply don't have the hardware (existing system modifications for example) and have to make something work. A spare ControlLogix/CompactLogix or SoftLogix will do the trick but having direct IO references in the logic will cause you headaches should the IO tree get wiped due to a controller change so you can run it on your test hardware.

If you work in a plant, and have many types of controllers you probably don't have the same available at your desk for test purposes. If you work for an SI with 20-30 engineers you may have some in-house hardware available but availability is generally an issue.

Buy brand new hardware because you are supplying it, eat the warranty as it sits on your desk.

Lack of a good "simulation" platform from RA is my biggest gripe with them. SoftLogix needs to live on...
 
Out of curiosity, is it preferable to do one over the other depending on the controller type? My company does most of it's development in Siemens, but every now and then we'll have a customer that requests Allen Bradley. I've noticed that in Siemens, the developers stick with aliasing, but in the few AB projects I've worked on, all of the I/O is mapped out in a separate routine.
 
I think for many it is force of habit to use mapping. You can map I/O with any PLC, where aliasing is something that not all support.

Out of curiosity, is anyone using input/output parameters as an alternative to aliases? It solves the I/O scan synchronization issue.

OG
 
Out of curiosity, is anyone using input/output parameters as an alternative to aliases? It solves the I/O scan synchronization issue.

Kind of. I create an AOI for a motor, and add the OUT and AUX as visible, required output & input parameters. Then I enter an unlinked alias for the fields in the AOI block.

In this way, I can develop while waiting for the I/O list to get finalized (the points are known, but they tend to move, as panels get shifted in the floor plan). I simulate using the unlinked alias names.

When the I/O list is ready, I import that from Excel. If it still changes, I import again.

If a device does not have a "required" component, (no. AUX, say), that "alias" tag will never get linked, and will serve a "dummy" tag to make the AOI happy. (There's a bit in the AOI to configure whether it has the feedback or not, of course. Or, I can just make the sim logic permanent for that point, always driving the AUX alias placeholder with the OUT).

But that's me. And I know that I'm not right in the head.
 
for IO I say mapping. Aliasing always causes issues when trying to swap IO points while making online edits. Mapping takes like 2 seconds.
 

Similar Topics

Hi everyone, Kind of new at this, so we recently upgraded our 1769-l32e to the newer 5069-L320erm, i converted the file over and Verify the...
Replies
8
Views
361
Hello Guys I have an 1756-L73S Controller with a Fanuc Robot mapped as follows: - In 1756-EN2TR Slot 2 the Fanuc Robot is defined as an...
Replies
5
Views
192
This has been on my mind for a while now, wondering if anyone here has any best practices or insights. I have been working with a plant that has...
Replies
8
Views
531
Hi long time out... I´m in a project now, that request to upgrade an old SLC to a new ControlLogix. Just the PLC. It is connected now to a...
Replies
5
Views
1,916
Hi all, I'm really new to this. I need to export the Modbus register mapping from a Modicon M580 through Control Expert for the registers that...
Replies
4
Views
888
Back
Top Bottom