Cover Story: High-Performance Motion Control
Networks Take High-Performance Motion Control to the Next Level
Networks simplify software development, axis coordination, code updates, and system characteristics.
by Rob Pearce, Senior Hardware Design Engineer and Dusty Schafer, Manager of Software Engineering, Danaher Motion
If you design machines that include a few independent motors, you most likely do not need to network the motor controllers, or drives. Software can simply command the independent drives to move a set distance or number of degrees. But when products such as pick-and-place machines, semiconductor-processing apparatus and other precision equipment require multiple drive "cooperation" with motion coordination, networked control becomes a must.
Here's why: Suppose you must create a machine that will include an X-Y gantry to move components from place to place. You could decide to put controllers in each drive and have each one tell the other where it is. Or you could choose a single programmable motion-control system and have it send an X-axis command to one drive and a Y-axis command to the other over a network.
The latter approach offers simplicity and flexibility because you need not specify exact machine functions before you start the machine's design. At a later point, you can decide the velocity, acceleration, and other characteristics for each axis and you can define how the axis drives will interact. Using a hard-wired design locks you into specifications that might change, but the use of a networked controller lets you "future proof" a design and easily add I/O devices or motor drives as needed.
Networked drives also simplify software changes to control algorithms because you can quickly download firmware changes and updates over a network. Non-networked drives must be pre-loaded by the manufacturer with the firmware needed to operate an attached motor. After the drive is shipped, a user can upgrade the firmware either by sending it back to the factory or by using a special dongle and software to "connect" with the drive and download new firmware.
If a large machine requires many motors, a networked system could start to run out of processing capability in the central controller and bump into bandwidth limits on the network. But designers could address that situation with several controllers that link two or more motion-control networks. So, there's not much of an argument against networking.
Some design teams also use a central controller--perhaps a high-end PC--and partition a system into specific tasks such as motion control, digital I/O, and machine vision. The I/O subsystem could use a CANopen network, the motion-control equipment could use a SynqNet network, and the machine-vision cameras might communicate over a Gigabit Ethernet connection. The relatively low bandwidth of CANopen channels work well for I/O devices, but precision motion-control drives require the higher bandwidth a SynqNet network provides. And because the PC manages all three networks and passes information between them, there's no need to "bridge" between networks or translate protocols.
Networking Offers Benefits
The use of a network to control motor drives has several other benefits. First, it reduces wiring, which can add significantly to costs and to the size of flexible cable carriers and retractors. Smaller, lighter network cables also reduce mass and inertia that can limit motor acceleration.
Second, smaller processors let manufacturers of intelligent drives make them smarter and thus increase their capabilities. A networked controller can obtain operating information such as operating temperature, voltage, and current for a selected motor. That information lets the controller make maintenance decisions and monitor operations.
Third, selecting a standard motion-control network eliminates interoperability problems when engineers select drives and I/O devices from different suppliers. In effect, the engineers can treat their motion-control equipment as an easily managed component in their overall system.
What are Your Options?
Designers have a wide spectrum of network choices that include RS-485, SynqNet, CANopen, Ethernet for Control Automation Technology (EtherCAT), Ethernet and Serial Realtime Communications System (SERCOS). A SynqNet network uses synchronous duplex data communications that operate over the IEEE 802.3 100BaseT physical layer. Instead of using the 74+ bytes specified by the 802.3 standard, the SynqNet protocol uses a minimum of 24 bytes, which improves network throughout. The information in Table 1 compares minimum cycle time, or latency time, for five networks; SynqNet, Ethernet, Firewire, SERCOS, and CAN.
Communications use a ring structure that provides inherent fault tolerance. So, even if a link between devices fails, the network continues to operate. If a machine has a loose connector or a bad cable, for example, the controller will report an error in the network segment that has the problem. The issues that people face with network cables are the same as those they run into with discrete wiring--cables that flex and break, bad connectors, improper connections, and so on. But problems occur to a lesser extent on a network because fewer wires mean less can go wrong. The network software checks for and counts errors and receivers and transmitters include built-in compensation. The statistical information the controller collects lets you quickly identify problems before they compromise SynqNet operations.
Bridge the Gap
You might wonder about converting one network protocol to another, or "bridging," between two different networks, say SynqNet and Ethernet. Most engineers would like to bypass that type of challenge and choose one network that can do everything they need. In some situations, though, an added or updated motion-control system may have to communicate directly with legacy hardware that has employed another network standard.
To avoid bridging, you might try "tunneling," which involves using an interface of the same type on the incompatible networked systems. If a SynqNet and CANopen network each provide an Ethernet port, you could tunnel between them through an Ethernet connection. On the SynqNet side, software provides the Ethernet stack with a data packet that goes to the CANopen side's Ethernet port. The CANopen system retrieves the data and converts it into CANopen-compatible information. Basically you have an Ethernet message coming out at one end and going in at the other end. Think of your home broadband. Your PC uses Ethernet communications to connect with a cable modem and at the other end of the cable your Internet service provider "sees" Ethernet communications. But the cable-service vendor uses a different communication format to get your Ethernet information from here to there.
In addition, our Motion Programming Interface (MPI) library includes all of the software pre-integration work for our customers. The library includes software for the drives from the different manufacturers that support the SynqNet standard. In essence, the library isolates programmers from coding details for particular drives.
How Do You Decide?
When it comes time to specify a motion-control network, engineers may look at the networked equipment and ask, “What is the performance and the cost?" They might forget about how their system will go together, how the software will work, how they will write the software and design it to handle devices from several manufacturers. Without proper planning, integration can take a lot of work when you deal with many vendors that provide different capabilities in their products.
Industry adoption and service is also a key factor in selecting the proper products to support your networking efforts and should be considered appropriately. It’s important to not only consider the technical aspects of your network, but also the level of service and support you and your team will receive after the purchase.
The Bottom Line
No network offers a magic combination of everything designers need. So to start, they should begin with a list of the system components they need and then work with vendors to get their hands on real equipment. They must try things to determine if they need customized network components or drivers. As always, marketing information and white papers cannot provide the entire story.
For further reading
"SynqNet Motion Control Pursues Open Status," The Industrial Ethernet Book.
For information on SynqNet development kits, visit: www.synqnet.org/pdfs/SQ_Developer_Kits.pdf
For information about SynqNet fault recovery, visit:
For information about Packet Error Counters, visit:
For more information about the SynqNet user community, visit:
About the authors:
Rob Pearce, Senior Hardware Design Engineer at Danaher's Performance Controls Group, is responsible for designing high performance PC-based motion controllers, servo drives and I/O devices for the SynqNet network. He currently focuses on fault-tolerant positioning schemes for PC-based motion controllers and servo drives. Rob holds a B.S. in Engineering from University of Exeter, UK