Distributed Motion Control: A Worthy Option for Connectivity
The trend toward distributed motion control is driven by one basic concept—by reducing wiring, costs can be lowered and reliability increased. However, before you get involved in making the multitude of choices regarding network buses, protocols, and a host of technical issues, you will need to determine whether distributed motion makes sense for your application.
The trend toward distributed motion control is driven by one basic concept-by reducing wiring, costs can be lowered and reliability increased.
However, before you get involved in making the multitude of choices regarding network buses, protocols, and a host of technical issues, you will need to determine whether distributed motion makes sense for your application.
In the end, it is the architecture and physical configuration of your machine that will dictate whether, and how, you distribute the control. Cost savings and flexibility offered by distributed control could be substantial, but the key is knowing when it can save money and which solutions will work best in your application.
Physical configuration of the specific machine or system will determine if the
choice of distributing motion control translates into significant wiring cost
savings. Start with a comparison of basics.
Distributed vs. centralized
A ‘classic’ centralized motion control architecture and a distributed architecture are compared in the first diagram. The centralized approach commonly uses a multiaxis servo or step motor card (or controller) that outputs
The distributed approach gives more intelligence to the amplifier (bottom of architecture comparison diagram). The PC has no motion control card; instead it sends commands over a network bus to the amplifiers that receive and process the commands. These amplifiers then close the servo loop, and typically perform some trajectory generation as well.
To gain the benefit of less wiring, the amplifiers should be located near the motors. In the ultimate distributed control model, the amplifier and motor are combined into a single ultra-integrated unit-completely eliminating any external wiring between the motor and the amplifier (see sidebar). This type of unit is sometimes called a ‘smart’ motor or integrated motor.
With either architecture, additional motion control functions can be executed in the main computer, but that discussion belongs elsewhere, under the topics of PC-based control and ‘soft motion.’
Hierarchical motion control architecture clusters several motion axes into functional groups.
Choice of distributed control hinges on three basic factors: the architecture of your control application, sensor interactivity requirements, and mechanical configuration of your system.
Architecture- means the native organization of the control system. Broadly speaking there are ‘flat’ motion control applications, where a number of motors must all be controlled more or less equally by the central PC, and there are hierarchical applications, where the motion axes are clustered into two, three, or more functional groups. (The term ‘PC’ used here means the software program that exerts overall control over the machine, but this could be a microprocessor, or even a PLC.)
A printing press incorporating multiple servo-controlled spools is a good example of a flat motion control system. For this application, timing is critical, and the central source of logic must drive all axes synchronously (see Flat Architecture diagram). Distributed motion control for such an application requires higher bandwidth with highly deterministic network buses.
For an example of a hierarchical application, consider a wafer handling system with a central robot (four axes), a wafer aligner (three axes), and a valve (two axes) working together to move a wafer from one point to another.
In this architecture (hierarchical diagram), the distributed network typically connects module controllers, which are themselves made up of a traditional centralized motion controller. To distribute the control for an application like this, less synchronized networks with less determinism may be used.
Sensor interactivity- When assembling a distributed system, try to anticipate the kinds of sensors required in your application. Does the behavior of the motion depend on the status of signals from another part of the machine or system? 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? Depending on the answers to these questions, it may be possible to place some of the system under distributed control, or none of it, or all of it. These answers will, at a minimum, influence the type of network bus used.
Mechanical configuration- The distributed approach should, in theory, result in higher reliability due to reduction in wiring. However, this is not a universal rule. Consideration of the mechanical and kinematic organization of your machine will ultimately answer such questions as, ‘How significant are the cost reductions in wiring?’ and ‘How will the machine be serviced if electronics are physically distributed throughout the machine?’
A cost reduction analysis must look at the entire machine system cost, which includes the cost of servicing the unit once it is in the field. Although the traditional card rack may be a mass of wires, for service considerations, there are benefits to keeping everything ‘under one roof.’
In addition, placing amplifiers near the motors in a distributed system may not be feasible because of weight, heat, or other environmental factors. Also, integrated servo motor and controller units have some size (power output) limitations. The traditional control rack cabinet can be air conditioned and insulated from the machine environment relatively easily.
The network bus jungle
Distributed controllers generally use a network bus to reliably connect the PC with the amplifiers and other components residing on the network. Once you have considered the design issues outlined above, you will need to select the appropriate network bus.
Network buses, which are used for distributed motion control, tend to have some common features. Compared to purely data transmitting buses, such as Ethernet, they tend to have deterministic response times. In addition, data transmission speed is faster than older ‘multi-drop’ networks, such as RS-485. Typical network data rates exceed 1 Mbit/sec, even approaching 1 Gbit/sec for the newest buses, such as Firewire.
Generally speaking, the network bus world is divided into lower-level buses called device networks , and higher-level buses called field networks . Device networks are designed to communicate among fairly simple sensors, actuators, and ‘smart’ amplifiers. This group includes CAN-based buses (such as CANopen, DeviceNet, and Profibus) as well as LonWorks. Fieldbuses are designed to provide higher data rates and more sophisticated data management; these include FOUNDATION fieldbus and Ethernet, among others.
Very few of the buses adhere to rigid definitions, however. For example, some companies now use Ethernet, typically thought of as a non-real-time data bus (but touted for speed), as a device-interconnect bus. Conversely, lower level buses are being expanded for higher data rates and greater data management capability.
Entirely new buses, whose future in motion control is still undecided, are also coming on the scene. Most interesting in this group is Firewire (IEEE-1394), expected to reach high volumes, and thus low cost per node, because of its use in the PC world.
If network transmission methods are many and varied, motion-focused protocols are few and far between. What protocols do exist, typically do not cater to motion, often encompassing sensors and other actuators that are not as sophisticated as motion controllers. Most popular in this category are DeviceNet and CANopen, protocols hosted on the CAN network. DeviceNet is well defined, so that today it is possible to buy DeviceNet-ready sensors and components off-the-shelf. A fully accepted standard for motion control over DeviceNet does not yet exist, however, so many users, who choose DeviceNet, build custom motion extensions.
One dedicated motion protocol worth mentioning is SERCOS (IEC 61491). This protocol uses a custom physical layer-based on a fiber-optic interconnect-and defines a complete motion-ready set of commands. Intelligent drives or amplifiers based upon SERCOS are available from a number of U.S. and European vendors. SERCOS is mainly used in larger drives and seldom finds application in low-power or low-cost systems.
Four application types
A brief look at a few types of motion applications reveals how their controls might be distributed. While not an all-inclusive sampling, these applications show a fairly broad spectrum of industries and products using motion control. The application types will be called: conveyor belt, all-in-box, cell controller, and synchronized multi-axis.
Conveyor-belt motion- includes applications in packaging, factory-floor automation, continuous flow processing, and some medical systems that take place in relatively large spaces over some distance. Common to these systems is a variety of actuators (including servo motors, cutters, pistons etc.) and a multitude of signals to start, stop, or change speed of the motion. In these applications, the primary motion elements tend to be stand-alone drives or intelligent amplifiers, which power a single motor, and which are linked to other sensors, actuators, and motors through a network, such as a CAN-based network or Ethernet. Since sub-millisecond synchronization is generally not required, the network reduces the cost of wiring across relatively large distances.
All-in-box machine- applications include semiconductor and medical robotics, pointing systems (including camera pointing), and scientific instrumentation. These systems tend to be highly engineered machines in which size and performance are the primary factors. Space is at a premium with sizes ranging from around a cubic foot to closet-sized.
With this kind of application, a serious question arises whether networking is warranted, because distributing electronics throughout the machine often causes more servicing problems than it solves. If networking is indicated, then one of the device networks is best, such as CAN, possibly using one of the sensor protocols like DeviceNet or CANopen to make the job of talking to off-the-shelf components easier.
Cell controller- applications include batch-oriented cell controllers, semiconductor cluster tools, some general automation, and some medical systems. This processing system is made up of two or more relatively autonomous, intelligent processing units. A network is used to communicate between each processing unit (each being an all-in-box machine). In this application, the network performs relatively little real-time synchronization, while it handles fairly large amounts of data. Ethernet or FOUNDATION fieldbus would be good choices.
Synchronized multi-axis- applications focus on machine tools, plotters, and measuring machines. Such machines perform highly synchronized, multi-axis motion, making SERCOS a good choice. The more adventurous might choose a bus such as Firewire with its high throughput. Unlike SERCOS, however, there is as yet no multi-vendor motion protocol defined for Firewire. Also, if you choose Firewire, or any network economically driven by the information-processing (IP) world, beware that product life cycles are shorter than in the industrial world. When the IP world moves to the next ‘hot’ technology, will buses such as Firewire still be supported?
In summary, industry discussions over distributed motion control have traditionally focused heavily on choice of network bus. However, before arriving at a choice of network bus, the design engineer (or machine user) must first consider the application-specific factors of control architecture, sensor interactivity, and machine configuration.
By starting with a thorough understanding of the machine’s data throughput, control latency, and serviceability issues, you will be able to choose the network scheme and protocol that best meets the particular needs of your application. No ‘one size fits all’ network exists on the market today, so selection should fully consider expansion and reorganization of the controller in the future. Be sure to look at wiring cost reductions in the context of related issues, such as serviceability, when determining how much of your system should go distributed.
|Chuck Lewin is chairman of Performance Motion Devices Inc., Lexington, Mass.|
Ultimate motor/controller distribution
In the last five years or so, the concept of distributed motion has been pushed to its ultimate limit by combining themotor, amplifier, servo controller, and feedback device into one unit. These integrated or ‘smart’ motors can tremendously simplify wiring, but consider all factors before committing to this solution. Integrated motor/controller packages can be relatively expensive compared to more traditional motion approaches.
Compare the alternatives equally, that is, on an installed system cost basis (wiring, separate enclosure, installation labor, etc.).
In addition, motor/controller combinations have some significant limitations, such as use of proprietary, lower bandwidth networks. At the same time, few can deny the appeal of this ‘easy-as-Lego’ motion control approach. As technology and price/performance improve, these devices will claim a bigger portion of the motion control pie.
What’s happening with SERCOS?
At motion control forums, the perennial question in networking is ‘what’s happening with SERCOS?’ After much discussion and years of waiting, the verdict is in. SERCOS (IEC 61491) is neither going to become the universal choice, not will it become obsolete or irrelevant any time soon. SERCOS (Serial Real-time COmmunication System), developed originally in Germany by machine-tool manufacturers, has slowly worked its way into the wider motion market wherever high-speed, tightly synchronized motion is a requirement. The future of SERCOS includes hosting over Firewire, as well as extensions to support non-motion components, such as I/O devices and sensors.