Peace of Mind with EtherCAT

July 1st, 2013 by

By Emmanuel Faure
Field Applications Engineer EMEA

While reading an article in Control Design recently, I was reminded of yet another very valuable aspect of EtherCAT  –  the ease of implementing cable redundancy in a line topology network.

All that’s required for this additional peace of mind is a second Ethernet port on the controller.  No special interface card is needed.

Let’s look quickly at how cable redundancy is done on a quad-core system – one core running Windows and three cores dedicated to IntervalZero’s RTX hard real-time software, which provides a real-time scheduler for Windows.

The EtherCAT network in the diagram below (Fig. 1) uses normal bi-directional Ethernet cabling that contains separate Tx and Rx cables.

In this case, the EtherCAT master is running on one RTX core, sending telegrams on the Tx cable and receiving them at the other end from the Rx cable after they have been processed.

All telegrams are relayed from the first slave to the next. The last terminal (Slave N) returns the telegram back to the master.

Normal bi-directional Ethernet cabling

Fig. 1

Unfortunately, in this configuration, if a cable or node fails, the slaves located after the damaged slave or after the cable break are no longer on line. (Fig.2) below.

Diagram of slaves no longer on line

Fig. 2

Cable redundancy (Fig. 3 below ) avoids this issue and transforms the line topology into a ring topology.

Cable redundancy

Fig. 3 

As you can see, the EtherCAT telegram is sent on the two network ports.

In situations where no redundancy is needed, only the telegram in the processing direction is processed, while the second telegram passes through the network in the forwarding direction and is not processed.

In a situation requiring redundancy, both telegrams pass through part of the network in processing and forwarding directions.

Diagram of redundancy for EtherCAT telegram


Leave a Comment