Feature Packs - EtherCAT Master Options
EtherCAT users expect interoperability as well as a well-defined set of functionality which an EtherCAT master has to provide.
Not all applications of course have the same requirements and thus, not every master has to support all features of the EtherCAT technology.
The most general requirements of an EtherCAT master are covered by the Class A and Class B editions of EC-Master, which fully conform to the respective ETG1500 EtherCAT master directives.
Additional functionality which may be needed for the broad usage of the EtherCAT technology in controllers, plants and machines are available as well.
These features can be considered to be optional, they are described by Feature Packs in the ETG1500 directive. The Feature Pack describes all mandatory master functionality for a specific feature, e.g. redundancy. EC-Master covers all such defined feature packs and even provides features beyond the officially defined ones. This page provides an overview of the available feature packs and the respective use case.
- Split-Frame Processing
- External Synchronization
- Hot Connect
- Cable Redundancy
- Master Redundancy
- EoE Third Party Tool Support Package
- UDP Mailbox Gateway
Feature Pack - 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.
Feature Pack - External Synchronization
The synchronization of system components or production lines with several EtherCAT Segments can be done with different solutions:
- Synchronization with an external grandmaster clock using IEEE 1588 protocol
- Synchronization by a bridge device.
Depending on the application the accuracy of the synchronization has different requirements. For the synchronization of two production lines often the accuracy in the range of milliseconds is enough.
However if two or more motion control networks should be synchronized it may be necessary to have the Sync-signals exact at the same time in all devices (e.g. for a network wide commutation information) - that means an accuracy better than a microsecond may be needed.
Within one EtherCAT Segment the Distributed Clocks (DC) mechanism can be used, to synchronize the network devices. DC offers accuracy much better than a microsecond.
The first device that should be synchronized is used as the reference clock for that segment.
The synchronization of several EtherCAT Segments with a high accuracy means that the DC reference clocks in the segments must be adjusted.
The leading clock is called Grandmaster clock. It can be an external Time information, e.g. GPS or DCF77 receiver (see Figure 27), but it can also be one of the DC reference clocks.
The synchronization of two or more EtherCAT segments can be done by a Bridge device as shown in this figure.
The Bridge has two EtherCAT connections (internal two EtherCAT Slave Controllers are used). The primary port is connected to the first segment; the secondary port is connected to the second segment. One of the two ports can be configured to be the leading time reference. The Bridge can calculate the time difference and offers the TimeControlValue to the Master. The Master can then adjust the Reference Clock. During startup the two segments can be powered-on at different times. That means that there will be an absolute time difference between the two segments.
To synchronize the Secondary Segment two software algorithms are involved:
- DCX: Synchronize the reference clock to bridge device
- DCM: Synchronize the Master timer to reference clock
Feature Pack - Hot Connect
Achieving a maximum flexibility with “Hot Connect”
The concept of “Hot Connect” first of all refers to the connecting and disconnecting of slaves in a running (hot) system.
However, this is just one of several possible scenarios.
Much more often it is required to operate the system without a perfect match between the EtherCAT bus configuration (ENI file) and the actually connected slaves or wiring.
Thus the following additional use cases can be covered (without the need to change the ENI configuration file):
- Setting up a complex control system, while parts of the system are not available, powered-off or disconnected.
- Running a system that consists of mandatory as well as optional devices (e.g. in a test & measurement environment)
- Flexibility within the wiring: slaves can be connected to different ports (e.g. analogue to CAN).
In order for “Hot Connect” to be used, no special EtherCAT functionality in the slave is required; in fact, any EtherCAT slave may be a member of a HotConnect group (HC group).
Every HC group just has to be uniquely identifiable, most often this is implemented using DIP switches.
This unique slave address then appears either in the Station Alias Register or at some address location within the slave memory.
Both methods are supported by the EtherCAT Master.
Furthermore, the application may program the station alias address by means of the master (e.g. for first-time system initialization).
The “Hot Connect” Feature Pack requires at least version 2.0 of the EC-Master stack.
All EtherCAT activities required to support HC are automatically handled by the stack in the background. There is no need for the application to interact.
Besides, as soon as a slave is connected or disconnected, the application will be informed by a call-back function (notification).
At any time the application may determine the actually connected slave devices using the appropriate master stack API function.
Within the HC feature pack the functionality “Border Close” offers additional security against connecting of slaves to an incorrect port.
By activating that function, all EtherCAT ports are closed, except the ports which are permitted by the configuration. Therefore slaves which are connected to these ports, are simply ignored and the system continues to run perfectly undisturbed.
We will be glad to answer any further questions concerning the topic “Hot Connect”.
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)
Feature Pack - 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).
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:
Feature Pack - EoE Third Party Tool Support Package
Using the mailbox protocol Ethernet over EtherCAT (EoE) standard Ethernet frames can be tunneled trough an EtherCAT network. Based on this, a communication to slaves with locally running TCP/IP-based applications (e.g. Web Server) can be established. More and more manufacturers of EtherCAT drives are supported this connection in their drive setup and tuning tools.
Acontis is offering all required software modules to enable TCP communication between a third party software on Windows and a EtherCAT slave supporting EoE. On the master controller just the proven RAS-Server has to be enabled. The RAS-Server is included in the EC-Master core license and available on many operating systems.
Feature Pack - UDP Mailbox Gateway
The Mailbox Gateway functionality within a master device can be used to route the EtherCAT mailbox protocol from an (external) device configuration tool via the Mailbox Gateway to the EtherCAT devices and vice versa. All Mailbox protocols that are defined in the EtherCAT specification can be used in general, i.e. CoE, FoE, VoE, SoE.
There is no error handling specified for the Mailbox Gateway functionality. A request to a non-existing slave device can lead to no response from the master. According to Function Guideline „ ETG.8200 EtherCAT Mailbox Gateway“.
Mailbox Gateway Structure