Making sense of motion networks

Which bus? Which protocol? Need a network at all? Here are some answers. 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 to a local robot controller which then interprets and executes the command. 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