Tag Structures and Dotfields

Today’s post is in response to an e-mail I received asking for my thoughts on Tag Structure. In part, George Steel wrote:

Great site, thanks for all your efforts. I am working on positioning my org to move from RS500 to RS5000 and from RSView to FT SE sometime in the future before our next upgrade shuts us down. Our PLC5s and SLCs have few symbols so I am working on an integrated tag structure.

Any thoughts on a structure? ISA works for some but leaves a lot of non-instrument based logic hanging.

I am focusing on a Location/Equipment/Function structure: R0300_P21_Suc_PT.EU_Max. = Primary/PS2 Pump1/Suction Pressure Transmitter.Engineering Units Max (for analog scaling).

The dot suffix is generated by AOIs (another part of my project under development). I’d like to see you address preferred tag structure in an article sometime.

When I first read the e-mail, I thought I had already written a post on this subject, but I went back and looked and I had really only discussed wire labeling and UDTs. While these do relate to tag structure and naming conventions, I can definitely cover this in more depth here.

First, for those of you unfamiliar with Allen-Bradley products and what George is doing, he is converting programs written for SLCs and PLC5s (older, register-based platforms) into ControlLogix programs written with RSLogix 5000. The ControlLogix platform is tag based, there are no registers that you can see, just a big database full of text addresses for each data value. In the image at the top of this screen, the clip in the upper right is from a SLC500, it shows the Symbol and Description for an N7 (signed integer) register. While the address can be typed into the program either as N7:40 or TOT_060_FT52, only the address of N7:40 is present in the PLC processor. The symbol is kind of a “short cut” or mnemonic to make it easier to find and organize things.

RSLogix 5000 has a utility that converts SLC or PLC programs into ControlLogix programs. It uses the symbol as the new tag name if a symbol is used, otherwise it converts to a name like “N7_40” which isn’t very descriptive at all. A few limitations: SLC symbols can be only 20 characters in length, whereas ControlLogix tags can contain 40 alphanumeric characters, not counting the dotfield. Since the SLC is register based, it has no dotfields outside of those built into the data type, such as the preset for a timer (T4:58.PRE, or TDL_010_GS01.PRE as a symbol).

So what is a dotfield? It is just the part of the tag after the period or dot. As George mentioned in his email, an AOI or Add On Instruction uses dotfields as part of it’s data definition, as does a UDT. The clip to the left side in the image above shows a UDT called “CakeRecipe” which I used to create the elements Flavor, LbsFlour etc. in the tag ModRecipe. This tag list is part of the advanced course I talked about a few weeks ago.

So these are a few of the constraints that will need to be followed when converting the programs; tag lengths will all be 20 characters or less (though they can be modified easily in Logix5000) and they won’t use UDTs unless you build new ones. Same thing with the AOIs. And some AOIs may have to be built anyway since several instructions such as SCP (Scale w/ Parameters and DCD (Decode) are not present in the ControlLogix.

As far as naming conventions, I have used a lot of different ones in the past depending on the industry and who the customer was. Process industries tend to like ISA definitions and P&ID designators, so some four digit numerical designators like “8454” and standard definitions like “PIT, EU, PSHH” will be used. I wrote a post back in 2012 called “What’s in a Name?” where I talked about some of the standard names that are used in the custom machinery industry. Because that’s been most of my background, I tend to use an “Assembly-Device-Action” description as shown in some of the tags in the above lists in the image; an example might be “LocCylAdvPX” for Locator Cylinder Advanced Proximity Switch.

It is nearly impossible to make a tag descriptive enough so that someone not familiar with the machine or process will understand it. Cylinder and Advance might be fairly straightforward, but Loc for Locator? Most people wouldn’t know what a locator is unless they were familiar with the machinery.

I am not a huge fan of numerical designators unless the number is printed on the machine or system somewhere. I know this is common it the process industry since everyone is used to using P&IDs, but in a manufacturing environment there can be high turnover and things move at a rapid pace. The easier you can make it for new technicians the better; ideally someone should be able to find a device without using an intermediate piece of paper. Tagnames are long enough now that it should be possible.

The symbol I used from the SLC above was TOT_060_FT52. TOT is an abbreviation for Totalizer, so far so good. The 060 is area 60 in the ABD bottling plant I have mentioned before. Until I had been there for a while I didn’t know that area 60 was the Syrup tanks, but it is labeled fairly clearly in SCADA, so I would have figured it out quicker if I had worked there full time. FT52 is Flow Transmitter 52, and this doesn’t give me a clue where in the maze of pipes the transmitter is. In my opinion an abbreviation like Syr for Syrup and TQ2 for Tank 2 would have made it easier, but the system was put in by Sidel who follows P&IDs fairly closely. Unfortunately they didn’t provide the P&IDs to the customer.

Bottom line, as long as the abbreviations are consistent and explained somewhere in the documentation I have been able to navigate most of the programs I have had to deal with. I am usually either the writer of the program, in which case I know the process well, or new to the program if I am modifying or consulting, in which case I need the documentation to be clear. Time is money, and if it takes me lots of digging or extra steps to figure out what and where things are neither myself or the customer is very happy. Also, even if you can’t fit the full information needed in the tagname, descriptions are cheap and you can write many lines in both the tag description and in the rung comments.

If you have an opinion on this I (and George I am sure) appreciate any experiences or techniques you may have.

About Frank

Electrical Engineer and business owner from the Nashville, Tennessee area. I also play music, Chess and Go.

I like to map all of the raw I/O data into a single UDT structured to represent the physical layout, and then create an alias tag for each device named the same as what’s on the schematic to use in the logic. I also find it helpful to split up the logic into multiple functional programs and make the alias tags local.

For example the alias tag might be named simply “LS1”, defined local to the “Cylinder 1” program, with the base tag as the global “IO.Block1.Terminal1.DI1”. The base tag would have a human-readable description like “Limit Switch 1: Cylinder 1 Retracted”, which would feed through into the alias tag. I would probably also use logic to immediately map “LS1” to a local tag in “Cylinder 1” called “Retracted”.

The alias tags allow for short field names in the logic that are much easier to read and remember, and they reduce global variables and dependencies between programs. By only referencing local aliases to I/O within a program, you can see at a glance what physical dependencies that program has and easily remap them if necessary (if an input channel malfunctions for example). The tag “Retracted” here makes the logic more readable and easier to adapt to different applications that might detect the position of Cylinder 1 differently (NC vs NO, multiple limits, analog position, different hydraulics, etc).

These multiple mappings can be somewhat confusing but they give the user several different ways to identify the device in question, which is useful since you never know what information the person troubleshooting the equipment has access to. It also makes naming conventions somewhat less critical since there’s less opportunity for confusion with more information available.

I think it’s important that each tag name be self-contained though. If you need both an electrical schematic and a hydraulic schematic to interpret the name of the tag, there’s something wrong. Worse if you need some specialized knowledge about the machine or process as well. I agree with the article that the less external information needed, the better.

The UDT structure probably needs to vary somewhat by application, but the idea of flowing from general to specific seems pretty universal. By using a single UDT for all of the IO, it’s obvious (with the “show alias information option” selected) that “LS1” references a physical device rather than a logic state, and you end up with a large tree structure called “IO” that’s pretty easy to navigate. You can also perform a cross-reference on “IO” and find every physical device reference at once, which I find useful.

The downside is that you can’t alter the UDT structure online, so it’s important to base it on something that isn’t likely to change often. I imagine there are some applications that require more flexibility than this method allows. I suppose you can accomplish basically the same thing without using UDTs though, with the right naming conventions.

4 Comments on “Tag Structures and Dotfields”

Eric says:

September 19, 2016 at 5:21 pm

I like to map all of the raw I/O data into a single UDT structured to represent the physical layout, and then create an alias tag for each device named the same as what’s on the schematic to use in the logic. I also find it helpful to split up the logic into multiple functional programs and make the alias tags local.

For example the alias tag might be named simply “LS1”, defined local to the “Cylinder 1” program, with the base tag as the global “IO.Block1.Terminal1.DI1”. The base tag would have a human-readable description like “Limit Switch 1: Cylinder 1 Retracted”, which would feed through into the alias tag. I would probably also use logic to immediately map “LS1” to a local tag in “Cylinder 1” called “Retracted”.

The alias tags allow for short field names in the logic that are much easier to read and remember, and they reduce global variables and dependencies between programs. By only referencing local aliases to I/O within a program, you can see at a glance what physical dependencies that program has and easily remap them if necessary (if an input channel malfunctions for example). The tag “Retracted” here makes the logic more readable and easier to adapt to different applications that might detect the position of Cylinder 1 differently (NC vs NO, multiple limits, analog position, different hydraulics, etc).

These multiple mappings can be somewhat confusing but they give the user several different ways to identify the device in question, which is useful since you never know what information the person troubleshooting the equipment has access to. It also makes naming conventions somewhat less critical since there’s less opportunity for confusion with more information available.

I think it’s important that each tag name be self-contained though. If you need both an electrical schematic and a hydraulic schematic to interpret the name of the tag, there’s something wrong. Worse if you need some specialized knowledge about the machine or process as well. I agree with the article that the less external information needed, the better.

The UDT structure probably needs to vary somewhat by application, but the idea of flowing from general to specific seems pretty universal. By using a single UDT for all of the IO, it’s obvious (with the “show alias information option” selected) that “LS1” references a physical device rather than a logic state, and you end up with a large tree structure called “IO” that’s pretty easy to navigate. You can also perform a cross-reference on “IO” and find every physical device reference at once, which I find useful.

The downside is that you can’t alter the UDT structure online, so it’s important to base it on something that isn’t likely to change often. I imagine there are some applications that require more flexibility than this method allows. I suppose you can accomplish basically the same thing without using UDTs though, with the right naming conventions.
- Frank says:
  
  September 22, 2016 at 9:05 am
  
  Excellent! My thoughts exactly on readability. The only problem occurs on platforms that don’t have UDTs and use symbols rather than tags, but even there, comments go a long way towards readability.
  - Eric says:
    
    September 26, 2016 at 4:48 pm
    
    I agree that comments are critical. I try to be very careful about how I phrase them, making sure to use capitalization and punctuation meaningfully, and trying to avoid ambiguous terms like “back” for example in favor of “retract” or “retracted” as appropriate. Of course “retracted” still has some ambiguity, but at least it’s obviously a position rather than a command, whereas “back” could be either.
    
    Organization is certainly harder on a platform like the Micrologix, but you can still improve readability through multiple mappings (or abstractions). I also try to group addresses by functionality, in 16-bit blocks, and label the integers as well as the bits.
    
    Then I use prefixes like “POS”, “INT”, “REQ”, “CMD”, “LS”, “PB”, “SOL”, etc in the symbol names, making sure nearly everything in the logic has an associated symbol. Even if it’s not immediately obvious to the user what those mean, he’ll figure it out quickly from the comments, or the other similar symbols and grouped memory addresses. After that, consistency goes a long way.
    
    Separating the logic by functionality is still important here too, as it adds context to everything. From the example in the article, if you already know you’re looking at a position mapping in the Locator Cylinder logic, it’s much more obvious what the symbol “LocCylAdvPX” means. It’s also still pretty obvious if I change it to “LCFwdPS”, or “PX_LCAdv”.
George Steel says:

October 16, 2019 at 10:28 am

Nice to see you pick up this thread again with your recent CE post “PLC tag and address naming conventions”.

Strange how this issue arises in so many different applications. Recently I have been updating/rewriting our inventory system and I find that standardizing the syntax of data entries is key to being logically consistent and thereby user and search friendly.

The old inventory seemed to have been entered by a different person for each item (6000+). I have found the same problems as in PLC programs and SCADA apps. Oh for a master template worshiped by all.

Next time Frank just post the Master Template and say QED.