For savvy machine builders, distributed motion control is fast becoming the architecture of choice because it uses fewer system components, improves motion accuracy and throughput, and improves diagnostics.
Whedco Inc., GE Fanuc
Ann Arbor, Mich.
Edited by Leland E. Teschler
The trend toward more distributed controls is a departure from the past practice in machine design of eliminating large main control panels and replacing them with smaller, modular control cabinets that can be easily added or removed. This provides smaller or larger systems as control requirements change. Distributed-motion-control systems work well with this design approach because they need fewer components. It's now possible to eliminate most point-to-point wiring with a single unit that integrates the motor, drive, control, and communications. This level of integration completely eliminates field wiring for motor signals and ensures precise positioning and diagnostic information because data are gathered at the source and sent back to PLCs, PCs, and operator interfaces through a wide-bandwidth network.
Integrating the I/O, controller, and networking overcomes many of the disadvantages of computer bus-based systems, such as eliminating the need for separate cards for each function. Hardware is much simpler and the entire system can be programmed with a single software package. These stand-alone controllers provide localized, high-speed control and are highly accurate and reliable.
The localized intelligence of integrated controls and drives also eliminates the need for control amplifier connections, and reduces I/O point-to-point wiring. Even a few connections can quickly produce complex wiring that takes longer to install and debug. For example, standard I/O point-to-point wiring that connects 16 output points from 16 separate motion controllers, such that each of the other motion controllers senses the output state of the other 15, requires 15 input connections to each of the controllers, for a total of 240 separate connections.
This standard point-to-point I/O wiring method makes controls complicated and inflexible and can make information-intensive tasks, such as machine diagnostics, a nightmare. But a distributed-control approach that uses a network connection to each motion controller needs only a single cable. Furthermore, the cable need only pass data, not operating voltage. This reduces electromagnetic interference with other systems and provides substantial overall system cost reductions and greatly improved diagnostics.
A distributed-motion-control system also accommodates preventative-maintenance features. For example, an integrated control and drive can monitor machine wear by comparing current demands in a system from day to day, identifying maintenance needs before the system experiences catastrophic failure.
Several technological trends are improving distributed-motion-control systems. New microprocessors and digital signal processors (DSPs) are faster, have more peripheral functions on-chip, and cost less than their old analog counterparts. Replacing analog circuits with DSPs and integrated controller-driver systems allows designers to use higher-level logic in response to changing operational conditions and improve servo update rates by an order of magnitude. The result is drive systems that are self-tuning, tolerant to a wide range of torque-to-inertia ratios, and stable over time and temperature variations.
Improvements in processing power deliver other benefits, too. As processors shrink, the space required for power electronics diminishes, resulting in smaller packages and more efficient hardware. Faster central processing units (CPUs) also deliver shorter instruction times, faster execution, and greater precision. And increased processing power also allows network connectivity in the controller. Downloading a program directly over the network to the controller drive takes advantage of the increased intelligence of the integrated device. A single controller can now adapt to accommodate different parts, diagnostic routines, and configurations, all via a single connection point to the network.
Control software is also taking advantage of increased processing power. Easy-to-use graphical user interfaces make it simpler for programmers to automate machine control processes. For higher-level systems, distributed motion control can provide a centralized programming environment running on industry-standard Windows 98/2000 or NT. Also, overall system bandwidth increases under the processing power of the CPU in the motion controller. Such an approach provides a single programming environment that shares all variable and tag information while delivering the benefits of a centralized programming environment.
Device-level networks such as DeviceNet and Profibus are adding features that help increase the number of applications for distributed motion control by allowing single-axis controllers to be used in multiaxis applications that require tightly synchronized motion and logic control. In some applications, a distributed, multiaxis motion-control system can be configured and installed at the same or lower cost than traditional centralized multiaxis control systems.
Speed versus bits/sec.
Network performance is critical to successful implementation of a distributedmotion-control network. People often mistakenly use speed on the wire as the prime measure of performance, when in fact there's much more to an effective network than raw data speed. Total system bandwidth and overall utility of the protocol are at least as important as bit rates.
Throughput is the most effective measure of bandwidth, and it is the best way to measure a network system's overall performance. A good working definition of throughput is the time it takes from detection of an event change (input) to actuation (output) based on logical decision making. Thus, throughput is a combination of several factors including protocol efficiency (ratio of data to total packet size), network model (information flow paradigm/number and frequency of messages), baud rate (raw bit speed over the wires), and node processing time.
One of the most popular and cost-effective factory networks is DeviceNet, which is based on the Controller Area Network (CAN) communications protocol. Although CAN was originally developed for automotive applications to allow manufacturers to replace costly wiring harnesses with low-cost network cables, it has proven to be cost effective, rugged, and easy to use in factory automation applications. Because it's based on a "producer/consumer" model of data flow, DeviceNet allows a controller to broadcast commands to the network. This feature enables a single message from one controller to be used by multiple devices, which uses less bandwidth.
Another feature of DeviceNet is that messages contain a service priority. This allows noncontrol critical messages, such as HMI updates, to be preempted by time-critical information such as real-time machine interlocks. Because the messaging was designed for control over relatively short distances (maximum distances of approximately 500 meters) under stringent requirements for high speed and reliability, the low apparent baud rate (up to 500 kbytes/sec) belies the performance of DeviceNet-networks, even when compared to noncontrol networks with baud rates measured in megabytes/sec.
Effective distributed motion control requires a full suite of services. These services reside on the application layer of the network. A single point of connection for all services makes life much easier for the designer, integrator, installer, and operator. Once the machine is connected, configuring the I/O, identifying peripherals, preparing for operation, and controlling the process must be supported, preferably with a common software environment. Because of the intelligence in distributed controllers, diagnostics are easier than ever to include. A distributed-motion-control system is one of the most demanding cases for distributed-control architecture, often requiring extensive configuration, localized intelligence, and complex algorithms to achieve the desired machine performance. Soon, some networks, like DeviceNet, will support services such as I/O messaging to configure axes and file transfer protocols on the same wire with control protocols. A single point of connection and built-in message prioritization will allow this architecture to provide machine designers with a distributed system that is easy to maintain. An effective solution must also include a way to download new programs for all facets of operation. And with the networking options available today, there's no reason why upgrades should be hard to implement.
The ultimate challenge to a control network is adding or removing work cells as functionality changes. Some networks require substantial programming modifications or rerouting of messages when the mix of work cells changes. Data flow can change, causing interrupt errors and disrupting network efficiency. On other networks, an object-oriented model and logical addressing allow the addition or subtraction of work cells without reconfiguration of other network nodes or communication paths.
THE ROLE OF STANDARDS IN DISTRIBUTED MOTION CONTROL
The bottom line in today's connected factory is that machines must be able to communicate with one another. That need is the driving force behind the push for open systems. Openness and interoperability are especially important for motion-control systems because machine designers often need to choose a motion-control system optimized for their specific applications which need to interface with PCs, PLCs, and operator interfaces from another supplier. At its most basic level, an open system must be a nonproprietary standard that is open to multiple vendors, a hardware and software specification to which technology providers can conform, and must define all seven layers of the Open Systems Interconnection (OSI) Reference Model.
However, "commonly available" is often confused with "standard." For example, Ethernet is commonly available but does not define a network standard. The OSI model requires an open network to be defined from the physical media through the application layer. Networking openness is best defined in reference to the Open Systems Interconnection (OSI) reference model.
The OSI model describes seven layers of related functions that are needed at each end of a network link to properly communicate a given message. The bottom layer describes the media (wires, wireless, or optical fiber) that carries the message. The top layer defines the applications that use the data, whether the intended use is machine control, production databases, or HMI. Between the two are defined layers for data linking, network and transmission protocols, session tracking and data presentation.
A complete network is one for which each layer has been defined, from the wires to the software profiles and services. Networks like DeviceNet and Profibus meet this standard and through their organizations ensure that machine designers who use these networks will have a truly open system.
Open specifications allow manufacturers to add features that meet specific needs, without having to implement a complete standard. For example, some stand-alone controllers feature interfaces to different networks. Compliance with each network's specifications lets the controller fit the rest of the network without requiring a full feature set that might increase costs.
Closed or proprietary specifications are usually published by developers and are not generally available to sponsors' competitors. They may use one or more OSI layers from an open standard as a starting point, but diverge from the specs to meet a specific need or to protect proprietary engineering or communications designs.
The chief drawback to proprietary protocols becomes evident when designers need to go outside the sole source network for parts or upgrades. Discontinuing use of a vendor's products and abandoning their closed networking system often requires massive expense, as hardware, software, and sometimes networking media must be replaced. Should the standard fail to keep pace with technology, or should the sponsoring organization switch to an open standard and abandon the proprietary system, users are left to fend for themselves.
It is not enough, however, to specify an open standard as the foundation for a motion control system. Also consider the suite of services and performance required for motion applications, as well as the availability of third-party vendors that can supply components that meet the specs.