Download the report.
A Control Design reader writes: Due to past issues with programming support of our automated machines, we have created a requirement for new equipment that the control software meet the IEC 61131 standard, and we have limited the approved controller manufacturers. However, that fixed just some of our support problems. Each machine supplier seems to have its own, varied opinions on how to write a program for an automated machine cycle, and a few think it should be written like it's process control, even though its discrete control.
Some of my team members think we should allow use of all the programs available within the IEC 61131 standard, and others say to limit the programming language to ladder logic, in most cases, and document the acceptable program structure to keep it simple. How can I box in the control software and machine control programming methods on equipment supplied to our manufacturing plant to ensure my maintenance technicians and programmers can provide quick, efficient support? Also, how can I standardize to make the control software easier to use and understand when troubleshooting?
Answers
Code intentions
For many years the IEC 61131-3 standard has helped make engineering teams around the world more effective and efficient. A major reason for this is that this IEC standard is not locked into one vendor’s system architecture or programming environment, which helps make code more portable between platforms. The well-known pillars of IEC 61131-3 include ladder diagram (LD), function block diagram (FBD), structured text (ST), instruction list (IL) and sequential function chart (SFC). With these different languages, PLC programmers have access to a well-stocked set of tools that help get different programming jobs done most efficiently.
While the IEC 61131 standard defines programming-language constructs and each of the language’s unique syntax and feature sets, it does not define standardized application of logical components. This is where the PLCopen organization helps define basic functions as simple as timers to more complex functions for motion control. This makes programming between platforms more consistent and open, ensuring that once programmers are proficient with these technologies, they are not forever locked into proprietary languages or automation platforms.
The practice of conducting the full machine control programming development in LD is in decline worldwide as other IEC 61131-3 languages, such as structured text, are more widely used than ever. As ladder is less frequently used, a common practice today is to program logic sequences in ST and develop overall machine states in a graphical programming language like SFC. For certain types of logic like Boolean functions, LD is still acceptable, but more complex mathematical models and algorithms are far easier to program using ST. To rule out ST and all other languages just because LD is the standard that fits in someone’s comfort zone would be severely limiting to the potential of your programming team.
Granted, there are many different possible strategies to architect machine control code and numerous interpretations of how the machine should behave in the real-world application. Therefore, it is important for controls development teams to document an official internal description of their code design intentions and coding standards (Figure 1). Everyone will have an opinion on the programming nuances, especially if they only like LD, but having a standardized approach to the machine control code means the entire team can open the code and make changes that are unanimously accepted by the rest of the team. We often see code in every industry start with the PackML state machine for the core states of the machine, and then the unique machine sequences are programmed within those states. This puts an industry-standard state machine at the core of your machine code that is well-tested and documented.
Figure 1: It’s important for controls development teams to document an official internal description of their code design intentions and coding standards
(Source: Beckhoff Automation)
The use of other modern programming tools outside of the IEC 61131-3 standard, such as those used for code static analysis, is another way to ensure better code quality and consistency across programming teams. Static code analysis is a tool that tests software—PLC code in this case—on the basis of coding rules and identifies the potential weak points of an implementation even during the development stage by checking for more than 150 programming rules. The analysis extends from checking for compliance with naming conventions through to examining the use of objects and operators, and it will return code readability and complexity matrices. Easier readability and an improved program structure are achieved through the analysis. Attention is drawn to possibly unintentional and faulty implementations, so these program points can be optimized at an early stage.
Be aware that not all modern machine control software platforms offer a comparable set of analysis tools, so evaluate systems accordingly. For example, one of the important features highlighted by programmers who prefer ladder is the ability to see logical programming flow in a graphical presentation. Some, but not all, modern development environments can show graphical programming flow in any of the IEC 61131-3 programming languages to indicate whether lines of code are being executed or not. This useful functionality successfully bridges gaps in programming languages and comfort zones previously experienced when debugging code. Embracing IEC 61131-3 is absolutely the right approach; just don’t limit yourself by deliberately avoiding some of the other very useful tools that are in the standard. They are in there for a reason.
Daymon Thompson / automation product manager—North America / Beckhoff Automation
Narrow and negotiate
This is an issue I have dealt with throughout my career. As a matter of fact, I just discussed it with a client. What is seen most often is clients that have multiple platforms, both from different manufacturers and within the same manufacturer as manufacturers come out with new products. In addition to that, whether from multiple suppliers or the same supplier, each programmer has his or her way to program. This can be the way the programmer structures ladder logic, using different forms of programming such as mixing function block and ladder and being inconsistent at times with how logic is configured from device to device.
Over the years, I have advised end users to pick a solid control-system manufacturer that has been around a long time, has fully formed tools that a programmer can use and has solid support should a problem or question arise. The end user should decide what is wanted in a control system and not base it solely on the lowest price available. There are manufacturers that come and go. An end user should pick one or two leading manufacturers and standardize on those suppliers. The end user might be able to negotiate good pricing if vendors compete for the standardized platform. The end user should also develop and/or borrow control-system standards for vendors to follow. This should not only include allowable hardware to supply, but also specify ladder programming, if that is what the end user wants, and also provide programming templates for vendors to follow that will require commenting on rungs, ladder structure and subroutine methodology.
End users should require that all vendors provide copies of source code to facilitate future troubleshooting and future purchases from companies that might provide packaged skids; here the company should require conformance with the platform and programming methodologies. Many suppliers will request premium charges for this, but that is typically negotiable, as well.
Peter M. Parr, BSME MBA / vice president, sales and marketing / Automation Controls & Design Specialist / wControl System Integrators Association (CSIA)member
PLC programming best practices
Once you have determined the best practices and specifics your facility requires in its automation-control programs, it is recommended you incorporate it into the request-for-quote process. Create an enforced policy where an employee from your company has to sign off on automation programming, confirming it meets or exceeds your company’s standards.
Ensure responsible employees are trained properly to identify basic best practices in PLC programming. This best-practice training, reducing downtime and helping our customers to become less OEM-dependent are prime training directives of our instructor-based PLC training.
Besides applying industry standards to your company automation-programming requirements, here are some best practices to add to your requirements. These help to ensure your in-house maintenance and engineering can work with the automation control programs and greatly reduce downtime.
-
The program should be designed with a primary effort to make it as easy for the laymen to understand as possible.
-
Ladder logic should be the programming language of choice with structured text and other IEC 61131 languages being used only in places where the automation machine vendor can satisfactorily meet the needs of the end-user or customer, if it is necessary.
-
Every program, regardless of size should have a ‘Start Up’ and ‘XREF’ subroutine.
-
The main subroutine (LAD 2) should be kept as small as possible and used primarily for program control/flow with jump-to-subroutine (JSR) rungs only for organizational purposes and processing speed.
-
Every rung should have a detailed rung comment explaining rung purpose and extra helpful information (Figure 2).
-
Every instruction should have a detailed description.
-
Don’t use acronyms in instruction descriptions.
-
Symbols [tags] should be as short as possible and easily identifiable with what they represent.
-
When tags are not used everywhere, symbols at a minimum should be used on memory locations that are related to real world, faults and frequently used memory.
Figure 2: Every rung should have a detailed rung comment explaining rung purpose and extra helpful information.
(Source: Business Industrial Network)
Actual PLC programming standards should be applied to your requirements, too.
-
Consider using one shots when executing move, copy and math instructions for data stability.
-
Minimize use of latching coils where seal-in logic in will suffice.
-
Every counter should have the corresponding reset programmed as well.
-
Whenever possible, forward-reverse motor control logic should have plugging timers to protect the motor.
-
Every source, destination and test value should be stored in a memory location such as an integer or floating point.
Don Fitchett / president / Business Industrial Network
Upstream downstream
Making IEC 61131-3 a requirement is an excellent step. Almost every control supplier uses it to some extent. The best approach is to use the languages where they do the best job.
In the United States, in our current time and place, there is no doubt you are going to want ladder logic, aka ladder diagram (LD). A small machine might work with all ladder logic, but, with more complex machines, all ladder ends up becoming “spaghetti code”—hard to troubleshoot and too easy to modify without documenting what was changed. Ladder provides useful, graphical logic, and it's what allowed the electricians to replace electromechanical relays and century-old electrician's relay logic without a steep learning curve.
Function blocks (FBs) and function block diagram (FBD) are really effective constructs and complement ladder. FBs can be used in LD and FBD structures and encapsulate much of the code that might otherwise turn into spaghetti.
Structured text (ST) is powerful, but, because is it textual, it's not that well accepted in the United States. It is best used to program complex tasks. Test the code, put it inside an FB and lock the FB down.
You don't see much low level instruction list (IL), an assembly language, so I won't even discuss it.
But you may run into some sequential function chart, and it, too, is an effective construct, though people in the United States are less familiar with it. It graphically depicts time- and event-driven control sequences.
All of that said, since you are not doing the programming, it becomes more difficult to define a common software structure for your various OEMs. But you can favor OEMs who produce more structured code using the appropriate languages as described here. And, while you strive for continuity, what you really want is to be able to operate, integrate, troubleshoot and adapt to changing needs with as little intervention as possible.
You don't actually want your technicians messing with the machine code, especially motion, for some very good reasons. Voiding the warranty is one. Treating the symptom rather than the cause of a maintenance problem is another.
Not documenting software changes is bad. You do need to be able to add encoders and photo eyes and respond to upstream and downstream equipment. So here are some functionalities to look for.
One we call Codebox. It's an IEC 61131-3 compliant programming environment that allows you to do those things you need to do outside of the actual control program, but interacting with it. It emphasizes the use of familiar ladder including power flow, all without the end user having access to the source code for the rest of the machine.
If your supplier's idea of software modularity is to copy and paste ladder logic from previous programs, insist on those modules being formatted as FBs instead.
The most amazing thing I've been involved with during the past eight years has been the development of IEC 61131-3-compliant modular application technology. These are like function blocks on steroids, where your supplier programs less and configures more. These aren't the typical canned routines; they are flexible and powerful software components that have a communications layer. So populating data required of one component will automatically be populated in other components that need the same data. This has become a really extensive set of development tools, from HMI to mundane tasks like access control to robotics and a single servo axis block that can replace 20 to 25 FBs.
Almost finally, in the Organization for Machine Automation and Control (OMAC), we saw the need to combat spaghetti code early in the development of PackML (ISA TR88.00.03), which defines standardized state machine, machine modes and tag names.
We called the structured code initiative Make2Pack, meaning a modular IEC 61131-3 approach to code to implement the state model. OMAC hasn't had the resources to address this phase. Here’s an action item: Join OMAC and push for the Make2Pack initiative.
And finally, the next generation of machine programmers and factory-floor technicians, schooled in advanced programming environments, is likely to reject how we program machines today as antiquated. The future is with modular-application technology, which turns automation components into something akin to IIoT-enabled appliances. It's still going to be IEC 61131-3, but not your father's IEC.
John Kowal / director, business development / B&R Industrial Automation
Marcel Voigt / solutions architect / B&R Industrial Automation
Headlong into text
As a technology provider, this is the most difficult question to answer because it pits two goals against each other. But there is a good answer.
The first goal is for the machine programmer to use the controller to tie together the mechanical system with the electrical system. I once had an end user of a machine I was making ask me why my program was so complex. I was flummoxed and insulted and then reviewed my code to come up with an answer. In the end, he was right, but not because of me. I said to my customer, “The machine code only reflects the complexity of the machine; take a look at the thing.” It was a complex machine: more than 20 servos, robotic functions, temperature control and more. I did go back and change my programming concept to make it easier to go through the code, but the complexity will always be there, ladder logic or not.
The second goal is ease of troubleshooting. It’s clear that end users need an easy way to troubleshoot machines, but this becomes difficult when you multiply the number of:
(OEMs) x (technology providers) x (machine types)
This equation means that creating programs for maintenance, setting standards, training support personnel and getting quick service are always going to be elusive unless we can change the way we specify machinery.
Future-proofing product lines is everyone’s goal, but, realistically, it’s nearly impossible; from generation to generation, yes, but the future is long. When we make advances in our hardware and software, the previous generation of products is sent on an obsolescence path. In my experience with lots of different technology providers, they are all battling obsolescence from their suppliers, as well—DSPs, processors, FPGAs, castings. This means that hardware is always improving and becoming more functional, which, again, is reflected in the software offered. This is then provided to OEMs that use their state-of-the-art methods, making their machine code change, as well. On top of that, machine programming is running toward text-based languages. It is easier now to find qualified C-class programmers than ladder programmers. Times are changing. Finally, many OEMs split their efforts into different groups for machine types, each one tailoring the code to best represent the machine. It is hard to imagine a program for a tube filler and case packer being the same—possible, but improbable.
So, what is the answer? Use today’s technology today; specify functionality. When I started programming, IEC 61131 was available but didn’t have all the programming features that are currently available. For instance, to replace a drive in the past, it was a guarantee that you would have to open the control software to parameterize, set bus addresses and maybe even change program references for the new drive to work.
Now, it is common for controls to auto-configure new drives based on the specified machine need. This means replacing a drive is a physical job, not a programming one. HMIs are also much more powerful than in the past because of the strides in technology. So now the help you get at the machine for troubleshooting is complete, if you ask for it. For example, it was common to create an alarm array in the PLC code that would be sent to the HMI for display. Now, that same PLC-alarm array triggers a cascade of help in the HMI based on the conditions of the machine. Instead of telling you there is a jam, the machine HMI tells you the process steps, depending on how it sensed the jam occurred.
If we see that technology providers are always adapting new technology, how can we force them to stay with old methodology, and do we really want them to? If OEMs are buying current technology and hiring computer-science graduates, why would we ask them to not make better software? The answer is to create a plant machine specification now for new machines coming in based on the way you want your maintenance people to work. Teach the machine to speak their language. It is possible. For example:
- All I/O should be displayed in ladder on the HMI for troubleshooting and tested or forced, if the machine function allows. Note: I am a fan of ladder, but it is awful for programming anything but Booleans. “There are 10 kinds of people in the world: those who like ladder and those who don’t.”
- All alarms result in a step-by-step recovery based on the I/O currently present.
- Changeover should be step by step, as well, or, better yet, automated. The fewer changeover points that are manual, the better your uptime.
- All hardware can be replaced without the use of software, just the use of the HMI.
- Common resources such as PDF files or movies should be incorporated into the machine environment. This helps when troubleshooting but also trains operators when they need it.
- A duplicate display—Web service—should be available in case the primary HMI fails.
- Use sensors to eliminate timers. The machine will work better, and there are fewer adjustments—reasons to go into code.
- Have an interface to configure upstream, downstream, manufacturing-execution-system (MES) and enterprise-resource-planning (ERP) connectivity. This is now easier with PackML; it can be done so that no one has to go into code.
- Everything needed for the machine to work should be available through the HMI. If it is missing, the OEM should provide a modification service to add and upload the missing function.
When you get to this point, maintenance people start calling the control a “black box.” In one way, it is: There is no reason to buy the software package, no reason to go into the code. But if you specified it and prequalified the functionality, it is your black box, designed according to your specification and supported by the OEM. PCs and cell phones both fit the definition of a black box, but do we really want all the flexibility of flip phones and Windows 3.1?
Win-win-win. Our engineering team spends most of its time creating a catalog of HMI/PLC code packages for specific functionalities such as cell control or auto-adjustment systems. We offer them to OEMs with a built-in modification service with the ability to customize to the machine and send them to end users as code-free solutions.
This allows the OEM and end user to work together on machine-specific training and improvements to the machine, and our overall support cost goes way down. We know the code works; we normally just send updates instead of breakdown service calls.
In the end, we all save a lot of time and money and instead focus on improvements. Once in a while, a super-complex machine comes along, and we have to return to the ground-up approach, but that happens less and less as our code packages grow.
Tom Jensen / senior vice president and general manager / AMK Automation
