Application process-data interface
Integrate EtherCAT Communication Through a Portable Layered Stack
Build supported EtherCAT communication functions into controllers, gateways, devices, and industrial products using clearly separated application, protocol, operating-system, and hardware interfaces.
LayeredArchitecture
PortableTarget Support
EtherCATCommunication
EtherCAT Software Stack
The MayilVeera EtherCAT Software Stack is intended as a reusable software foundation for supported EtherCAT product roles. Its layered architecture separates the application process image from network-state handling, core protocol functions, operating-system services, and hardware or bus access.
The website must clearly state whether the product is a MainDevice stack, SubDevice stack, integration layer, or another EtherCAT component. It must not imply capabilities from the general EtherCAT standard that have not been implemented and tested in the MayilVeera product.
For general technology context, see the EtherCAT Technology Group overview.
Logical Architecture
A website-level view of how the product connects sources, processing layers, diagnostics, and destination systems.
Machine / Device Application
01
Application Process Image
02
EtherCAT Integration API
Process DataStateConfigurationDiagnostics
03
EtherCAT Core Components
04
Operating-System Abstraction Layer
05
Bus/Network Abstraction Layer
06
NIC / Ethernet Controller / EtherCAT Slave Controller
EtherCAT Network
Key Capabilities
Network and device-state handling
Cyclic process-data exchange
Mailbox protocols only when included
Operating-system abstraction layer
Bus or network-interface abstraction
Configuration and diagnostic APIs
Porting support for defined platforms
Example applications and integration tests
Error and state diagnostics
How It Works
The document flow is presented as an implementation-style process so visitors can understand the operating path quickly.
- 01
The application exchanges process data through the stack interface. The stack manages the supported EtherCAT state and communication functions, while the operating-system and bus-abstraction layers connect the protocol implementation to the selected processor, network controller, or EtherCAT device hardware.
Applications
Where It Fits
Machine controllers
Motion and automation platforms
Distributed I/O devices
EtherCAT gateways
Embedded EtherCAT products
Test and simulation tools
Robotics and material-handling equipment
Packaging and assembly machinery
OEM controller platforms
Existing-product migration to EtherCAT
Benefits
Practical Benefits
Separates product application code from platform-specific interfaces
Supports reuse across compatible hardware platforms
Provides a structured porting boundary
Reduces repeated implementation of common network functions
Simplifies testing of application, OS, and hardware layers independently
Integration and Deployment
Integration must define the product role, target hardware, operating system, network interface or ESC, process-data size, cycle requirement, synchronisation, topology, mailbox requirements, diagnostic behaviour, and conformance expectations.
Reliability and Safety
Network-state and link diagnostics
Watchdog behaviour
Error counters
Defined process-data validity
Recovery and restart behaviour
Resource and timing monitoring
EtherCAT communication performance must be validated on the final target
Standard EtherCAT communication is not automatically safety-rated; safety functions require the applicable safety architecture and qualified implementation
Need Help Selecting the Right Product?
Equipment and controller make or model
Required interfaces, protocols, channels, or tag count
Operating environment and target platform
Update rate, cycle time, delivery schedule, and custom engineering needs
Do not publish price, availability, certification, warranty, protocol, electrical rating, capacity, performance, or compatibility statements until they are linked to the exact shipping SKU or software version.
Frequently Asked Questions
Is this a MainDevice or SubDevice stack?
The final product package must explicitly identify the role. Separate variants should have separate datasheets and capability matrices.
What cycle time does it support?
A cycle-time claim is valid only when accompanied by the target processor, operating system, network controller, number of devices, process-data size, topology, and test conditions.
Does it include Safety over EtherCAT?
Only state this if the exact safety capability has been implemented, assessed, and supported under the required licence and certification framework.
Integrate EtherCAT into Your Product
Share the required role, target processor, operating system, network controller or ESC, process-data size, node count, cycle time, synchronisation, mailbox protocols, and conformance objectives.
Start Your Product Discussion