Ethernet starts out fast, with micro-second-level response times, when it runs alone under good conditions. However, Ethernet-based networks usually begin to bog down, to multiple milliseconds and longer, for many of the same reasons that strain capacities of all communication, automation and/or control networks.

Data gathering and transmission problems at the device and I/O level; inefficient switching, too many devices, and poorly coordinated traffic on the network itself; and error-checking and translation hurdles at upper-layer communication levels, such as TCP and UDP, can steal precious slices of time from Ethernet-based networks. These delays can prevent Ethernet from bringing its well-known advantages to discrete, motion control, and other higher-speed applications.

"Any network suffers from overhead, which is the preamble and postamble needed to trap the bits required to move a message payload over a network. The negative is that this overhead is higher for Ethernet than for most protocols, especially when the TCP/IP stack is added. The positive is that Ethernet moves data a lot faster than other protocols," says Dick Caro, CEO of CMC Associates (Acton, MA). "For example, a proprietary network may have a 16-bit address, while Ethernet has a 48-bit address, but it moves so fast that this doesn't usually count against the user. Even so, you'll rarely get more than half the declared connect speed, which means if a device's connect speed is 100 Mbps, then its total payload speed will be closer to 50 Mbps."

Luckily, there are several useful methods for speeding up Ethernet-related components and software, and many more being developed. Some use innovative techniques to streamline network communications, while others simply seek to make transmission and reception more reliable.

One of the most promising real-time Ethernet solutions is the IEEE 1588 Standard Precision Time Protocol (PTP), which defines a method for sub-microsecond synchronization of the clocks in sensors actuators, and other terminal devices on a standard Ethernet-based network or other distributed application using commercially available technology. Originally developed by John Eidson, of Agilent Laboratories (Palo Alto, CA), for distributed instrumentation and control tasks, 1588 was approved by the Institute of Electrical and Electronics Engineers (IEEE) in November 2002.

IEEE 1588's basic function is that the most precise clock on a network synchronizes all others, according to Dirk Mohl, head of industrial Ethernet product development at Hirschmann Electronics. In his recent paper, "IEEE 1588—Precise Time Synchronization as the Basis for Real-Time Applications in Automation," he adds that Hirschmann tested IEEE 1588 enhanced plug-in modules on its Mice modular Ethernet switches, and found that its synchronization accuracy was within ±100 nanoseconds at maximum jitter, and that frequency distribution of the offset values between master clock and slave amounted to 23.95 nanoseconds with an average value of -4.248 nanoseconds.

As a result, several manufacturers have been working on solutions based on IEEE 1588. They include Rockwell Automation and the Open DeviceNet Vendors Association (ODVA), which have been working to integrate 1588 with their Common Industrial Protocol (CIP) and EtherNet/IP protocol in a project called CIP Sync. In a recent paper, "Application of IEEE 1588 to a Distributed Motion Control System," three Rockwell engineers report that they've applied 1588 to a distributed motion control system prototype, which includes three motion controllers, each connected to one drive over SERCOS via a SERCOS adapter card. Each drive is referred to as one axis of motion, but two are designated as slaves and one is designated as a master.

Each slave is geared to the master axis in a one-to-one ratio, due to the master's controller periodically sending position references to each slave's controller. The clocks on all nodes are synchronized via Ethernet by using 1588, which runs on a 50 MHz PowerPC CPU. The basic motion operation requires motion tasks running in each node to be synchronized to each other. Transactions between nodes are based on a synchronized periodic update cycle. This applies to controller-to-drive transactions and controller-to-controller transactions (see graphic on page 35). To synchronize all motion in the system, motion tasks and position update cycles are synchronized to the 1588 clock.

"Because 1588 allows for distributed time synchronization, we can schedule distributed control actuation across multiple nodes as a function of time," says Anatoly Moldovansky, principal engineer at Rockwell's Automation Control and Information Group (ACIG). He adds that the prototype's 1588 application with distributed motion via Ethernet proved to be reliable and accurate. The hardware assist circuit provides jitter accuracy of %100 nanoseconds between the master and slave clocks.

"Instead of reacting when data comes in, devices on an IEEE 1588-based network can schedule actions, which allows far more efficient communications and control with less bandwidth and less jitter," says Doug McEldowney, NetLinx marketing manager at ACIG.

In another real-time Ethernet project, Beckoff Automation recently developed its RTEthernet concept, which is a way for its TwinCat software to communicate with a standard Ethernet controller card using 7-microsecond telegrams. Though they can be up to 1,500 bytes, the minimum telegram contains 46 bytes, which is enough to indicate the status of 368 I/O points, and is typically enough for one I/O block. To separate this real-time data from other network traffic, TwinCat's I/O system filters incoming Ethernet frames by real-time relevance, and stores less time-sensitive TCP messages in a buffer. RTEthernet's strategy is to avoid TCP/IP and UDP/IP overhead, and route to devices directly using their network cards' MAC-ID hardware addresses.

Besides ensuring speed, RTEthernet can help add flexibility to existing networks. For example, to upgrade the control system for its lines producing crosslinked polyethylene (PEX) tubing from PLCs to PC-based automation, Uponor Wirsbo (Apple Valley, MN) recently selected Beckoff's RTEthernet-based BK9000 Ethernet Bus Couplers. The company uses Beckhoff's C3640 PC for the main controller, which runs Visual Basic software code developed by Uponor. This code connects to various I/O signals via Schneider Electric's Modbus TCP Ethernet protocol and the BK9000s, which form a distributed Ethernet I/O interface that transfers signals to the C3640 via the Ethernet network.

Luther Kemp, Uponor's electrical controls engineer, says his company required a versatile, standardized network to control its many machinery types. "This way we have the flexibility to swap components if and when a problems arises," says Kemp. "We can build I/O modules exactly the way we want. PC-based Ethernet systems, like Beckhoff's, offer endless programming possibilities. It allows us the opportunity to write programs that control the machinery, create custom user interface screens, and collect real-time data such as temperature and processing rates."

Similarly, system integrator Paine Machine Tool (Delta, B.C., Canada) recently upgraded 16 CNC machines with a DNC solution that included Thin Q Ethernet serial device servers (ESDS) from Quatech. These servers convert serial data into Ethernet data; accumulate serial data in a buffer; and send it in packets to reduce Ethernet network traffic. Because CNC machines are typically "drip fed" commands from an attached PC or LAN, these packets can sometimes introduce potentially destructive latencies.

ThinQ solves this problem with a software-selectable Ultra-Low Latency setting that allows Paine's CNC machines to send Ethernet data bit by bit as soon as it's received. Quatech reports that the setting's SDS function tested at 2.16 msec minimum and 71 msec maximum with a mean of 2.5 msec. "This can really help minimize network traffic," says David Johnson, Quatech's product marketing manager. "Especially when an application has multiple devices, it's important not to bottleneck the most important data."

Larry Komarek, Phoenix Contact's product marketing manager, adds that real-time Ethernet performance can be improved by configuring a network to allow multicasting. Rather than opening point-to-point, single-casting communication with one device at a time, multicasting gets a predetermined group of devices online, and broadcasts to them simultaneously. This is also the method used by virtual local areas networks (VLANs), and it can help improve data throughput on a network.

McEldowney suggests that networks reaching the I/O level implement IGMP snooping functions with full-duplex communications to filter this multicast data. He also recommends using port mirroring, which involves mirroring communications to a second port on a switch for diagnostic purposes. "This is like eavesdropping on communications through a switch to reflect what's going on," says McEldowney. "It's useful when you're looking to do control via Ethernet, but you may have more security requirements."

Other efficiencies possible with some Ethernet switches include using VLANs to segregate network traffic within a switch. This can allow one 12-port switch to function like two separate switches. "However, you also have to make sure your switch can keep up with the wire speed of the network and devices connected to it," he adds.

CMC Associates' Caro adds that simply using Ethernet switches can improve real-time performance because they can accomplish with hardware what fieldbus protocols must do with logic capabilities. "As data moves from point A to point B in an Ethernet switch, it learns the source and destination addresses," he says. "If you tried to do this with the fieldbuses, it would be very costly, even more so because Ethernet hardware is faster and cheaper.