PLC programming: 5

mistakes to avoid
Stick with your architecture and remember to reuse your code
Daniel Fenton
01/15/2014
Every PLC programmer will make a
mistake when he or she is writing code.
Whether its the result of pressure by the
customer, lack of coffee in the morning, or
simply getting distracted at the wrong
time, here are the top five mistakes to
avoid.
1. Not sticking to an organized architecture
When a program is first laid out, all of the code for each portion should fall into neat,
orderly sections. Keeping each part of the code separate allows the person working with the
program to easily visualize the overall execution of the program.
It also helps to debug the program if something goes wrong, since each piece of code is
encapsulated into its own structure. Finally, it looks better, because there isnt the mess of
an entire program on the screen at one time.
Unfortunately, as the developer and post-deployment maintainers work on the code,
sometimes the code begins to creep out of each section, and intertwine with the supposedly
isolated functions around it. This leads to confusion as tags hop from one sheet to the next,
or outputs are written twice during execution.
It also leads to disorganized code. Finally, this can be dangerous, as minor tweaks across
the board cause little program issues to build up until something breaks. Maintaining code
organization and encapsulation is critical to the longevity of a PLC program.
2. Not documenting the code
Documenting code as it is written and, further, as it is maintained is critical to keeping a
PLC and its program operational during the long periods of time between updates and
adjustments. A quick few sentences on each major portion can save a lot of time and
headaches later on. It can also help the programmer put his or her thoughts on paper, which
can be helpful in figuring out the next step.
Even though the code may make sense at the moment it is programmed, the five minutes
spent explaining thoroughly why a particular technique was used can save hours when,

months later, a user must decipher what is going on. All too often, code originally installed
in a system will change due to fixes, updates, and feature additions. If the documentation is
not updated with the code, this can lead to confusion and misinterpreted programming.
3. Creating redundant tags and variables
As logic statements and ladder rungs are written out, often a program can have multiple
branches of logic that eventually lead to a tag that functions as a sort of flag. This flag
will usually wind up activating other pieces of logic in the program. Sometimes, these
pieces of logic are mutually exclusive, such as a Boolean variable, which requires the
program to send a message to one remote station or another, depending on the status of
certain inputs.
The IEC 61131 Structured Text statements IF and ELSE are purpose-built for this exact
logic, so that only one tag needs to be tested. If the tag is true, one set of code is executed.
If the tag is false, another set of logic is executed.
If a programmer is not paying attention, he or she can be put in the situation of creating a
flag_1 and a flag_2, with both of these tags performing the same duty. Now, both
variables need to be tested, which leads to increased code complexity and greater memory
utilization. Not only are both of these results poor programming practice, but repetitive use
of redundant tags and variables will require that a program utilize a more powerful (and
therefore expensive) processor than otherwise required.
4. Not reusing existing code
Aside from ease of maintenance, debugging, and readability, the reason it is so important to
encapsulate and isolate code in a program is that code encapsulated inside of a function
block can be reused over and over throughout the program. This removes the requirement
to rewrite the code that already exists inside of a function block. Therefore, the programmer
can generate a standard, all-use function block that can be debugged and modified once,
and have that change reflected throughout the entire program.
Collections of these general use function blocks are called function block libraries, and
many manufacturers offer application or industry-specific function block libraries for
download on their websites. These function block libraries heavily cut down on the amount
of development time required for a given application or project.
Sometimes, without realizing it, a programmer will find him- or herself writing code thats
already been written. Where five or six of the same pieces of equipment need to operate
similarly, it is easy to create a function block that accepts the inputs of the sensors and
outputs solutions for the actuators. On the other hand, it can be more difficult on seemingly
one-off algorithms to find a reason to write generic code.
The effort needed to write a function block that is generic enough to be reused must be
balanced against the time spent for development on the project. It is worthwhile, however,
to bear in mind that a little extra time spent immediately can save a lot of time later on.

5. Not utilizing version control

Keeping your code organized is another major practice that is sometimes lost in the
commotion of trying to complete a project for commissioning. Version control systems can
be as simple as naming a project for a particular PLC once it has been deployed, or as
powerful as a dedicated application used specifically to track what the changes are in each
major revision.
The use of such versioning schemes mitigates situations where a particular fix or feature
might have gone out to the field, and the PLC has a program that may or may not have
those changes.
Programmers often forget to keep track of what changes are in the program on the PLC
without a proper versioning strategy. Documentation, a good naming scheme, and possibly
dedicated version control software can lessen these issues and increase the detail available
to the programmer.
Dedicated version control software also allows a system to track the user that made every
single change, documented or otherwise. This can be particularly useful if multiple
programmers are working on the same program.
Daniel Fenton is a product specialist with Phoenix Contact.