Coding is responsible for the clean water we drink, the telephone calls we make, the TV shows we watch and more. It has a big influence in our lives whether we know it or not, and poorly developed code can not only cause great frustration but it can also be very costly, even dangerous!
This is why we want to point out how if you’re a programmer you can improve in your coding, and if you’re a manager or user you can ask the right questions of your programmer and better understand the coding process.
This is probably the most common type of programming in automation. Ladder logic is great for those with an electrical background because it looks like a relay logic circuit. Fault finding with ladder logic is often easier than other methods because you can see each condition in the rung and quickly identify what is preventing your desired outcome. Ladder logic is great for single dimensioned outcomes (e.g. on/off), but it can get quite complex for repeated or multi-conditional outcomes (e.g. looping functions)
Function block is used widely in the HVAC (air conditioning) industry and is based on blocks that have pre-defined code inside to perform a specific function like a timer or a comparator. Function block code is programmed by linking the input and output signals of various blocks together and is great for those with an electronic background because it graphically looks like logic gates. Function block code is generally more suited for programmers who are process based in thought and familiar with P&ID (Piping & Instrumentation Drawing) formats.
Structured text is very popular in the computer sciences and is highly favoured by those with computer based backgrounds like web or app developers. As the name suggests, structured text is a text based code and is great for complex maths and repeating conditional functions. What would generally take dozens of lines in ladder logic to complete these types of functions can easily be completed in structured text with only a few lines of code.
I am often surprised how a program can develop into a complex tapestry of code, what I end up with is nothing like what I started out with. The best way to begin is to lay the foundations by starting with the basics first and then go back to add all of the bells and whistles into the program later, think of it like programming in layers.
Start by setting up the basics. In PLC programming I set up the controller and add all of the modules first. I then give each input and output a description (which is great when it comes time to use it in your code to check that you have grabbed the right one!) then add the basic control code into the subroutines for each device. Once the basics are in, I then go back and start adding the specific functionality, building on that original base code. Remember that you will have many balls to juggle and many angles to think about while you’re programming. Have a systematic approach to your programming and do one thing at a time, get that section right before moving on to the next.
Keeping notes on what you have to do and where you need to come back to will help free your mind to concentrate on your task at hand. As you are programming you will have many ideas and thoughts popping into your head to do with your code, list them on a piece of paper that you can refer back to so you won't forget.
Quite often the piece of code you are currently writing will rely on another bit of code that you haven't developed yet. In these situations so I don't forget and to get it off my mind, I put a line in the area where the yet developed code will go and add some brief comments. I then place some sort of "error" in the line of code like an un-tagged variable so the program will not compile properly, this allows me to keep programming the bit of code I am currently working on, and later on if I forget, the program compile error will remind me that I need to go back and finish that section of code.
Just like the assignment that was started the night before it was due, your program will never reach its true potential if you rush your code. When you give yourself time to clearly go through your logic and review your code you will be able to identify silly mistakes, programming loop holes, and greatly improve your code.
There will be times that a problem will have you stumped, you would have worked on it for hours with no success and frustration could be setting in. Stop and take a break, you will be surprised how many ideas that will come to you when you’re not even thinking about programming. Quite often I have had a great idea or a solution to a problem while I was sleeping or doing a mundane task. I once was working on a problematic section of code late one night for several hours with no success, but the next morning with a clear head I had it solved in 20 minutes! The answer was simple but I couldn’t see it with a weary mind.
Keep your code as simple as possible, it makes it easier to follow, easier to fault find, and easier to modify in the future. Overly complex code is generally fraught with loop holes and unforeseen errors due to its complexity. You won’t look like a clever programmer because your code is complex or large, in fact it takes a smarter programmer to develop code that is both functional and simple.
Why do something in one line of code which takes a rocket scientist's degree to work out, when you could have broken it down into 2 or 3 simpler lines with the same functionality and make it much easier to follow? There will come a point in time when you will look back at your code and have no idea what the hell you were thinking, and you won't even be able to follow your own work!
Reusable code is the holy grail of programming. When you create a reusable piece of code that serves a specific purpose or function, you can then place that code throughout your program many times without the need to re-write it every time.
Well tested reusable code gives you the advantages of;
In PLC programming, there are several ways you can achieve this;
There are times that you would use one over the other. A function block or separate routine is easily updated or changed in one spot and the changes are globally applied throughout your program, whereas specifically pasting the code into various sections of your program means that you can tailor each section as necessary, but for a global change you would have to go to each section and make the same change multiple times.
In any program, consistency in your code is absolutely crucial. Regardless of any inefficiencies or errors in your code, you should always be consistent. There is nothing worse than trying to work with a program that was started one way and ended in a different way. A program that is consistent is easier to navigate which automatically means that it is easier to fault find, modify and integrate with for third parties.
Key areas in programming where consistency is required are;
Standardise on a naming convention for your code, and by that I mean all the tags, variables, routines and functions that will make up your program. Quite often in a process control program we will prefix the tag or variable with the P&ID number for quick reference, for example MO701_ALM_FTST for Motor 701 failed to start alarm.
When you have several thousand variables in your code to navigate, a standardised naming convention will save you time in searching and improve your accuracy in programming.
Keeping variables and conditions in the same position between similar lines of code throughout your program will make navigation easier and quicker, particularly when you are fault finding or diagnosing an issue.
In our case one of the lines of code in our motor control routines are the motor ready status, shown in the Ladder Logic picture above. All of the conditions in this line need to be true before a flag is raised to say this particular motor is ready. No matter what motor in our code you go to, the position of these conditions always remains the same.
Similar to line structure, functional structure is keeping your code in the order of processing. If you were to program a recipe to bake a cake, the first step would be to add the ingredients, the second step would mix the batter and pour it into a tin, and finally the third step would bake the cake in the oven. Your program for the cake shouldn’t have the baking function before the ingredients function.
Keeping your functional structure in the order of processing will make programming easier and help your code run more efficiently.
If I had to choose which of these items is the most important, it would have to be error and fault handling in your program. Errors and faults will happen within any program and careful consideration is needed to both limit and handle them.
Errors and faults can come in various forms;
This is where your knowledge of the process will be an advantage, allowing you to identify possible situations or faults within the process that will need handling. For example, what happens if that pump stops working while that valve is open?
Generally a well written functional description will list most of the faults that will need handling, but you will find there are a few extras that will need to be taken care of within your code.
Never assume that an operator or user will enter data into your program in the correct format or range. Always have checks in place to validate the data entered by the user. Is it valid? Is it within the limits?
To prevent accidental triggers by a user, consider having a double action for major events that require 2 deliberate triggers by the user before the desired outcome. An example of this would be shutting a plant down, the operator could click on a shutdown button which then pops up a confirmation window “Are you sure you want to shut down the plant?”
In certain situations a program can run into a problem, and without error handling that problem could crash the program. One of the most common errors I see in PLC code are counters with variables that have no limits, and eventually the variable’s value is exceeded and the PLC goes into program fault.
An example of this is a motor start counter in a PLC. Every time the motor starts, a counter adds 1 to an accumulated total. An unsigned 16 bit integer has a limit of 65,535. If that motor was to start for a 65,536th time, the integer variable in the counter would be exceeded and possibly fault out the PLC (I say possible because it does depend on how the program fault handling has been set up in the PLC). An easy fix would be to add one more line under the counter that resets this value if it gets to 65,535, thus avoiding a program fault one day.
I cannot stress enough how important it is to comment your code, there is no such thing as over-commenting! Comments are a great way to explain what your code is doing and any thoughts you had at the time of writing that code. The comments might explain why that piece of code is there, or why the code is performing the function that it is. Code comments help anyone else who navigates through your program to understand your thought process, and trust me, you will be grateful one day that you took the time to comment your code because in the future they will help you understand your own thought process!
It is extremely frustrating to work with a program that has no comments. You don’t have to comment every single line of your code, but at least the beginning of major sections within your program. Don’t fall for the trap of telling yourself “No need to add comments, I’ll remember this”
It may seem obvious but once you have finished your program, thoroughly test your code. I say thoroughly because testing can be boring and I know some programmers who do not put enough time into this phase of the code development.
Code testing not only proves the functionality of your program but also identifies errors within your code. I generally find that most errors are the copy and paste type where I forgot to change the pasted values, and the code was using the wrong data. A dumb mistake but one that is easily identified with proper and thorough testing.
Your testing should incorporate the following;
There will be times that your code will be executing too fast to catch exactly where a fault within the code is happening. A great solution is to use temporary break points in your code so you can “pause” the code execution, or move key values within your code into temporary variables so you can see what was happening at each stage. Be sure though to prefix your temporary variables with something like “Test” or “Temp” so you can easily go back at the end of testing and remove them.
Residual and redundant code not only bogs down your program and ties up valuable memory, but it can also make it more difficult and confusing to navigate. As your program changes, be sure to remove redundant code and variables that no longer have a use within your program.
Your program will go through many changes and alterations, not only as it is developed but also throughout its functional life, and it is crucial that you keep track of the various versions your program goes through.
Program version control is the tracking of changes to your program over time. Added features or changes to your program are commissioned under a new version, with the old version left un-touched. Version control makes it easier to identify bugs in a specific release and allows you to quickly roll back to the last known working version while the buggy version is further developed. Where the program is used on multiple sites, you can easily keep track of where each site is up to and what version it is running.
The simple method of version control is a version prefix to the file name and just a few comments at the beginning of your code identifying the version and changes from the last one, but this is reliant on the programmer being diligent enough to keep the notes updated. Alternatively, there are dedicated software packages out there that can manage version control for you and keep a detailed log of the different versions of your program and who made what changes when.
Whatever works for you, make sure you keep track of your program versions, and back them up!
So take this knowledge and make your next program better than your last.
Published By: Automated Electrics
Written By: Chris Orban