Programming for the Future

Think about the people that will have to work on your project someday down the road. You can make their job easier, and one of those people may be you.

By Stephen Carson July 23, 2012

Have you ever gone online with a PLC and realized it contained no structure, the I/O was all over the place, and there were no comments in the logic? Fortunately, all projects are not retrofits or adding code to an existing PLC program. Sometimes you get to start from scratch. There are some good practices to follow when launching a new project that will help simplify a complicated program and make it easier to follow should someone else need to edit the code in the future.

There is a difference between a program that merely works and one that is well thought out and elegantly executed. The beginning of a well structured program is not just adding contacts to ladder rungs. Just because a PLC program can control a process or equipment when the process is running well does not mean it is a well-written program. A well-written program gathers and incorporates information about the process and handles the process when it is not functioning as expected. This is what separates it from just a piece of code.

Review and study the documentation provided about the process and pay attention to every detail. Thoroughly review the P&ID drawings, specifications, and any information provided about the system. Talk with maintenance and operations personnel to provide you with information to control the process from an operations perspective. This will allow you to provide a system that will function well and will contain items that you may not have thought of yourself.

Program code should be grouped in logical routines based on equipment by area. Each rung should contain a comment that provides enough information to clarify each section of the program. There is no such thing as too much documentation when you are having an issue and are trying to resolve problems quickly within the process. Grouping the program code by area and providing extensive documentation will provide more efficient troubleshooting, which will result in less downtime for the process. The primary goal of process control is to provide a robust system that will handle interruptions, but if an unforeseen problem should arise, code that is grouped in a logical order and is well documented can be interpreted easily by the customer.

Another good practice is to separate safety and interlocking logic from the process logic. This logic should still be organized by area similar to process logic, but provides a quick reference for safety and interlocking process control logic.

One key to saving time when developing a program is to familiarize yourself with the software you will be using. The software product you will be programming with may already contain instructions that will save you time just by have a good knowledge of the programming software and the instruction set that it contains.

This post was written by Stephen Carson. Stephen is a project engineer at MAVERICK Technologies, a leading system integrator providing industrial automation, operational support and control systems engineering services in the manufacturing and 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, and business process optimization. The company provides a full range of automation and controls services – ranging from PID controller tuning and HMI programming to serving as a main automation contractor. Additionally MAVERICK offers industrial and technical staffing services, placing on-site automation, instrumentation and controls engineers.