SoftwareJanitor,
Let's just go back and take a look at what you had read, or what you thought you had read...
Timbert said:
I use an alias to tie the hardware schematic into the program.
For example, Local:1:I.Data.0 is the physical tag, the alias is PB101, and the tag name is Start_PB. This way when it comes time to troubleshoot you can look for the physical I/O point, the device that is connected to that point, or the function of the device.
SoftwareJanitor said:
...the impression I got was that all the aliasing was being done at the same scope level - which would be redundant...
If we read it carfully we may see that they have not specified which scope the example Alias tag is, was or would be created at. Also, from what I am reading, there is only one Alias tag present in this scenario...
Base tag: Local:1:I.Data.0 <<< Module-defined tag - Controller-Scoped
Alias tag: PB101 <<< User-defined tag - could be Controller-Scoped or Program-Scoped
Alias tag: PB101 - Description: Start_PB
This is one Alias tag with a particular tag description.
What Timbert is most likely describing here is a typical usage of Aliasing at the same scope i.e. the Controller-Scope. As Module-defined tagnames are normally undesirable for clarity in programming, many of us may create a User-defined Alias tag at the Controller-Scope to reference the Module-defined Base tag.
An example naming convention, which can often be according to a specification for the project, may require a single tag contain a Base tag reference declaring the physical I/O point, an Alias tagname declaring the field device, and a tag description declaring the device's operation.
So...
The User-defined Alias tag references the physical I/O Base tag Local:1:I.Data.0 denoting input 0 on the input module in slot 1.
The Alias tagname is PB101, denoting assumedly the field device Push Button 101
The Alias tag description Start_PB denoting Start Push Button which is the operation of the field device.
When you see this Alias tag assigned to an instruction instance it is possible to view all three references at once, along with any rung comments that may be present.
A user can, of course, simply use Base tags directly assigned to instruction instances, with detailed tag descriptions so as to achieve similar results...
Base tag:
Local:1:I.Data.0
Tag Description:
PB101:
Start_PB
So why would a user possibly be better off using the Aliasing method?...
Besides adding a level of clarity, Alias tags can facilitate the use of reusable, template, generic, canned or boxed logical routines, however programmers like to call it.
If we create, say, a Program Routine for controlling a motor via a drive. The tags used within this Program will be referencing Controller-Scoped Module-defined tags for the drive in some way or another. The Program could be referencing the drive tags directly, or via Aliased Program-Scoped tags, either directly to the drive tags or even through Aliased Controller-Scoped tags and then to the drive tags. In all cases except when directly referencing the drive tags, the facility is there to assign different Base tags to the Alias Program-Scoped tags.
In this manner, it is possible that such routines' logic or code could be copied and used to control several motors, and not just within the one project. If we want to reuse this code with other physical devices and their Module-defined tags, then we simply assign the relevant Base tags at design time.
Another way users often "can" such logic is by using an Add-On Instruction (AOI) which contains similar logic to the above mentioned routine. Similarly, the AOI will have default User-defined tags created, often referred to as backing tags, which will need to reference the Base tags required by the user.
Each instance, where either a generic routine or canned AOI is used, the Base tags may be user selectable.
Another advantage, that was previously mentioned, is facilitating preprogramming where the hardware is not yet known. A user can create their program routines and define all Program-Scoped tags, not Aliases, and complete and test their logic. When the hardware is eventually present, and their Module-defined tags have been declared, the user can convert all the Program-Scoped tags to Alias tags and reference the actual Base tags for the hardware.
Another small example might be where the same signal, within the same project, may have different operational meaning to different stages of the process. An Aliased "EndStrokeProx01" signal may signify the end of one operation in one program, but the same signal may need to signify the beginning of another operation in another program - "EnablePhase02". Both these could be Program-Scoped Alias tags in different programs, within the same project, but both referencing the same Module-defined Base tag.
And so on...
Aliasing is there as an optional feature. If one does not feel it is of benefit to them, from a clarity, specification, segregation or reuseability point of view, then simply do not use it.
Note: Any use of the words "reference ", "pointer", "define", "declare", or the like, with regards to Rockwell Automation programming languages, by them or us, is not intended to mean the same as you are familiar with in C++. They are not the same in many respects. These terms are not exclusive to the object oriented C++ programming language and may be used in many languages with similar or dissimilar meaning.
I would, for your own benefit while trying to learn this new language and instruction set, try to put your C++ knowledge to one side and focus on understanding how this language works, as is, without constantly trying to understand why it does not seem to do what you would expect it to do in the C++ world. That's not easy, I know, but do try.
Regards,
George