IEC 61131-3 programming has had a large impact on the high-performance motion industry. Learn how the language and standard relates to your design work.
Since the mid 1990s, substantial efforts have been made to standardize programming in all areas of industrial control. The increasing abundance of low-cost programmable logic controllers or PLCs has been at the heart of the increased use of the new IEC 61131-3 standard, which was designed to provide a global platform for PLC programming, independent of hardware. Indeed, this standard is both intricate and robust, and much of the industrial programming done today is governed by it.
As OEMs build machines with increasingly complex motion and non-motion related tasks, some machine integrators and end users in the motion industry want to improve compatibility of motion control software across different vendor platforms. The integration of IEC 61131-3-certified PLCs and motion controllers yields an advantage for individuals with experience in both arenas, and the ability to incorporate such software packages is increasingly valuable.
In short, the IEC 61131-3 programming standard has changed the high-performance motion industry by creating a delicate balancing act between system simplicity and performance — an issue already recognized by some motion manufacturers.
The result is hybrid motion control platforms that combine the best of both worlds. Specifically, implementation of a virtual PLC running on top of normal firmware allows users to program in the proprietary programming language for complex motion related tasks, and to program in the IEC 61131-3 languages for general PLC-related functions.
First some background
IEC 61131-3 is the only global standard for industrial control programming, and its scope is to specify “syntax and semantics of programming languages for programmable controllers.” IEC 61131-3 is only part three of the larger IEC 61131 standard, but is the most important because it defines the programming languages and common elements. Five different programming languages — ladder diagram, function block diagram, structured text, instruction list, and sequential function chart — are defined in the IEC 61131-3 standard, as well as elements that are common to all programming languages, including programs, function blocks, functions, declarations, data types, variables, and so on. Most importantly, the IEC 61131-3 standard gives machine integrators and end users more flexibility in choosing PLC hardware: It removes software incompatibility issues.
Ideally, a designer who writes software for manufacturer X's PLC should be able to use that same software for manufacturer Y's PLC. Though this full level of portability is not yet possible, IEC 61131-3 has allowed designers to leverage programming experience with manufacturer X PLCs to utilize those same skills (and a good portion of their software) with manufacturer Y PLCs.
Why isn't there full portability for software written for a particular application? The main reason is that the standard does not include details about the implementation or a way to certify different manufacturer products. This lack of a common implementation has led to a wide variety of different IEC 61131 programming environments that are not usually cross compatible. That said, work has been done to establish an XML format to allow programs to be transferred from one programming environment to another — but this is an ongoing process that is not accepted by all IEC programming environments. Even so, IEC 61131-3 has been accepted worldwide, and most manufacturers offer PLCs that can be programmed in IEC 61131-3 programming languages.
When it comes to software, the motion control industry is on the opposite side of the spectrum than the industrial control industry. Nearly every motion-control manufacturer uses a proprietary programming language, with some manufacturers even having multiple languages developed around their motion control hardware. While this is beneficial because the programming language can be designed to best utilize the hardware controller capabilities, this fragmentation discourages machine integrators and end users from switching hardware because of the substantial cost involved in training engineers and redeveloping the software. It also discourages machine integrators from using a hodgepodge of different motion controllers for different tasks because of the headache involved in learning how to program all of them.
For example, if a machine integrator has spent 100 hours developing a software application using Delta-Tau's PMAC programming language, he or she would be hesitant to switch to a different hardware platform that could better fit the application needs.
Another example would be if a machine integrator already has an Allen-Bradley Guard PLC performing safety-monitoring tasks, but wants to offload that responsibility to a high performance motion controller — so that the controls can be more centralized and require less hardware, for a more cost-effective product. In this case, the safety application would have to be rewritten in the programming language that runs on the motion controller — a potentially costly endeavor.
Pieces fit together
Though motion control is an area for which IEC 61131-3 has no directly defined standards, IEC 61131-3 does provide an overall framework for building a motion control standard. PLCopen (a worldwide vendor-independent association) took the initiative to design a standard that leverages the IEC 61131-3 function-block concept for increased universality.
As defined by IEC 61131-3, a function block may be written in any of the IEC 61131-3 languages and in most cases it can be written in C. PLCopen initiated the Technical Committee 2 - Task Force Motion Control to create a library of function blocks that covers basic tasks of single and multi-axis motion, with the goals of simplicity, efficiency, consistency, universality, flexibility, and completeness. Similar to IEC 61131-3, the PLCopen Motion Control specification is completely hardware independent and as such it does not define the actual implementation of the function blocks. This means that it suffers the same pitfalls of IEC 61131-3 — namely, that most PLCopen Motion Control programming environments are not cross compatible. Another drawback is its limited capability for utilizing the advanced product dependent features that most high-performance motion controllers offer.
To illustrate, consider two very simple programs designed to control one axis. The main purpose of each program is the same — to control an X axis using digital inputs, and then display the status with digital outputs. The first is written using function-block diagrams in an InfoTeam OpenPCS IEC-61131 programming environment; the second is written in ASCPL+ using ACS Motion Control's ADK. The function-block diagram is easier to read if the designer has never used the ACSPL+ program but ASCPL+ is much simpler to program.
Consider a more complex motion application. Many high-performance motion controllers allow users to create a PT and PVT path motion using simple commands written in proprietary programming language. PLCopen Motion Control does not have any defined function blocks for this kind of motion, and implementing them on a hardware dependent basis would be a costly venture.
With one global software standard now defined for the motion control industry, the main question that a machine integrator or end user should ask is: How does this impact me? The answer to this question depends on the background of the application and the person asking the question, though some general guidelines can be used.
Machine integrator considerations
Machine integrators are responsible for combining a wide assortment of different sensors, actuators, controllers, mechanical components, and HMIs into a high-performance, efficient, and cost-effective system. It is important that the user interface be relatively friendly for the end user to reduce the amount of training, as well as maintenance costs. The user interface should also be designed so that it can be used in a global environment, particularly if end users are located in different countries.
These factors are all sound reasons for using a global motion-control programming standard. The open code allows an integrator to become an IEC 61131-3 programming expert, as well as work with all of the controllers at his or her disposal. Instead of being tied to a specific manufacturer or controller because the designer has devoted a large amount of time to learn how to program it, here designers can now pick hardware specifically for cost and features. With open software, designers can also reuse software developed for other related systems and projects, in turn minimizing software development time.
In contrast: Consider a packaging-machine manufacturer that uses PLCopen motion-control function blocks to reduce in-house and end-user training costs. Expecting similarly reduced training and costs is unrealistic for higher-performance systems that require complex kinematics, intricate motion profiles, and specialized processes. Why? For these more sophisticated systems, it is counterproductive to try to write controller-dependent function blocks to handle high-performance tasks when proprietary programming language is usually most suitable and easier to debug.
End users are most concerned with system performance, cost, user friendliness, and maintenance. They require systems that are easy to understand and troubleshoot, for reduced need to rely on machine integrators or system component manufacturers. In short: Machine user interfaces should be simple so that the training for using the system is minimized. The system as a whole should be cost effective in initial as well as ongoing maintenance costs. Finally, system performance should not suffer as a result of these requirements.
With this in mind, global motion-control programming standards also sound enticing, as they guarantee all of the above except for higher system performance. Even so, system complexity will always determine whether or not system performance will suffer under a hardware-independent programming.