Mapping vs Aliasing

That's why I said, "kind of".

I've only used Inputs and Outputs with Phase programs, not normal ones. I never could figure out a use for them. Unless I missed something big (possible), you can't call a program like you do a routine, passing parameters with a JSR (except in an Event Task, and using Public tags).

How does using Input and Output parameters solve the I/O scan synchronization issue? If the input tag is just an alias to Local:3:I.Data.5, doesn't its "bit bucket" get read every time it is referenced, and thus change when the I/O point changes, which may be intra-scan?

Or is that a fundamental difference between "Input" and "Local" ?
 
Input parameters are only updated at the beginning of the scan. Output parameters are updated at the end of the scan. Input parameters cannot change state in the middle of the scan whereas aliases are updated immediately.

And parameters are accessible outside of the program where they are defined unlike local (program) tags.

OG
 
Interesting. My "new thing learned" for the day. Thanks, OG.

So moving the Alias tags from the Controller scope to a program ("IO") makes them only updated once per scan (of that Program in that Task)? And they'd be referencable anywhere (as "\IO.aliastagname")?

I'm not entirely sure how useful that would be, but then, I'm big on UDTs and AOIs, so I wind up "mapping" everything into those structures anyway, and so don't care if they're asynchronous or not; the I/O address is only used once in the program.

But I'll keep thinking about this, to see if there's a nifty way of exploiting this.

Again, thanks.
 
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.

No, genius. You map i/o values to logical tags in a "mapping" program to logically named tags, and use those throughout the program.

If you ever have to move the i/o point, say for a bad channel, or whatever, if you use an alias, you're stuck. If you use simple mapping, it's no problem.

And if you ever use aliases in program for me, you'll be fired and blacklisted.
 
Last edited:
And if you ever use aliases in program for me, you'll be fired and blacklisted.

Which is your right, just like if you were ever work for me, and don't program as I say -- which may include aliasing -- you would be let go. "He who pays the bills makes the rules."

Aliases are like hammers: they're tools. Faced with a nail, I'll use a hammer. Faced with a screw, I will not. To me, saying "no aliasing" is as idiotic as saying "always alias".

Or "always map", for that matter. The whole asynchronous thing is way over-hyped. 99% of the time, it doesn't matter. We tend to naturally buffer our inputs anyway: putting photoeyes behind On-timers and Off-timers, to ensure that they are actually seeing something, for example.

Output coils are only used once (without error, anyway), so don't need to be mapped.

HMI communication has ALWAYS been asynchronous to scan, and it bit me once -- once -- on a PLC-5 application. Once I understood what was going on, I rewrote the code so that it didn't matter. But we don't worry about buffering our HMI addresses, do we? Even if the same bit might be referenced in multiple places in the code? Not that I've seen, anyway.
 
But we don't worry about buffering our HMI addresses, do we? Even if the same bit might be referenced in multiple places in the code? Not that I've seen, anyway.

Completely agree with your tool analogy, all tools in the chest are useful given their purpose. Usually it comes down to understanding, application and value add.

We might worry about efficient communications to/from the HMI (assuming Ethernet). Pack the HMI data into an array for communications purposes. Using this as an example highlights advantages of aliasing, mapping and HMI comms in respective areas.

A base array Digital_Inputs that might communicate to the HMI:

Code:
Local:1:I.1 --> Mapped to: Digital_Inputs[0] --> Alias of "DoorOpenProx" 
Local:1:I.2 --> Mapped to: Digital_Inputs[1] --> Alias of "DoorClosedProx"
Local:1:I.3 --> Mapped to: Digital_Inputs[2] --> Alias of "DoorLocked"
.
.
.
Local:1:I.n --> Mapped to: Digital_Inputs[n] --> Alias of "SomeUsefulName"

HMI/SCADA references the array, PLC program references the alias to make it a bit more readable.

Like you, my IO naturally buffers itself due to the usage of AOIs for device control, but I still have routines to "map" the IO as inputs into the respective AOI, both for input and output areas. The advantage is that the hardware tree is irrelevant until you actually require it for commissioning, allowing you to test and develop on whatever equipment you have at your disposal. Aliasing an IO point in this example doesn't provide any additional value.

To expand a bit, the alias names in my example would actually be AOI names as the AOI would provide additional logic functionality for the IO device:

Code:
DoorOpenProx.Digital_Input (mapped physical IO point)
DoorOpenProx.Debounce_Timer
DoorOpenProx.Simulation_Mode
DoorOpenProx.Simulation_State
DoorOpenProx.State (based on debounce timer and simulation)

I find the alias to be more useful for the corresponding AOI reference rather than the physical IO itself.

I think aliasing gets a bit of a bad rap because many just think of IO aliasing rather than aliasing to make your program a bit more structured and refined. Aliasing a program tag to a controller tag can save quite a bit of time if you are replicating many identical programs (say for example tank farm application).
 
I worked on a job that they used aliasing to link to original IO logic.
Can you imagine trying to work with "%I0105" that is actually "%I0090"??? If you do not have original logic you are more lost.
It would have been way easier to have a section where %I0090 is mapped to %I00105, and actually use text for input address.
 
I tend not to use mapping routine (although I'm in the minority there). I prefer to have a "YV107" routine, that does "one stop shopping" for all thing related to valve 107 -- interlocks, I/O links, AOI call, equipment module interface, or anything else that relates to that control module.

I generally don't alias the I/O, and merely map the Local:I tag to the AOI element.
But in larger systems, where the code is outstripping the hardware design, I put in "placeholder tags" for where the I/O will go -- just stand-alone BOOLs that I'll reference (in a separate Program) by simulation logic. Depending on when the official I/O list (or rather, I/O address assignment) gets done, I'll replace the placeholder with the real I/O, or I'll do a partial tag import, and turn those "placeholders" into aliases.

The latter is faster, since it comes straight out of Excel; but the former doesn't have extra tags that serve little useful purpose in the PLC.

Time & money usually override Engineering Quality. They shouldn't, didn't used to, and it's getting worse every year, bit by byte. Like I said, "he who pays the bills makes the rules".

I'm counting the days until retirement.
 
I say map the point to a structure (UDT in Rockwell speak) and do any processing in the mapping (adjust for NC/NO, filtering logic, etc) so the point in your IO structure is useful as-is. I usually make a structure that goes something like IO.DIn.MyDigitalInputName or IO.AO.MyAnalogOutputName and the autocomplete makes things go very quickly as far as generating the actual logic.

Aliasing has a lot of negatives, probably the biggest being you can't even do it until you have all the hardware picked out. It's a concept specific to Rockwell and how IO works in Logix/Studio5k so the whole paradigm doesn't work on most other platforms, while mapping to a structure can be done in some fashion on every major platform. In the past, tracking down the original point through the alias was problematic (largely fixed in newer versions making it easy to tell where aliases point and jump right to the source). It's also disjointed, you can't put aliases in a structure, making organizing code difficult.

The big advantage to Aliasing is that it is easy to do in comparison to making and mapping a UDT. This has more to do with the UDT editor being total **** than anything else, but you definitely can knock out aliasing much faster.

Just an FYI:
Aliases are not pointers, it's basically just a big list of find and replace. Because of this, it actually uses less processor power than mapping to a UDT because the value is never moved to a new memory location. However, if this is a noticeable effect on your project's performance, you need a better PLC.
 

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
362
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
196
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,923
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
889
Back
Top Bottom