The suitability of motion control in an Ethernet environment needs to be evaluated case-by-case, because each application handles time differently. The worst scenario is when a controller commands an axis to move and it does not react for several microseconds. The first step in considering Ethernet for a control medium is to define real time in terms of the control strategy needed for that particular installation. Here, real time does not necessarily mean fast execution. It might mean that execution depends on a tolerable time progression of events.

A prevailing view of real-time motion control within Ethernet is that multiple axes can send position data to a central controller that will then coordinate the axes. “There are a few cases that have been successful with a particular version of Ethernet,” says Dave Edeal, industrial marketing manager, MTS Sensors. “There is a subset of Ethernet that addresses synchronization, a key element for us. The 100Mbps Ethernet is fast enough and the bandwidth large enough to accommodate all the data that motion devices will generate, including feedback sensors. We can resolve data to 25 bits, which is a lot on a typical serial bus, but not for Ethernet. Even so, for devices like sensors, it’s not trivial to synchronize multiple clocks in a system to reduce jitter to a reasonable level.”

Jitter in communications refers to variations in actual timing among the clocks that control all real-time systems. It is one reason designers need to decide whether Ethernet is fast enough to handle a closed-loop servo system or to use it only to download programs, send commands to the motion controller, and check the status of the controller for diagnostics and remote applications.

Some systems can tolerate a little jitter. For example, controller-to-controller Ethernet communications that function with transmission rates of 100ms, usually will not be affected by jitter. Likewise, distributed I/O handles cycle times of 10ms with little affect from jitter. Motion control systems, however, function best with transmissions that contain less than 1ms of jitter.

“A common Ethernet network is still possible when the current loop is a closed-loop analog signal,” says Lisa Wade, VP-Marketing & Sales, Galil Motion. “You can still have digital communication from the controller to the drive for adjustments and diagnostics using Ethernet and still close loops using analog signals.”

In addition, Ethernet has systemic issues to consider. Even small amounts of data are sent in large frames. Plus, a subsystem bus may be needed, particularly with modular I/O systems, which often adds unavoidable delays to transmission times.

A Closer Look
Despite these issues, the most commonly used Ethernet based protocols for motion control are: EtherNet/IP, EtherCAT, Ethernet Powerlink, ProfiNet/ProfiNet IRT, and SynqNet. Most of these protocols include a time-synchronization sub-network protocol based on IEEE 1588. One of its benefits is that time is synchronized as close to the physical layer of a protocol stack as possible. Handling timing functions here avoids many of the delays mentioned earlier.

IEEE 1588 came about to define an accurate, reliable technique to synchronize the timing signals that are essential to have simultaneous, coordinated servo-control axes movements. This protocol defines a technique for synchronizing independent clocks running on separate nodes. All nodes down to the sensor and actuator levels may have an IEEE 1588 clock that uses the Precision Time Protocol (PTP). PTP uses a master/slave format where synchronization telegrams adjust the time of local clocks. A grandmaster clock that has the best inherent stability, accuracy, and resolution governs the whole system. Boundary clocks reside where more than one PTP communication path exists, typically used in hubs and switches. Ordinary clocks reside in devices with one port, such as a sensor.

Slave nodes are set to operate at a precise time. Node data are time stamped locally; making the accuracy of ordinary clocks crucial. Periodically, the master broadcasts a synchronization signal indicating when a message will physically leave, and then it notes the actual time the message was sent. Slaves note the time they received the transmitted message.

Often a part of the EtherNet/IP, Ethernet/Powerlink, EtherCAT, and ProfiNet protocols, IEEE 1588 does not make Ethernet more deterministic or reliable. However, it does provide a method for other protocols to do so. The protocols may implement the 1588 techniques differently.

EtherNet/IP (EIP):
EIP is managed by the Open DeviceNet Vendors Association (ODVA). It uses the application layer, CIP, which is also used on DeviceNet and ControlNet. Thus, these networks are interoperable.

CIP Sync consists of a Time Sync object and associated services for synchronizing nodes. “CIP Sync lets us synchronize devices on the wire to within ± 100 nanoseconds of one another,” says Steve Zuponcic, Chair of ODVA’s Distributed Motion Joint Special Internet Group. “Consider a number of devices on the wire that have the same notion of time, that is, they all have a defined measurement of time that is within a few hundred nanoseconds or less than a microsecond from one another.

“Now, say an actuator needs to be repositioned at a specific point in time,” continues Zuponcic. “By all of the devices knowing the time and the position, they will coordinate because time is the event, not the data delivery. We are using a technique that the process industries have used for years, PID, proportional, integral, and derivative control. Recently, advances in implementing digital data over Ethernet have made the PID technique available for motion applications. Most other network-motion approaches use time slicing with scheduled bandwidth for each node. That’s fine, but when data are not transmitted to or from a node within a specific time window, then it’s not possible to handle that application.”

One potential drawback to EIP arrangements is that jitter may be introduced into the protocol stack and some reports claim that CIP Sync will not necessarily guarantee determinism. In EIP, jitter crops up because this protocol sends all real-time data through the TCP/UDP/IP stack. TCP initializes and configures the message. User Datagram Protocol (UDP) transmits real time I/O data. UDP is similar to TCP but lacks transmission overhead data. While the absence of overhead speeds message transmission, UDP can introduce time delays and it puts the burden on the designer to ensure packets go to the right nodes. When guaranteed transmission is a must, designers can confine those nodes needing real-time feedback to one segment of the EIP system to reduce jitter and increase determinism.

An important benefit of working through the TCP stack, however, is that EIP does not modify the lower layer protocols. Other Ethernet motion systems replace the MAC layers with their own protocol techniques to achieve real-time transmission. “This can affect compatibility, and force designers to use routers or gateways to go from the motion portion of the network to the Ethernet portion,” adds Zuponcic. Depending on the design, there can be applications that function better with the motion portion isolated on a separate EIP subnet. “Even so, with EIP, designers won’t need different manufacturers’ versions of connecting pieces,” says Zuponcic, “they will use what they currently use with their Ethernet system, because all such components are open.”

EtherCAT®
Ethernet for Control Automation Technology (EtherCAT) was developed by the Beckhoff company. It is fast and deterministic, and processes data using dedicated hardware and software such as Beckhoff’s TwinCAT operating system and TwinCAT Y driver.

EtherCAT uses a full duplex, master-slave configuration, and accommodates any topology. It can process 1000 I/O points in 30µs and communicate with 100 servo axes in 100µs. Axes receive set values and control data and report actual position and status. A distributed clock technique that is a simple version of IEEE 1588 synchronizes the axes with less than 1µs of jitter.

The master initiates all communications, which controls traffic and guarantees determinism. Slaves range from intelligent nodes to 2-bit I/O modules. The physical media can be either 100Base-TX fiber optic cable or E-bus, which is an EtherCAT physical layer that uses a Low Voltage Differential Signal (LVDS) scheme.

Part of the reason for this protocol’s higher speed is that messages are processed in hardware before they are forwarded to the next slave. Slaves read data relevant to them as the data frame passes and they insert new data into that same data stream on the fly. This procedure does not depend on the run-time of the protocol stack, so processing delays are typically just a few nanoseconds.

EtherCAT can be configured to interoperate with other TCP/IP networks, including Ethernet versions. It can work with UDP in a protocol stack, however it won’t be deterministic. Also, switches and routers between the master and the slaves will negate determinism. Lastly, this protocol is compatible with Sercos.

Ethernet Powerlink
Ethernet Powerlink is a software-only protocol supported by the Open Modular Architecture Controls (OMAC) Users Group. Promising a cycle time of 200µs with 1µs jitter, this protocol uses cyclic communication with time-slot division. Following a master/slave model, real-time and non real-time domains handle time critical and less time-critical data respectively. Ethernet Powerlink offers a clear boundary between a machine and the factory network, preventing potential security issues while keeping data transparent.

Determinism comes from a cyclic timing schedule used by all nodes that access the physical layer. Time critical data are sent in the isochronous phase of the schedule and non time-critical data are sent in the asynchronous phase. A Managing Node uses explicit messages to grant access to the physical medium. In this manner, only one node has access to the network at a time, avoiding collisions.

At start-up, all networked nodes synchronize to the Managing Node’s clock. Then, the Managing Node assigns a fixed time window for each node to transfer time-critical data. All other nodes can listen to all data during this isochronous phase. Real-time behavior depends on the precision of this basic cycle time.

Individual phase lengths can vary as long as the total of all phases remain within the basic cycle time boundary, which is monitored by the Managing Node. Designers can configure the duration of the isochronous and the asynchronous phases. To synchronize traffic across multiple real-time segments, this protocol will use IEEE 1588.

Ethernet Powerlink uses the bandwidth of the Ethernet protocol efficiently. Some nodes can share common time slots in addition to transferring isochronous data during each basic cycle. Use of repeating hubs rather than switching hubs reduce path delay and frame jitter, increasing determinism.

ProfiNet and ProfiNet IRT
ProfiNet is often a regional choice for applications with many Siemens’ products. It offers response times of 10 to 100ms. ProfiNet Isochronous Real Time (IRT) offers response times of 5 to 10ms. Cycle time is 1 ms, jitter accuracy is 1µs, and determinism is guaranteed. This protocol is based on full-duplex switched Fast Ethernet, but there are proprietary alterations to the layers.

This protocol divides a communication cycle into standard TCP/IP open channel and a deterministic real-time channel. The division ratio is system dependent and chosen by the designer. It prioritizes the data messages in the switches using IEEE 1588 priority tagging. A reserved time window transfers messages in a reliable cyclic sequence. The remaining cycle time is used for standard TCP/IP communication. Enhancements to ProfiNet and ProfiNet IRT include ProfiSafe, which incorporates safety protocols for the manufacturing and processing industries.

SynqNet®
This protocol is based on Ethernet and implements synchronous duplex data transmission using 100BaseT media. Developed by Motion Engineering Inc., now a part of Danaher Motion, more than 200,000 axes use this protocol.

Arranged in a bus or ring topology, SynqNet limits time delay jitter to less than 1µs by using phase-locked loop techniques. “These techniques are part of our patent,” says Paul Hewitt, VP Engineering and Controls, Danaher Motion. “We have a master clock on the control side and phase-lock loops interconnected between all the nodes that synchronize the independent clocks of each network slave to the master. We can drive tighter timing with phase-lock loops. It’s a scheme developed for minimal control latency that is necessary for 16 to 20-axis machines such as chip shooters.”

With full-duplex wiring, this protocol can deliver a deterministic data rate for cycle times as short as 25µs for four axes. Another technique that speeds response time is smaller frames. Ethernet frames are typically 84 bytes. SynqNet frames are 24 bytes.

At the controller level, designers will need to use Danaher devices that are compatible with SynqNet. Multiple parties sell SynqNet controls for I/O and drives. “Plus, customers can design their own equipment to connect to SynqNet,” adds Hewitt. “We control the master side to maintain our guarantee that this protocol will work as we say it will.”

Diagnostics are retrieved from any node on the network in real time at consistent cycle rates. The data are brought back to the controller and passed onto the factory network through tools or the application interface. If the drive amplifier has a processor, designers can look into its memory through a host connected to the network and watch it in real time. The benefit is the ability to predict machine failure, diagnose quickly, and then fix the problem.

SynqNet can tell designers whether packets are missing or corrupt, and whether there’s a bad connector, wire, amplifier, or I/O node. A fault-tolerance feature automatically detects a failure and redirects traffic to keep the network up, giving operators the option of a graceful shutdown.

:: Design World ::