Motion programming comes of age

Motion control systems have been evolving for decades now, as applications have demanded an increasing level of innovation and simplification. Complex operations are becoming easier to implement, at higher speeds and with greater accuracy. Now PLCOpen Motion Control is providing a standardised way to code these applications for cross-platform compatibility and code re-use.

For the most part, manufacturers of motion control have been creating their own propriety solutions, with their own unique method of programming, distinctive syntax and semantics. Solutions developed on one platform are tied to that particular hardware and considerable engineering input is required to recode the same functionality into a different motion controller. While PLC ladder code will require some effort to transcode into a different vendor system, motion control programs are far more difficult to recode as motion controller architectures are too diverse and performance is highly hardware specific.

Motion controllers have typically been dedicated devices and have used a large variety of different languages to program. They use either high-level languages resembling C or BASIC, ladder variants or visual block diagrams. So system programmers have had to move between typical PLC-based systems, and the more specific and specialised motion controller language and environment, as well as handle data between the two systems, typically over a fieldbus system. The challenge then is to create a development environment where motion programming is fully integrated with the typical PLC languages such as Ladder (LD), Structured Text (ST) and Function Block Diagram (FBD). Data handling should also be common throughout, and the entire program should run on one hardware platform.

PLCopen Motion Control is providing greater exposure for PLC programmers and general system integrators alike to what is a rather specialised field. PLCopen is an international, vendor-neutral and product-independent association responsible for promoting the IEC61131 suite of standards which relates to programmable logic controllers. The 61131 specifications were created by the International Electrotechnical Commission (IEC) in order to standardise the methods by which PLCs are programmed and operate. It incorporates both programming languages and data types, and has formed an ideal basis on which to build further standardised methods of operation. PLCopen Motion Control has been based on this underlying level of standardisation and in combination the two standards have created an opportunity for high-level re-usability of code and minimal transition time between different platforms for the motion control domain.

How do we standardise motion control across all platforms?

The motion control system is defined as a state system. These states are mutually exclusive and define all possible states of a motion control axis. It is important to note that the motion controller and servo actuator are not differentiated in this model; they are effectively integrated into one device in this state definition. An axis in fault can be caused by a physical axis error (such as overload or overtravel) or by a programming error (out of software limits or impossible command velocity), and while the fault code will be different, the behaviour of the system will be consistent.

Figure 1 shows these states and also includes some of the function blocks which act on the particular state. For instance, an axis starts in the Disabled state. It can then be powered up and will move to the Standstill state. Once in Standstill, it is possible to transition to other states of motion. This is an important stage of the standardisation process as it clearly defines the base behaviours of a motion system.

Figure 1: State diagram for an axis.

In a similar manner, all aspects of motion control can be logically defined and standardised. Many functions are quite straightforward - for example, a relative move is a benign function which is easily comprehended in any system. The process of defining standard behaviour becomes increasingly beneficial as the complexity of the motion increases. For instance, discrete motion (positioning) functions where the transition velocity is zero are readily coded in any system. However, when multiple motion functions are required to create a more complex motion path, blending from one motion operation to another is required. An opportunity to simplify the process is available and PLCopen Motion Control defines standard blending operations.

Following this theme, and increasing the complexity of motion control, the advantages of a standardised set of coordinated motion for 3D space is also clear. One common issue with motion systems is that when multiaxis control is performed, it is sometimes performed with mathematical models which link the axes. However, it is not always clear to the motion controller which axes are critical to be moved in synchronisation. Hence, when a fault occurs, the motion controller will not always ‘know’ which other axes will be affected. By defining an axis group, however, the motion controller can perform better error response for other axes which are in the same group but not in error. Also, trajectory planning can be improved with better definition of the grouped axes. This formalisation of concepts into a standard is forming a bridge between the once distinct worlds of PLC and CNC/Robotics. It is now possible to run robots with complex coordinate transformations from a PLC-type system. While this is possible, it does require substantial processing power to perform in real time; hence, controllers with this capability will tend to be based on non-ASIC platforms, such as the ubiquitous Intel chipsets. This standardisation has allowed robots to become an integral part of a control system, rather than an independent asynchronous system. Such systems can be termed ‘machine controllers’ due to the level of integration of motion control and logic control, the two primary requirements for modern machine control. There are definitive advantages to having both the motion control and logic control in the one package, including, but not limited to, practically unlimited exchange of data between the logic and motion engines, without the latency which can limit performance in traditional systems. In fact, it is now possible to perform perfect synchronisation between a robot and additional servo axes using a machine controller, a feat which was previously only possible to achieve purely in the robot controller domain.

Hardware independence

Underlying this abstraction is the axis variable structure with a structured data type of AXIS_REF. The composition of this structure is flexible and specified by the manufacturer and is a comprehensive structure of data which fully defines the state of the axis. An axis is referred to by this variable and passed to and from the function block as an input/output type. This allows any function block to read and modify the axis data as well as contain the state with easy accessibility and standard methodology.

The ultimate goal of all this standardisation is the independence of the program code from the underlying hardware. If controllers from different manufacturers support the same functions, rely on the same syntax for programming and behave in exactly the same manner, the programmer is liberated from working with the particular characteristics of a specific motion manufacturer’s system. However, to achieve this, the program code must be completely abstracted from the hardware. This will allow the programmer to concentrate on the code required, without having to be particularly concerned with the hardware platform. IEC61131 disassociates the programmer to a large extent from the hardware platform. In a similar vein, PLCopen Motion Control does the same for the programmer of a motion control system.

Importantly, the PLCopen methodology is able to be implemented on hardware which has not necessarily been designed with this in mind. Since it is effectively a layer of abstraction, it can be implemented over the top of most hardware using function blocks which interface between the expected PLCopen operation methodologies and the underlying hardware. This makes this approach easier for vendors to implement without a hardware redesign. PLCopen compatibility is possible by providing a set of function blocks which serve as a gateway between the standard I/O of the function block and the low-level, controller-specific control of the hardware.

The development of intellectual property and ‘know-how’ for a system integrator or machine builder is extremely important. Often a particular motion platform is chosen by a machine builder or specified by an end user, and while the PLC may be readily changed, the motion system is ingrained and represents the single largest cost for a user to request a change of hardware. The cost to supply the same machine with a different motion control system is therefore prohibitive for all but the largest of customers. This is due to the level of integration between the code and the hardware - the program is so specific to that hardware that to recode for a new system and achieve exactly the same behaviour is very time consuming and costly. In fact, some machine manufacturers will not contemplate this change at all, an attitude of ‘get what you are given’ is prevalent from some OEM machine builders.

This portability of code has some caveats, however. For instance, it has not been defined how to transport graphical language code, such as Ladder, between different programming packages. An intermediate language is required at this stage, such as a mnemonic language. This has been defined, however, for the Structured Text (ST) language as the code is portable as ASCII text. It is possible to export/import using text files or use the ubiquitous cut-and-paste method to move ST code between packages. However, once the code has been transported from one package to another, the variables, structures and behaviour of the system will be the same, even if a different controller or servos are used. This is still a very large step forward and will dramatically reduce the programming for a different vendor system. It becomes essentially a manipulation of code, rather than a complete rewrite, that is required.

Figure 2: Sequential motion programming using PLCopen function blocks.

Nonetheless, a system coded with PLCopen function blocks will be instantly much more recognisable and supportable by general-purpose PLC programmers, especially when the code for motion and logic coexist in the one controller. Having a look at a sequence of moves, it can very readily be seen that the function blocks in Figure 2 will trigger four discrete moves on two axes, and the target position and status of each move can be seen at a glance. Also, the current state of the control sequence is visible as the ‘Done’ outputs will turn green as each step is completed and lead to the execution of the next function block. This shows the level of integration between the motion control and logic engines of an IEC61131 and PLCopen Motion Control compliant controller. For contrast, a program for a dedicated motion controller system (based on the BASIC programming language) is shown in Figure 3. Tracing of the GetPart and InPos variables is very easy when the logic and motion controller are united; a dedicated motion controller will require tracing of these variables to the PLC controller, which will likely be handling the remainder of the logic. It is also more difficult to assess which step the motion controller is currently executing, compared with the graphical ladder version of the same program.

Figure 3: Example of similar programming sequence based on a BASIC language system.

There are clear benefits for a combination of logic and motion control engine in the same controller. While PLCopen Motion Control and IEC61131-3 have enabled PLC programmers to take on motion control programming with a relatively short learning curve, it is the combination of the motion and logic engines as well as the standard programming of PLCopen Motion Control which will be responsible for a reduction of total cost of ownership for motion-controlled machines.