Say Goodbye to Confusing PLC Logic with Variable Naming 2.0

Today I am going to share with you my preferred method of naming variables when programming PLC applications.  If you incorporate these simple techniques in your own programming, you can easily save hours on troubleshooting tasks, and your logic will be so much easier to read and to understand.

Let's start with an example to clarify my point of this post.

Let's assume we get a request from a customer to add 2 counters to their application that can count up to a 100.000 (one hundred thousand) using 2 separate triggers.  So we create the following ladder logic:

If Trigger_1 is active, we count up Counter_1, and if Trigger_2 is active, we count up Counter_2.  Beautiful in it's simplicity...

Now let me ask you this.  Which datatypes did I use for my counter variables?   There is no way of telling from this screenshot alone, right?  

What if I told you that I created Counter_1 - by mistake - as an Integer, and Counter_2 as a double integer.  Wouldn't you agree that Counter_1 will have a problem counting to 100.000? (range of integer datatype = -32768 -> +32767).  So my mistake (creating Counter_1 as an integer) would probably go unnoticed here and could lead to logic that would simply not work = 1 unhappy customer.

Now have a look at the screenshot below.  Same example, but with slightly adjusted variable names for my counters. 

Wouldn't you agree that it is intuitively clear that iCounter_1 is an integer, and diCounter_2 is a double integer?  By just adding a lowercase "i" (integer) as a prefix in front of the Counter_1 name, and a lowercase "di" (double integer) as a prefix in front of the Counter_2 name, troubleshooting these networks becomes exponentially easier.  

And that's what today's post is all about - improving the readability/clarity of your variables by adding data type prefixes in front of your variable names.

Let's get this out of the way first - I DID NOT INVENT THIS NAMING CONVENTION.  I wish I did, but I didn't so I cannot take any credit for this.  What I CAN take credit for is applying these naming conventions to all variables in my applications and by doing so delivering a more clear and easier-to-troubleshoot application for my clients.

This naming convention is based on the Hungarian notation, and goes as follows:

• Write the first letter of each word in uppercase, the remaining letters in lowercase 
• In front of the base name, append a prefix in lowercase to indicate the data type of the variable
   

More information you can find RIGHT HERE (look under the section Recommendations for variable names).

Here are some examples of datatype prefixed applied to variables with basic datatypes:

I would recommend you start applying these prefixes to your variables TODAY.  You'll get the hang of it in no-time, and after doing this for a while, it will feel like second nature - easy and effortlessly.

So let's look at some more examples.  Let's take a function block in Siemens for example.
The screenshot below is taken from a function block of the sample of application of my TIA Portal - PLC Programming Basics course.

The screenshot shows the block interface of the function block and is divided into 5 parts:

• Input
• Output
• InOut
• Static
• Temp

All tags in the input area of the block interface start with the prefix 'i_'.  This makes it immediately clear inside the logic of the function block, that this variable is an input.  The same goes for the output area, where 'q_' is used as a prefix, and the InOut area where 'iq_' is used as a prefix.  Are you following me on this one...?

For the static area (=retained variables), I am using the standard lowercase datatype prefix, and for the temp area, I am using the underscore prefix '_' to indicate in my logic that these variables are temporary (=non-retained) variables.

So let's have a look how all of this looks in actual logic.

In these networks 2 and 3, we are starting a pump and opening a valve.
In network 2 for example, it is clear as rain that:

• #iq_stStateHandler.State.xRunning is an InOut variable
• #i_xValve_Open is an Input variable
• #q_xStart_Pump is an Output variable
• #_xCmd_StartPump is a temporary variable

Wouldn't you agree that reading the logic becomes much more clear by using these data types prefixes in front of the variable names?  

Would you go back to your normal way of writing tags like "COUNTER", "VALVE_OPEN", "STATE_RUNNING", if you knew that there's a more elegant way of doing things...? 

So there you have it. 

I hope you enjoyed reading this post, and I hope you see the immediate advantages to use these naming conventions into your own programming.  Personally, I learned about these conventions some odd 10 years ago, and I never looked back.  My applications have become more clear, easier to read and understand, easier to troubleshoot, and easier to handover to other programmers.

Go give it a try and make your applications shine like never before!

-Hans