Motion control: To network or not to network?
Inside Machines and Embedded Systems: Understanding how motion control architectures fit a particular application also can help in deciding what motion control network should be used.
Motion control is the art and science of controlling motors to affect a precise movement profile, and understanding motion control architectures can help in determining if or when a motion control network should be used.
Whether used to move test tubes or to cut metal, motion controllers plan the trajectory, drive and monitor the motors, and provide regular status updates to the higher level controller. Two primary control architectures are used for the design of motion control systems; centralized and distributed. With the introduction of high-speed, low-cost digital control networks, new choices are available for building distributed control systems. And with the advent of ever-higher power and more compact switching amplifiers, centralized designs are increasing how much of the controller can reside on one printed circuit card.
Understanding these technology trends can help explain how and when these two different control architectures should be used in a particular motion control application.
What shape is the motion application?
The nature of the application's control problem has a major impact on which control approach, centralized or distributed, will have the edge in an application.
Broadly speaking, there are flat motion control applications where a number of motors will be controlled more or less equally by a central PC or controller; there are hierarchical applications where the axes are clustered into 2, 3, or more functional axes; and there are stand-alone applications where the machine controller operates largely or entirely without network connection and oversight. Figures 1, 2, and 3 show this.
An example of a flat motion control problem is a printing press with multiple servo-controlled spools. In this application timing is critical, and the central controller, usually a PC or PLC, must drive all axes in synchrony. Typical commands in such a system are “move axis #1 to position X, move axis #2 to position Y,” etc.
An example of a hierarchical motion control application is a semiconductor wafer handling system that has a central robot (4 axes), a wafer aligner (3 axes), and a valve controller (1 or 2 axes). In this architecture the network typically connects the local robot or valve controllers to a central network, but the actual motion control is local to the robot, aligner, or valve. Thus the overall machine controller doesn’t give commands such as “move robot axis #2 to position 12345,” it gives commands, such as “extend robot arm,” which the local robot controller interprets and executes.
An example of a stand-alone application is a tape archival system that allows an operator to walk up to the control panel and request a specific tape for retrieval. Here the stand-alone machine controller may execute a whole sequence of arm moves based on a local user-provided command such as “retrieve tape # 1234.” In this approach a network, if one is connected, is used for reporting and monitoring rather than active control.
Plug in distributed motion drives
After understanding the “shapes” of control applications, it’s important to understand the options for the physical devices that can be used in a motion control system. Two will be covered here: distributed drives and machine controller cards. There are many variations of these devices, but they all boil down to just one of these two physical device types.
Distributed motion control drives, sometimes also called intelligent amplifiers, communicate to a central host via a network and provide a suite of motion controller features, such as profile generation, loop closure, and amplification.
Depending on the application required, two kinds of distributed drives are used. The first can be referred to as a tightly coupled drive, and uses high-speed, deterministic networks such as SERCOS, EtherCAT, or Ethernet Powerlink. The second can be referred to as a loosely coupled drive, and uses slower speed networks such as Ethernet, CANBus, and RS485.
Tightly coupled drives require a motion card, or a PC running special software, to synchronize and coordinate the motion of each axis. Each drive receives rapid, synchronized, position, and/or velocity updates, generally several hundred, or even several thousand times per second.
Loosely coupled drives are also controlled from the host, but assume more profiling capability in the drive and greater latency. In this architecture, commands are sent to each drive such as “move the axis to position x using a point-to-point s-curve.” Interactions in those drives tend to be more autonomous and use local sensor inputs to stop and start motion.
Choosing a motion network
Networks that can connect to these devices can be dedicated motion-only networks, such as SERCOS, or networks that can be used for motion as well as other functions. These general purpose networks include RS485, CANBus, EtherCAT, Ethernet Powerlink, Profibus, Interbus-S, and Ethernet.
While we are looking at networks for motion control, what about the protocol that we will execute on these networks? The most popular is CANopen, which is a protocol that is hosted on the CANBus network, and also on EtherCAT. With this protocol it is possible to buy off-the-shelf CANopen-connected sensors and motion drives.
Unfortunately, a fully plug-and-play standard is not quite a reality yet. This is because many vendors build CANopen motion extensions into products, making them incompatible with other vendor's products.
The options can be confusing, but for most users designing a machine, bus choice really comes down to three choices: RS-485 (yes, the old standby), CANBus/CANopen, and Ethernet or one of the deterministic Ethernet variations (EtherCAT or Ethernet Powerlink).
See next page for more about machine controller cards, and how to choose a motion network