Machine commissioning: A programmer’s checklist

Inside Machines tips and tricks: Control engineers need to practice these programming tips to ensure project timeline pressure doesn’t harm the machine project.

10/31/2012


A lot of emphasis is placed upon the importance of specification gathering and project planning before starting a machine project. Once projects are underway, control engineers are typically under pressure from project managers to complete programming on time even though they may be waiting for the mechanical and electrical teams to finish their parts of the projects. The control engineers working on programming the machine face a time crunch as the deadline nears. Due to commercial reasons, in many situations, final programming is done after the machine ships to the customer, leaving testing incomplete.

In the race to deliver the project on time, programmers may be tempted to skip the “wrap-up” steps after programming is complete. Below are eight essential wrap-up steps that make the project easy to maintain, easy to troubleshoot, and easy to build upon, if needed.

Program

1. Map the various areas in control algorithm (from the basic design document) to drawings in the project: A basic design document is the first step in project design. The design document translates customer requirements to a plan of action that contains designs of algorithms required for machine operation. Programmers use the control algorithms laid out in the basic design document to write code for motion control and other logic required for machine operation. Multiple drawings or program organizational units (POUs) may be required to complete one control algorithm. In such situations, once the coding is complete, a map that links specific parts of the algorithm to POUs is essential to understand the project’s flow of code. Such a mapping gives the user a better understanding of the layout of the program and the sequences used in machine control. This map can help understand sequence issues on machine controllers that have multitasking capabilities.

Documentation like this will be a good starting point to someone who will be taking ownership of the machine code after the initial programmer hands it off. It may not be possible to include such documentation in the project itself. A separate document may be necessary for this purpose. A simple example of how an algorithm can be converted to a color-coded flowchart with the roles of individual drawings/POUs is shown in Figure 1. 

Figure 1: Map the control algorithm to the drawing or program organizational units (POU) in the project. Courtesy: Yaskawa America

2. Document inputs to each POU and outputs from each POU: Documenting inputs flowing into a drawing and outputs flowing out of a drawing will help a user understand the data flow within a project. Such documentation will help in understanding the process and in troubleshooting the application. This way the project is modular and each POU or drawing can be checked for functionality independently. For example, Figure 2 below details data flow in a part of a project. To troubleshoot an issue related to H10.03, one can look at the inputs and outputs of H10.03. Only if the inputs to H10.03 are as expected should the user go into H10.03 to troubleshoot the code there. If the inputs to H10.03 are not as expected, the user should not delve into the code in H10.03. 

Figure 2: Diagram shows critical inputs and outputs of POUs and their flow within the project. Courtesy: Yaskawa America

3. Define variables (status variables/ parameters) at key points in the code to help troubleshoot: Modularity and transparency are important properties of good code that is easy to troubleshoot. To be modular and transparent, the programmer must make an effort to break down complicated sequences to smaller sequences such that variables can be monitored closely for accuracy. This also paves the way for easy maintenance. Such programming practices may affect the programmer’s time while programming, but they will save a lot of time during start-up and later during troubleshooting. 

Figure 3: Defining variables in key locations of the code helps troubleshooting later. Courtesy: Yaskawa America

A screenshot of Structured Text (ST) code broken down for making the code modular is shown in Figure 4. If the code were not made modular with the introduction of the additional variable, the total number of lines of code would be small, but complex and unmanageable.

Figure 4: Ensure code is modular. Courtesy: Yaskawa America 

Placing functionality at critical locations to monitor motion parameters in motion applications during program development will help immensely in the long run. This will prevent an unnecessary waste of time during the debug stage of application start-up. This is very important in applications that involve synchronized motion like electronic camming or electronic gearing. The above-mentioned motion functions involve various internal parameters whose understanding will help in application troubleshooting. 

Figure 5: Monitor motion parameters in application code. Courtesy: Yaskawa America

4. Plan for part replacement strategies in the code: Over the lifetime of a machine, various components of the machine will have to be replaced. When a machine component controlled by the motion controller is replaced, the motion controller should have the capability to extract the same functionality from the new component as it did from the old component prior to it becoming worn out or faulty. This involves keeping a copy of the working component’s parameters as part of the project. The programmer will have to foresee such a scenario and design code with this capability. Most motion controllers have the capability to retain parameters and compare parameters. If needed, the retained parameters can be sent to the new component that is installed in the machine. It is beneficial to incorporate these aspects into the code before machine commissioning and not wait for a component to become faulty before thinking of replacement strategies.

Figure 6: Plan a machine component replacement design in application code. Courtesy: Yaskawa America 

Finalizing project and documenting start-up 

1. Save parameter files as part of the project (after final machine setup): One of the last steps before commissioning a machine is parameter optimization and turning on motion components to optimize performance. This will involve editing parameters on various components that are part of the control system. After the parameters are finalized, the programmer should make the extra effort to save a copy of these parameters as part of the project.

Figure 7: Save final configuration and parameters to the project folder. Courtesy: Yaskawa America

2. Review project access rights: Many times, OEMs use custom algorithms to control motion. If the OEM wishes to protect certain algorithm implementations from end users, such code should be password protected. Most programming software products have selections for read/write protection. Selected portions of the code that are not for public viewing or editing should be placed under password protection. 

Figure 8: Protect code with Intellectual Property (IP). Courtesy: Yaskawa America 

3. Review deliverables at project hand-over: At the time the customer receives the project, the programmer should make arrangements such that all required files are handed over. The OEM and user should agree on whether the code and project can be reused on other machines if the user wishes to replicate the machine. The programmer should understand how the software allows a user to create a project image. The various checks that can be performed are:

a. Save source files on the controller if the programmer wants to allow the user to upload the project from the controller into the user’s PC at a later date. This is one form of backup. This allows the user to extract the project that is currently running on the machine.

b. Lock the project before hand-over. If the user does not want to make any edits to the project and wants to use the project for monitoring only, the programmer should lock the project. Locking a project helps in version control. A user will not be able to make edits to a locked project. Another good practice for version control is using the date as part of the project name.

c. Make sure all firmware and user libraries are compiled and included with the main project. If the project is built with the help of add-on user/firmware libraries that are not part of the standard software install, the programmer should take the extra step to include these libraries with the main project. The programmer should also check to make sure that the libraries and the paths are linked with the main project appropriately.

d. Lay out detailed steps that will help a user clone machines if the OEM wants to allow the user to do so. 

4. Document performance analysis (plots and numbers): Documenting machine performance in plots of motion parameters and in numbers of parts processed is essential at start-up. This will serve as a template for troubleshooting, commissioning other machines, analysis for improvements, and more. Start-up performance documentation should be reviewed and approved by the customer.

Often when a user complains about a machine not performing as per specifications, documentation made at machine start-up will come in handy to compare and verify. This will help explain any differences in performance over time. On motion applications, performance analysis must be done at the machine controller level and also at the drive level. The controller side analysis will help in evaluating the machine performance as a whole. Drive analysis will help in detailed evaluation of the axis in question. Various performance factors like tuning and filtering can be gleaned out of such performance plots. 

Figure 9: Controller analysis of production cycle is shown. Courtesy: Yaskawa America

Figure 10: Drive analysis of motion cycle is shown. Courtesy: Yaskawa America

A programmer who does not address these steps appropriately can be compared to a car manufacturer who does not add a spare tire and the user’s manual as part of the new car that rolls out of the assembly line.

- Nishant Unnikrishnan is application engineer, Yaskawa America Inc. Edited by Mark T. Hoske, content manager, CFE Media, Control Engineering and Plant Engineering, mhoske(at)cfemedia.com

Key concepts

Control programming tips:

-Draw a map

-Document inputs

-Define variables

-Plan for part replacement strategies 

Consider this

With automation programming projects, is three out of four not bad...when you’re talking about compiling and including firmware and user libraries in time? 

Go Online - See links below for the follow articles

UML use cases, sequence diagrams: Easily converted into executable code 

Seven habits of unsuccessful projects 



No comments
The Engineers' Choice Awards highlight some of the best new control, instrumentation and automation products as chosen by...
Each year, a panel of Control Engineering editors and industry expert judges select the System Integrator of the Year Award winners.
Control Engineering Leaders Under 40 identifies and gives recognition to young engineers who...
Learn more about methods used to ensure that the integration between the safety system and the process control...
Adding industrial toughness and reliability to Ethernet eGuide
Technological advances like multiple-in-multiple-out (MIMO) transmitting and receiving
Big plans for small nuclear reactors: Simpler, safer control designs; Smarter manufacturing; Industrial cloud; Mobile HMI; Controls convergence
Virtualization advice: 4 ways splitting servers can help manufacturing; Efficient motion controls; Fill the brain drain; Learn from the HART Plant of the Year
Two sides to process safety: Combining human and technical factors in your program; Preparing HMI graphics for migrations; Mechatronics and safety; Engineers' Choice Awards
The Ask Control Engineering blog covers all aspects of automation, including motors, drives, sensors, motion control, machine control, and embedded systems.
Join this ongoing discussion of machine guarding topics, including solutions assessments, regulatory compliance, gap analysis...
News and comments from Control Engineering process industries editor, Peter Welander.
IMS Research, recently acquired by IHS Inc., is a leading independent supplier of market research and consultancy to the global electronics industry.
This is a blog from the trenches – written by engineers who are implementing and upgrading control systems every day across every industry.
Anthony Baker is a fictitious aggregation of experts from Callisto Integration, providing manufacturing consulting and systems integration.
Integrator Guide

Integrator Guide

Search the online Automation Integrator Guide
 

Create New Listing

Visit the System Integrators page to view past winners of Control Engineering's System Integrator of the Year Award and learn how to enter the competition. You will also find more information on system integrators and Control System Integrators Association.

Case Study Database

Case Study Database

Get more exposure for your case study by uploading it to the Control Engineering case study database, where end-users can identify relevant solutions and explore what the experts are doing to effectively implement a variety of technology and productivity related projects.

These case studies provide examples of how knowledgeable solution providers have used technology, processes and people to create effective and successful implementations in real-world situations. Case studies can be completed by filling out a simple online form where you can outline the project title, abstract, and full story in 1500 words or less; upload photos, videos and a logo.

Click here to visit the Case Study Database and upload your case study.