What’s your taste in Ethernet?

When planning a high-speed motion control application, consider the features you need, the deterministic nature of your application, and just how much Ethernet compatibility your system requires.

Share Print Related RSS
Page 1 of 3 « Prev 1 | 2 | 3 View on one page

INE, July 2005 cover image

YOU SAY YOU NEED network speed, but want to keep things relatively simple? Several strains of Ethernet promise to deliver performance, determinism, and improved compatibility compared with what older token-passing networks could do. Today, Ethernet is in because it’s cheap, and its advantages outweigh its disadvantages.

But where and when can you use these Ethernet hybrids? Whether you’re planning a robotic, printing, packaging, or other high-speed motion control application, you’ll want to consider the features you need, the deterministic nature of your application, and just how much Ethernet compatibility your system requires. Then one of the flavors might begin to look like your best match.

All Ethernet Is Not the Same
First, some background. In 1985, the IEEE 802.3 Ethernet spec originally defined just Layers 1 and 2 of the OSI model (the physical layer—wiring and sockets, and the data link layer—modulators and demodulators, i.e., media access). Today, the addition of TCP/IP protocols (Layers 3 & 4) carries network and application-based data over the wires. While these upper-layer protocols are carried on the same wire via TCP/IP and go through the same switches, they don’t by themselves allow devices to “talk” to one another.

Today, we usually think of Ethernet and TCP/IP together. While some real-time Ethernet-based networks do indeed use TCP/IP, others may only resemble Ethernet at Layer 1 or Layer 2. While only Layer 1 and/or Layer 2-compatibility might increase speed and performance, it does not necessarily guarantee much in the way of connectivity—unless you’re willing to use gateways or other protocol converters. So if the only level of compatibility is the physical or data link layer, how are these networks any different than a proprietary fieldbus? Good question. Does this remind you a bit of the fieldbus wars?

To Paula Doyle, graduate of the Industrial Ethernet University and doctoral researcher with the Circuits and Systems Research Centre at the University of Limerick, Ireland, it seems the fieldbus wars of the ‘90s are repeating themselves in Industrial Ethernet battles. “Current work by the IEC TC65 Committee is considering at least 10 solutions to real-time Industrial Ethernet. Each standard offers different levels of service with respect to use of TCP/IP, support for normal network traffic and real-time behavior. Most standards do not use TCP/IP for real-time communication, but instead implement a portion of a cyclic communication channel for IP-based traffic, thus providing compatibility with the IP suite.” 

Real-time and Ethernet
Plain old Ethernet wasn’t designed for real-time or deterministic responses. The basic architecture of Ethernet, carrier sense multiple access/collision detect (CSMA/CD), plus the use of hubs led to very unpredictable response times. Real time is a “bolt-on” to Ethernet.

There are three basic ways to get real-time responses from Ethernet, states Andreas Pfeiffer, board member of the Ethernet Powerlink Standardization Group (EPSG), and Dipl.-Ing. for Bernecker & Rainer Industrie-Elektronik, Eggelsberg, Austria. Often times, they’ll all be used together. The first way, which speeds up Ethernet but does not necessarily guarantee real-time, deterministic responses, is to use switched Ethernet. Most Ethernets today are switched and, while a switched system provides full-duplex operation between the switch and any of its nodes, the switch itself can be the source of bottlenecks as its buffers try to keep up with heavy traffic at each of its nodes.

"Two additional approaches help make Ethernet more deterministic,” says Pfeiffer, “the application of IEEE 1588 Precision Time Protocol (PTP) and the use of time slicing.”

The IEEE 1588 spec defines methods to synchronize distributed clocks in a network and time stamp data, says Pfeiffer. “In and of itself, 1588 can’t do the synchronization; it can only define when data arrives late, he adds” A method of implementing 1588 is shown in Table 1. (Click here to view a .pdf of Table 1.)

“All distributed clocks are calibrated regularly using synchronization telegrams,” says Pfeiffer. “Each piece of data is tagged with information stating when it was captured or a when certain activity needs to be started. The receiver processes the time tag according a prescribed schedule. The clocks can be implemented in hardware (usually ASICs) or software depending on the precision required.” The IEEE 1588 specification is not relegated just to Ethernet; it can be used in any network architecture to guarantee deterministic responses.

Time slicing, used in Profinet IRT and Ethernet Powerlink, helps guarantee that critical tasks always are assigned a specified time slot to send data; less-important data is transmitted as is necessary. This Layer 1 method organizes the network’s data transmission chronologically. A managing node handles time allocation, making sure that every node transmits critical data without interference.

Page 1 of 3 « Prev 1 | 2 | 3 View on one page
Share Print Reprints Permissions

What are your comments?

Join the discussion today. Login Here.

Comments

No one has commented on this page yet.

RSS feed for comments on this page | RSS feed for all comments