One thing's for sure; we are past the heyday of the motion controller as backplane-expansion card with field wiring. There are two main reasons. First is the trouble of finding a consistent source of inexpensive computers that can physically accommodate a given expansion card. The second is the cost, complexity, and unreliability of bringing numerous conductors directly back to the main computer.
One alternative approach is to keep at least a minimal version of the controller as a backplane expansion card, but to simplify wiring by switching to a serial link. Low update rates and lack of determinism in most fieldbus designs confine these links to handling high-level commands for independent drives. This can work well when the motion needn't be tightly coordinated between axes, but can falter if coordination is required. More than a few designs have started down this road, implementing fieldbus links for simple and uncoordinated axes, only to find the approach couldn't handle coordinated axes. Even when coordination requirements are not tight, delays in handshaking between tasks can limit performance in this approach.
A second strategy in the design of motion-control systems is to make the fieldbus the connection between the host computer and motion controller. More options are available here because the required bandwidth and determinism requirements of this link are generally not so high.
Such a fieldbus connection avoids the necessity for having the control board fit in the backplane bus. The expansion card requires cable links to breakout boards because it's impractical to bring field wiring directly to or inside the computer. With the controller outside the computer, there are better strategies for the field wiring.
But fieldbus interfaces are increasingly used for general-purpose I/O control. Here the update rates and determinism requirements are not high. Some of the computer-wire buses also find use as controller-to-drive links. Their higher bit rates and ability to provide deterministic update rates make them candidates for tightly coordinated control.
How the links stack up
Serial links in common use today have several origins; from the personal computer (PC), the industrial I/O, and the servocontrol world.
From the PC world come USB, Ethernet, and FireWire. USB (1) can run 5 m at most, with unisolated electrical transmission. Although the raw bit rate of 12.5 Mbits/sec is quite good, the complex collision avoidance algorithms make the effective bit rate at most 20% of that, or 2.5 Mbits/sec. Achieving synchronous transmissions, especially bidirectionally, is difficult and impossible at frequencies greater than 1 kHz. The second-generation USB (2) promises much higher bit rates and an 8 kHz "heartbeat," but other limitations remain. It should be remembered that the intent of this interface was to connect relatively slow computer peripherals.
Ethernet can have high bit rates (10 Mbits/sec or 100 Mbits/sec) and can go substantial distances. However, its common implementations were not designed with hard real-time applications in mind. It is used more and more in motion-control, but generally not as the controller-to-drive link.
FireWire has seen several noncompatible implementations as controller-to-drive links. It has high raw bit rates of 200 Mbits/sec and 400 Mbits/sec, and an 8-kHz synchronous transfer mechanism. However, it also has complex collisionavoidance schemes that cut its effective bit rate to about 20% of the raw rate. One prominent implementation can control at most eight axes at a 2-kHz update rate. Also the distance between nodes is limited to 4.5 m and there is no electrical isolation. Finally, the synchronous transfers necessary in a servoloop can only happen at 8 kHz with no provisions for change.
Of course, the links designed specifically for motion control can go much greater distances; Sercos can go up to 75 m between nodes, Macro up to 3,000 m. They are designed around a bidirectional synchronous cyclic data-transfer mechanism for smooth operation of difficult profiles and for passing data. They have more variable cycle update rates than most other mechanisms. In addition, optical fiber provides complete electrical isolation.
However, Sercos' relatively low data rates (2 to 8 Mbits/sec) often force the loops to be closed in the drive. For this reason, all Sercos drives must support sophisticated positioning functions, even if they are not used in a given application. This boosts the cost and complexity of the drives, and the difficulty of setup.
Macro's high data rate (125 Mbits/sec) permits a fast loop update rate. This, in turn, permits use of a simple protocol and lets the central controller close all loops. The processor at the remote slave station (if required) need only copy data between the ring registers and the machine-interface I/O registers, and monitor the ring for failures. These processes are simple enough to be handled in ASIC circuitry if their routines needn't change.
Macro thus provides the best of both worlds: highly distributed hardware to simplify wiring and centralized software to simplify intertask communications. Designers have employed distributed hardware solutions for many years to simplify system wiring. Many have mistakenly believed this approach requires highly distributed software, which in turn depends on complex, highlevel protocols to communicate between tasks.
A link such as Macro lets centralized software handle such applications. It eases implementation of tasks that would be difficult, if not impossible, in a distributed system: control laws that are cross-coupled between axes, adaptive control schemes that depend on the states of multiple axes, and the like.
From kilobits to megabytes in 30 years
Traditional wire communication links such as RS-232 and RS-422 have been around for over 30 years. The earliest motion controllers typically used one of these communication links, whether just for configuration in a stand-alone application, or actively during use. These links are still used if the required communication bandwidth is not great. However, the fact that most implementations cannot exceed 38.4 kbits/sec and almost none exceed 115.2 kbits/sec makes these links impractical in many applications.
Backplane buses emerged in the 1980s. Motion control applications adopted them in the 1990s, with ISA, VME, and STD buses predominant at first, followed by the PCI bus. A key virtue of these buses is the simple method of addressing different devices: with only a little extra logic, the same processor doing the computation could directly address different devices on the bus. There's no need for a dedicated processor to manage backplane-bus communications, unlike most wire links.
Some of the thorniest issues have been in form factor. A backplane-expansion board may no longer fit a specific computer because components may be in the way, or there are fewer expansion slots. Special industrial buses such as VME or even industrial PCs avoided many of these problems, but lost the low cost of the high-volume office market.
The need to connect peripherals with high-speed links brought networks such as Universal Serial Bus (USB) and Apple's FireWire, designed with digital video applications in mind.
From the industrial world came a different class of networking: fieldbus systems were designed to simplify and reduce wiring between controllers, sensors, and actuators. They replaced the parallel wiring of traditional systems, along with their large and long wiring bundles.
A typical fieldbus uses serial communication, daisy-chaining many devices on a single
cable. Each device requires some intelligence to handle issues of addressing, protocol, and arbitration. Most fieldbus designs are optimized for discrete I/O devices.
The most common fieldbus format is CANbus out of North America and Profibus out of Europe. There are several software protocols using the basic CANbus format, the most common being DeviceNet and CAN Open.
A couple of wire links have been designed especially for controller-to-drive interface. These are distinguished by built-in features for cyclic, bidirectional data transfer, and real-time determinism. The first was Sercos, developed in Germany. Originally running at 2 Mbits/sec and more recently at 4 and 8 Mbits/sec, it uses an optical-fiber ring topology to connect the controller to drives. The cyclic update frequency of the Sercos ring is not high enough to close loops across the ring, so Sercos drives must interpolate positions between each command, plus close all servo loops and perform any required commutation. This requires sophisticated and relatively expensive drives, plus a complex protocol to handle all the gains and modes.
Macro (Motion And Control Ring Optical), developed in the U.S., has a data rate of 125 Mbits/sec and updates fast enough to close loops over the ring. Remote nodes can be inexpensive and simple, as is the communications protocol. Macro employs base technologies developed for 100-MHz Ethernet and Fiber Distributed Data Interface, adding protocols and timing suitable for the hard real-time requirements of motion control.
Curtis S. Wilson, Vice President of Engineering and Research • Delta Tau Data Systems Inc. • Chatsworth, Calif.