Programming PLCs: Keep the documentation clear and simple

Poor programmable logic controller documentation and housekeeping can lead to unnecessary troubleshooting and downtime. Keep it simple in order to avoid the possible risks and confusion.

There are different rules and programming methods that are needed based on the hardware and software being used. Programming in a Siemens programmable logic controller (PLC) is not identical to programming in an Allen-Bradley PLC. There are general good practices that should be followed in any programming. The obvious is to have the program function and control as desired. Maintaining good documentation and housekeeping are good general practices in programming. Code should be easily read and understood by programming colleagues and customers. Poor documentation and housekeeping can add unnecessary time to troubleshooting, downtime, and programming. Programming structure and how complicated it may or may not be is another variable that will affect how easily the code is deciphered. I suggest following the KISS principle: “Keep it simple, stupid”. Avoid unnecessary complexity and keep it simple and straightforward.

Good documentation will make your programming life easier. Adding rung comments and descriptions to tags greatly helps understand the code and the process that the code is controlling. Typically, if a programmer has an allotted schedule to program, documentation is typically not a problem. It might become a problem when time is running out and code needs to be cranked out, with the mindset that the programmer will add the documentation at a later time—that later time may or may not come. Keeping up with documentation while commissioning code can prove difficult, at time of commissioning the priority is ensuring the code is functional and meets customer processing needs. Having multiple programmers on the same PLC program might also cause some distress with documentation. Communication and coordination between the programmers will help minimize the loss of documentation.

Documentation is critical in the aspect that it helps the customer/programmer understand more easily what is going on or what is the intent of the code. I suggest to program with the mindset that you the programmer will need to maintain it. Typically we program and walk away from a site and might not return to the site for a long period of time. It will be nice if you return to the site to add code for a new process or enhancing their process and you can easily understand what you wrote several years before with little to no effort. Same goes with other programmers within your company or other sub-contractors that the customer might hire. Sure, we can easily determine that we can write the code in the most complex way and have little to no documentation to make the other guy depend on you to make any programming updates or changes. While this might sound good for job security, it is not good practice. Customer will not appreciate relying on the one guy. Customers typically want out off the shelf parts to ease maintenance and downtime—same concept can be viewed on programming. Customers typically steer away from custom software and rather move to something that has an open source code and good software support. Whatever makes sense to minimize possible future downtime and future upgrades/enhancements/additions.

With documentation, another good practice is housekeeping. Keeping the code clean and removing tags and code that simply goes nowhere and not needed. As programmers we typically take our best practices to new projects, especially if the new project has no predetermined code structure standard. Why reinvent the wheel. But while doing so, we need to remove whatever code we carried over from our copy and paste that is not needed, cut the fat. As a programmer, it’s not easy going into a program that has little to no documentation and it doesn’t help that after reverse engineering the code you discover that a percentage of the code is bogus and not needed. After a few choice words the first question you ask yourself is, who wrote this? Don’t be the one.

In conclusion, good documentation and housekeeping are good programming practices. I’m sure we have all ran into a program that had little to no documentation and it was a bit of a nightmare on hours to reverse engineer what the program is doing. Even if the program documentation is written in a foreign language to your own, at least it has documentation, Google Translate to the rescue.

This post was written by Miguel Guiterrez. Miguel is a Senior Control System Specialist at MAVERICK Technologies, a leading automation solutions provider offering industrial automation, strategic manufacturing, and enterprise integration services for the process industries. MAVERICK delivers expertise and consulting in a wide variety of areas including industrial automation controls, distributed control systems, manufacturing execution systems, operational strategy, business process optimization and more.