PLC & HMI Tag Naming Tips
The Impact On Rapid Code Generation
A Tag Naming Best Practice Suggestion
For those PLC’s (programmable logic controllers or Programmable Automation Controllers) that allow the user to name each variable, I would like to suggest that as a best practice, PascalCase variable naming together with a hierarchical tag format in the form of AreaSectionEquipmentFunction be used primarily when naming variables.
So for example CheeseBelt1MotorStartPB, CheeseBelt1MotorRunCmd, CheeseBelt1MotorRunning, CheeseBelt1MotorFault, and perhaps there are 20 or 100 more CheeseBelt1.. type tags. Here “Cheese” is the Area, Belt1 is the Section or Equipment, Motor is also a piece of Equipment (that is part of Belt1), and RunCmd is the Function.
This hierarchical form of tag naming can sometimes eliminate the need to add descriptors to the tag as the tag name is ideally self-explanatory. This is especially true on smaller projects. For larger projects the tags can get long and so abbreviations are often used for common names. For example in an actual application the word for Cheese might be abbreviated “Chee” or even “C”. In this case it might be helpful to add the word cheese to either the tag descriptor or put a list of abbreviations in a rung comment at the beginning of the program.
This hierarchical form allows for rapid code generation if say there are 2 or more Belts with the same or similar functionality. Once the code for one Belt has been developed the code for Belt 2 is just a copy and paste of belt 1 with a search and replace of Belt1 for Belt2. From there, Belt1 and Belt2 can be copied and pasted to make Belt3 and Belt4. If there is a need for say 20 belts, then Belt1 through Belt9 would be copied and pasted and the word “Belt” would be searched and replaced with “Belt1” to get Belt11 – Belt19. The more of one object that needs to be made the more efficient generating the code becomes.
This hierarchical form also allows all the variables for a particular piece of equipment to be seen by just doing an alphabetic sort of the tags. No more hunting around to find all the variables. Because the variables can be quickly replicated using copy, paste, and replace techniques, the tag names can stay perfectly organized. Also if an orphan tag is generated such as CheezeBlt4…. instead of CheeseBelt4…. typos or deviations in naming become more readily apparent when browsing the tag list.
Notes on Tag Naming Standardization
I have come to prefer using the word “Run” or “Stop” to indicate a command and words ending in “ing” like “Running” or “ed” like “Stopped” to indicate status based on a PLC input. Here I used RunCmd to further clarify that this is intended to drive a PLC output. For pushbuttons from any source including HMIs, I use the PB suffix such as StartPB, StopPB, or JogPB. For toggles or switch inputs that are maintained, the suffixes vary somewhat but generally SW is used for ModeAutoSW or ModeManSW as functions. (The actual mode would have the suffix of ModeAuto or ModeMan appended to the “base tag”).
Additionally most all tag names are chosen so that when the tag statement is true the tag is on or a “1” value in the PLC. For example the RunCmd is on when the bit is a “1”, the same for “Running” or “Fault”. The only exception might be the input for a Stop pushbutton (StopPB) as these are wired normally closed at the input of the PLC to be fail safe. So a “0” value when the physical Stop push button is pressed will stop the device. Often I/O are mapped to intermediate tags and in these cases the input is inverted again as it is brought into the logic so that the StopPB again will turn to a “1” when the device is to stop. Analysis shows that this can be done without losing any fail safety, though it often isn’t immediately obvious for programmers new to this idea.
There can be many more rules applied on any particular project but the above two (2) points have been common for most all my projects where I got to decide. For larger projects it is not uncommon to start and maintain a tag dictionary for how names are constructed, a list of abbreviations and the meaning of abbreviations. This is especially useful when 2 or more people are writing code, but can be useful for even one engineer that might need to take a break from the program.
Tagging Using Structured Tags
For PLC’s that support structured tags (also called user defined tags) the tags in the above example could also be structured as CheeseBelt1.Motor.RunCmd, CheeseBelt1.Motor.Running, CheeseBelt1.Motor.Fault, etc. With structured tags there may only be one tag that encapsulates all the elemental tags associated with Belt1. Therefore making a Belt2 tag is just a matter of making another instance of the structured tag that was used for Belt1. When an element needs to be be added for Belt1 through Belt5 for example, then only the definition of the structure needs to be changed for all 5 belts to get the new elemental tag.
Structured Tag use in User Defined Instructions
Structured tags are even more powerful when they are combined with User Defined Instructions (Called AOI’s by Rockwell, DFBs by Schneider, and Blocks such as FCs by Siemens). A CheeseBelt1 control could be contained in a single User Defined Instruction with just one structured variable called CheeseBelt1. Making additional CheeseBelts would require just inserting a single instruction block and assigning a single structured tag for each additional belt.
This can greatly improve program development time and program maintainability.
The primary caution to using structured tags or user defined instructions/blocks is that they are not always editable when online with a running processor. So choosing which of the above methods to use is often influenced by what kind of changes might be needed in the field to the running machine.
Another caution is that if there is a lot of debug or maintenance required, the process can be more tedious if you only have a few instances of the instruction in the program.
When Not To Use Hierarchical Formatted Tags
There are times however when it seems prudent to deviate from the hierarchical AreaSectionEquipmentFunction approach. An example of this is when there is a need to write code that needs to index through an array. In this case the variables may be defined as array elements. However depending on the manipulation that is needed, the array elements may be structured tags. This will allow for some level of clarity in the meaning of the tags.
Array tags generally require additional documentation to clarify the meaning of each tag element so array tag use should be limited only if special manipulation is needed that requires an index to search or loop through the array.
I am looking for a time when PLC software will allow some kind of enumeration capabilities in the named tags, so that arrays with numeric index numbers can be eliminated, but as of this writing I am not aware that this kind of functionality is available from any of the major PLC manufacturers.
Created: 04/16/2014 6:14pm CST; Edited 04/21/2014 3:44pm CST:
for Publishing on 04/21/2014 at 7:55 am CST