Just as different motion control systems have different characteristics, so too do the different networks used by those systems to communicate. Understanding those differences can have a major impact on operational efficiency.
“Traditionally, motion control has been performed by a motion controller commanding servo drives,” notes Atef Massoud, motion and drives engineer at Omron Automation and Safety (www.omron247.com). “The interface between the controller and the servo drives for many years was discrete wires. There were, however, many limitations to the traditional interface.” These include the cost of cabling, EM noise in the interface, resolution and bandwidth limitations that make it difficult to achieve high performance and deliver diagnostic data. “Using a digital deterministic network can solve these limitations,” he says.
Nate Holmes, product manager for motion control for National Instruments (www.ni.com), concurs. “Digital protocols are a great option because engineers can have a 1:n instead of a 1:1 connection to the controller, meaning they can daisy-chain multiple drives. Fortunately, it’s a two-way street, so engineers can send the commands and also receive a variety of process data back from the drive, such as health, internal monitoring, faults and positional information.
“Additionally,” notes Holmes, “users can distribute drives at much greater distances from the controller. For example, up to 100 meters per node is a common distance for Ethernet-based digital protocols.”
Ethernet, of course, has been a game changer in the world of automation. “Ethernet is an ideal technology because it’s been around for a long time and it is available on most microbuses today,” says Sari Germanos, technology marketing manager for the Ethernet Powerlink Standardization Group (www.ethernet-powerlink.org). Powerlink is one of several deterministic, Ethernet-based network protocols that handle high-speed motion control. Others include EtherCAT, Sercos, Profinet, CC-Link IE and CIP Sync.
Ethernet’s inherent advantage over fieldbus systems in terms of bandwidth permits timely access to the types of diagnostic and process data Holmes and Massoud speak of. “It is also an independent technology and very well understood,” says Germanos. “There are a lot of protocols out there to choose from, and the infrastructure is already in place.”
Effects of high speed
Applications that need high-speed motion control include packaging, machine tools, storage and handling systems, printing systems, and converting systems such as paper cup converters. The centrality of increased data availability (do you mean “the increasingly centralized nature of data”?) in these systems requires rapid network communications. Joaquin Ocampo, product manager for automation vendor Bosch Rexroth (www.boschrexroth-us.com), says, “I would define rapid motion as the need to have many processes or parts moving at high speeds at the same time on a machine or production line, where data must be shared quickly to communicate what position the part or machine is currently in, and in what position they need to be in. In these systems, the rapid motion takes place in every step of the process, so it is critical for the machine to receive the appropriate data rapidly, in order to know where or in what step of the process the part or material is located, and to know when to move it to the next step.”
How does this relate to the choice of network protocol? “You need to know that the given communication protocol will handle the amount of data and will not slow the transmission rates,” says Ocampo. “You need to know if the data transmission will be reliable, if it will come in and out at the same time, and that it will not change.”
The consequence of not having proper communications to handle high-speed motion is that the necessary data may not be ready when needed. “You do not want to work with old data,” Ocampo stresses. “You do not want to miss that data coming in from the previous module, and you do not want to wait unnecessarily for new data to arrive in order to continue the work. It is obviously better if the machine is working fluently or continuously without stopping.”
Germanos notes one of the ways such troublesome delays can happen. “With standard Ethernet, any device can talk anytime it wants. With all this traffic, when frames collide the transmitter is going to pause and then resend. So if I want to issue a command and get a response in, say, half a millisecond, it’s hard to guarantee that with standard Ethernet. It is not deterministic and that becomes a problem when you are trying to do motion control.”
People sometimes address this problem with switches, Germanos continues, “using a switch to block other components while two components are communicating. Communications from other components are placed in a queue. However, if the queue gets too long, your packet is going to get dropped.”
Germanos, whose preferred motion-control protocol is Powerlink, says, “As a user, I would want to have deterministic, real-time performance. I’d like to have a large amount of asynchronous bandwidth for situations such as doing maintenance while the machine is running.”
The asynchronous capability is not only used for service. It is also available for components to transfer unscheduled status data, which may be essential for preemptive diagnostics: A component may need to log some additional performance information while the machine is running normal operation. The asynchronous data stream is also used to transfer video and still images for machine vision applications.
“I want a solution that is flexible in terms of topology, because you never know what your system is going to look like,” Germanos adds. “Also, it must have hot-plug capability, electromagnetic compatibility, and easy commissioning and maintenance.” Also desirable: multicast capability, giving any node on the network the potential to see the data of any other node on the network.
Multi-bus communications
As persuasive as Germanos is, not everyone agrees that the Powerlink protocol is the only way to go. Parker Hannifin (www.parkermotion.com/ips), for instance, has opted to employ EtherCAT with its next-generation control products. “EtherCAT is deterministic, a feature we already have with our current control platform, but going with EtherCAT will allow a
lot more systems to integrate easily with our Next Gen control because EtherCAT already has a very strong market penetration,” says Mario Mitchell, product manager for the Electronics business unit of Parker Hannifin Corp.—Electromechanical Automation N.A. “It also enables us to communicate with many different buses—a feature we didn’t have as strongly with the previous platform.”
Mitchell insists that it is important—for control vendors and end users alike—to be able to communicate with as many different buses as possible.
Like Mitchell, Craig Dahlquist, automation team leader for motion control specialist Lenze Americas (www.Lenze.com), also speaks to motion control communication needs from a vendor’s perspective. Lenze, he says, felt “it was imperative to use Ethernet-based communications to handle the high volume of information that has to be transferred to and from external devices. The transfer time is also critical, and normally a 1-2 ms update rate is necessary for some information.
“If your system cannot transfer data at a high enough volume and rate,” Dahlquist adds, “then you cannot offer products to run the new high-speed machinery. Without having products that can run with these protocols, your products will not compete in the current market.”
Lenze’s controllers employ built-in EtherCAT for the reasons cited above, as well as for some very dollars and cents considerations: “EtherCAT uses generic Ethernet cabling and other hardware components. This makes cabling inexpensive and easily obtainable,” notes Dahlquist.
Questions remain
Simply employing a deterministic variant of Ethernet will not answer all your high-speed motion control questions. “Some of the factors that need to be considered when a machine builder works with this type of network,” says Bosch Rexroth’s Ocampo, “are the amount of data that will travel across the network, and the possibility that if the machine needs to be expanded, it can handle the extra data.”
Sometimes, Ocampo says, machine builders just go by the specifications of the communication protocol without taking into account the number of devices connected to it, which could cause the transmission speeds to be lower. “If this is the case, then the performance of the machine may not be achieved,” he says.
National Instruments’ Holmes adds, “These buses have a limit on the loop rates engineers can achieve between the controller and the drives. With EtherCAT, for example, the number of nodes, amount of data on the network, and processing power of the controller all contribute to determine the maximum speed at which it’s possible to send and receive process data while meeting timing requirements on the deterministic bus.”
Holmes pegs typical loop rates for these applications at 1-10 ms, and says this is usually acceptable for sending position commands for pre-determined profiles such as torque and velocity. This is because the position setpoints are interpolated on the drive side to create intermediate setpoints for control loops, which helps provide smoother motion.
“However, whenever engineers try to make decisions and update motion based on other sensor information in the system that is present on the controller, they’re limited to that controller/drive chain loop rate,” says Holmes.
For some applications, this is still acceptable, but it can lead to challenges with high-speed/high-performance motion applications. If engineers try to update the motion profile on the fly, based on sensor feedback on the controller, the speed of response or resolution in which they can detect a change will be limited by that loop rate,” says Holmes. “As a result, this can limit the top velocity of the system, or more importantly, the stability of the system. This could limit throughput or make it necessary to design for the control loop limitations.” He adds that this is usually more applicable to torque-control applications.
Bear in mind…
Holmes notes that issues can also arise when engineers want to correlate sensor information to position. “Often the desire is to have this data at a much higher resolution than once a millisecond. If this is the case, they can no longer use the position returned through the digital bus. Rather, they must wire encoders or other feedback devices directly to their controller to correlate to their measurements, as well as to their drive to provide feedback for the motion control loops.”
As a sort of coda to his observations, Holmes spells out the following checklist of things users should be aware of:
• What data needs to be correlated to position/velocity/torque?
• Is it available on the drive or the controller?
• To determine loop rates at which engineers can communicate over a digital bus, they need to consider processor power and the amount of data on the network.
• Be aware that motion setpoints will be a function of feedback frequency when correlating measurements to motion data.
• Bear in mind that control loop rates and bandwidth will also be affected by feedback frequency if performing higher-level control between drives and controller, such as force feedback applications.
In terms of what users should look for in a communication system for high-speed motion control, Omron’s Massoud offers this partial checklist: It should, he says, provide asynchronous communication for setup, configuration and diagnostics; permit easy integration with a mix of different servos and controllers; be an open, non-proprietary standard; have redundancy features; support time stamping; exhibit minimum jitter; and permit hot connect/disconnect.
Finally, for those who would employ high-speed motion control systems, Bosch Rexroth’s Ocampo has this practical tip: “Make sure the proper cable is being used and that it is routed far from other high-voltage cables that may cause noise in the transmission.”
