|Recent developments in motion networks include motion processors that directly support a network node connection. Motion processors are dedicated ICs that process motion language commands such as move to this location or start the motion after this signal goes active, and include special hardware that lets them directly interface to dc-servo, brushless-dc, or stepmotors.
One such product is the MC58000 Series from Performance Motion Devices Inc. It provides all the usual motion functions such as profile generation, servoloop closure, and commutation, but adds a complete CANbus network connection that simplifies construction of low-cost, multiaxis motion networks.
Performance Motion Devices Inc.
Distributed motion-control networks have gained acceptance as a way to simplify wiring, lower cost, and boost reliability of certain machines and processes. But finding the right network architecture for the job and sorting out the related technical issues can be a challenge.
Architecture, in this context, is the structure and organization of a control system. Broadly speaking, there are two types of control architectures: flat and hierarchical. Flat architectures use a central PC to (more or less) provide equal control to several motors. The central PC could be a software program, a microprocessor, or PLC. An example of a flat motion-control system is a printing press with multiple, servocontrolled spools. Because timing and latency are critical metrics in such a machine, a central controller (often a PC or PLC) drives all axes in synchrony by issuing commands such as move axis #1 to position X; move axis #2 to position Y.
A typical semiconductor wafer-handling system built around a hierarchical architecture may include a four-axis central robot, a three-axis wafer aligner, a one or two-axis valve controller, various "pancake flippers," and other mechanical actuators. The network connects a central PC to local controllers that handle the various components. The central PC does not, for example, directly command a robot axis to a particular position as it does in flat architectures. Rather, it issues higher-level commands such as extend robot arm to a local robot controller which then interprets and executes the command.
The lay of the LAN
When planning a motion system, try to anticipate the kinds of sensors and signals needed to make it work. Does motion depend on the status of signals coming from another part of the machine? Will sensors and other nonmotion-controlled actuators such as relays reside on the network bus? How quickly must motion cease when the system encounters an error? Answering these questions helps determine what components belong on a motion network and, at a minimum, influences the choice of network type.
Also, look at how a machine or process is physically organized. Serviceability and lifetime ownership costs strongly affect control-system design choices. For instance, distributed-control schemes that place amplifiers near motors may not always be feasible for reasons of weight, heat, or other environmental factors.
In contrast, cabinets that house traditional control racks can be air conditioned and insulated from the machine environment in most cases, advantages that may offset the complicated wiring associated with the approach. Machines with electronics distributed throughout can cost less to build than those with external controls, but the anticipated savings should be weighed against the cost of servicing the equipment in the field.
Profibus, Foundation field bus, USB, Sercos, and LonWorks: these buses are rarely used for most general-purpose motion networks, with the possible exception of Profibus in Europe. Sercos, for example, was originally developed in Germany for machine tools but has since expanded to serve other applications needing high-speed, tightly synchronized motion. Sercos uses a custom physical layer and includes a complete motion-ready set of commands. Sercos-enabled intelligent drives and amplifiers are readily available, though the drives tend to be larger and fairly expensive and seldom find use in low-power (<1 kW) or low-cost systems.
The more likely candidates for general-purpose networks -- especially for companies building their own machine controls rather than purchasing turnkey proprietary motion systems -- include Ethernet, CANbus, RS485, and FireWire.
Ethernet's big claim to fame is speed: It supports data rates from 10 Mbits/sec to 1 Gbit/sec. Low cost is another plus thanks to the hardware being sold in high volume. Recent microprocessors are capable of real-time I/O as well as hosting a complete Ethernet protocol stack. Ethernet is not deterministic in its native, full protocol mode, though it can be made more so by stripping away some of the higher-level layers. In fact, the biggest drawback to Ethernet is its complex protocol layers. These may not be a problem when communicating with multiaxis robots or intelligent controllers, but may become a nuisance when the distributed module is supposed to be simple and cheap.
Ethernet has traditionally been the network of choice for interconnecting intelligent standalone modules. But some modern motion systems now include Ethernet "inside-the-box." Helping to make this possible are microprocessors such as the Motorola Coldfire family that provide dedicated control functions as well as Ethernet connectivity all on a single chip.
CANbus was first developed for use in automobiles and has since evolved into a device-level interconnect bus suitable for medical automation, packaging, liquid dispensing, and other general automation tasks. Motion users have embraced CANbus because of its robustness and ease of use. DeviceNet and CanOpen protocols run on CANbus can access standard, off-the-shelf sensors and actuators. CANbus is probably the most widely used bus for "inside-the-machine" networking. It's slower than Ethernet but faster than RS-485.
The RS-485 bus and its cousins RS-422, and RS-232 are often used to communicate between motion modules. Many all-in-one integrated motors incorporate RS-485, for example. What these low-tech asynchronous serial buses lack in protocol sophistication and automatic error checking, they make up for in simplicity and low cost.
FireWire (IEEE 1394) was developed by Apple Computer for use in video processing. A number of motion vendors refer to FireWire as the "ideal" motion bus because of its high speed and determinism, though users building their own network-based control systems generally don't use it. FireWire has a cable-length limitation of 10 ft, depending on data rate, and is extendible with repeaters. It is commonly used in highly synchronized applications such as machine tools. Both FireWire and USB tend to have steep learning curves which is probably one reason why system builders don't use them more.
While not an all-inclusive list, the following applications are representative of industries and products that use motion-control networks.
Conveyer belt -- Typical applications: packaging, factory-floor automation, continuous-flow processing, medical-liquids analyzers.
Conveyors involve the control of actuators, servomotors, cutters, and valves over relatively large distances. Networks greatly simplify wiring and control costs in these far-flung arrangements. Primary motion elements include stand-alone drives or intelligent amplifiers that control a single motor, which themselves loosely link to other sensors and actuators. Submillisecond synchronization is generally not needed, and interactivity tends to be localized and autonomous. Conveyors would be well served either by CANbus or one of the higher-level protocols such as CanOpen or DeviceNet. Ethernet is also an option, especially if Ethernet-based off-the-shelf actuators are available.
Stand-alone machine -- Typical applications: semiconductor and medical robotics, pointing systems, scientific instruments.
Stand-alone machines typically range in size from a few cubic feet to about closet-sized. There is some doubt as to whether networking is even warranted in these cases because distribution of electronics throughout a machine often causes more servicing problems than it solves, despite a total reduction in wire count. If networking can be used to advantage, however, then CANbus may be a good choice. Ethernet would make sense for remote communications.
Hybrid controller -- Typical applications: Chemical processing, pharmaceuticals, semiconductor equipment, general automation, medical systems.
Hybrid-controller applications include both standalone and conveyor-belt-type control elements. They blend communications between intelligent modules with direct control of device-level actuators and sensors. Ethernet, CANbus, or RS485 can work in this application, depending on the required bandwidth.
Synchronized multiaxis -- Typical applications: Machine tools, plotters, measuring machines.
Sercos may be a good choice, and for the more adventurous, FireWire. Be aware that a traditional multiaxis card-based centralized controller may be every bit as cost effective and reliable as a distributed controller for this type of application.