Detect bad connections

The new master function ecatBadConnectionsDetect() analyzes all the error counters of the slave, to find out if there is a problem in a connection. If one of the error counters shows a value not equal to zero, a bad connection notification is generated, which contains the exact position of the faulty connection.

The analyzed counters are:

  • ESC error counters
  • Invalid Frame Counter
  • RX Error Counter
  • Lost Link Counter

Junction Redundancy with Distributed Clocks

An EtherCAT network can be built up in a very flexible way. In addition to a simple line, star, or tree topology, it is also possible to create local rings. By using junction devices, like the Beckhoff EK1122, or the Omron GX-JC06, these local rings can increase the network reliability.

In the local ring all standard EtherCAT slave devices are supported. With the new EC-Master V3.0 update, even the high-precision synchronization based on Distributed Clocks (DC) is supported within the local ring.

  • Create local ring cable redundancy using junction devices
  • Stay operational in case of a break in the local ring
  • Multiple local rings supported

Master Redundancy

In order to increase the availability of the EtherCAT system and provide for failure scenarios, a second fully redundant Master system can be added to the network via acontis' Master Redundancy feature. This new feature will create an ACTIVE Master and an INACTIVE Backup Master. In normal operation the INACTIVE Backup Master simply forwards frames through and back onto the network using acontis' optimized Ethernet drivers for fast packet forwarding:

Data Synchronization and Inter-Master Communication

By means of fast packet forwarding the ACTIVE Master still receives all the frames in time for the next cycle.
The INACTIVE Backup Master has access to all Process Data. It parses and modifies received frames and adds frames itself after cyclic slave frames. The ACTIVE and INACTIVE Backup Master can communicate with each other using Ethernet-over-EtherCAT (EoE).

Failover

If the ACTIVE Master fails, the INACTIVE Backup Master can takeover and become ACTIVE. Due to the fact that the INACTIVE Backup Master has been connected to the network the whole time, it can control the bus after getting ACTIVE in the case of a failover:

Cable Redundancy with Master Redundancy

Cable Redundancy can be combined with Master Redundancy. The ACTIVE Master communicates directly to one segment of the EtherCAT slave network and indirectly to the other segment of the EtherCAT slave network through the INACTIVE Backup Master:

Slave-to-Slave Mailbox Communication

Slave-to-slave Mailbox Communication enables a communication path based on the mailbox protocols between one slave and another slave. The master will handle these requests fully automatically. All specified mailbox protocols, like CAN application protocol over EtherCAT (CoE), Vendor-specific Profile over EtherCAT (VoE), etc. can be used.

For example, the Beckhoff Multi-axis servo system AX8xxx makes use of slave-to-slave communication to exchange data between the the power supply module and axis modules.

Split-Frame Processing

The Split-Frame Processing Feature Pack enables the processing of multiple EtherCAT cyclic tasks in separate application threads. From the application perspective, this makes it possible to structure EtherCAT process data across multiple threads. Therefore, process data that requires different cycle times can be handled accordingly.
Additionally, the processing of acyclic communication can also be outsourced to a separate thread.

For example, a typical application for the Split-Frame Processing Feature Pack would have one tasks for servo drives that requires very fast cycle times, and another task for I / O data that does not need very fast processing or special cycle time requirements.

EC-Engineer makes it easy to create configurations with several EtherCAT cyclic tasks:

The timing of an application utilizing Split-Frame Processing application would look like the following:

  • Thread 0 runs with a 250 microsecond cycle time and handles the processing of EtherCAT task 0. This thread also sends out the process data for all other tasks.
  • Thread 1 runs with a 500 microsecond cycle time and handles only the processing of EtherCAT task 1.
  • Thread Acyc runs with a 1 millisecond cycle time and processes only the acyclic communication and also the Master management tasks.