More end users are asking for robots, motion controllers, and programmable logic controllers (PLCs) to be programmed in familiar PLC languages, which are easier for machine builder programmers to understand, and for end users' service personnel to maintain. To reduce the complexity and harmonize the look, feel, and function of three separate platforms, the PLCopen working group for motion control has come up with a set of standardized tools to allow coordinated motion to be run directly from a PLC-like programming environment.
Traditionally, industrial robots have been programmed in complex proprietary languages that are difficult for anyone but robot programmers to understand. Motion controllers are wide and varied, and are usually programmed using a PC library or another proprietary language, while PLCs tend to be programmed in ladder logic. In today's automation environment, PLCs, motion controllers, and robots must be tightly integrated. Many elements are incorporated into the machine design with each requiring the programming strengths exhibited by a proprietary language.
PLC programming
Since their inception in 1968 through a request by General Motors (to come up with a way to replace hardwired relays), PLCs have been programmed in ladder logic. They can easily control processes that require digital and analog devices, but more complex processes that are sequential in nature are more difficult than they would be in programming languages such as BASIC, C, or C#. PLCs have evolved to include programming in BASIC or C, but most still rely on ladder logic [among the IEC 61131-3 programming languages].
Many low-end PLCs support motion control via step and direction outputs. Some higher level motion control can be achieved through expensive dedicated modules that must be added to the basic system. Even though most devices are programmed in ladder logic, most require an intimate knowledge of the programming environment, which changes from manufacture to manufacture, and their higher level functions are usually achieved through specialized function blocks.
Motion controllers
Motion controllers for the general market typically include interpolated motion (linear and circular), coordinated motion, gearing, camming, and event triggered motion (where a sensor and position latch are used). Older controllers used dedicated inputs and outputs per axis. Motion inputs such as enable, over travel limits, and encoder inputs (one or two per axis) and motion outputs like servo command (normally +/- 10 V analog) and/or stepper command (step and direction) were provided. Most controllers also have some general purpose I/O capability. New controllers rely on digital networks like EtherCAT [EtherCAT Technology Group] or Mechatrolink [Mechatrolink Members Association] to pass control signals to the drives and receive and transmit the digital IO connection, which is wired directly to the drive.
When dealing with the motion on linked axes, the typical motion controller cannot compete with robot controllers. With typical motion controllers, if the end effector had to move to a specific point, it was necessary to figure out the correct positions for each of the axes. Inverse kinematics is needed for robots and other machines with mechanically linked mechanisms. The use of inverse kinematics requires formulas to translate the specific point in world space to the individual positions that each joint (or axis) needs to be at to move the mechanically connected mechanisms to the end point. Again, as these systems are wide and varied, most require an intimate knowledge of a specific programming environment.
Robotic controllers
Robot controllers have been engineered to achieve the best control of specific complex mechanisms. Most controllers are manufactured for a specific device and are programmed in a specialized language created by the manufacturer that varies greatly from platform to platform. Robot controllers are very efficient when controlling the library of devices for which they were designed; however, most are not the best in terms of communications, integration, or programming power.
Goal of the PLCopen standard is to allow programming independent of the hardware or specific manufacturer. When hardware vendors support the same underlying code, and behave in the same manner, the programmer is free from learning proprietary languages associated with each manufacturer.
In the past, often only the dedicated robot controllers supported kinematics and inverse kinematics. Now, it's a lot more common for many motion controllers to offers some subset of robot-type commands, especially in controllers targeted for packaging automation. The lines are being blurred between robot controllers and motion controllers, but it is still up to the programmer to coordinate between these different systems, with each programmed in a different language usually designed for a specific purpose.
PLC and motion together
The PLCopen working group for motion control has standardized and logically defined all aspects of machine control programming. This is one of the best attempts of marrying PLC, robot, and motion control in one easy-to-understand language that is common among many manufacturers.
Many of the function blocks are basic; for example, relative and absolute moves are function blocks which are easily understood in any motion control system. The standardization and common look and feel of multiple control systems is an advantage when the difficulty of the required motion increases. For example, it is easy to string relative or absolute moves together when each individual move stops before the next move begins. But imagine a more complex set of movements where the axis is required to transition to the next move at some nonzero velocity, blending the individual moves into one fluid motion throughout the entire path of the axis. PLCopen Motion Control defines standard blending operations to allow the programmer to achieve this fluid motion with common blending and transition modes that a manufacturer can implement.
One of the basic issues when moving multiple axes together with a mathematical model that controls mechanically linked axes, is that it is not always clear which axes are critical to move in synchronization. So when a fault occurs, the motion controller cannot always tell which other axes are affected. PLCopen addresses this by defining a motion group, so that the controller can generate a proper error response when one of the grouped axes has an error. This grouping concept allows the programmer freedom to concentrate on the specific task required of the machine and have the controller take care of the function of the group through implementation of the group state machine shown in the diagram.
The PLCopen motion standard includes part four, which contains function blocks for coordinated motion. They define a standardized set of function blocks for the complex control of movement within 3D space that includes blocks for kinematic transformations. Typically, these transformations have to be supplied by the vendor, so for most manufacturers, if the motion controller doesn't support it, it cannot be added.
There are the basic supported mechanisms like SCARA and delta, but in addition to these, any programmer is allowed to write his own kinematic transformations. Specialized functions are available to call these kinematic routines whenever a world position needs to be converted into joint space, or vice versa.
This standard is now creating a bridge between the once separate worlds of PLCs, computer numerical controls (CNCs), robotics, and motion. It is now possible to program the complete control of the machine from one PLC-like system. This standard has allowed robots and motion controllers to become integral parts of a control system, rather than independent systems. They integrate motion control and logic control, the two primary requirements for modern machine control. There are definitive advantages to having 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 synchronization between a robot and additional servo axes using a machine controller, a feat which was previously possible purely in the robot controller domain.
Programming independence
Ultimately, the goal of the PLCopen standard is to allow the program code to be independent of the hardware or specific manufacturer. When different hardware vendors support the same underlying code, and behave in the same manner, the programmer is free from learning proprietary languages associated with each manufacturer. This results in allowing complex complete machine control systems with improved accuracy and throughput to be developed in a shorter time to market. PLCopen has allowed this development by reducing engineering complexity and the specialized training required so that the overall system is more familiar to wide array of existing PLC programmers.
- Jamie Solt is senior motion product engineer at Yaskawa America Inc. Edited by Mark T. Hoske, content manager, CFE Media, Control Engineering, mhoske(at)cfemedia.com
