PLC programming: 5 mistakes to avoid

Stick with your architecture and remember to reuse your code


Every PLC programmer will make a mistake when he or she is writing code. Whether it’s 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.

Proper PLC programming is the first step in delivering a first-rate plant floor automation system. Courtesy: Phoenix

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 isn’t 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 that’s 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.

michael , NC, United States, 01/22/14 07:19 AM:

Very good information. One thing I'll say though, is even if a program is convoluted and confusing, if it's got good documentation, it usually can be deciphered. So, PLEASE document as you write logic!
MICHAEL , MS, United States, 01/22/14 05:11 PM:

I agree with Michael from NC. After working with PLCs for 30+ years, the greatest weakness in most programs I have encountered is lack of documentation; most have had little or none! I thoroughly document my programs because the person I may be helping is me - refreshing my memory 6 months or more later.
robert , , 01/23/14 08:45 PM:

We definitely need good documentation. I would add this: documentation of the reasoning behind the change (It can also help the programmer put his or her thoughts on paper) as well as the actual change that was made. Haven't we all had ideas that we thought would work or fix the problem but didn't workout the way we planned? Plus it seems we get an incite into what the process needs to do. A big Thank You to all you programmers out there!
Evan , United States, 03/06/14 09:55 AM:

When documenting, don't just state what the code is doing, i.e. multiplying x by y.
State the reasoning, exactly what you are trying to accomplish.
i.e. Multiplying user input by 133.333 to scale to correct value for output.
Rene , Non-US/Not Applicable, Mexico, 07/24/14 03:31 PM:

The article sounds good, but it would be better with some examples.I have troubles with the organized architecture. I would apreciate if someone help me with some examples about to organize projects (methodology).
RAY , MO, United States, 01/22/16 12:25 PM:

Evan has hit the nail on the head, explaining the purpose for the code can be a great starting point for the code itself.
The Top Plant program honors outstanding manufacturing facilities in North America. View the 2015 Top Plant.
The Product of the Year program recognizes products newly released in the manufacturing industries.
The Engineering Leaders Under 40 program identifies and gives recognition to young engineers who...
Prescriptive maintenance; Hannover Messe 2017 recap; Reduce welding errors
Safety standards and electrical test instruments; Product of the Year winners; Easy and safe electrical design
Safer human-robot collaboration; 2017 Maintenance Survey; Digital Training; Converting your lighting system
Mobility as the means to offshore innovation; Preventing another Deepwater Horizon; ROVs as subsea robots; SCADA and the radio spectrum
Future of oil and gas projects; Reservoir models; The importance of SCADA to oil and gas
Big Data and bigger solutions; Tablet technologies; SCADA developments
Automation modernization; Predictive analytics enable open connectivity; System integration success; Automation turns home brewer into brew house
Commissioning electrical systems; Designing emergency and standby generator systems; Paralleling switchgear generator systems
Natural gas for tomorrow's fleets; Colleges and universities moving to CHP; Power and steam and frozen foods

Annual Salary Survey

Before the calendar turned, 2016 already had the makings of a pivotal year for manufacturing, and for the world.

There were the big events for the year, including the United States as Partner Country at Hannover Messe in April and the 2016 International Manufacturing Technology Show in Chicago in September. There's also the matter of the U.S. presidential elections in November, which promise to shape policy in manufacturing for years to come.

But the year started with global economic turmoil, as a slowdown in Chinese manufacturing triggered a worldwide stock hiccup that sent values plummeting. The continued plunge in world oil prices has resulted in a slowdown in exploration and, by extension, the manufacture of exploration equipment.

Read more: 2015 Salary Survey

Maintenance and reliability tips and best practices from the maintenance and reliability coaches at Allied Reliability Group.
The One Voice for Manufacturing blog reports on federal public policy issues impacting the manufacturing sector. One Voice is a joint effort by the National Tooling and Machining...
The Society for Maintenance and Reliability Professionals an organization devoted...
Join this ongoing discussion of machine guarding topics, including solutions assessments, regulatory compliance, gap analysis...
IMS Research, recently acquired by IHS Inc., is a leading independent supplier of market research and consultancy to the global electronics industry.
Maintenance is not optional in manufacturing. It’s a profit center, driving productivity and uptime while reducing overall repair costs.
The Lachance on CMMS blog is about current maintenance topics. Blogger Paul Lachance is president and chief technology officer for Smartware Group.
Featured articles highlight technologies that enable the Industrial Internet of Things, IIoT-related products and strategies to get data more easily to the user.
Compressed air plays a vital role in most manufacturing plants, and availability of compressed air is crucial to a wide variety of operations.
This digital report will explore several aspects of how IIoT will transform manufacturing in the coming years.
Maintenance Manager; California Oils Corp.
Associate, Electrical Engineering; Wood Harbinger
Control Systems Engineer; Robert Bosch Corp.
This course focuses on climate analysis, appropriateness of cooling system selection, and combining cooling systems.
This course will help identify and reveal electrical hazards and identify the solutions to implementing and maintaining a safe work environment.
This course explains how maintaining power and communication systems through emergency power-generation systems is critical.
click me