Feature Pack - Cable Redundancy

Cable redundancy is designed to compensate for the failure of a communication cable section in the EtherCAT system. A ring topology, which normally is operated in both directions, is therefore used. Both branches can nevertheless still be reached if the ring is interrupted at some point.


A second network port is used for ring closure at the EtherCAT master control system. Both cyclic and acyclic frames are sent simultaneously through both ports, and are transported through the system.

In the absence of any fault, all the EtherCAT slaves are reached in the forward direction (so called processing direction) from the primary port. This means that they are processed, since the EtherCAT Slave Controller (ESC) is only passed through in the forward sense.
When there is no fault, all the EtherCAT slaves are reached from the secondary port in the reverse direction - the data in the "redundancy" frame is therefore not changed.

In each case, the EtherCAT frames arrive, possibly modified, at the other port, and are checked by the EtherCAT master. In case of a cable break, both frames are processed - each one on the respective side of the failure. Therefore both frames contain a part of the input data. The master has to combine the data of both frames, and gets one frame with all the input data. The working counters from both frames are added to check for its validity. It is unimportant whether an EtherCAT slave is reached from the primary or redundancy port. The EtherCAT master has to consider that a frame on one side is lost and the other frame returns. To find the matching frame it is useful to mark the frames with an identification or use appropriate mechanism.

The cable redundancy is single-error tolerant, i.e. communication with the slaves can continue if the cable is interrupted in one place. When the communication is restored the original communication direction is restored. If the communication is interrupted in more than one place, all connections have to be restored before another fault may occur.


In case of cable break all types of EtherCAT communications (process data and mailbox protocols) are be supported without any restrictions.
Handling of the following use cases:

  • Normal operation
  • Stay operational in case of cable break between two slaves
  • Stay operational in case of cable break between primary port and first slave
  • Stay operational in case of cable break between secondary port and last slave
  • Stay operational in case of cable fixed
  • Start/Stop (State change) in case of cable break
  • Adjustment of Auto Increment address in case of cable break
  • Frame loss in case of cable break (partner frame was not received)