What's up with "tags"?

I am not arguing just for sake of arguing and there is nothing personal in my arguments.
I really try to realize tag concept, all its advantages and the price I pay for them, should I decide to go LX5000.
So what's wrong with supporting your opinion with reasonable arguments?
 
Actually, can anybody provide a link to formal definition of the tag?
All the AB documentation I've seen assumes this already known by the reader.
However, there are some uncler details.
As far as I understand, the main conceptual difference between tag and name (aka symbol) is that tag does not have physical allocation, which allocation is up to the controller OS.
Is this correct?
Are there any other conceptual differences?
 
Last edited:
Page 61 of 1756-QS001D-EN-P.pdf

"Tag – store data. There is no fixed data table or
numeric format for data addresses. The tag name is the address. You create the tags that you want to use."


A symbol in RS500 is more like an alias in RS5000 then a tag. A symbol still needs a memory address to which it is assigned, it means nothing on its own. As stated a tag is the memory address, which has meaning. An alias is typically created to denote a specific IO address, it basically maps a character string to the physical address.

As mentioned once you create user defined tags in RS5000, you can create numerous custom tags just by defining a single tag as type "udt" instead of bool, int, dint....
 
Last edited:
One of the side effects of legacy addressing is that we tend to think of memory addresses as devices, ie, timers, coils, etc, instead of what it really is, an address to a spot in contiguous memory and elements such as coils and timers are arbitrary and artificial. Memory itself is not divided or configured - elements are overlays provided by the programming software editor that help us manage memory - and take the guess work out of it. In many PLCs you still have to remember how many words you need to reserve after a particular address when you use if for a timer. File elements remove the guess work. Tags take it one step farther.

A tag is a pointer to a location in memory. Think of it like this: You tell your friend there will be a party at Bob's house. Bob's house has an address, a location on a street in a city, but you and your friend don't know the house number of Bob's house, but both of you do know where Bob's house is, so all you need to tell your friend is that the party is at Bob's house. A tag is kind of like that. Now suppose that Bob's house is a really big house and Bob has a pool and backyard basketball court. So now its Bob's mansion and the address actually consists of more than your typical 100' lot. House and Mansion give us an idea of how large Bob's place is, likewise a tag data type tells the compiler how large a chunk of memory is involved. However, we don't have to know exactly how many acres of land Bob's Mansion occupies. In Bob's place, we can designate parts of Bob's mansion, as in Bob's pool or Bob's tennis court. So you can be more specific: there will be a Bar-B-Que at Bob's deck and swimming at Bob's pool, ie BobsMansion.Deck and BobsMansion.Pool. You and your friend still don't need to know the street address of Bob's mansion to find Bob's pool and deck.


One more note about Tags verses Symbols. Tag names are stored in the PLC because they are an integral part of the program. Symbols are an external association, and do not exist in the PLC, they are not an integral part of the program. Therefore when you upload from a ControlLogix PLC you get the tag name, and if the programmer was kind enough to use a meaningful tag name its easy to decipher the program. You get no such luxury when you upload from a PLC5 or SLC500, all you get is the address with nothing to indicate what it is.
 
Last edited:
What about indirect addressing?
How is it done with tags?
And how to scan an array of error bits, for instance (assuming ladder language)?
TagIndirect.JPG

ConveyorSpeedArray is DINT array of 100.
ConveyorNumber is DINT.
MasterConveyorSpeed is DINT.
ConveyorErrorArray is BOOL array of 100.
ConveyorError is BOOL.

This is just a generic example of indirect addressing.
Hope this helps.
 
Also, the use of tags that are descriptive of the fuctions they are involved in helps lead to self-documenting code.

An instruction with a tag named "Open_Pump1" means a lot more than an instruction with a register labelled "B3.0"

$

From a wiring/troubleshooting perspective, tags suck big time for two reasons, 1) its a pain to figure out what actual input it is wired to and 2) no one puts the tagname on the prints. The prints show a terminal # and a long description but with no matching tagname it can turn into a guessing game. Antoher example of programmers making it easy on themselves and more difficult on others.
 
From a wiring/troubleshooting perspective, tags suck big time for two reasons, 1) its a pain to figure out what actual input it is wired to and 2) no one puts the tagname on the prints. The prints show a terminal # and a long description but with no matching tagname it can turn into a guessing game. Antoher example of programmers making it easy on themselves and more difficult on others.

Tag names don't belong on prints, the PLC IO address does belong on prints as well any label given to that IO such as "V100" for a valve. If the address/label is not listed, this is the fault of the engineer not the "tag" style referencing. If the programmer was good they would use some part the label "V100" in the tag name. Such as "V100_Off", "V100_Open", "V100_Force_On".

You can always find the IO addresses in the tag database as they are automatically added into it when the IO is configured into the program. The Controllogix addressing will appear in the tag database similar to this depending on the type of IO used.

Local:0:O.Data.0
Local:0:O.Data.1
.
.
Local:0:O.Data.15

So the last address is in the local rack, slot 0, output 15. If you have a set of prints, and the program it is pretty straight forward. Heck even if you don't have a set of prints it is not that hard if the program had any structure.

A prime example of somebody not understanding the PLC/programming software.
 
Last edited:
From a wiring/troubleshooting perspective, tags suck big time for two reasons, 1) its a pain to figure out what actual input it is wired to and 2) no one puts the tagname on the prints. The prints show a terminal # and a long description but with no matching tagname it can turn into a guessing game. Antoher example of programmers making it easy on themselves and more difficult on others.

All drawings we create have tags and wire numbers (matching PLC I/O). It is much easier/faster to troubleshoot a device if it is tagged in the field, the drawings, the program, and the HMI. From an SI perspective, this is a must. This is one of the many ways we keep good relations with customers and electrical contractors.
 
One more note about Tags verses Symbols. Tag names are stored in the PLC because they are an integral part of the program. Symbols are an external association, and do not exist in the PLC, they are not an integral part of the program. Therefore when you upload from a ControlLogix PLC you get the tag name, and if the programmer was kind enough to use a meaningful tag name its easy to decipher the program. You get no such luxury when you upload from a PLC5 or SLC500, all you get is the address with nothing to indicate what it is.

This is exactly what I think of when I point to the advantages of tags over symbols.
 
Plus the tag names in the plc program can be used exactly within the HMI (wonderware). I hated tagname programming until I got into it. I would have it no other way now.
 
RE: A prime example of somebody not understanding the PLC/programming software.

I understand PLC/programming software just fine........just don't understand programmers.
 
Plus the tag names in the plc program can be used exactly within the HMI (wonderware). I hated tagname programming until I got into it. I would have it no other way now.

Ditto! In fact, I can create my HMI first, export the tags and import them into CLX, and everything's ready. No associations that WW tag Motor1_Aux = I:0.0/3. In CLX, Motor1_Aux = Motor1_Aux.

Also, I don't think the benefit of UDT (User defined types) is stressed enough. I can create a type ONE TIME for most Motors like:

FwdCommand
RevCommand
FwdStatus
RevStatus
Speed
Amps
etc.

Then I create a tag called Conveyor1 of type Motor. Now I instantly have access to:

Conveyor1.FwdCommand
Conveyor1.RevCommand
Conveyor1.FwdStatus,

etc...

Very organized, very efficient and self documenting.
 
Last edited:

Similar Topics

Hi I have a ifix 5.5 application where the operator opens a valve by clicking on a screen object. I can trace from object to data base that it is...
Replies
2
Views
49
Afternoon all, I'm working on setting up a large excel recipe table for porting updates through the Linx Gateway RTD/DDE function into my recipe...
Replies
2
Views
128
Greetings I have a problem, my system is the following: wincc v8.0 (demo), logo8.3, abb m2m analyzer. I created some pages to display the...
Replies
0
Views
91
Hi All, we've recently upgraded from FTView SE v10 to v12. Since the upgrade we've been having a problem where the HMI is slow to update tags in...
Replies
0
Views
103
Hello, I have a pair of redundant 1756-L71 controllers rev 24. These controllers currently have produced and consumed tag interfaces to 3 other...
Replies
2
Views
198
Back
Top Bottom