Technical Article

PLC Naming Conventions: How Should I Write My Tag Labels?

December 28, 2023 by Shawn Dietrich

It’s important to consider your PLC tag naming convention when using different styles. Learn when and why you might even use more than one, depending on the circumstances and scope of your project.

Documenting codes is one of the most basic, but also most under-valued concepts in PLC programming. Using poor writing styles can render even simple codes unreadable, but, if used properly, they can aid in troubleshooting very complex projects.

 

Address-Based PLC Tags

Years ago, it was universally standard for a tag in a PLC to represent an address location in the PLC’s memory, and the tag name displayed that address. For Allen-Bradley controllers such as the SLC 500 or the MicroLogix, a tag name might be N7:2.3 or B3:1.2. This type of tag address naming required spreadsheets and well-commented tags, provided you had the PLC code and didn’t need to upload it as the comments were not stored in the PLC. Comments and descriptions can include real-world properties, but the tag names themselves cannot.

 

Name-Based PLC Tags

Today with modern controllers, we often use strings or human-readable tag names. The tag still represents an address location in memory, but we don’t need to use the address as a tag name; we can instead use tags with a display name such as “MotorsON.” This symbolic naming allowed programmers to create tags with function meaning and reduced the amount of time debugging code.

Unfortunately, this benefit of easy labeling opens the door to bad habits. In this article, I’ll outline some tag naming conventions to help make your code more readable.

 

Choosing Proper Capitalization

Even before choosing the style of the language to use when naming the tags, the method by which the words are written is important for the sake of readability and clarity. Even if excellent tag names are chosen, the effort is wasted if they are difficult to read.

 

Example controller code showing capitalization cases

Figure 1. In this example code, the only spaces exist between commands and in comment text strings. The variables and commands follow the ‘Camel’ capitalization case. Image used courtesy of the Control Automation engineering team

 

Regarding Spaces in Tag Names

One initial note deals with the use of spaces. In most programming, spaces (and many punctuation marks) indicate the transition between variables and commands. If we included spaces in a tag name, the compiler would try to interpret the second part of the tag name as a command, which would be invalid. Therefore, most IDEs do not allow the use of spaces and marks in tag names at all.

 

Camel Case

A popular method for naming variables or tags is using the camel case style. This style, made popular by PC programmers (take a look at any microcontroller code), involves combining words without punctuation marks or spaces, but capitalizing the first letter of words in the middle of the phrase. For example, a variable with the function of turning on a light might be “lightOn” or “greenLightOn.” By capitalizing the first letter you can see where a new word begins without using a space. As an illustration, compare the phrases:

thisisnotcamelcasewriting

thisIsCamelCaseWriting

And it is immediately clear that, although you can likely still read the first one without too much difficulty, the second option is much easier.

 

Pascal Case

Similar to the camel case, the Pascal case is another style popularized by computer programming and web development. The difference with Pascal's case is the first letter of each word is capitalized instead of each word after the first. For example, “LightOn” or “GreenLightOn.” This style is often used in conjunction with the camel case to differentiate between different scope variables.

 

Snake Case

This style uses an underscore to separate words while still pertaining to syntax restrictions of no spaces. Snake case is normally used with capitalizing every letter of each word, or it can be combined with camel or Pascal case. For example, “MOTORS_ON” or “Motors_On.”

While this style does separate the words, it elongates the tag names, which might lead to truncation in spreadsheets and the main ladder logic view.

 

Choose Your Style

Everybody has a different way of programming PLCs. Some of you will be bound to code standards and SOPs, while others have free will to program how they want. Whether you are developing a standard or if you just want to be able to understand your code faster, using a combination of different styles may help you out.

Camel and Pascal cases are the most popular naming styles used in computer programming, so it makes sense to adopt this convention into PLC programming. In a PLC, you have global and program-scoped tags, but you can name your tags in different ways so that you will know just by looking at the tag where it is accessible.

In most of my own projects, I like to use the Pascal case for global scope tags, the camel case for local tags, and for Ethernet modules, I prefer to use the snake case. By combining these three styles, I can know the scope of a tag at a glance just by recognizing the style.

 

PLC program with global and program scope tags

Figure 2. PLC project scopes can determine how and where to use various capitalization cases, such as snake case for global tags and Pascal case for the Ethernet module. Image used courtesy of the Control Automation engineering team

 

Choose Your Words Wisely

Your tag name is just as important as your style convention, you want to make sure the tag name isn’t too long, but you have also shown what the function of the tag is. For example: “Upper_Conveyor_Motor_On” is a very long tag name and will likely get truncated when used in the logic. The same tag name can be shortened to “UpConv_ON” or “upConvOn,” resulting in a much shorter tag name that still gets the point across.

Many PLC IDEs will have a maximum number of characters permitted for a tag name, and will automatically truncate or use multi-line display when the tag is used in the logic, making those long tag names very hard to read. Incorporating the wire number or a reference to the electrical prints in your tag name is a great way to reduce troubleshooting.

Typically there will be a remote I/O device, and I like to name it similarly to the electrical prints. This way, if someone searches the “upConvOn” tag, they will see that it is copied into the 123RIO device tags which can be found on page 123 of the electrical drawings. The figure below illustrates this concept with the electrical drawing on the left compared to the tag names in the logic on the right.

 

Comparison of electrical prints and PLC logic

Figure 3. Comparison of electrical drawing device names and PLC logic device names. Image used courtesy of the author

 

Short Form Naming

Some devices might have a long name like “conveyor” and will take up many characters within your tag name. To keep the tag name short try using short form or abbreviations for known devices. For example, “conveyor” can be “conv,” “double” can be “dbl,” and “push button” can be “pb” or “btn.” If your short form doesn’t make much sense, you can always add a comment to the tag. In modern processors, the tag and rung comments are stored in the PLC.

 

You Chose… Poorly

A common example of poor tag naming is using underscores and capital letters, such as “CELL1_HMI_PUSHBUTTON” or “SERVOMOVEHOMEPUSHBUTTON.” Creating tag names this way makes them very difficult to read and when other people need to work with your code they might find it stressful and difficult to troubleshoot. Using all caps should be avoided or only used for tags that are not used often in your code, such as naming Ethernet modules or I/O cards on the PLC backplane. The tags created by Ethernet modules or I/O cards are often copied to other tags with different styles.

 

Developing A Convention

Once you have decided how you will use the different naming styles in your project, stick with them throughout your code. Try not to switch conventions within the same project as this will confuse other people (or even yourself). The purpose of developing a naming convention is to reduce confusion and troubleshooting time, so obviously, you should try to develop something easy to understand.

As with all code standards, try to keep your style simple only use a couple of naming styles at most. Be sure to document your plan, this way, when people ask for training or an explanation, you will already have the information ready.

 

Featured image used courtesy of Adobe Stock

1 Comment
  • H
    Hugo January 05, 2024

    Hm, interesting timing. I’m just about to release a white paper on PLC tag-naming. Mine is a bit more opinionated and prescriptive - likely due to my advanced age (or different experiences).

    Like. Reply