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.

By Chuck Lewin December 2, 2013

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

Machine controller cards

The major alternative to distributed drives is a machine controller card, also called a motion control card. The distinction is that a motion control card connects via a backplane bus to a separate motherboard or processer card, but here we will refer to stand-alone single-card controllers and backplane motion cards as machine controller cards.

In the machine controller approach a microprocessor holds the machine’s application code, and a motion controller IC, also called a motion processor, generates profiles, does servo loop closure, and manages the time-critical elements of axis control. Note that it is possible, particularly for simple control applications, for the machine application microprocessor and the motion processor to be one and the same.

The advantages of the machine controller card approach are many-fold including easier serviceability since repair of the entire controller card is a simple swap-out. Another advantage is reduced wiring since the amplifiers are located on the card. Finally, the physical form factor of the card along with the connector interfaces can be tailored to suit the application.

There are two major variations of machine controller cards: off-the-shelf and custom built. Off-the-shelf cards, particularly bus-connected motion cards, have been around for a long time and are available from several different vendors.

Custom built cards, while more work on the design side, are also a strong choice. The most important trend here is integration of the amplifier, either IC or module-based, directly onto the card.

Another trend is use of off-the-shelf IC-based motion controllers. These units provide profile generation, servo loop closure, commutation, and a myriad of time-critical functions such as automatic safety responses, programmable breakpoints, and other types of automatic motion axis management.

How to choose a network

Here’s how to select a motion control network. Certain factors may make one architectural approach more suited than another.

When considering a distributed motion network, try to anticipate the kinds of signaling that will be required in your application. Does the behavior of the motion depend on the status of signals located on another part of the machine? Will you place sensors, and other non-motion controlled actuators, such as relays, on the network bus? How quickly does the motion have to shut down if an error occurs?

Another important consideration regarding how, and how much, you can use a network-based approach is the mechanical organization of the connected machine. This issue addresses questions such as, “How will the machine be serviced if electronics are physically distributed throughout the machine?” Although the traditional card rack that the technician services may be a mess of wires, there is something to be said for keeping everything under one roof. Serviceability and lifetime ownership cost strongly affect control system design choices.

Remember also that distributing the control by placing amplifiers near the motors may not always be feasible for weight, heat, or other environmental reasons. The traditional control rack cabinet can be air conditioned and insulated from the machine operating environment. This is often not possible if the controls are distributed.

When is one control approach used over another? There is no easy or simple answer, and sometimes two architectures can be used equally well for a given application.

In broad terms, the more cost sensitive the application, the more likely it is that the person designing the motion application will design a card and, depending on power level, integrate on-board amplifiers. When designing a card, it is possible to choose exactly the connectors needed and set the form factor of the card for that particular motion application.

Highly synchronized applications such as machine tools will gravitate toward multi-axis motion cards or a tightly coupled distributed drive approach. These drives allow a lot of flexibility in motor type and power range. Don’t forget that a motion control card will be needed for overall path generation, or you will use a PC running dedicated G-code software.

A large middle ground of applications, such as medical automation, semiconductor automation, scientific instrumentation, and low-power general automation, can be served by several approaches including off-the-shelf machine controller cards, custom-built machine controller cards, or loosely coupled distributed drives.

– Chuck Lewin is founder and vice president of engineering, Performance Motion Devices. Edited by Mark T. Hoske, content manager, CFE Media, Control Engineering, mhoske@cfemedia.com.

ONLINE

At bottom of this article, look for related articles on motion control.

Key concepts

  • Understanding motion architectures can help with machine design and network selection and design.
  • Two motion control devices include distributed drives and machine controller cards.