RTC Magazine

A number of Ethernet fieldbus solutions use fieldbus masters to send Ethernet packets to individual fieldbus slaves, or broadcast to a group of fieldbus slaves. This usually takes the form of a fieldbus packet encapsulated inside an IP packet such as UDP. The fieldbus master must then wait for the slaves to process the received data and respond to the fieldbus master via a response packet.

In an EtherCAT fieldbus system, Ethernet packets are delayed only a few nanoseconds by each slave in the chain because the slave reads and writes to the encapsulated datagram each time it is received. Ethernet packets are “processed on-the-fly.” Each slave extracts data bits inside the Ethernet packet addressed specifically to it, while simultaneously forwarding the packet to the next device in the chain. Similarly, data to be returned to the EtherCAT master is inserted on-the-fly while the packet is processed by the slave, as the Ethernet frame passes through the device.

EtherCAT fieldbus masters are built using commercially available standard network interface cards (NICs). EtherCAT fieldbus slaves utilize a device called a Fieldbus Memory Management Unit (FMMU) that can read, write and forward EtherCAT Ethernet packets on-the-fly. It is possible to build high-performance, deterministic, fieldbus systems that are flexible, expandable and cost-effective using standard Ethernet cables and connectors.

An EtherCAT fieldbus avoids the determinism problems associated with packet collision on standard Ethernet networks (like most TCP/IP networks in operation today) by isolating the fieldbus network segments from conventional network segments. Ethernet packets are placed onto the EtherCAT network by an EtherCAT master where they are processed on-the-fly by EtherCAT slaves. This process on-the-fly technique accommodates bandwidth utilization approaching 97% utilization, or the equivalent of 97 Mbits/s using 100 Mbit/s Ethernet hardware.

Standard Ethernet

A key goal of the EtherCAT fieldbus is to use standard Ethernet packets so that one can utilize standard, low-cost, 100 Mbit/s Ethernet connectors, cables, switches and silicon (for 100Base-TX and 100Base-FX media). Packing useful bits and bytes into each Ethernet packet for on-the-fly read and write operations by multiple EtherCAT slaves is the key to maximizing usage of standard Ethernet packets.

By definition, Ethernet packets designed for 100 Mbit/s media have a minimum size of 64 bytes and a maximum size of 1518 bytes. After subtracting the standard Ethernet packet overhead of 18 bytes (Destination Address, Source Address, Frame Type and Frame Checksum), a minimum size Ethernet packet can deliver a 46 byte payload, whereas a maximum size packet can deliver 1500 bytes of data. An EtherCAT datagram, the EtherCAT data object stored inside an Ethernet packet, has an overhead of two bytes per Ethernet packet plus 12 bytes per EtherCAT datagram. This leaves room for 32 EtherCAT data bytes in a minimum size Ethernet packet to 1486 EtherCAT data bytes in a maximum size Ethernet packet (Figure 1).

An Ethernet packet that contains an EtherCAT datagram can be easily identified as an EtherCAT packet because it contains an EtherType number in the Type field equal to 0x88A4 (hex 88A4), a number that has been issued by the IEEE Registration Authority for use with EtherCAT-type Ethernet packets. It also ensures that standard Ethernet hardware can transmit and receive EtherCAT network packets.

A single Ethernet frame can contain more than one EtherCAT datagram, which might be appropriate for complex EtherCAT fieldbus systems. In that case, the Ethernet packet takes on the format in Figure 2.

If an EtherCAT packet needs to be routed over a standard TCP/IP network, it can be transported inside a UDP packet, where it is marked for easy identification using UDP port number 34980 (0x88A4), a number assigned by the Internet Assigned Numbers Authority (IANA) for transport of EtherCAT packets over TCP/IP networks. EtherCAT packets embedded inside a UDP packet have a format similar to those shown in Figures 1 and 2.

Near Maximum Performance

By efficiently packing EtherCAT data into each Ethernet packet it is possible for an EtherCAT network to utilize nearly 100% of the available bandwidth of 100 Mbit/s. Achieving high bandwidth utilization, however, also requires that one step back from the standard collision detection (CSMA/CD) mechanism that is common to most Ethernet networks.

Ethernet packet collisions are avoided by controlling access to the EtherCAT fieldbus, or by segmenting the network into EtherCAT network segments. A typical EtherCAT master transmits packets onto an EtherCAT segment on a regular periodic schedule. Packets are forwarded by the EtherCAT slaves on a segment, which process them on-the-fly for both read and write operations. Packets are not stored and forwarded by EtherCAT slaves; rather, they are inspected and retransmitted on-the-fly as they pass through each EtherCAT slave. Standard Ethernet cabling is wired for full-duplex operation over the segment so that when a packet reaches the last slave in a segment it can be returned to the EtherCAT master, via the receive lines of the Ethernet cable, again passing through each EtherCAT slave in the network segment in reverse order.

The effective utilization of an Ethernet packet varies between 50% and 98%, depending on the size of the EtherCAT datagram, for those scenarios where one cycle of fieldbus data is transmitted inside a single EtherCAT datagram within a single Ethernet packet. As mentioned previously, a maximum size Ethernet packet, containing one EtherCAT datagram can hold 1486 data bytes, or 11,888 data bits.

Because no collision detection is required on an EtherCAT segment, we can send out packets at the maximum rate the cable will transmit. Adding 20 bytes of “time” for the inter-frame and preamble overhead required of standard Ethernet hardware, the theoretical percent utilization of the Ethernet cable, or bandwidth utilization, ranges from 38% for a minimum size packet up to 97% for a maximum size packet.

In other words, a theoretical throughput of 38 Mbits/s to 97 Mbits/s is possible for an EtherCAT fieldbus segment. This assumes that all the data required of an EtherCAT segment fits within one EtherCAT datagram, which fits inside one Ethernet packet, and packets are placed on the cable at maximum throughput.

Efficiency in Addressing

EtherCAT datagrams can contain any mixture of reads and writes. Just as a single packet can address multiple devices, it is also possible to perform reads and writes within a single packet.

All the slave devices on an EtherCAT segment share a single MAC address. In effect, an EtherCAT segment can be thought of as one large Ethernet device. Each Ethernet packet is shared by all the EtherCAT slaves on a network segment. Ethernet frames are transmitted through the slaves on the segment, in sequence, from the first slave device (the owner of the MAC address of the segment, or the “Segment Address Slave”) to the last.

Logical addressing, built into the EtherCAT protocol, is used to efficiently pack the data delivered by an Ethernet frame. Each slave addressed by an EtherCAT datagram is, in essence, reading from or writing to a shared memory segment stored on the EtherCAT master. That memory segment is being “shared” by the master with the slaves thru EtherCAT datagrams. Slaves read from the datagrams and write to the datagrams on-the-fly, as they pass through (Figure 3).

Each slave is assigned space in the master’s shared memory block. This assignment is done at the bit level. A slave is assigned the following:

• A bit-oriented, starting logical address to locate its data in an EtherCAT datagram
• A bit-oriented physical address within the slave device that corresponds to the logical address assignment
• A bit length consistent with the physical address type (from 1 to 64)
• A direction that specifies if this is a read or write location (input or output)

More than one of these logical-to-physical assignments may exist for each slave. For example, a simple digital I/O device, with one input bit and one output bit would have two such assignments. Each assignment would be of length 1. One logical address would be assigned as an input bit and the other would be assigned as an output bit. More complex devices would require more bits, depending on their physical function and internal register requirements.

Determinism at the Master

EtherCAT devices are capable of processing Ethernet packets at a very high speed with loop rates ranging between 10 and 90 kHz. Obviously, then, the actual loop rate achieved will depend heavily on the ability of the EtherCAT master to transmit and receive data over the Ethernet cable, while simultaneously processing that data in its internal process image (the shared memory segment that contains a reflection of the fieldbus device registers).

Virtually all modern NICs include a DMA engine, meaning that the process of transferring data from the process image to the fieldbus interface card is eliminated, requiring no CPU overhead. Instead, the NIC’s DMA engine can transfer data directly from the process image to Ethernet packets on the cable. Conventional fieldbus interfaces require that the control computer CPU copy data from the process image to the interface card’s internal RAM.

Maintaining synchronism between the process image and the EtherCAT packets then becomes important. Determinism at the EtherCAT master is a desirable trait for achieving stable loop rates. Because EtherCAT masters can utilize standard NIC hardware, common industrial PCs or specialized embedded PCs can be used without concern for the availability of specialized fieldbus adapter hardware. Real-time operating systems, Linux, and even Windows can be used as the operating system to drive the EtherCAT master. In the case of a general-purpose OS, such as Windows, it is useful to host the EtherCAT master on a real-time platform that works in conjunction with Windows.

Not Just About Performance

EtherCAT was not just designed to be the highest performing fieldbus that uses standard Ethernet packets, it also includes features that are an absolute necessity for real factory-floor applications. Features like: distributed clocks for synchronization, flexible cabling topologies, network redundancy, support for safety protocols and built-in diagnostics.

A clock jitter of significantly less then 1 microsecond is achievable within an EtherCAT segment. Because each EtherCAT segment is organized as a ring, every device in a segment can determine its “time position” within the ring by measuring the time between transmission and return of an EtherCAT packet. This propagation delay data can then be used to adjust the distributed clocks of each slave device so that they will run synchronously. EtherCAT segments support a variety of topologies, such as line, tree and star.

While a star technology is most commonly applied to switched office networks, it is not likely to be used by most EtherCAT networks. The line and tree topologies are more conducive to fieldbus applications because they require fewer connections and utilize a much simpler and more flexible cabling schema. Additionally, switches and hubs are not required by EtherCAT segments configured as lines or trees (Figure 4).

Optional cable redundancy enables devices to be changed (hot plugged) without having to shut down the network. Redundancy is very inexpensive: requiring only an additional Ethernet interface in the EtherCAT master and a return cable to turn a line topology into a ring topology. Switchover takes one cycle. EtherCAT also supports redundant masters with hot standby. An EtherCAT slave immediately returns a frame if an interruption occurs, so that failure of a device does not lead to the complete network being shut down.

EtherCAT networks are designed to simultaneously support the transport of safety and control communication over the same network. The EtherCAT safety protocol is certified to IEC 61508 and meets the requirements of Safety Integrated Level (SIL) 4. EtherCAT safety data can be routed without a need for safety routers or gateways.

Bit faults during the transfer of packets are reliably detected by evaluating the Ethernet packet’s CRC checksum. Automatic monitoring of error counters by slave devices allows for precisely locating defective network sections. Intermittent errors, such as those caused by EMI, bad connectors or damaged cables can also be detected and located.

TenAsys
Beaverton, OR.
(503) 748-4720.
[www.tenasys.com].

EtherCAT Technology Group
[www.ethercat.org].