We use cookies to make your experience better. To comply with the new e-Privacy directive, we need to ask for your consent to set the cookies. Learn more.
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.
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.
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.
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.
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.
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:TIVE 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:
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.
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“.
EC-Master Tutorial: Getting Started with EC-Master On Linux
EC-Master Tutorial: Getting Started with EtherCAT on Renesas RZ/N1 Running Linux
Tecnologix offers support which is directly handled by development team. Do not hesitate to get in touch with our experts.
Just ask here