Code standardization increases throughput
By Michael Shell and David Imes
Your manufacturing customer has a complex system worth millions of dollars in capital investment, with 20 outputs from packaging going to seven palletizers, six PLCs, over a dozen HMI stations, around 400 motors, two dozen barcode-scan points, plus numerous merges, switches, diverts, and miles of conveyors. Now the system is choking, and bottlenecks are racking up downtime, productivity is suffering, and troubleshooting the system requires excessive downtime.
Over the years, different integrators and plant personnel have changed the code used to control the entire system many times, so nothing is standard any longer, and equipment problems are difficult to resolve because they are masked by code issues. The answer to these issues is a full code rewrite, which is a major undertaking. However, if handled correctly, the disruption to production can be minimal, and the ROI can be significant.
Where do you begin duplicating the pre-existing logic in a standardized format? One piece builds upon another, so the starting point is a critical key to the success of the project. Here are some recommendations:
Start by identifying the standard that the client wants to use going forward. Whether creating a new standard from scratch or modifying an existing one, agreeing on a standard is essential for success. The standard generated for this manufacturer outlined specifics of the PLC programming structure, nomenclature, tags, and standard routines. A functional specification is developed as well as the sample PLC code and routines for the new standard. A library of generic PLC routines is built that could be configured and applied to every equipment type, whether it be belt, roller or accumulation conveyor, a divert or switch, or merge section, and so on.
From there, develop a logic narrative for the system. The existing PLC code is reverse-engineered and listed out as a logic narrative to tell how each and every piece of equipment and conveyor will work together. How the PLC will interact with other equipment, naming conventions, and other factors are determined. Once everything is clearly laid out and approved by the client, work on the new code is started.
Next, develop the code. Using the approved standard and sample routines, the team develops the PLC code in a two-step process. First, repetitive logic is developed using a code generator tool-guaranteeing there are no mistakes made during data input and editing. Then, the team focuses on writing the intricate, custom portions of the code as detailed in the logic narrative.
At this point, integrators may feel inclined to move directly to the plant to download and test the code. Taking this step at this time may prove costly to the client and impact production significantly. Experience has shown that using emulation software such as PolySim and in-house Factory Acceptance Testing (FAT) to thoroughly test the code is far more cost effective versus a live download testing onsite.
Emulation modeling enables the manufacturer's real factory situations to be controlled entirely by the new PLC and HMI code. An emulation is a complete model of the system controlled by the actual PLC code in real time. This facilitates fully testing the new control system with more variables, receiving more data faster than running the system in the field. Trying to "break the system" with in-house FAT allows the system to be pushed to its limits and creates confidence in the ability of the new code to efficiently manage the whole system. By reducing the efforts needed onsite and achieving a more vertical startup, this nearly eliminates program-related risks during startup and creates major savings for the customer.
Now, the logic is ready to download and be put through a rigorous validation process. Once downloaded, the same scenarios are validated in the field that have been validated using the emulation model. This sets the stage for a nearly vertical start-up, cutting onsite validation time by 50%. Since success depends on the ability of plant personnel to support the system, formal detailed, code-specific training and documentation is provided to the customer.
Was it worth it? The code rewrite exceeded the manufacturer's objectives. New standardized code delivered higher throughput, greater reliability, and faster speeds in the first week. Partials are less than 15%, and downtime has been cut in half. Emulation-based FAT cut onsite validation, creating major savings. Equipment and hardware-related issues previously masked by old code are identified and resolved, reducing the impact on production.
ABOUT THE AUTHOR
Michael Shell is a project lead, and David Imes is a senior engineer, at Polytron, Inc., a member of the Control System Integrators Association (CSIA). To find out more, visit www.polytron.com or contact Ron Sklamm at email@example.com.