Know your PLC programming audience

It is in every programmer’s nature to write sparkling, efficient code that reflects their years of experience and prowess.  With the assortment of commands that seasoned pros have in their working knowledge, it is tempting – alluring, even – to write 15 lines of pristine code when it might take a less experienced programmer 100 lines to achieve the same functionality.

Remember time is money in manufacturing. And during a hectic, stressful breakdown event, the last thing you want is a technician struggling to understand how your code is manipulating the signals, particularly if that struggle is the difference between 5 minutes of downtime and 45 minutes of downtime. Programmable logic controller (PLC) code should never be a bottleneck when troubleshooting.

The person I try to have in mind when I program is the “third shift electrician.” This is a person with a lot of responsibility to a lot of different systems, and most likely without the full support of expertise that a day shift worker might have during a major breakdown. It is important to provide this person with a clear, well-documented program that makes tracing the tags behind motion controls a breeze.

Keeping just a few simple guidelines in mind will help to ensure that your code is never the reason for an extended downtime period.

Follow the PLC programming standards

First and foremost, follow all programming standards that are provided by the customer, and secondly standards that are defined in-house.  In a manufacturing operation that has many OEMs providing equipment, consistency is paramount to keeping production moving. Even when you’re sure you see a better way to do things, fight the urge and stick to the standards!  If maintenance staff expect things to be written a certain way, deviation from standards can cause a lot of lost time.

In-program documentation

Modern controllers have the inherent ability to provide good documentation. Clear and concise tag names, tag descriptions, and rung comments are essential for communicating your intent to someone troubleshooting a system. When applicable, descriptions should always directly reference field devices. This is especially important with system interlocks. If motion in your equipment requires a permissive from another system, comments in your program should include specific I/O or tag addresses in said interlocked system. There is nothing more frustrating than a tag being populated by a message from an undocumented source when troubleshooting.

Program inventory control

For PLCs that do not store documentation directly, it is essential to practice good program inventory control. Often times in a modern project, multiple integrators perform work on the same PLC: the OEM responsible for motion controls; another integrator delivering recipe data; and yet another doing quality data collection… projects have a lot of moving parts! Establishing a clear protocol for making changes and adding documentation to a master file will save everyone time and energy, and, most importantly, ensure that the entire program is fully commented on when the launch is complete.

Keep it simple, smartypants

The quickest way to process data is not always the best, from a holistic perspective. Of course, with the code you need to write, using indexed addresses to move words into a tag array using nested for-next loops with multiple pointers might be the most efficient way to get the job done. But, would a series of conditioned copy statements serve the same function and be much, much easier to follow? As always, know your audience. No one wants a call at 3 a.m. because someone needs help getting a machine running…and the earful from your customer the following day probably won’t be fun either.

Keep this list of pointers in mind:

• Follow the standards!
• Use clear tag names that intuitively correspond to hardware components where applicable
• Add concise, straightforward comments to relate intent of logic
• Include corresponding I/O or tag addresses in your descriptions of system interlocks
• Practice good version control; make sure you are using the latest commented program, and put the program into inventory when you have finished your changes
• Avoid indexed addressing if possible; document all components of the array(s) if it is unavoidable
• Try to copy like data types to like data types
  • Good: DINT → DINT
  • Less good: DINT → INT
• Try to keep numerical addresses the same when copying data
  • Good: FaultArray[5]  HMIArray[5]
  • Less good: FaultArray[10]HMIArray[7]

– This originally appeared on RedViking’s blog. RedViking is a CFE Media and Technology content partner. Edited by Chris Vavra, web content manager, Control Engineering, CFE Media and Technology, cvavra@cfemedia.com.

Original content can be found at www.redviking.com.

Do you have experience and expertise with the topics mentioned in this content? You should consider contributing to our CFE Media editorial team and getting the recognition you and your company deserve. Click here to start this process.