In manufacturing, serviceability is often a more important metric than elegance.
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.
But remember, in manufacturing, time is money. 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. 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 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.
To sum up, here’s a quick list of pointers to keep 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]
Learn More about PLC Programming from the Experts
PLC programming needs to be adapted to meet the needs of your intended audience. Working with an experienced manufacturing company like Red Viking can help ensure your productivity remains solid. Keep following our blog for more industry insights or give our team a call today to discuss how we can help your business grow.