100% found this document useful (1 vote)

81 views

EtherCAT Slave V5 Protocol API 01 EN

Ethercat slave protocol API

Uploaded by

shruti

Available Formats

Download as PDF, TXT or read online on Scribd

100% found this document useful (1 vote)

81 views

EtherCAT Slave V5 Protocol API 01 EN

Ethercat slave protocol API

Uploaded by

shruti

Available Formats

Download as PDF, TXT or read online on Scribd

You are on page 1/ 127

Protocol API

EtherCAT Slave

V5.1.0

Hilscher Gesellschaft für Systemautomation mbH

Table of contents
1 Introduction............................................................................................................................................. 5
1.1 About this document ...................................................................................................................... 5
1.1.1 List of revisions .................................................................................................................................. 5
1.2 Functional overview ....................................................................................................................... 5
1.3 System requirements ..................................................................................................................... 5
1.4 Intended audience.......................................................................................................................... 5
1.5 Technical data ................................................................................................................................ 6
1.6 Terms, abbreviations and definitions ............................................................................................. 8
1.7 References to documents .............................................................................................................. 9
2 Getting started ...................................................................................................................................... 10
2.1 Loadable Firmware (LFW) ........................................................................................................... 10
2.2 Configuration ................................................................................................................................ 10
2.2.1 Configuration methods .................................................................................................................... 10
2.2.2 Sequence and priority of configuration evaluation ........................................................................... 10
2.2.3 Configuration parameters ................................................................................................................ 11
2.2.4 Application sets the configuration parameters ................................................................................. 12
2.2.4.1 Reconfiguration .............................................................................................................. 13
2.2.4.2 Delete configuration ........................................................................................................ 14
2.2.4.3 Configuration lock ........................................................................................................... 14
2.2.5 Configuration software..................................................................................................................... 14
2.3 Cyclic data exchange - Process data input and output ................................................................ 14
2.3.1 Bus On / Bus Off ............................................................................................................................. 14
2.4 Acyclic data exchange ................................................................................................................. 15
2.5 Object Dictionary .......................................................................................................................... 16
3 Stack structure and stack functions .................................................................................................. 17
3.1 Structure of the EtherCAT Slave stack ........................................................................................ 17
3.2 Base function ............................................................................................................................... 19
3.2.1 ESM component .............................................................................................................................. 19
3.2.1.1 EtherCAT State Machine (ESM) ..................................................................................... 19
3.2.1.2 AL Control Register and AL Status Register .................................................................. 20
3.2.1.3 Slave Information Interface (SII) ..................................................................................... 22
3.2.2 MBX (Mailbox) component .............................................................................................................. 25
3.3 CoE function ................................................................................................................................. 25
3.3.1 CoE function .................................................................................................................................... 25
3.3.1.1 CoE Emergencies........................................................................................................... 26
3.3.2 SDO component .............................................................................................................................. 26
3.3.3 ODV3 component ............................................................................................................................ 26
3.3.3.1 Access rights .................................................................................................................. 27
3.3.3.2 CoE Communication Area for EtherCAT ........................................................................ 27
3.3.3.3 Custom Object Directory based on Minimal Object Directory ......................................... 27
3.3.3.4 Description of objects of minimal object dictionary ......................................................... 28
3.3.3.5 Default Object Dictionary ................................................................................................ 30
3.3.3.6 PDO Mapping for cyclic Communication ........................................................................ 32
3.3.3.7 Complete Access............................................................................................................ 33
3.4 Behavior when receiving a Set Configuration command ............................................................. 33
3.5 Watchdogs ................................................................................................................................... 34
3.5.1 DPM watchdog ................................................................................................................................ 34
3.5.1 SM Watchdog .................................................................................................................................. 34
3.5.1 PDI Watchdog ................................................................................................................................. 34
3.6 Ethernet MAC address ................................................................................................................. 35
4 Status information ................................................................................................................................ 36
4.1 Common status ............................................................................................................................ 36
4.2 Extended status ........................................................................................................................... 36
5 Requirements to the application......................................................................................................... 37
5.1 Sequence within the host application........................................................................................... 37
5.2 General initialization sequence .................................................................................................... 38
5.3 Explicit Device Identification......................................................................................................... 39
5.3.1 Initialization sequence ..................................................................................................................... 39
5.3.2 Set Firmware Parameter ................................................................................................................. 41
5.4 Complete Access for object data hold by application .................................................................. 43
EtherCAT Slave V5 | Protocol API
DOC181005API01EN | Revision 1| English | 2019-04 | Released | Public © Hilscher, 2018-2019
Table of contents 3/127
5.5 Dynamic PDO mapping................................................................................................................ 45
5.5.1 One application registered (application successful) ........................................................................ 46
5.5.2 One application registered (application not successful) .................................................................. 48
5.5.3 Multiple applications registered (one application unsuccessful) ...................................................... 48
5.5.4 Complete Access: one application registered (application successful) ........................................... 49
5.6 Remanent data handling .............................................................................................................. 50
5.6.1 Protocol stack stores remanent data ............................................................................................... 51
5.6.2 Application stores remanent data .................................................................................................... 51
6 Application interface ............................................................................................................................ 52
6.1 General......................................................................................................................................... 52
6.1.1 Register Application service ............................................................................................................ 52
6.1.2 Unregister Application service ......................................................................................................... 53
6.1.3 Link Status Changed service ........................................................................................................... 53
6.2 Configuration ................................................................................................................................ 53
6.2.1 Set Configuration service ................................................................................................................ 53
6.2.1.1 Set Configuration request ............................................................................................... 54
6.2.1.2 Set Configuration confirmation ....................................................................................... 68
6.2.2 Set Trigger Type service ................................................................................................................. 69
6.2.3 Get Trigger Type service ................................................................................................................. 69
6.2.4 Set IO Size service .......................................................................................................................... 70
6.2.4.1 Set IO Size request ........................................................................................................ 70
6.2.4.2 Set IO Size confirmation ................................................................................................. 71
6.2.5 Set Station Alias service .................................................................................................................. 72
6.2.5.1 Set Station Alias request ................................................................................................ 72
6.2.5.2 Set Station Alias confirmation ......................................................................................... 73
6.2.6 Get Station Alias service ................................................................................................................. 74
6.2.6.1 Get Station Alias request ................................................................................................ 74
6.2.6.2 Get Station Alias confirmation ........................................................................................ 75
6.3 EtherCAT State Machine ............................................................................................................. 76
6.3.1 Register for AL Control Changed Indications service ...................................................................... 76
6.3.1.1 Register for AL Control Changed Indications request ..................................................... 77
6.3.1.2 Register For AL Control Changed Indications confirmation ............................................ 78
6.3.2 Unregister From AL Control Changed Indications service ............................................................... 79
6.3.2.1 Unregister From AL Control Changed Indications request ............................................. 79
6.3.2.2 Unregister from AL Control Changed Indications confirmation ....................................... 80
6.3.3 AL Control Changed service............................................................................................................ 81
6.3.3.1 AL Control Changed Indication ....................................................................................... 81
6.3.3.2 AL Control Changed response ....................................................................................... 84
6.3.4 AL Status Changed service ............................................................................................................. 85
6.3.4.1 AL Status Changed Indication ........................................................................................ 85
6.3.4.2 AL Status Changed response ......................................................................................... 87
6.3.5 Set AL Status service ...................................................................................................................... 88
6.3.5.1 Set AL Status request ..................................................................................................... 88
6.3.5.2 Set AL Status confirmation ............................................................................................. 89
6.3.6 Get AL Status service ...................................................................................................................... 90
6.3.6.1 Get AL Status request .................................................................................................... 90
6.3.6.2 Get AL Status confirmation ............................................................................................. 91
6.4 CoE .............................................................................................................................................. 92
6.4.1 Send CoE Emergency service......................................................................................................... 92
6.4.1.1 Send CoE Emergency request ....................................................................................... 92
6.4.1.2 Send CoE Emergency confirmation ................................................................................ 94
6.5 Packets for Object Dictionary access .......................................................................................... 95
6.6 Slave Information Interface (SII) .................................................................................................. 95
6.6.1 SII Read service .............................................................................................................................. 95
6.6.1.1 SII Read request............................................................................................................. 95
6.6.1.2 SII Read confirmation ..................................................................................................... 96
6.6.2 SII Write service .............................................................................................................................. 97
6.6.2.1 SII Write request ............................................................................................................. 97
6.6.2.2 SII Write confirmation ..................................................................................................... 97
6.6.3 Register for SII Write Indications service ......................................................................................... 99
6.6.3.1 Register for SII Write Indications request ....................................................................... 99
6.6.3.2 Register for SII Write Indications confirmation .............................................................. 100
6.6.4 Unregister from SII Write Indications service................................................................................. 101
6.6.4.1 Unregister from SII Write Indications request ............................................................... 101
6.6.4.2 Unregister from SII Write Indications confirmation........................................................ 102
6.6.5 SII Write Indication service ............................................................................................................ 103
6.6.5.1 SII Write indication........................................................................................................ 103
6.6.5.2 SII Write response ........................................................................................................ 104
EtherCAT Slave V5 | Protocol API
DOC181005API01EN | Revision 1| English | 2019-04 | Released | Public © Hilscher, 2018-2019
Table of contents 4/127
6.7 Ethernet over EtherCAT (EoE) ..................................................................................................105
6.7.1 Socket interface ............................................................................................................................. 105
6.7.2 Ethernet interface .......................................................................................................................... 105
6.8 Remanent data services ............................................................................................................105
6.8.1 Set Remenent Data ....................................................................................................................... 105
6.8.2 Store Remenent Data .................................................................................................................... 105
7 Resource and feature configuration via tag list ..............................................................................106
8 Status and error codes ......................................................................................................................107
8.1 Stack-specific error codes ..........................................................................................................107
8.1.1 General.......................................................................................................................................... 107
8.1.2 Set Configuration ........................................................................................................................... 107
8.1.3 ESM............................................................................................................................................... 108
8.1.4 MBX............................................................................................................................................... 108
8.1.5 CoE ............................................................................................................................................... 108
8.1.6 DPM .............................................................................................................................................. 110
8.1.7 EoE ............................................................................................................................................... 111
8.1.8 ODV3............................................................................................................................................. 111
8.2 EtherCAT-specific error codes ...................................................................................................112
8.2.1 AL status codes ............................................................................................................................. 112
8.2.1.1 Standard AL status codes ............................................................................................ 112
8.2.1.2 Vendor-specific AL status codes .................................................................................. 113
8.2.2 CoE Emergency codes .................................................................................................................. 114
8.2.3 Error LED status ............................................................................................................................ 115
8.2.4 SDO Abort codes .......................................................................................................................... 116
8.2.4.1 SDO Abort codes.......................................................................................................... 117
8.2.4.2 Correspondence of SDO Abort codes and status / error codes .................................... 118
9 Appendix .............................................................................................................................................120
9.1 Legal notes .................................................................................................................................120
9.2 EtherCAT summary concerning vendor ID, conformance test, membership and network logo 123
9.3 List of tables ...............................................................................................................................124
9.4 List of figures ..............................................................................................................................126
9.5 Contacts .....................................................................................................................................127

EtherCAT Slave V5 | Protocol API

1 Introduction
1.1 About this document
This manual describes the application interface of the EtherCAT Slave protocol stack V5 and
provides information about how an application has to use the EtherCAT Slave protocol stack.

1.1.1 List of revisions

Rev Date Name Revision
1 2019-04-05 HHE, RGÖ Firmware/stack version V5.1.0
Table 1: List of revisions

1.2 Functional overview

The stack has been written in order to meet the IEC 61158 Type 12 specification. The following
features are implemented in the stack:
EtherCAT Base Component
 HAL initialization of the associated EtherCAT interface
 EtherCAT interrupt handling
 EtherCAT State Machine
 Mailbox Receive handling
 Mailbox Send handling
CANopen over EtherCAT Component
 Master-to-Slave SDO communication
 Slave-to-Slave SDO communication
 Object dictionary
 Complete Access
Ethernet over EtherCAT Component
File Access over EtherCAT Component

1.3 System requirements

This software package has the following system requirements to its environment:
 netX chip as CPU hardware platform

1.4 Intended audience

This manual is suitable for software developers with the following background:
 Knowledge of the programming language C
Further knowledge in the following areas might be useful:
 Knowledge of the IEC 61158 Part 2-6 Type 12 specification documents
 Knowledge of the IEC 61800-7-300
 Knowledge of the IEC 61800-7-204

EtherCAT Slave V5 | Protocol API

1.5 Technical data

The data below applies to EtherCAT Slave firmware and stack version V5.1.0.

Technical data

Feature Value
Maximum number of cyclic input data 1024 bytes
Maximum number of cyclic output data 1024 bytes
Acyclic communication (CoE) SDO
SDO Master-Slave
SDO Slave-Slave (depending on master capability)
Type Complex Slave
Supported protocols SDO client and server side protocol
CoE Emergency messages (CoE)
Ethernet over EtherCAT (EoE)
File Access over EtherCAT (FoE)
Supported state machine ESM – EtherCAT state machine
Supported of synchronization modes Freerun (The application of the slave is not synchronized to EtherCAT)
Synchronous with SYNCMAN Event (Slave's application is synchronized to
the SM2/3 Event)
Synchronous with SYNC Event (Slave's application is synchronized to the
SYNC0 or SYNC1 Event)
Supported features PDI watchdog
EtherCAT mailbox handling
EtherCAT state machine handling
Master-to-slave SDO communication
Slave-to-slave SDO communication
Integrated CoE object dictionary (ODV3)
Ethernet over EtherCAT (EoE) handling
File Access over EtherCAT (FoE) server
Number of FMMU channels 8
Number of Sync Manager channels 4
Distributed Clocks (DC) Supported with 32-bit timestamps and isochronous PDI functionality
(Sync0, Sync1)
Ethernet 2 Ethernet Interfaces 100BASE-TX/FX, 1 green Link/Activity LED per
Ethernet Interface
Integrated Dual-PHY (supports Auto-Negotiation and Auto-Crossover)
Data transport layer Ethernet II, IEEE 802.3
Table 2: Technical data

Firmware/stack available for netX

netX 50 no
netX 51 no
netX 52 no
netX 90 yes
netX 100, netX 500 no
netX 4000 yes

EtherCAT Slave V5 | Protocol API

Configuration
Configuration by packet to transfer configuration parameters

Diagnostic
Firmware supports common diagnostic in the dual-port-memory for loadable firmware.

Limitations
EtherCAT Slave stack
 AoE application interface not available
 FoE for firmware upload is supported, but application interface not available
ESC - EtherCAT Slave Controller
 no DC Latch functionality
 no support of bit-wise FMMU mapping (Exception: Fill Status of Transmit Mailbox)
 restricted DC Sync-Signal Generation
 no Single-Shot Mode support
 no Acknowledge Mode support
 restricted DC Control Functionality
 no adjustment of Register Speed Counter Start (0x0930:0x931)
 no showing of Register Speed Counter Diff (0x0932:0x933)
 no MIO (PHY Management Interface) access from EtherCAT Master side
 no physical Read-Write commands supported (APRW, FPRW, BRW)

Limitations for specific use cases

Additional limitation for use cases A (netX 90 CPU with no external SPI / SQI Flash and no
external SDRAM at APP CPU) and B (netX 90 CPU with external SPI / SQI Flash or external
SDRAM at APP CPU): FW functions are limited by available internal RAM / Flash
Additional limitation only for use case A (netX 90 CPU with no external SPI / SQI Flash and no
external SDRAM at APP CPU): COM firmware size is limited to 500 KB

EtherCAT Slave V5 | Protocol API

1.6 Terms, abbreviations and definitions

Term Description
ADS Automation Device Specification
AL Application layer
AoE ADS over EtherCAT
AP (-task) Application (-task) on top of the stack
API Application Programming Interface
ASCII American Standard Code for Information Interchange
CoE CANopen over EtherCAT
COS Change of State
DC Distributed Clocks
DL Data Link Layer
DPM Dual port memory
E2PROM (EEPROM) Electrically erasable Programmable Read-only Memory
EoE Ethernet over EtherCAT
ESC EtherCAT Slave Controller
ESM EtherCAT State Machine
ETG EtherCAT Technology Group
EtherCAT Ethernet for Control and Automation Technology
FMMU Fieldbus Memory Management Unit
FoE File Access over EtherCAT
IEEE Institute of Electrical and Electronics Engineers
LFW Loadable firmware
LOM Linkable object modules
LSB Least significant byte
MSB Most significant byte
OD Object dictionary
ODV3 Object dictionary Version 3
PHY Physical Interface (Ethernet)
PDO Process Data Object (process data channel)
RTR Remote Transmission Request
RxPDO Receive PDO
SDO Service Data Object (representing an acyclic data channel)
SHM Shared memory
SM Sync Manager
SoE Servo Profile over EtherCAT
SSC SoE Service Channel
TxPDO Transmit PDO
VoE Vendor Profile over EtherCAT
XML eXtensible Markup Language
Table 3: Terms, abbreviations and definitions

EtherCAT Slave V5 | Protocol API

1.7 References to documents

This document refers to the following documents:
[1] Hilscher Gesellschaft für Systemautomation mbH: netX Dual-Port Memory Interface Manual,
Revision 15, English, 2019.
[2] Hilscher Gesellschaft für Systemautomation mbH: Packet API, netX Dual-Port Memory,
Packet-based services (netX 90/4000/4100), Revision 1, English, 2019.
[3] Hilscher Gesellschaft für Systemautomation mbH: Object Dictionary V3 Protocol API,
Revision 4, English, 2017.
[4] Hilscher Gesellschaft für Systemautomation mbH: Protocol API, Socket Interface, Packet
Interface, Revision 5, English, 2019.
[5] Hilscher Gesellschaft für Systemautomation mbH: Protocol API, Ethernet interface, Packet
interface, Revision 10, English, 2019.
[6] IEC 61158 Part 2-6 Type 12 documents (also available for members of EtherCAT
Technology Group as specification documents ETG-1000)
[7] Proceedings of EtherCAT Technical Committee Meeting from February 9th, 2005.
[8] IEC 61800-7
[9] EtherCAT Specification Part 5 – Application Layer services specification. ETG.1000.5.
[10] EtherCAT Specification Part 6 – Application Layer protocol specification. ETG.1000.6.
[11] EtherCAT Indicator and Labeling Specification. ETG.1300.
[12] EtherCAT Protocol Enhancements. ETG.1020.
[13] EtherCAT Slave Information Annotation ETG 2001
[14] EtherCAT Slave Information Specification ETG.2000

EtherCAT Slave V5 | Protocol API

2 Getting started
This chapter describes the basics of the Hilscher EtherCAT Slave stack. This includes information
about
 the use case
 the configuration of the EtherCAT Slave stack
 principles of cyclic and acyclic data exchange
 object dictionary

2.1 Loadable Firmware (LFW)

The application and the EtherCAT Slave Protocol Stack run on different processors. While the host
application runs on a computer typically equipped with an operating system (such as Microsoft
Windows® or Linux), the EtherCAT Slave Protocol Stack runs on the netX processor together with
a connecting software layer, the AP task. The connection is accomplished via a driver (Hilscher
cifX Driver, Hilscher netX Driver) as software layer on the host side and the AP task as software
layer on the netX side. Both communicate via a dual port memory (DPM) into which they both can
write and from which they both can read. Figure 1 explains this situation:

Figure 1: Use case: Loadable Firmware

2.2 Configuration
2.2.1 Configuration methods
You can use one of the following methods to configure the EtherCAT Slave stack:
 The application can set the configuration parameters using the Set Configuration service to
transfer the parameters within a packet to the stack.
 You can use one of the following configuration software to set the configuration parameters.
 You can use Communication Studio configuration software (which creates a
configuration file named CONFIG.NXD)

2.2.2 Sequence and priority of configuration evaluation

The EtherCAT Slave stack has implemented the following sequence and priority of configuration
evaluation:
EtherCAT Slave V5 | Protocol API
DOC181005API01EN | Revision 1| English | 2019-04 | Released | Public © Hilscher, 2018-2019
Getting started 11/127
1. In case the file CONFIG.NXD is available, the stack will use the configuration parameters
from this file and starts working.
2. The stack “waits” for the configuration parameters and remains unconfigured. The application
has to use the Set Configuration service (see page 53) to configure the EtherCAT Slave and
a Channel Init service to activate the configuration parameters.

2.2.3 Configuration parameters

Basic configuration parameters
The basic configuration parameters set the values for e.g. startup behavior of the stack, the vendor
id, product code, etc. The application has to set these parameters with the Set Configuration
service (page 53).

Component configuration parameters

The EtherCAT Slave stack consists of several components. Each component has is its own
parameters (configuration structure).
The following table lists the components of the stack.
Component Meaning Details on page
CoE CANopen over EtherCAT 60
Data structure for configuration of CoE component
Structure ECAT_SET_CONFIG_COE_T
EoE Ethernet over EtherCAT 61
Data structure for configuration of EoE component
Structure ECAT_SET_CONFIG_EOE_T

EtherCAT Slave V5 | Protocol API

FoE File Access over EtherCAT

Data structure for configuration of FoE component (component not yet supported)
Structure ECAT_SET_CONFIG_FOE_T
SoE Servo Profile over EtherCAT 61
Data structure for configuration of SoE component (component not yet supported)
Structure ECAT_SET_CONFIG_SOE_T
Sync Modes Synchronization modes 62
Data structure for configuration of Sync Modes component
Structure ECAT_SET_CONFIG_SYNCMODES_T
Sync PDI Process data interface for synchronization 63
Data structure for configuration of Sync PDI component
Structure ECAT_SET_CONFIG_SYNCPDI_T
UID Unique Identification 64
Data structure for configuration of UID component
Structure ECAT_SET_CONFIG_UID_T
Boot Mbx Boot mailbox 65
Data structure for configuration of Bootmailbox component
Structure ECAT_SET_CONFIG_BOOTMBX_T
Device Info Device information 66
Data structure for configuration of Device Info component
Structure ECAT_SET_CONFIG_DEVICEINFO_T
Sm Length Sync Manager 67
Data structure for configuration of Syncmanagers address spaces
Structure ECAT_ESM_CONFIG_SMLENGTH_DATA_T
Table 4: Component configuration parameters

You only have to fill these data structures with data if they are used and evaluated. This depends
on the flags within parameter Component Initialization of the Base Configuration Parameters
described above. Each flag controls whether the data structure for a single component is evaluated
(flag set) or not (flag equals 0).
Please refer to chapter Set Configuration service on page 53 for a detailed programming
reference.

2.2.4 Application sets the configuration parameters

In case the application configures the EtherCAT Slave, the application has to perform the following
steps:
1. Configure the device using the Set Configuration service (page 53). This provides the device
with all parameters needed for operation. These include both basic parameters for I/O sizes
and for identification such as Vendor ID and Product code as well as the component
configuration. When the stack confirms the Set Configuration to the application, the given
configuration has been evaluated completely and prepared for use.
If the application sends several configuration packets to the stack, the stack uses the last
received configuration packet before the application sends a Channel Init.
2. Perform the Channel Init (for further information, see reference [1]) to activate the
configuration parameters. As a result, the stack is ready to start communication with an
EtherCAT Master.
Figure 2 shows the Set Configuration and Channel Init sequence.

EtherCAT Slave V5 | Protocol API

Figure 2: Set Configuration / Channel Init

2.2.4.1 Reconfiguration
It is possible to reconfigure the stack at any time. To do so, simply send a new configuration to the
stack followed by a Channel Init request (reference [1]). Sending the new configuration without the
Channel Init request will not have an effect to the running communication. The new parameters will
be stored in the RAM only. Sending the Channel Init request will stop any communication and take
over the new parameters.
As an alternative for reconfiguration, a specific packet is available (section Set IO Size service on
page 70) which contains two parameters only: input length and output length. Thus, it is not
necessary to send a complete configuration packet twice.

EtherCAT Slave V5 | Protocol API

2.2.4.2 Delete configuration

The deletion of the configuration is not possible in EtherCAT because this would stop the physical
interface to work and thus break the logical ring structure and cut the communication with the
following slaves in the topology.

2.2.4.3 Configuration lock

If the configuration of the stack is locked as described in Dual-Port Memory Interface Manual
(reference [1]) the following behavior is implemented in the stack:
 The stack does not accept new configuration packets.
 The stack rejects any Channel Init Request.

2.2.5 Configuration software

A separate manual describes the configuration via Communication Studio.

2.3 Cyclic data exchange - Process data input and output

This section describes how the application can get access to the cyclic IO data, which is
exchanged with the EtherCAT Master. The EtherCAT Slave stack provides different ways to
exchange this data. Depending on the user’s application, only one of these methods may be used:
Use case loadable firmware: If the netX chip operates as dedicated communication processor,
while the user’s application runs on its own host processor, I/O data can be accessed using the
mechanism described in reference [1] only.
EtherCAT uses the concept of a cyclic process data image. Each master or slave of an EtherCAT
network has an image of input and output data. This process data image is updated using cyclic
Ethernet frames.
More information on how cyclic data exchange is accomplished with suitable PDO mappings can
be found at subsection PDO Mapping on page 32.

Input and output data of EtherCAT Slave

Offset Area Length (byte) Type

0x1000 Output block 1024 Read/Write
0x2680 Input block 1024 Read
Table 5: Input and output data

2.3.1 Bus On / Bus Off

The BusOn/Off bit controls whether the stack is allowed to proceed further than Pre-Operational
state.
If this bit is set, the stack can be brought into Operational state by the EtherCAT master e.g.
TwinCAT.
If this bit is cleared, the stack will fall back to Pre-Operational state and notify the master about this
by setting the code ECAT_AL_STATUS_CODE_HOST_NOT_READY in the AL Status Code area.
#define ECAT_AL_STATUS_CODE_HOST_NOT_READY 0x8000
For a list of available AL Status Codes please refer to chapter AL status codes.

EtherCAT Slave V5 | Protocol API

2.4 Acyclic data exchange

Acyclic communication: Application to EtherCAT Slave
The EtherCAT Slave stack uses two mailboxes in the dual-port memory to communicate (acyclic
communication) with the application.
This acyclic communication via the dual-port memory is done through channels, which each have
two mailboxes. A Send Mailbox for transfer from host system to firmware or and a Receive Mailbox
transfers from firmware to host system. Each mailbox can hold one packet at a time. The netX
firmware stores packets that are not retrieved by the host application in a packet queue.

Note: The packet queue has limited space and may fill up so new packets may be lost. To
avoid these data loss situations, we strongly recommend emptying the mailbox
frequently, even if the host application does not expect any packets.

Acyclic communication: EtherCAT Master to EtherCAT Slave via Service Data Objects
For acyclic data exchange between an EtherCAT Slave and an EtherCAT Master, the EtherCAT
mailbox is used. The ODV3 component manages Service Data Objects accomplishing acyclic data
exchange. For more information refer to the separate ODV3 documentation, see document
reference [3].

EtherCAT Slave V5 | Protocol API

2.5 Object Dictionary

The EtherCAT Slave uses objects to hold values and device parameters. The EtherCAT Master
can access via the EtherCAT network to these objects and the application can access these
objects.
You can operate the stack either with the default object dictionary or with a custom object
dictionary.

Default object dictionary

The default object dictionary contains all objects that are necessary to bring the slave to
operational state.
In the default object dictionary, the objects, which define the process input data and the process
output data, are handled as single bytes and each byte is represented by a subobject in the object
dictionary.
If a configuration software is used to configure the EtherCAT Slave device, the default object
dictionary has to be used.
Section Default Object Dictionary on page 27 describes the default object dictionary.

Custom object dictionary

The custom object dictionary can be used to structure the process input data and the process
output data with several/different data types e.g. to use data type uint32_t. This requires that the
application program configure the stack.
The custom object dictionary contains a minimal object dictionary only and the application has to
add all mandatory objects and objects required for the use case.
Section Custom Object Directory based on Minimal Object Directory on page 27 describes the
minimal object dictionary.

EtherCAT Slave V5 | Protocol API

3 Stack structure and stack functions

3.1 Structure of the EtherCAT Slave stack
The following figure shows the internal structure of the EtherCAT Slave stack.

Figure 3: Structure of EtherCAT Slave stack

The following table explains the meaning stack functions:

Function Description
Base function The base function provides the EtherCAT state machine and the mailbox of an EtherCAT
slave.
CoE This function splits the CoE messages according to their rule in the CANopen over
EtherCAT. It also handles CoE emergencies.
SDO (part of CoE) This component handles all SDO-based communications inside the CoE component.
ODV3 (part of CoE) This component performs all accesses to the object dictionary (such as reading, writing,
creating, deleting and maintaining objects). For a description of the ODV3 services, see
reference [3].
EoE This provides the Ethernet over EtherCAT function.
FoE This component provides the File over EtherCAT function.
Generic AP Task Interface to the application.
EtherCAT GCI Adapter Adapts the API services to stack internal function calls.
Table 6: EtherCAT Slave stack functions

EtherCAT Slave V5 | Protocol API

DOC181005API01EN | Revision 1| English | 2019-04 | Released | Public © Hilscher, 2018-2019
Stack structure and stack functions 18/127
The stack provides the following functionality:
The Generic AP task represents the interface between the EtherCAT Slave protocol stack and the
dual-port memory and is responsible for:
 Control of LEDs
 Diagnosis
 Packet routing
 Update of the IO data
 The EtherCAT state machine manages the states and operation modes of the protocol stack,
generates AL Control events, and sends them to all registered receivers.
 The EtherCAT Mailbox / DL (MBX component) provides the low-level part of data
communication.
 The CoE function handles the CoE related mailbox messages and routes them to the
appropriate components. In addition, the CoE function provides a mechanism for sending
CoE emergency messages.
 The SDO component performs SDO communication via mailboxes, i.e. acyclic
communication such as service requests.
 The ODV3 component handles access to the object dictionary (acyclic communication).
The triple buffer mechanism provides a consistent synchronous access procedure from both sides
(DPM and Generic AP task). The triple buffer technique ensures that the access will always affect
the last written cell.
You can find information about the various component:
 In section ESM component beginning at page 19 for the ESM component
 In section MBX beginning at page 25 for the MBX component
 In section CoE function beginning at page 25 for the CoE component
 In section SDO beginning at page 26 for the SDO component
 In reference [3] for the ODV3 component
The dual-port memory is used to exchange information, data and packets. The EtherCAT Slave
Generic AP task takes care of mapping the EtherCAT Stack API to the Dual-Port-Memory. The
application only accesses the AP component.

Overview
The main topics described in this chapter are:
 Base Component
 CoE function
 EoE Component
The packets mentioned in this chapter are described in the programming reference within the next
chapter Application interface.

EtherCAT Slave V5 | Protocol API

3.2 Base function

3.2.1 ESM component

The ESM component coordinates all components that have registered themselves with their
respective queues as AL control event receivers. Additionally, it notifies the mailbox component of
the current state and sets their operation modes.

3.2.1.1 EtherCAT State Machine (ESM)

Purpose
The EtherCAT State Machine (ESM) can describe the states and state changes of the slave
application. The ESM implements the following four states that the EtherCAT specification
precisely describes (see there for reference):
 Init: The EtherCAT Slave is initialized in this state. No real process data exchange happens.
 Pre-Operational: Initialization of the EtherCAT Slave continues. No real process data
exchange happens. The master and the slave communicate acyclically via mailbox to set
parameters.
 Safe-Operational: In this state, the EtherCAT Slave can process input data. However, the
output data are set to a ‘safe’ state.
 Operational: In this state, the EtherCAT Slave is fully operational.
A fifth state called Bootstrap is also allowed by the EtherCAT specification, but not necessary.

Figure 4: State Diagram of EtherCAT State Machine (ESM)

Note: The states Operational and Safe-Operational may be prohibited in special situations.
See section Basic configuration parameters on page 11 for more information.

Closely connected to the ESM are the AL Control Register and the AL Status Register of the
EtherCAT Slave. See reference [1] for more information on these registers.

EtherCAT Slave V5 | Protocol API

3.2.1.2 AL Control Register and AL Status Register

 The AL Control Register contains the requested state of the EtherCAT slave.
 The AL Status Register contains the current state of the EtherCAT slave.

Handling and controlling the EtherCAT State Machine

The AL Control Register and the AL Status Register provide a synchronization mechanism for
state transitions between the master and the slave. The EtherCAT specification precisely describes
these, see there for more information.
The Hilscher EtherCAT slave stack provides mechanisms for notifying user applications about
state changes of the EtherCAT State Machine (ESM). Furthermore, an application can control
state changes of the ESM if necessary. Such mechanisms are necessary for the realization of
complex EtherCAT slaves (see reference [9]). If an application wants to get informed about state
changes it has to register via HIL_REGISTER_APP_REQ. As result, the stack will send an AL
Status Changed Indication to the application.

Figure 5: Sequence diagram of state change with indication to application/host

The packets mentioned above indicate that a state change has already happened. An application
has no chance to control or interrupt a transition; it just gets informed about it.
To unregister use the HIL_UNREGISTER_APP_REQ packet.
If an application additionally wants to control ESM state changes, it has to register for AL
Confirmed Services.
Registering for AL Confirmed Services may be necessary e.g. in following cases:
 Servo Drive with use of Distributed Clock (Synchronization)
In Motion Control applications, it is of utmost importance that all devices work synchronized.
Therefore, drives often use a Phased Locked Loop (PLL) to synchronize their local control
loop with the bus cycle. As long as this has not happened, the status of the device may not
proceed to „Operational“(see reference [10]). Using AL Confirmed services, an application
can delay the start up process and synchronize their local control loop first. After the local
PLL has “locked in” the device may proceed to „Operational“.

EtherCAT Slave V5 | Protocol API

DOC181005API01EN | Revision 1| English | 2019-04 | Released | Public © Hilscher, 2018-2019
Stack structure and stack functions 21/127
 CoE Slaves with dynamic PDO mapping allow a flexible arrangement of process data. The
master configures the layout of the process data, which the slave has to transmit during
cyclic operation. Therefore CoE Slaves often delay the transition to „Safe-Operational“ and
set up copy lists before eventually proceeding to the requested state. This approach allows
the slaves just to process the copy lists in cyclic operation, regardless to the configured
mapping, which is very fast.
When using LFW or SHM API, the AL Control Changed service relies upon a packet mechanism.
For registering the service, use Register for AL Control Changed Indications service. To unregister
use Unregister From AL Control Changed Indications service.
After registering for AL Control Changed service, the stack informs an application via AL Control
Changed Indication packet each time when a master has requested a state change of the ESM via
AL Control register (0x0120). The stack will remain in the current state until the application triggers
a state change via a Set AL Status request. This enables an application to delay or even interrupt a
state change. Furthermore, it can signalize errors to the master using AL Status Codes (see
reference [10] or chapter AL status codes of this document).

Figure 6: Sequence diagram of EtherCAT state change controlled by application/host

Note: The stack will not send any indications when switching downwards, for instance when
switching from Operational down to Init state.

EtherCAT Slave V5 | Protocol API

Figure 7: Sequence diagram of state change controlled by application/host with additional AL Status Changed indications

3.2.1.3 Slave Information Interface (SII)

As mandatory element, each EtherCAT slave has a slave information interface (SII) which is
accessible by the slave. Physically, this is a special storage area for slave-specific data in an
EEPROM memory chip. Its size is variable in the range of 1 kBits – 512 kBits (128 – 65536 Bytes).
The size of the SII is limited to 64 K. Because there is no separate EEPROM in the netX chips, the
SII is virtually created in the netX.
After configuration, the firmware writes the content of the SII to the virtual EEPROM. In case the
application has created a custom object dictionary, the EtherCAT Slave does not have enough
information to write the whole SII image. In this case, the application has to write the SII data
starting from address 0x80 using the SII related functions (see section Slave Information Interface
(SII) on page 95) at every startup of the device.

EtherCAT Slave V5 | Protocol API

DOC181005API01EN | Revision 1| English | 2019-04 | Released | Public © Hilscher, 2018-2019
Stack structure and stack functions 23/127
Structure
You can consider the SII as a collection of persistently stored objects. For instance, these objects
may be:
 configuration data
 device identity
 application information data
Masters access the SII of the Slave in order to obtain slave-specific information for instance for
administrative and configuration purposes.
The Hilscher EtherCAT Slave Stack provides following packets for SII interaction (see section
Slave Information Interface (SII) on page 95):
 SII Read service
 SII Write service
 Register for SII Write Indications service
 Unregister from SII Write Indications service
 SII Write Indication service
The contents stored in the SII can be divided into the following separate groups of parameters:
Slave Information Interface Structure (as defined in IEC 61158, part 6-12)

Address Range Value/Description

0x0000 - 0x0007 EtherCAT Slave Controller configuration area
0x0008 - 0x000F Device identity (corresponds to CoE object 1018h)
0x0010 – 0x0013 Delay configuration
0x0014 - 0x0017 Configuration data for the Bootstrap Mailbox
0x0018 - 0x001B Configuration data for the Standard Send/Receive Mailbox
0x001C - 0x003F Other settings
> 0x003F Optionally additional information may be present
Table 7: Slave Information Interface structure

Note: The addresses mentioned in the table above relate to 16-bit words.

More detailed information about the SII structure can be obtained from the standard document IEC
61158, part 6-12, “EtherCAT Application layer protocol specification” (especially refer to section
5.4, “SII coding” in this context). Also the EtherCAT Specification Part 5 (ETG1000.5: “Application
layer service definition”) might contain additional information. These standard documents are
available from ETG.
The optional additional information area (addresses > 0x003F) is organized by different categories.
There are standard categories and vendor-specific categories allowed. All categories have a
header containing among others the length information of the rest of the data of the category.
Unknown categories may be skipped during evaluation.

EtherCAT Slave V5 | Protocol API

DOC181005API01EN | Revision 1| English | 2019-04 | Released | Public © Hilscher, 2018-2019
Stack structure and stack functions 24/127
In general, each of these categories mentioned in Table 9: Available standard categories is
structured as follows:
Slave Information Interface Categories

Parameter Address Data Type Value/Description

1st Category Header 0x40 UNSIGNED15 Category Type
0x40 UNSIGNED1 Reserved for vendor-specific purposes
0x41 UNSIGNED16 Length String1
1st Category data 0x42 Category dependent String1 Data
2nd Category Header 0x42 + x UNSIGNED15 Category Type
UNSIGNED1 Reserved for vendor-specific purposes
UNSIGNED16 Length String2
2nd Category data Category dependent String2 Data
… …
Table 8: Definition of categories in SII

The following standard categories are available:

Category Description Category Type Supported by the Is generated at ‘Set
Hilscher EtherCAT Configuration’
Protocol Stack
NOP No info 0 Yes No
STRINGS String repository for other 10 Yes Yes
Categories structure
Data types Data Types (reserved for 20 No No
future use)
General General information structure 30 Yes Yes

FMMU FMMUs to be used structure 40 Yes Yes

SyncM Sync Manager Configuration 41 Yes Yes
structure
TXPDO TxPDO description structure 50 Yes No

RXPDO RxPDO description structure 51 Yes No

PDO Entry PDO Entry description - Yes No

structure
Table 9: Available standard categories

For more information on the standard categories, refer to the following tables of reference [10]:
 For STRINGS: see table 20.
 For General: see table 21.
 For FMMU: see table 22.
 For SyncM: see table 23.
 For TXPDO and RXPDO: see table 24.
Hilscher does not define any additional vendor-specific categories of its own.

EtherCAT Slave V5 | Protocol API

3.2.2 MBX (Mailbox) component

Purpose
On the first hand, the MBX component handles all mailbox messages sent by the master and
sends them further to the registered queues according to the type they specified to receive. The
respective parts of the EtherCAT stack e.g. CoE hook to this component to perform their services.
On the other hand, the ECAT_MBX component handles all mailbox messages to be sent to the
master. Additionally, its state is controlled by the ESM component according to the requested state
changes. The respective parts of the EtherCAT stack e.g. CoE hook to this component to perform
their services.
The ECAT_MBX component provides the basis for application level protocols such as
 CoE (CANopen over EtherCAT)

3.3 CoE function

The main topics described in this chapter are:
 CoE function
 SDO component
 Object Dictionary V3 component

Purpose
There are two different reasons to use CoE (CANopen over EtherCAT):
1. CoE provides acyclic communication. Use CoE to access and configure service data such as
communication parameters or device-specific parameters. These service data are stored as
service data objects (SDO) within an object dictionary (OD). The EtherCAT Slave protocol
stack V5 from Hilscher uses the Object Dictionary V3, which is described in reference [3].
2. CoE also provides an easy migration path from CANopen to EtherCAT. CoE emulates a
CAN-based environment working on EtherCAT and allows the use of CAN profiles.
In detail, the CoE functionality allows:
 SDO download: Acyclic data transfer from the master to a slave
 SDO upload: Acyclic data transfer from a slave to the master
 SDO information service: reading SDO object properties (object dictionary) from a slave
 CoE Emergency Requests
The host can initialize uploads, downloads and information services. Only slaves will generate
emergencies. The master collects the emergencies and displays them via the slave diagnosis.
In addition, CoE affects cyclic communication, as the communication parameters related to PDOs
can be configured via SDO to specific object dictionary entries. For more information, see section
PDO Mapping on page 32.
For more information, see references [9] and [10].
3.3.1 CoE function
The ECAT_COE component is the main handler of all CoE related mailbox messages and routes
them to the components associated with those inside the CoE function. In addition, the ECAT_COE
component provides a mechanism for sending CoE emergency messages.

EtherCAT Slave V5 | Protocol API

3.3.1.1 CoE Emergencies

If abnormal states or conditions occur, the slaves send CoE emergencies to the master. A CoE
emergency message contains a standard CANopen emergency frame consisting of
 Error code (2 bytes)
 Error register (1 byte)
 Data (5 bytes)
The CoE emergency message may contain additional data.
The master collects the CoE emergencies and stores up to five emergencies per slave. If further
emergencies occur, these are dropped. The existence of at least one emergency is represented in
the slave diagnosis of the master. The host can read out these emergencies. The host decides
whether it deletes the emergencies or they remain in the master.
 See section Send CoE Emergency service on page 92 for more information about the CoE
Emergency Service.
 See section CoE Emergency codes on page 114 for a list of CoE Emergency codes and their
meanings.

3.3.2 SDO component

The SDO component does not provide any packets for the host application to communicate with.
The complete packet interface for the SDO functionality of the EtherCAT Slave protocol stack V5 is
provided by ODV3 and described in an own separate manual (reference [3]).

3.3.3 ODV3 component

This component acts as a connection to the object dictionary V3 described in reference [3].
It provides the following functionality:
 Basic services for reading and writing objects
 Information services for retrieving object-related information
 Management services for creating, maintaining and deleting objects
A stack can be configured with more than one ODV3 component.
Also take the following topics into account:
 Access rights
 Complete Access
 CoE Communication Area for EtherCAT
 Custom Object Directory based on Minimal Object Directory
 Description of objects of minimal object dictionary

EtherCAT Slave V5 | Protocol API

3.3.3.1 Access rights

For access rights that apply for the EtherCAT Slave protocol stack V5, see reference [3].
Additionally, the following combinations have been defined:
ECAT_OD_READ_ALL = (ECAT_OD_READ_PREOP | ECAT_OD_READ_SAFEOP | ECAT_OD_READ_OPERATIONAL |
ECAT_OD_READ_INIT)
ECAT_OD_WRITE_ALL = (ECAT_OD_WRITE_PREOP | ECAT_OD_WRITE_SAFEOP |
ECAT_OD_WRITE_OPERATIONAL | ECAT_OD_WRITE_INIT)
ECAT_OD_ECAT_ALL = (ECAT_OD_SETTINGS | ECAT_OD_BACKUP | ECAT_OD_MAPPABLE_IN_TXPDO |
ECAT_OD_MAPPABLE_IN_RXPDO | ECAT_OD_READ_PREOP | ECAT_OD_READ_SAFEOP |
ECAT_OD_READ_OPERATIONAL | ECAT_OD_WRITE_PREOP | ECAT_OD_WRITE_SAFEOP |
ECAT_OD_WRITE_OPERATIONAL)
ECAT_OD_ACCESS_ALL = (ECAT_OD_READ_ALL | ECAT_OD_WRITE_ALL)
(where | means logical OR operation in this context).
3.3.3.2 CoE Communication Area for EtherCAT
Table 10 lists the structure of the CoE Communication Area.
Data type index Object Name Type M/O/C
1000 VAR Device Type UNSIGNED32 M
1001 Reserved
:::: :::: :::: ::::
1007 Reserved
1008 VAR Manufacturer Device Name String O
1009 VAR Manufacturer Hardware Version String O
100A VAR Manufacturer Software Version String O
100B Reserved
:::: :::: :::: :::: ::::
1017 Reserved
1018 RECORD Identity Object Identity (23h) M
101A Reserved
:::: :::: :::: :::: ::::
Table 10: CoE Communication Area - General overview

For index values larger than 0x1100, please refer to reference [3] or to the EtherCAT specification
(references [9] and [10]).
3.3.3.3 Custom Object Directory based on Minimal Object Directory
Using the ECAT_SET_CONFIG_COEFLAGS_USE_CUSTOM_OD configuration flag, the user can
enable or disable working with a custom object dictionary.
 If this configuration flag is not set, the stack will create a default object dictionary.
 If this configuration flag is set, the stack will only create a minimal object dictionary.
The following contains a list of the objects contained in this minimal object dictionary. Note that
without providing additional objects by a user application an EtherCAT master will not be able to
bring the slave to Operational state.

EtherCAT Slave V5 | Protocol API

Index Subindex Object Comment

0x1000 00 Device Type
0x1018 00 Identity Object Fixed value, set to 4
0x1018 01 Vendor Id
0x1018 02 Product Code
0x1018 03 Revision Number
0x1018 04 Serial Number
Table 11: Minimal Object Directory

The stack always creates these objects regardless of using a custom object dictionary or not.

Note: Each object to be used for process data transfer has to be byte aligned.

3.3.3.4 Description of objects of minimal object dictionary

Device Type

Index 0x1000
Name Device Type
Object code VAR
Data type UNSIGNED32
Category Mandatory
Access Read only
PDO mapping No
Value Bit 0-15: contain the used device profile or the value
0x0000 if no standardized device is used
Table 12: CoE Communication Area - Device Type

Identity Object

Index 0x1018
Name Identity Object
Object code RECORD
Data type IDENTITY
Category Mandatory
Table 13: CoE Communication Area – Identity Object

Number of entries

Index 0x1018

Sub Index 0
Description Number of entries
Data type UNSIGNED8
Entry Category Mandatory
Access Read only
PDO mapping No
Value 4
Table 14: CoE Communication Area – Identity Object - Number of entries

EtherCAT Slave V5 | Protocol API

Index 0x1018

Sub Index 1
Description Vendor ID
Data type UNSIGNED32
Entry Category Mandatory
Access Read only
PDO mapping No
Value Vendor ID assigned by the CiA organization
Table 15: CoE Communication Area – Identity Object - Vendor ID

Product Code

Index 0x1018

Sub Index 2
Description Product Code
Data type UNSIGNED32
Entry Category Mandatory
Access Read only
PDO mapping No
Value Product code of the device
Table 16: CoE Communication Area – Identity Object - Product Code

Revision Number

Index 0x1018

Sub Index 3
Description Revision Number
Data type UNSIGNED32
Entry Category Mandatory
Access Read only
PDO mapping No
Value Bit 0-15: Minor Revision Number of the device
Bit 16-31: Major Revision Number of the device
Table 17: CoE Communication Area – Identity Object - Revision Number

Serial Number

Index 0x1018

Sub Index 4
Description Serial Number
Data type UNSIGNED32
Entry Category Mandatory
Access Read only
PDO mapping No
Value Serial Number of the device
Table 18: CoE Communication Area – Identity Object - Serial Number

EtherCAT Slave V5 | Protocol API

DOC181005API01EN | Revision 1| English | 2019-04 | Released | Public © Hilscher, 2018-2019
Stack structure and stack functions 30/127
3.3.3.5 Default Object Dictionary
The stack creates a default object dictionary if the configuration flag
ECAT_SET_CONFIG_COEFLAGS_USE_CUSTOM_OD is set to zero.
The default object dictionary contains all objects that are necessary to bring the slave to
operational state. The online objects created by the stack match with the objects described in the
ESI file. The RxPDO and TxPDO objects described in the ESI file are the maximum possible
PDO´s, which can be transferred/ created. After the configuration was send to the stack, it creates
a set of process data objects according to the configured process data length. (This set is a subset
of the process data objects in the ESI file.) If the process data size changes due to a Set IO Size
command, the present objects are deleted and a new set of objects is created. For every byte of
process data, a single subobject is created in the OD.
The object dictionary created in this way is not sufficient for every user. To serve special needs it is
possible to create a custom object dictionary (see section Custom Object Directory based on
Minimal Object Directory on page 27) A custom object dictionary is necessary if PDO objects with
different sizes to 1 byte are required. The default objects cannot be changed and additional
process data objects cannot be added to the default object dictionary. If only additional SDO
objects are needed, they can be added to the default objects created by the stack. For this case,
we recommend using the object range 0x4000 to 0x5FFF in order to avoid conflicts with process
data objects.
The following table shows the objects created by the default OD.

Index Subindex Object Comment

0x1000 00 Device Type
0x100A 00 Manufacturer Software Version
0x1018 00 Identity Object Fixed value, set to 4
0x1018 01 Vendor Id
0x1018 02 Product Code
0x1018 03 Revision Number
0x1018 04 Serial Number
0x1600 00 RxPDO Number of mapped process data objects, value
range 1...200 (not present if output data is zero)
Direction: master -> slave
0x1601 00 RxPDO Number of mapped process data objects, value
range 1...200 for data bytes 200 – 399 (not present
if output data <= 200 bytes)
0x160x .. .. ..
0x1A00 00 TxPDO Number of mapped process data objects, value
range 1...200 (not present if output data is zero)
Direction: slave -> master
0x1A01 00 TxPDO Number of mapped process data objects, value
range 1...200 for data bytes 200 – 399 (not present
if output data <= 200 bytes)
0x1A0x .. .. ..
0x1C00 00 Sync Manager Communication Types Number of elements ( max 8 sync managers are
defined in default OD )
0x1C00 01 Sync Manager 0 Value: 0x01
0x1C00 02 Sync Manager 1 Value: 0x02
.. .. .. ..
0x1C10 00 Sync Manager 0 PDO Assignment 0 because Receive Mailbox
0x1C11 00 Sync Manager 0 PDO Assignment 0 because Transmit Mailbox

EtherCAT Slave V5 | Protocol API

Index Subindex Object Comment

0x1C12 00 Sync Manager 0 PDO Assignment Number of assigned mapping objects (not present if
output data is zero)
Direction: master -> slave
0x1C12 01 Subindex 001 0x1600 (not present if output data = zero)
0x1C12 02 Subindex 002 0x1601 (only present if output data exceeds 200
byte)
.. .. .. ..
0x1C13 00 Sync Manager 0 PDO Assignment Number of assigned mapping objects (not present if
input data is zero)
Direction: master -> slave
0x1C13 01 Subindex 001 0x1A00 (not present if output data = zero)
0x1C13 02 Subindex 002 0x1A01 (only present if output data exceeds 200
byte)
.. .. .. ..
0x2000 00 Outputs Number of elements, value 0..200 (only present if
output data configured)
0x2000 01 1 Byte Out (0) Acyclically read value of this process data byte
.. .. .. ..
0x3000 00 Inputs Number of elements, value 0..200 (only present if
output data configured)
0x3000 01 1 Byte In (0) Acyclically read value of this process data byte
.. .. .. ..
Table 19: Default Object Dictionary

EtherCAT Slave V5 | Protocol API

DOC181005API01EN | Revision 1| English | 2019-04 | Released | Public © Hilscher, 2018-2019
Stack structure and stack functions 32/127
3.3.3.6 PDO Mapping for cyclic Communication
The process data objects (PDOs) provide the interface to the application objects. They are
assigned to the entries in the object dictionary. The process of assignment is denominated as PDO
mapping and is practically accomplished via a specific mapping structure in the object dictionary
(for EtherCAT: Sync Manager PDO Assignment (Objects 0x1C10 – 0x1C2F)).
This mapping structure is located at:
 0x1600-0x17FF (0x1600 for the first RxPDO)
 0x1A00-0x1BFF (0x1A00 for the first TxPDO)

Figure 8: PDO Mapping

Figure 8: PDO Mapping explains the relationship between object dictionary (left upper part), PDO
mapping structure (right upper part) and the resulting PDO containing the application objects to be
mapped (lower part).
One entry in the PDO mapping table requires 32 bit. It consists of:
 16 bit containing the index of the object dictionary entry containing the application object to
be mapped
 8 bit containing the subindex of the object dictionary entry containing the application object to
be mapped
 8 bit containing the length information.
The use of the mapping structure must be configured. In EtherCAT, this is done by the Sync
Manager PDO Assignment (Objects 0x1C10 – 0x1C2F)
Sometimes it is necessary to change the mapping after startup of the device (e.g. for modular
devices). For information on this topic, refer to section 5.5

EtherCAT Slave V5 | Protocol API

3.3.3.7 Complete Access

The SDO Complete Access mechanism allows reading out a whole object with all subobjects at
once. The ODV3 component translates those accesses, so they appear as single accesses to the
application side and no special handling is required. For additional information, see section 5.4. A
common use case is to handle the download of start-up parameters for dynamic process data. For
this case, please refer to 5.5

3.4 Behavior when receiving a Set Configuration command

The following rules apply for the behavior of the EtherCAT Slave protocol stack when receiving a
set configuration command:
 The configuration packets name is
 ECAT_SET_CONFIG_REQ for the request and
 ECAT_SET_CONFIG_CNF for the confirmation.
 The configuration data are checked for consistency and integrity.
 In case of failure, the stack rejects all data. The stack sends a negative confirmation packet.
 In case of success, the stack stores the configuration parameters internally (within the RAM).
 The stack will activate the parameterized data only after a channel initialization has been
performed.
 No automatic registration of the application at the stack happens.
 The confirmation packet ECAT_SET_CONFIG_CNF only transfers simple status information,
but it does not repeat the whole parameter set.
If you allowed the automatic start of the communication (this can be chosen within the Set
Configuration Request packet), the device will allow advancing the ESM state beyond Pre-
Operational state. Otherwise, setting of the BusOn bit via ApplicationCOS is required; see section
Bus On / Bus Off on page 14 of this document.
If a watchdog error occurs prior to setting the BusOn bit via ApplicationCOS (see section 3.2.4 at
pages 57 and 58 of reference [1],), this will prohibit advancing to ESM states beyond Pre-
Operational (in this context, also see section Watchdog on page 34 and the following sections of
this document).
You can recognize this situation by the unusual characteristic signal of the LEDs and an AL Control
Changed Indication with indicated EtherCAT states “Init” or “Pre-Operational” being sent to the
host. In this case, a channel reset is required. If you intend to use the DPM interface, also refer to
the related DPM manual (reference [1]).

EtherCAT Slave V5 | Protocol API

3.5 Watchdogs
Three watchdogs exist in the context of the EtherCAT Slave stack.
 The DPM Watchdog monitors the communication between the host application and the
stack via the dual-port memory.
 The SM Watchdog monitors the process data received from the EtherCAT network.
 The PDI Watchdog allows the master to monitor whether the EtherCAT Slave is still running.

3.5.1 DPM watchdog

The DPM Watchdog is relevant for LFW users only. The application and the EtherCAT Slave uses
two watchdog cells in the dual-port-memory for each communication channel, for details see
reference [1].
Use the basic configuration parameters of the Set Configuration service (page 53) to configure the
watchdog time. If the DPM Watchdog expires, the EtherCAT Slave will return to the Pre-
Operational state. The stack notifies the master with the AL Status Code:
#define ECAT_AL_STATUS_CODE_DPM_HOST_WATCHDOG_TRIGGERED 0x8002
The application has to use Channel Init service, because the EtherCAT Slave requires a Channel
Init to leaves this state.
For a list of available AL Status Codes, see section AL status codes on page 112.

3.5.1 SM Watchdog
The EtherCAT Slave uses the SyncManager Watchdog to monitor the receiving of process data.
This watchdog is only related to SyncManager 2 (master to slave). The default value is set to
100 ms, the value 0 deactivates the watchdog.
In case the EtherCAT Slave has input data only, the watchdog will not be started at all. If the
EtherCAT Slave receives no process data within the configured time, the AL Status Code
ECAT_AL_STATUS_CODE_SYNC_MANAGER_WATCHDOG is set and the slave falls back to the
SafeOP state. The AP task starts to trigger the SM Watchdog with the first reading of the buffer
and triggers again with each next reading. The master resets the watchdog with every PDO cycle.
The EtherCAT Master or a configuration tool can change the watchdog time by writing the related
registers (0x420, 0x400 = divider for both watchdogs.) in the EtherCAT Slave. LFW users (OEM
customization) can add an entry in the ESI file, see Reg0420 in reference [14].
The typical examples that lead to a watchdog timeout are unplugging the network cable or long
cycle times.

3.5.1 PDI Watchdog

The PDI watchdog has a default value of 100 ms. Zero deactivates this watchdog. The EtherCAT
Master or a configuration tool can configure the related registers by writing the related registers
(0x410, 0x400 = divider for both watchdogs, 0x110 = status) in the EtherCAT Slave.

EtherCAT Slave V5 | Protocol API

3.6 Ethernet MAC address

The stack requires the following MAC addresses for operation:
MAC address Used for Mapping to Required
Flash Device Label
- Unused MAC address 1–3 No
(communication CPU)
Second Interface MAC Ethernet interface (NDIS), if MAC address 4 Required, if the Ethernet interface
activated. (communication CPU) (NDIS) is activated.
- Unused MAC address 5–8 No
(communication CPU)
Table 20: Ethernet MAC addresses

Note: For the EtherCAT Slave, no MAC address is required. However, the EtherCAT Master
can set a MAC address via the network.

Note: Other protocols require up to 4 MAC addresses and use MAC address 1–4 of the Flash
Device Label. In case you design a device and intend to use the device with other
protocols, then 4 MAC addresses are required in the Flash Device Label.

The stack uses the MAC addresses from the following sources:
 Flash Device Label: The stack reads all MAC addresses from the Flash Device Label
located in the Flash memory (either integrated in netX 90 or attached to netX 4000) and uses
them. A Flash Device Label offers up to eight MAC addresses.
 Application: The application can change each MAC address using the Device Data Provider
Set service before configuring the firmware. MAC addresses must be set at the latest before
setting "Bus State on".

EtherCAT Slave V5 | Protocol API

4 Status information
The EtherCAT Slave provides status information in the dual-port memory. The status information
has a common block (protocol-independent) and an EtherCAT Slave specific block (extended
status).

4.1 Common status

For a description of the common status block, see reference [1].

4.2 Extended status

Currently, the EtherCAT Slave stack V5 does not support extended status.

EtherCAT Slave V5 | Protocol API

5 Requirements to the application

5.1 Sequence within the host application

Figure 9 shows the sequence within the host application program.

Figure 9: Sequence within the application

EtherCAT Slave V5 | Protocol API

5.2 General initialization sequence

Figure 10 shows the general initialization sequence. Note that all needed registration requests are
performed after the Channel Initialization and before the bus is switched on. The only exception is
the Register Application Request, which comes in the beginning.

Figure 10: Initialization sequence with placing of registrations and object dictionary creation

EtherCAT Slave V5 | Protocol API

5.3 Explicit Device Identification

This section describes the sequence if function Explicit Device Identification (optional) is used.

5.3.1 Initialization sequence

Figure 11 shows the initialization sequence diagram. Prerequisite for correct operation is a power
on or system start. The PHYs will be disabled after power on or system start.

Figure 11: Initialization sequence for Explicit Device Identification

Remarks: HIL_START_STOP_COMM_REQ can be replaced with BusOn via CommCOS

HIL_CHANNEL_INIT_REQ can be replaced with ChannelInit via CommCOS.
The application has to set the Device Identification Value before the BusOn is to be executed.
The Device Identification Value is handled according to the Explicit Device Identification via ESC
registers ALSTATUS / ALSTATUSCODE. For details on the functionality of those registers within
the stack, see reference [12].
A description of Figure 11 is on the following page.

EtherCAT Slave V5 | Protocol API

Handling of Device Identification Value (set locally in the slave)

This section is about the Device Identification Value, which is set from the master on the slave by
ID selector (e.g. an address from a rotary switch or a display) and read out by Requesting ID
mechanism. The address can be send to the slave by using the
HIL_SET_FW_PARAMETER_REQ_T packet:
 In order to get the address, the user application has to poll the address switch.
 Setting a value unequal to zero with the parameter usDeviceIdentificationValue
ECAT_SET_CONFIG_UID in the Set Configuration request activates the address handling
by the stack. The value zero deactivates the handling.
 After activation of the address handling, the address switch has to be polled and the current
value has to be provided to the stack to get the correct information before the slave starts to
communicate over the network. Therefore, the command HIL_SET_FW_PARAMETER_REQ
has to be sent before BUS_ON. The stack writes the address into register 134. This
mechanism ensures that the address is set after every cold start of the device.
 Additionally it is necessary to poll the switch frequently while the device is running and send
the Command HIL_SET_FW_PARAMETER_REQ to stack, when the address has changed.
(This is optional since the conformance test version 7000.2 V1.2.6) The stack will not give
the new address to the master until he requests it again.
 If the address handling is switched off, because the device does not support it, the address
should not be sent by HIL_SET_FW_PARAMETER_REQ, because this request also activates
the address handling. (Also, beware that there is no entry ´IdentificationReg134´ in the ESI
file if the address is not supported.)
 Setting the address value with the parameter usDeviceIdentificationValue (Set
Configuration request) only without polling is also possible and can make sense e.g. for
machine manufacturers, but it is no longer sufficient for fulfilling the conformance
requirements.
Please note the difference between the terms Station Alias (see section Set Station Alias service
on page 72) and Explicit Device ID:
 A Station Alias is a value (with a range from 0 to 65535) designating a station. It is set from
master side. (It can be used to send commands to a slave similar to the way the first station
address is handled.)
 An Explicit Device ID is a value which can be assigned for identification purposes, for
instance by means of a rotary switch. The Device Identification Value is an overall term and
means the address in the station alias register is also a Device Identification Value, because
it identifies the slave explicitly (see reference [12]).

EtherCAT Slave V5 | Protocol API

5.3.2 Set Firmware Parameter

Packet parameters

ulParameterID
ulParameterID contains the value PID_ECS_DEVICE_IDENTIFICATION (0x30009001).

ulParameterLength
ulParameterLength contains the value 4.

abParameter

Field Meaning
abParameter[0] Low Byte of Device Identification Value
abParameter[1] High Byte of Device Identification Value
abParameter[2] set to zero
abParameter[3] set to zero
Table 21: abParameter

Packet description

Structure HIL_SET_FW_PARAMETER_REQ_T Type: Request

Variable Type Value / Range Description

Structure HIL_PACKET_HEADER_T
ulDest uint32_t Destination address / handle
ulLen uint32_t 12 Packet Data Length in bytes
ulCmd uint32_t 0x2F86 HIL_SET_FW_PARAMETER_REQ

Structure HIL_SET_FW_PARAMETER_REQ_DATA_T
ulParameterID uint32_t 0x30009001 PID_ECS_DEVICE_IDENTIFICATION
ulParameterLength uint32_t 4 Length of parameter
abParameter uint8_t[4] See description of abParameter
Table 22: Request Packet HIL_SET_FW_PARAMETER_REQ_T

EtherCAT Slave V5 | Protocol API

Packet description

Structure HIL_SET_FW_PARAMETER_CNF_T Type: Confirmation

Variable Type Value / Range Description

Structure HIL_PACKET_HEADER_T
ulLen uint32_t 0 Packet Data Length in bytes
ulSta uint32_t 0 Status code of the packet
ulCmd uint32_t 0x2F87 HIL_SET_FW_PARAMETER_CNF
Table 23: Confirmation Packet HIL_SET_FW_PARAMETER_CNF_T

Example
The following example shows how to set a value as identification value:
void FillOutFwParamDeviceIdentPacket(uint32_t ulSrc, HIL_SET_FW_PARAMETER_REQ_T* ptPkt,
uint16_t usIdentValue)
{
ptPkt->tHead.ulCmd = HIL_SET_FW_PARAMETER_REQ;
ptPkt->tHead.ulExt = 0;
ptPkt->tHead.ulSta = 0;
ptPkt->tHead.ulSrcId = 0;
ptPkt->tHead.ulSrc = ulSrc;
ptPkt->tHead.ulLen = 12;
ptPkt->tHead.ulRout = 0;
ptPkt->tHead.ulId = 0;
ptPkt->tHead.ulDestId = 0;
ptPkt->tHead.ulDest = 0x20; /* addressed communication channel */
ptPkt->tData.ulParameterID = PID_ECS_DEVICE_IDENTIFICATION;
ptPkt->tData.ulParameterLength = 4;
ptPkt->tData.abParameter[0] = usIdentValue & 0xFF;
ptPkt->tData.abParameter[1] = usIdentValue >> 8;
ptPkt->tData.abParameter[2] = 0;
ptPkt->tData.abParameter[3] = 0;
}

EtherCAT Slave V5 | Protocol API

5.4 Complete Access for object data hold by application

This section describes the sequence of packets for the use case "object dictionary holds object
and subobjects descriptions, application holds data" for a Complete Access. For a description of
the use case, see reference [3].
This section is not for the use case dynamic PDO mapping; therefore see section Dynamic PDO
mapping on page 45.
The ODV3 component translates SDO up- and downloads with Complete Access from an
EtherCAT Master into single accesses to the application. The main difference of the Complete
Access compared to the standard access is the order when the object validation indications are
sent: with Complete Access, the validation indications are implicit.
If a Complete Access request from EtherCAT Master fails, the application has to restore the former
object values.
The following example shows how to handle the packets for a write object request correctly to
support both single access and complete access.

Figure 12: SDO download with Complete Access (successful)

EtherCAT Slave V5 | Protocol API

DOC181005API01EN | Revision 1| English | 2019-04 | Released | Public © Hilscher, 2018-2019
Requirements to the application 44/127
The application has to save new values using a copy of the values in order to be able to restore the
former value of the objects in case of an error. After the application has received the validation of
the last written subindex, the application has to take over the (new) values of successful answered
values only. In the case of an abort of the Complete Access request, the ODV3 component will
send all validation indications with fSuccessful set to False.
The example shows that the application answers the write indication on subindex 2 with the error
code HIL_E_CO_OBJDICT_UNSUPPORTED_ACCESS. This does not lead to an error for the
Complete Access download request itself. The value of the subindex just remains unchanged.
In case subindex zero of an object is read-only and the Master or configuration tool tries to write
more subindices as subindex zero of this object contains, causes for example a failure of the
Complete Access request.

EtherCAT Slave V5 | Protocol API

5.5 Dynamic PDO mapping

Dynamic PDO Mapping means that the process data configuration of the EtherCAT Slave device
can be changed via EtherCAT. The EtherCAT Master or a configuration tool can use
 PDO Assignment (Sync Manager objects e.g. 0x1C12/0x1C13), or
 PDO Configuration (e.g. 0x1600/0x1A00)
or both in order to change the PDO Mapping dynamically. The use case of dynamic PDO Mapping
for example is a modular device. Because of the required functionality for the complete device, the
user application will be more complex if the user application has to support both PDO Assignment
and PDO Configuration.
This section describes, how the application has to support the dynamic PDO Mapping functionality
and which sequences of packets occur.
The following figures show the handling for PDO Assignment. Please observe the sequence of
packets and make sure that the Set IO Size request reaches the slave stack before the evaluation
of process data length takes place. The sequence of writing the assignment objects 0x1C12 and
0x1C13 may differ from configuration tool to configuration tool because the sequence is not
defined. For details on the download order, see reference [13].
For the dynamic PDO Mapping, the user application has to response on multiple indications of the
ODV3_WRITE_OBJECT service from the EtherCAT Slave stack. As soon as the user application
receives "Writing subindex 0 with the value of the highest subindex", the end of the dynamic
mapping for each PDO is indicated. The user application will receive only one
ODV3_WRITE_OBJECT indication if no process data for a direction has been configured.

Note: The EtherCAT Slave stack sends the

ODV3_WRITE_OBJECT_VALIDATION_COMPLETE packet only if the user application
has registered to get this indication for the particular object or in case Complete Access
is used.

For more information about the dynamic PDO mapping, see chapter 10 in reference [12] and
reference [13].

EtherCAT Slave V5 | Protocol API

5.5.1 One application registered (application successful)

Figure 13: Dynamic PDO assignment: One application registered for write indications (successful)

EtherCAT Slave V5 | Protocol API

DOC181005API01EN | Revision 1| English | 2019-04 | Released | Public © Hilscher, 2018-2019
Requirements to the application 47/127
The user application has to create two lists. One list contains the current configuration and the
other list contains a copy (shadow list) of the original configuration in order to save the new
configuration. As soon as subindex 0 is set to zero, the user application has to copy the current
configuration into the shadow list. Only at the end of correct configuration sequence, the user
application can copy the shadow list back to the current configuration list. In case of error which
means that at least one "ODV3_WRITE_OBJECT_CNF ulSta is not 0" occurs, the current
configuration list stays valid and the process data length can be restored.
As soon as the application receives "ODV3_WRITE_OBJECT indication with subindex 0 has value
zero", the application has to send the first Set IO Size request of the sequence to the EtherCAT
Slave. The Set IO Size request contains the length of input and the length of output. The length for
the current written I/O direction gets value 0, the length for the other direction gets the current
value. After the application has received the Set IO Size confirmation, the application has to send
the ODV3_WRITE_OBJECT response for subindex 0. The application has to send this Set IO Size
request because of the possibility that no more write object requests follow in case the configured
data size is zero. In case, the device has additionally fix configured process data in the specific
direction (which is not downloaded by the configuration tool), this first Set IO Size request with
value zero should not be send or instead send with the length of the fix process data. The
ODV3_WRITE_OBJECT_VALIDATION_COMPLETE indications have no effect because there is
no other application registered.
The application receives values for the subindices within the write indication. If the object is
deactivated, (subindex 0 is zero, which means "writing allowed") the application has to save the
new value in the shadow list. If not, the application has to compare the current value with the new
value. If they match, this is an allowed request otherwise this access is not allowed (0x06010003 =
Subindex cannot be written, SI0 must be 0 for write access). This behavior allows a master to
check the configuration.
The end of object writing is indicated by "ODV3_WRITE_OBJECT indication sets subindex 0 to a
value unequal to zero". The application has to calculate the process data length and send the Set
IO Size request to the EtherCAT slave. This Set IO Size request has to contain the length of input
and the length of output and one length has a new value. As soon as the application has received
the Set IO Size confirmation, the application has to send the ODV3_WRITE_OBJECT response for
subindex 0.
Only this sequence ensures that the EtherCAT Slave stack uses the new data size for the next
process data evaluation, which takes place before changing the operating mode to Safe-
Operational.

EtherCAT Slave V5 | Protocol API

Figure 14: Dynamic PDO assignment: One application registered for write indications (not successful)

Until the first ODV3_WRITE_OBJECT confirmation for subindex 0, the sequence is the same as
described in section One application registered (application successful). If one of the following
write object indications fail indicated with "ulSta unequal to zero" from the application, the
application has to restore the former I/O size or has to set a default size. An example for this case
can be that a written value is out of range.

5.5.3 Multiple applications registered (one application unsuccessful)

In case of multiple applications are registered, the application has to check the
ODV3_WRITE_OBJECT_VALIDATION_COMPLETE indications. If at least one other registered
application answers a write object indication on the same object with ulSta unequal to zero, all
applications will get the ODV3_WRITE_OBJECT_VALIDATION_COMPLETE with the respected
error code. In this case, the application has to restore the former I/O size or has to set a default
size as Figure 14 on page 48 shows.
For a sequence diagram, see reference [9].

EtherCAT Slave V5 | Protocol API

Figure 15 Dynamic PDO assignment: One application registered for write indications, successful (Complete Access)

The ODV3 component splits a single Complete Access from master into several single requests.
To get the subindices in the correct order for PDO mapping, the application has to to set the flag
ODV3_ACCESS_FLAGS_SUBINDEX_0_WRITE_0_FIRST during object creation. The application
also has to set the flag ODV3_INDICATION_FLAGS_ON_WRITE_INVALIDATED, see reference
[5].
The application has to copy the current configuration list with all its values to a second list (shadow
list). In the shadow list, the application saves the new configured data. At the end of a correct
configuration sequence, the application copies the valid subobjects of the new configuration back
to the current configuration list. In case, the Complete Access fails (ODV3_WRITE_OBJECT_CNF
ulSta is not zero), the configuration of the current list is still valid and process data length can be
restored or is unchanged.
The sequence starts with setting subindex 0 to zero. In comparison to single access, the
application does not need to send a Set IO Size request, because Set IO Size follows after the
EtherCAT Slave V5 | Protocol API
DOC181005API01EN | Revision 1| English | 2019-04 | Released | Public © Hilscher, 2018-2019
Requirements to the application 50/127
validation indication. The application receives values for the subindexes with the following write
indications. In case the object is deactivated (subindex 0 = zero and writing is allowed), the
application has to save the new values to the shadow list. If not, the application has to compare the
current value with the new value. If they match, this is an allowed request otherwise the access is
not allowed (0x06010003 = Subindex cannot be written, SI0 must be 0 for write access). The
indication for subindex zero unequal to zero is checked to match highest written subindex.
All validation indications, which are following show whether the written value is valid or wheather
an error has occurred. The validation for subindex 0 indicates the end of the configuration for the
application. In case the validation is successful, the application has to copy the valid entries to the
current configuration list. The application has to calculate the process data length and send the Set
IO Size request to the EtherCAT slave, which contains the length of input and the length of output.
One length has a new value.
Additional considerations:
The main difference of the Complete Access compared to the standard access is that all write
object validation packets are send after the last write object response that has reached the ODV3
component. The amount of validation packets coming straight after the last write object response
can be very high. As a result, the application has to take the following two points into account:
1. For LFW users: The application has to empty the mailbox frequently because otherwise the
buffers in the packet queue for the mailbox runs out of packets. Depending on the amount of
validation packets, it may be necessary for the application to poll the mailbox with a higher
frequency, while the startup parameters are downloaded. Afterwards the application can
decrease the frequency for a standard acyclic packet handling.
2. The master tries to change the EtherCAT state right after the download of the last startup
parameter has been finished. This means, the confirmation reaches the master after the last
write object. The state change request leads to a process data validation within the slave. To
avoid that the process data evaluation is done before the new data size is set, the validation
responses from application side can be neglected (they are not evaluated by the EtherCAT
Slave stack). If problems occur, it is also possible to define a timeout for the state changes in
the ESI file.

5.6 Remanent data handling

Remanent data contains device parameters e.g. Station Alias Address (Second Station Address).
The protocol stack automatically updates the remanent data whenever a non-volatile parameter
changes.
When you design your application, you have to determine whether
 the protocol stack stores the remanent data or
 the application stores the remanent data.
By default, the protocol stack stores remanent data.
In case “application stores the remanent data”, the firmware file (*.nxi) has to be configured using
the Tag List Editor software. In the tag list “Remanent Data Responsibility” the tag “Remanent Data
stored by Host” has to be set to enabled. In case “stack stores the remanent data”, no change in
the tag list of the firmware is required.

EtherCAT Slave V5 | Protocol API

5.6.1 Protocol stack stores remanent data

Requirements
The protocol stack requires access to non-volatile memory.

Firmware configuration
In the tag list “Remanent Data Responsibility” the tag “Remanent Data stored by Host” has to be
set to disabled in the firmware file (*.nxi). This is the default setting in a firmware.

5.6.2 Application stores remanent data

In case the host application stores remanent data, the protocol stack no longer accesses the Flash
memory, but provides the complete remanent data block towards the host application per
indication. The host application has to store the provided data with each indication and has to set
this data back to the stack in the (re)configuration process.

Requirement to the application

The application has to use the Channel Component Information service
(GENAP_GET_COMPONENT_IDS_REQ) to get the information about the required size for remanent
data of each protocol stack component. The application has to use the Set Remanent Data service
(HIL_SET_REMANENT_DATA_REQ) and to support the Store Remanent Data service
(HIL_STORE_REMAMENT_DATA_IND).

Firmware configuration
In the tag list “Remanent Data Responsibility” the tag “Remanent Data stored by Host” has to be
set to enabled in the firmware file (*.nxi).

Configuration
The application has to use the Set Remanent Data service (HIL_SET_REMANENT_DATA_REQ) to
provide the remanent data to each protocol stack component any time the host application starts
up for the first time (e.g. when coming from power up) and before the application sends the Set
Configuration request (page 54). For a state diagram, see section General initialization sequence
on page 38.

During runtime
The stack component indicates to the application the Store Remanent Data service
(HIL_STORE_REMAMENT_DATA_IND) each time remanent data has been changed. Th stack
component provides the remanent data as a block towards the application. The application has to
store the remanent data with each indication.

Description of the services for handling remanent data

For a detailed description of the Channel Component Information service, the Set Remanent Data
service, and the Store Remanent Data service, see reference [2].

EtherCAT Slave V5 | Protocol API

6 Application interface
The following chapters define the application interface of the EtherCAT Slave stack. The
application task is named AP task in the following sections and chapters.
The AP task’s process queue is keeping track of all its incoming packets. It provides the
communication channel for the underlying EtherCAT Slave Stack. Once, the EtherCAT Slave
Stack communication is established, events received by the stack are mapped to packets that are
sent to the AP task’s process queue. On the one hand, every packet has to be evaluated in the AP
task’s context and corresponding actions be executed. On the other hand, initiator services that are
be requested by the AP task itself are sent via predefined queue macros to the underlying
EtherCAT Stack queues via packets as well.
All tasks belonging to the EtherCAT stack are grouped together according to their functionality. The
following overview shows the different tasks that are available within the EtherCAT stack.

6.1 General
Overview over the General Packets of the EtherCAT Slave Stack
Service Command code Page
Register Application service 0x2F10, 0x2F11 52
Unregister Application service 0x2F12, 0x2F13 53
Link Status Changed service 0x2F8A, 0x2F8B 53
Table 24: Overview over the general packets of the EtherCAT Slave stack

6.1.1 Register Application service

This service is described in DPM Interface Manual for netX based Products, see reference [1]. The
stack will generate an initial AL Status Changed Indication when this request is received.
When an application has been registered for indications, the EtherCAT Slave stack may produce
the following indications:
 AL Status Changed Indication
 Link Status Changed Indication
The stack will only send other indications of the EtherCAT Slave Stack if an application has
registered itself for that indication. For example, if an application wants to receive an AL Control
Changed Indication from the stack, it has to be registered with the Register for AL Control
Changed Indications service.

Note: It is required that the application returns all indications it receives as valid responses to
the stack. Do not change any field in the packet header except ulSta, ulCmd and
ulLen. Otherwise, the stack will not be able to assign the response successfully.

The service is described in DPM Interface Manual for netX based Products (reference [1]).

EtherCAT Slave V5 | Protocol API

6.1.2 Unregister Application service

Using this service the application can unregister with the EtherCAT Slave stack: the stack will not
generate indications any more. The service is described in DPM Interface Manual for netX based
Products, see reference [1].

6.1.3 Link Status Changed service

This service indicates a link status change for a specific port e.g. cable plugged/unplugged in an
Ethernet Port. The stack polls the port status cyclically to generate the messages.
For a description of this packet, see documentation reference [2].

Note: It is necessary to register the application by HIL_REGISTER_APP_REQ (see reference

[1] for more information) in order to receive a Link Status Changed Indication.

6.2 Configuration
For a complete configuration of the stack, the application can use the following packets:

Service Command code Page

Set Configuration service 0x2CCE, 0x2CCF 53
Set Trigger Type service 0x2F90, 0x2F91 69
Get Trigger Type service 0x2F92, 0x2F93 69
Set IO Size service 0x2CC0, 0x2CC1 70
Set Station Alias service 0x2CC6, 0x2CC7 72
Get Station Alias service 0x2CC8, 0x2CC9 74
Table 25: Configuration packets overview

6.2.1 Set Configuration service

The application has to use the Set Configuration service to configure the stack on startup.

Attention: As described in Dual Port Memory manual (reference [1]) it is required to send a
Channel Initialization request to the EtherCAT Slave stack after performing the Set
Configuration Request. The stack will not use the configuration until it receives the
Channel Initialization Request.

For detailed information on the packet sequence, see section Configuration on page 10.
If the stack does not receive this message, the slave will not proceed further than to Pre-
Operational state. If the master requests Safe-Operational, the slave will notify the master with
the following code in the AL status code:
#define ECAT_AL_STATUS_CODE_IO_DATA_SIZE_NOT_CONFIGURED 0x8001
For a list of available AL Status Codes, please refer to chapter AL status codes.

Static PDO mapping vs. dynamic PDO mapping

This configuration service is fully appropriate only for static PDO mapping. In case of dynamic PDO
mapping, the application must additionally send a Set IO Size request each time the input or output
length has changed.

EtherCAT Slave V5 | Protocol API

6.2.1.1 Set Configuration request

The application has to send this request to the protocol stack in order to configure the stack with
configuration parameters. The following applies:
 Configuration parameters will be stored internally in RAM.
 In case of any error, no data will be stored at all.
A Channel Initialization request is required to activate the configuration parameters.

Packet structure reference

/* codes for parameters of "set configuration" packet */
#define ECAT_SET_CONFIG_COE 0x00000001
#define ECAT_SET_CONFIG_EOE 0x00000002
#define ECAT_SET_CONFIG_FOE 0x00000004
#define ECAT_SET_CONFIG_SOE 0x00000008
#define ECAT_SET_CONFIG_SYNCMODES 0x00000010
#define ECAT_SET_CONFIG_SYNCPDI 0x00000020
#define ECAT_SET_CONFIG_UID 0x00000040
#define ECAT_SET_CONFIG_AOE 0x00000080
#define ECAT_SET_CONFIG_BOOTMBX 0x00000100
#define ECAT_SET_CONFIG_DEVICEINFO 0x00000200
#define ECAT_SET_CONFIG_SMLENGTH 0x00000400

#define ECAT_SET_CONFIG_SYSTEMFLAGS_AUTOSTART 0x00000000

#define ECAT_SET_CONFIG_SYSTEMFLAGS_APP_CONTROLLED 0x00000001

#define ECAT_SET_CONFIG_COEDETAILS_ENABLE_SDO 0x01

#define ECAT_SET_CONFIG_COEDETAILS_ENABLE_SDOINFO 0x02
#define ECAT_SET_CONFIG_COEDETAILS_ENABLE_PDOASSIGN 0x04
#define ECAT_SET_CONFIG_COEDETAILS_ENABLE_PDOCONFIGURATION 0x08
#define ECAT_SET_CONFIG_COEDETAILS_ENABLE_UPLOAD 0x10
#define ECAT_SET_CONFIG_COEDETAILS_ENABLE_SDOCOMPLETEACCESS 0x20

#define ECAT_SET_CONFIG_COEFLAGS_USE_CUSTOM_OD 0x01

#define ECAT_SET_CONFIG_SYNCPDI_SYNC0_OUTPUT_TYPE_MASK 0x01

#define ECAT_SET_CONFIG_SYNCPDI_SYNC0_POLARITY_MASK 0x02
#define ECAT_SET_CONFIG_SYNCPDI_SYNC0_OUTPUT_ENABLE_MASK 0x04
#define ECAT_SET_CONFIG_SYNCPDI_SYNC0_IRQ_ENABLE_MASK 0x08
#define ECAT_SET_CONFIG_SYNCPDI_SYNC1_OUTPUT_TYPE_MASK 0x10
#define ECAT_SET_CONFIG_SYNCPDI_SYNC1_POLARITY_MASK 0x20
#define ECAT_SET_CONFIG_SYNCPDI_SYNC1_OUTPUT_ENABLE_MASK 0x40
#define ECAT_SET_CONFIG_SYNCPDI_SYNC1_IRQ_ENABLE_MASK 0x80

/* basic configuration */
typedef struct ECAT_SET_CONFIG_REQ_DATA_BASIC_Ttag
{
uint32_t ulSystemFlags;
uint32_t ulWatchdogTime;
uint32_t ulVendorId;
uint32_t ulProductCode;
uint32_t ulRevisionNumber;
uint32_t ulSerialNumber;
uint32_t ulProcessDataOutputSize;
uint32_t ulProcessDataInputSize;
uint32_t ulComponentInitialization;
uint32_t ulExtensionNumber;
} ECAT_SET_CONFIG_REQ_DATA_BASIC_T;

/* component configuration */
typedef __struct ECAT_SET_CONFIG_COE_Ttag
{
uint8_t bCoeFlags;
uint8_t bCoeDetails;
uint32_t ulOdIndicationTimeout;
uint32_t ulDeviceType;
uint16_t usReserved;

EtherCAT Slave V5 | Protocol API

DOC181005API01EN | Revision 1| English | 2019-04 | Released | Public © Hilscher, 2018-2019
Application interface 55/127
} ECAT_SET_CONFIG_COE_T;

typedef struct ECAT_SET_CONFIG_EOE_Ttag

{
uint32_t ulReserved;
} ECAT_SET_CONFIG_EOE_T;

typedef struct ECAT_SET_CONFIG_FOE_Ttag

{
uint32_t ulTimeout;
} ECAT_SET_CONFIG_FOE_T;

typedef struct ECAT_SET_CONFIG_SOE_Ttag

{
uint32_t ulIdnIndicationTimeout;
} ECAT_SET_CONFIG_SOE_T;

typedef struct ECAT_SET_CONFIG_SYNCMODES_Ttag

{
uint8_t bPDInHskMode;
uint8_t bPDInSource;
uint16_t usPDInErrorTh;
uint8_t bPDOutHskMode;
uint8_t bPDOutSource;
uint16_t usPDOutErrorTh;
uint8_t bSyncHskMode;
uint8_t bSyncSource;
uint16_t usSyncErrorTh;
} ECAT_SET_CONFIG_SYNCMODES_T;

typedef struct ECAT_SET_CONFIG_SYNCPDI_Ttag

{
uint8_t bSyncPdiConfig;
uint16_t usSyncImpulseLength;
uint8_t bReserved;
} ECAT_SET_CONFIG_SYNCPDI_T;

typedef struct ECAT_SET_CONFIG_UID_Ttag

{
uint16_t usStationAlias;
uint16_t usDeviceIdentificationValue;
} ECAT_SET_CONFIG_UID_T;

typedef struct ECAT_SET_CONFIG_BOOTMBX_Ttag

{
uint16_t usBootstrapMbxSize;
} ECAT_SET_CONFIG_BOOTMBX_T;

typedef struct ECAT_SET_CONFIG_DEVICEINFO_Ttag

{
uint8_t bGroupIdxLength;
uint8_t szGroupIdx[127]; /* Matches ESI DeviceType:Group Type */
uint8_t bImageIdxLength; /* reserved, set to 0 */
uint8_t szImageIdx[255]; /* reserved */
uint8_t bOrderIdxLength;
uint8_t szOrderIdx[127]; /* Matches ESI DeviceType:Type */
uint8_t bNameIdxLength;
uint8_t szNameIdx[127]; /* Matches ESI DeviceType:Name */
} ECAT_SET_CONFIG_DEVICEINFO_T;

typedef struct ECAT_SET_CONFIG_SMLENGTH_Ttag

{
uint16_t usMailboxSize;
uint16_t usSM2StartAddress;
uint16_t usSM3StartAddress; /* should match (usProcDataSm2Start + 3 *
((usProcDataSm2Length + 3) & (~3)) <= usProcDataSm3Start)*/
} ECAT_SET_CONFIG_SMLENGTH_T;

typedef struct ECAT_SET_CONFIG_REQ_DATA_COMPONENTS_Ttag

{

EtherCAT Slave V5 | Protocol API

DOC181005API01EN | Revision 1| English | 2019-04 | Released | Public © Hilscher, 2018-2019
Application interface 56/127
ECAT_SET_CONFIG_COE_T tCoECfg;
ECAT_SET_CONFIG_EOE_T tEoECfg;
ECAT_SET_CONFIG_FOE_T tFoECfg;
ECAT_SET_CONFIG_SOE_T tSoECfg;
ECAT_SET_CONFIG_SYNCMODES_T tSyncModesCfg;
ECAT_SET_CONFIG_SYNCPDI_T tSyncPdiCfg;
ECAT_SET_CONFIG_UID_T tUidCfg;
ECAT_SET_CONFIG_BOOTMBX_T tBootMxbCfg;
ECAT_SET_CONFIG_DEVICEINFO_T tDeviceInfoCfg;
ECAT_SET_CONFIG_SMLENGTH_T tSmLengthCfg;
} ECAT_SET_CONFIG_REQ_DATA_COMPONENTS_T;

typedef struct ECAT_SET_CONFIG_REQ_DATA_Ttag

{
ECAT_SET_CONFIG_REQ_DATA_BASIC_T tBasicCfg;
ECAT_SET_CONFIG_REQ_DATA_COMPONENTS_T tComponentsCfg;
} ECAT_SET_CONFIG_REQ_DATA_T;

/* request packet */
typedef struct ECAT_SET_CONFIG_REQ_Ttag
{
HIL_PACKET_HEADER_T tHead;
ECAT_SET_CONFIG_REQ_DATA_T tData;
} ECAT_SET_CONFIG_REQ_T;

Packet description

Variable Type Value / Range Description

ulDest uint32_t Destination address / handle
ulLen uint32_t Packet Data Length in bytes
ulCmd uint32_t 0x2CCE ECAT_SET_CONFIG_REQ
Data - ECAT_SET_CONFIG_REQ_DATA_T
tBasicCfg structure ECAT_SET_CONFIG_REQ_DATA_BASIC_T basic configuration data
tComponentsCfg structure ECAT_SET_CONFIG_REQ_DATA_COMPONENTS_T component configuration data
Table 26: ECAT_SET_CONFIG_REQ_T – Set Configuration request packet

The following pages describe the structures ECAT_SET_CONFIG_REQ_DATA_BASIC_T and

ECAT_SET_CONFIG_REQ_DATA_COMPONENTS_T.

EtherCAT Slave V5 | Protocol API

Basic configuration data

The basic configuration data structure ECAT_SET_CONFIG_REQ_DATA_BASIC_T contains the
following parameters:
Variable Type Value / Range Description
ulSystemFlags uint32_t 0, 1 Behavior at system start:
0 = automatic (default)
1 = application controlled
For a description, see below this table.
ulWatchdogTime uint32_t 0, 20 – 65535 DPM Watchdog time in ms
0 = off, default: 1000
Time for the application program for retriggering the EtherCAT
slave watchdog. A value of 0 indicates that the watchdog
timer is switched off. The watchdog will only be active after
first triggering.
ulVendorId uint32_t 0...232-1 Vendor ID
Vendor Identification number of the manufacturer of an
EtherCAT device.
Default: 0xE0000044 for cifX/comX/netIC denoting device has
been manufactured by Hilscher
Vendor id, product code, and revision number for Hilscher,
see Table 28 (page 58).
ulProductCode uint32_t 0...232-1 Product code
Product code of the device. Default: 0x00020004
ulRevisionNumber uint32_t 0...232-1 Revision number
Revision number of the device as specified by the
manufacturer.
ulSerialNumber uint32_t 0...232-1 Serial number
Serial number of the device. Default: 0
Value 0 forces the stack to read the serial number from the
security memory or Flash device label in the device. If security
memory or flash device label is present, but cannot be
accessed correctly, value 0 is used.
ulProcessDataOutput uint32_t 0...1024 Process data output size (in bytes)
Size Default: 4 Byte
ulProcessDataInput uint32_t 0...1024 Process data input size (in bytes)
Size Default: 4 Byte
ulComponent uint32_t Bit mask Component initialization bit mask, enables or disables certain
Initialization components of the EtherCAT Slave stack. For a list, see
below.
ulExtensionNumber uint32_t 0...232-1 Currently not used
Number which identifies an additional configuration structure
default: 0.
Table 27: Basic configuration data

Continued on next page.

EtherCAT Slave V5 | Protocol API

DOC181005API01EN | Revision 1| English | 2019-04 | Released | Public © Hilscher, 2018-2019
Application interface 58/127
The EtherCAT Slave stack supports simultaneous setting of input and output data length to zero.
The use case for is for example modular devices: Set both input and output length to zero and use
the Set IO Size service (page 70) to set the calculated input and output data length.

Parameter ulSystemFlags
#define ECAT_SET_CONFIG_SYSTEMFLAGS_AUTOSTART 0x00000000
#define ECAT_SET_CONFIG_SYSTEMFLAGS_APP_CONTROLLED 0x00000001
This parameter is bit zero of the system flags.
The start of the device can be performed either application controlled or automatically:
Automatic (0): Network connections are opened automatically without taking care of the state of
the host application. Communication with an EtherCAT master after starting the EtherCAT Slave is
allowed without BUS_ON flag, but the communication will be stopped if the BUS_ON flag changes
state to 0.

Important: If the master sets the slave to Operational state when Automatic has been choosen,
probably the application will not be initialized completely.

Application controlled (1): The channel firmware is forced to wait for the host application to wait
for the BUS_ON flag in the communication change of state register. For further information, see
section reference [1]. Communication with EtherCAT Master is allowed only with the BUS_ON flag.

Important: If the initialization of the slave application is to be controlled by the slave application
itself, Application controlled must be chosen. The master is only able to change the
state of the slave in case of the slave application setting the BUS_ON flag.

Important: If Application controlled (1) is chosen and a watchdog error occurs, the stack will not be
able to reach the „Operational“ or the „Safe-Operational“ state. In this case, a channel
reset is required.

For more information concerning the bus startup parameter, see section Controlled or Automatic
Start of the netX DPM Interface Manual (reference [1]).

Parameter ulVendorId, ulProductCode and ulRevisionNumber

You can take the values for the parameters ulVendorId, ulProductCode and
ulRevisionNumber from the XML file, which is bundled with the particular firmware.
The following default value sets for the identification data have been defined:
Firmware Vendor ID Product code Current revision number
netX90 0xE0000044 0x0000003D 0x00000005
netX4000 0xE0000044 0x0000003E 0x00000005
Table 28: Values for the parameters ulVendorId, ulProductCode and ulRevisionNumber

EtherCAT Slave V5 | Protocol API

DOC181005API01EN | Revision 1| English | 2019-04 | Released | Public © Hilscher, 2018-2019
Application interface 59/127
Parameter ulComponentInitialization
You can use the value ulComponentInitialization to enable or disable certain component
parameter evaluation of the EtherCAT Slave stack. If a bit is set, the EtherCAT slave stack will
evaluate the data structure related to that bit.
The following flags are defined for ulComponentInitialization
#define ECAT_SET_CONFIG_COE 0x00000001
#define ECAT_SET_CONFIG_EOE 0x00000002
#define ECAT_SET_CONFIG_FOE 0x00000004
#define ECAT_SET_CONFIG_SOE 0x00000008
#define ECAT_SET_CONFIG_SYNCMODES 0x00000010
#define ECAT_SET_CONFIG_SYNCPDI 0x00000020
#define ECAT_SET_CONFIG_UID 0x00000040
#define ECAT_SET_CONFIG_AOE 0x00000080
#define ECAT_SET_CONFIG_BOOTMBX 0x00000100
#define ECAT_SET_CONFIG_DEVICEINFO 0x00000200
#define ECAT_SET_CONFIG_SMLENGTH 0x00000400
The flags have the following meaning:
Bit Description
0 CoE parameter evaluation
0 - disabled
1 - enabled
1 EoE parameter evaluation
0 - disabled
1 - enabled
2 FoE parameter evaluation (component not yet supported)
0 - disabled
1 – enabled
3 SoE parameter evaluation (component not yet supported)
0 - disabled
1 - enabled
4 Synchronization modes parameter evaluation
0 - disabled
1 - enabled
5 Sync PDI parameter evaluation
0 - disabled
1 - enabled
6 Unique identification parameter evaluation
0 - disabled
1 - enabled
7 AoE parameter evaluation (component not yet supported)
0 - disabled
1 - enabled
8 Bootstrap Mailbox parameter evaluation
0 - disabled
1 - enabled
9 Device Info parameter evaluation
0 - disabled
1 - enabled
10 Sm Length parameter evaluation
0 - disabled
1 - enabled
11-31 Reserved
Table 29: Parameter ulComponentInitialization

EtherCAT Slave V5 | Protocol API

DOC181005API01EN | Revision 1| English | 2019-04 | Released | Public © Hilscher, 2018-2019
Application interface 60/127
Components Configuration Data
The component configuration data structure ECAT_SET_CONFIG_REQ_DATA_COMPONENTS_T
contains the following parameters:
Parameter Type Meaning
tCoECfg ECAT_SET_CONFIG_COE_T CoE configuration parameters
tEoECfg ECAT_SET_CONFIG_EOE_T EoE configuration parameters
tFoECfg ECAT_SET_CONFIG_FOE_T FoE configuration parameters
tSoECfg ECAT_SET_CONFIG_SOE_T SoE configuration parameters
tSyncModesCfg ECAT_SET_CONFIG_SYNCMODES_T Sync modes configuration parameters
tSyncPdiCfg ECAT_SET_CONFIG_SYNCPDI_T Sync PDI configuration parameters
tUidCfg ECAT_SET_CONFIG_UID_T Unique identification configuration parameters
tBootMbxCfg ECAT_SET_CONFIG_BOOTMBX_T Boot mailbox configuration parameter
tDeviceInfoCfg ECAT_SET_CONFIG_DEVICEINFO_T Device info configuration parameter
tSmLength ECAT_ESM_CONFIG_SMLENGTH_T SyncManager configuration parameter
Table 30: Component configuration parameters

CoE configuration parameter

The CoE configuration data structure ECAT_SET_CONFIG_COE_T contains the following
parameters:
Parameter Type Meaning Range of values
bCoeFlags uint8_t Flags for CoE configuration see below
bCoEDetails uint8_t CoE details (refer to value “CoE details“ of category see below
“General” in the SII)
ulOdIndicationTimeout uint32_t Timeout for object dictionary indications in has to be unequal to 0
milliseconds (default:1000)
ulDeviceType uint32_t Device type in object 0x1000 of object dictionary as in ETG specification
usReserved uint16_t reserved
Table 31: CoE configuration parameters

Use the following flags for CoE configuration:

Bit Description
0 Object dictionary creation mode
0 - Object dictionary shall be created with default objects
1 - Object dictionary shall not be created with default objects, only minimal object dictionary (contains
objects 0x1000 and 0x1018) is created, the user has to provide objects (flag
ECAT_SET_CONFIG_COEFLAGS_USE_CUSTOM_OD can be used to enable this mode)
Table 32: Flags for CoE configuration

Use the following flags CoE details:

Bit Description
0 Enable SDO
1 Enable SDO Information
2 Enable PDO Assign
3 Enable PDO Configuration
4 Enable PDO upload at startup
5 Enable SDO complete access
Table 33: Flags for CoE details

EtherCAT Slave V5 | Protocol API

DOC181005API01EN | Revision 1| English | 2019-04 | Released | Public © Hilscher, 2018-2019
Application interface 61/127
The flags for CoE details refer to the value “CoE details“ of the category “General” in the SII. They
will be directly copied from the configuration request packet to the category “General” in the SII. If
the user does not configure the CoE component of the stack (ECAT_SET_CONFIG_COE not used), the
following default values apply:
 Enable SDO
 Enable SDO Information
 Enable PDO upload at startup
 Enable SDO complete access
The other flags are not set.

EoE configuration parameter

No parameter.
Parameter Type Meaning Range of values
ulReserved uint32_t No parameter set to 0
Table 34: EoE configuration parameters

FoE configuration parameter

The FoE component is activated by default for most targets to allow firmware updates even if it is
not set here. The FoE configuration data structure ECAT_SET_CONFIG_FOE_T contains the
following parameter:
Parameter Type Meaning Range of values
ulTimeout UINT32 FoE timeout in milliseconds has to be unequal to 0
(default:1000)
Table 35: FoE configuration parameters

For all targets supporting a file system, FoE is activated by default.

Targets with no file system, e.g. CIFX targets, FoE is deactivated by default.
Note that there is currently no packet interface available for FoE.
SoE configuration parameter
SoE is currently not supported by the stack.
Parameter Type Meaning Range of values
ulIdnIndicationTimeout uint32_t Currently not supported set to 0
Table 36: SoE configuration parameters

EtherCAT Slave V5 | Protocol API

Sync Modes configuration parameter

The synchronization modes configuration data structure ECAT_SET_CONFIG_SYNCMODES_T
contains the following parameters:
Parameter Type Meaning Range of values

Synchronization Parameter: Dual-port Memory

bPDInHskMode uint8_t Input process data handshake mode 4, Buffered Host
Controlled mode (default,
not changeable)
bPDInSource uint8_t Input process data trigger source (which triggers Free run, SM2/3, Sync0/1
the input handshake cell) (see below for flags )
usPDInErrorTh uint16_t Threshold for input process data handshake 0 … 0xFFFF
handling errors
Note: this is the error threshold of the EtherCAT
sync manager for the (master) outputs (usually
SM2)!
bPDOutHskMode uint8_t Output process data handshake mode 4, Buffered Host
Controlled mode (default,
not changeable)
bPDOutSource uint8_t Output process data trigger source (which triggers Free run, SM2/3, Sync0/1
the output handshake cell) (see below for flags )
usPDOutErrorTh uint16_t Threshold for output process data handshake 0 … 0xFFFF
handling errors
Note: this is the error threshold of the EtherCAT
sync manager for the (master) inputs (usually SM3)!
bSyncHskMode uint8_t Synchronization handshake mode
bSyncSource uint8_t Synchronization source for the special sync Free run, SM2/3, Sync0/1
handshake cell (may be used for an additional sync (see below for flags)
decoupled from process data)
usSyncErrorTh uint16_t Threshold for synchronization handshake 0 … 0xFFFF
handling errors
Table 37: Synchronization Modes configuration parameters

The following flags are defined for sync sources:

Value Description
0x00 ECAT_DPM_SYNC_SOURCE_FREERUN – no synchronization in use
0x22 ECAT_DPM_SYNC_SOURCE_SM2 – SM2 used as synchronization trigger
0x23 ECAT_DPM_SYNC_SOURCE_SM3 – SM3 used as synchronization trigger
0x02 ECAT_DPM_SYNC_SOURCE_SYNC0 – SYNC0 signal used as synchronization trigger
0x03 ECAT_DPM_SYNC_SOURCE_SYNC1 – SYNC1 signal used as synchronization trigger
Table 38: Flags for EtherCAT synchronization sources

The application can be synchronized with the EtherCAT bus cycle. For information on the
handshake, see reference [1].

Note: The EtherCAT Slave supports buffered host controlled mode only.

When starting with process data exchange, the application has to do a handshake with the netX
once to receive the first process data. In order to do the first handshake toggling, the application
has to call the xChannelIORead function once.
A common use case is to synchronize the process data exchange on SyncManager2 event with
activated handshake mode to exchange data. After the slave has received a frame, the slave
triggers an interrupt and copies the output process data (master to salve) received from the bus
EtherCAT Slave V5 | Protocol API
DOC181005API01EN | Revision 1| English | 2019-04 | Released | Public © Hilscher, 2018-2019
Application interface 63/127
into the triple buffer in the slave controller. As soon as data is copied, the output valid mark is set
and the AP task copies data into the local memory. The input handshake bit in the dual-port
memory is toggled and the local cycle of the application starts. After the slave has copied the
received data, the slave gives back the input handshake bit back to the netX. Now the slave copies
its input data (slave to master) to the triple buffer and gives the output handshake bit to the netX
that copies the data to the bus and gives the handshake back again. A synchronization for
exchange of input process data (slave to master) is not necessary because the application can do
this right after output data is received and thus as fast as possible.
The values for the discussed use case SM2 synchronous are:
Parameter Description Setting
bPDInSource process data trigger source for inputs (master - ECAT_DPM_SYNC_SOURCE_SM2
> slave)
bPDInHskMode handshake bits which show that data is copied HIL_IO_MODE_BUFF_HST_CTRL
to DPM
bPDOutSource process data trigger source for outputs (slave - ECAT_DPM_SYNC_SOURCE_FREERUN
> master)
bPDOutHskMode handshake bits which show that Data is HIL_IO_MODE_BUFF_HST_CTRL
copied to DPM
bSyncSource for special sync handshake cell, not needed ECAT_DPM_SYNC_SOURCE_FREERUN
Table 39 Example for SM2 synchronous mode

A similar configuration is used for DC synchronous mode, which eliminates the jitter of the bus
cycle. The only difference is to set the bPDInSource to ECAT_DPM_SYNC_SOURCE_SYNC0.
The synchronization on SM3 event makes sense if only inputs are transmitted.

Note: All values mentioned above have no influence on the real physical sync signal
generation by the ESC. Whether it is active or not and which sync signal. This is done
by the following parameters in ECAT_SET_CONFIG_SYNCPDI_T and from the master
side, which has to activate signals by writing to ESC registers.

Sync PDI configuration parameter

The sync PDI configuration data structure ECAT_SET_CONFIG_SYNCPDI_T contains the
following parameters:
Parameter Type Meaning Range of values
bSyncPdiConfig uint8_t Sync PDI configuration (EtherCAT slave register 0…255
0x151) The default value is
0xCC.
usSyncImpulseLength uint16_t Sync impulse length (in units of 10 ns). 0…65535
The default value is
1000.
bReserved uint8_t reserved
Table 40: Sync PDI configuration parameters

Keep in mind, that the application must enable and explicitly configure the distributed clocks
feature including the Sync0/Sync1 settings in the configuration of the EtherCAT Master.
Even, if a sync signal in the slave is activated through the configuration of the EtherCAT master,
but the application does not need the sync interrupt for synchronisation, the interrupt has to be
activated. This is necessary, because the stack uses the interrupt to monitor the presence of a
sync signal. Otherwise, the stack cannot reach Operational state. By default, the Sync Interrupt is
always enabled.

EtherCAT Slave V5 | Protocol API

DOC181005API01EN | Revision 1| English | 2019-04 | Released | Public © Hilscher, 2018-2019
Application interface 64/127
The following flags (masks) are defined for bSyncPdiConfig:
#define ECAT_SET_CONFIG_SYNCPDI_SYNC0_OUTPUT_TYPE_MASK 0x01
#define ECAT_SET_CONFIG_SYNCPDI_SYNC0_POLARITY_MASK 0x02
#define ECAT_SET_CONFIG_SYNCPDI_SYNC0_OUTPUT_ENABLE_MASK 0x04
#define ECAT_SET_CONFIG_SYNCPDI_SYNC0_IRQ_ENABLE_MASK 0x08
#define ECAT_SET_CONFIG_SYNCPDI_SYNC1_OUTPUT_TYPE_MASK 0x10
#define ECAT_SET_CONFIG_SYNCPDI_SYNC1_POLARITY_MASK 0x20
#define ECAT_SET_CONFIG_SYNCPDI_SYNC1_OUTPUT_ENABLE_MASK 0x40
#define ECAT_SET_CONFIG_SYNCPDI_SYNC1_IRQ_ENABLE_MASK 0x80
The flags have the following meaning:
Bit No. Description
0 SYNC0 Output type
0 - Push Pull
1 - OpenDrain
1 SYNC0 Polarity
0 - low active
1 - high active
2 SYNC0 Output enable/disable
0 - disabled
1 - enabled
3 SYNC0 mapped to PDI-IRQ
0 - disabled
1 - enabled
4 SYNC1 Output type
0 - Push Pull
1 - OpenDrain
5 SYNC1 Polarity:
0 - low active
1 - high active
6 SYNC1 Output enable/disable:
0 - disabled
1 - enabled
7 SYNC1 mapped to PDI-IRQ:
0 - disabled
1 - enabled
Table 41: Description of flags for the variable bSyncPdiConfig

Unique Identification configuration parameter

The unique identification configuration data structure ECAT_SET_CONFIG_UID_T contains the
following parameters:
Parameter Type Meaning Range of values
usStationAlias uint16_t Configured Station Alias 0x00 = not evaluated
here, handling by firmware
0x01 - 0xFF = value
usDeviceIdentificationValue uint16_t Device Identification Value 0x00 = switch off handling
0x1 - 0xFF = activate
handling (value)
Table 42: Unique Identification configuration parameters

The value usStationAlias will be written into the EEPROM and the register 0x12 of the ESC.
A configuration tool can write the station alias address to the EEPROM. It will be transferred to the
ESC register at startup of the device. If it is set here, this possibility is no longer available, because
EtherCAT Slave V5 | Protocol API
DOC181005API01EN | Revision 1| English | 2019-04 | Released | Public © Hilscher, 2018-2019
Application interface 65/127
the value configured by the tool will be overwritten by usStationAlias. Therefore, for most use
cases the parameter should be set to zero. To change the Configured Station Alias, the application
can use the Set Station Alias service.
Device Identification Value: If it is possible to set an address from the device side (for instance, via
a rotary switch, a display or by other ways), the Device Identification Value can be set here.
Otherwise, set the value to zero to deactivate the handling. If the parameter
usDeviceIdentificationValue is set, the application needs to send the packet
HIL_SET_FW_PARAMETER_REQ in addition to update the address in case it has changed. This is
necessary to fulfill the conformance requirements. The actual value should be updated by sending
this packet to the stack before the bus is switched on. The use of HIL_SET_FW_PARAMETER_REQ
automatically activates the address exchange as well, so if it is used, the parameter
usDeviceIdentification is obsolete.

Boot Mailbox configuration parameter

The Bootstrap Mailbox configuration parameter data structure ECAT_SET_CONFIG_BOOTMBX_T
contains the following parameter:
Parameter Type Meaning Range of values
usBootstrapMbxSize uint16_t Bootstrap Mailbox size 0 = switch off Bootstrapmailbox
128 ... 3200
Mailboxes always have the same size for both
directions and the size has to be 4 byte
aligned.
Table 43: Bootstrap Mailbox configuration parameters

The Bootstrap Mailbox size has a default value of 128 byte, which is defined in the configuration
file. If the component parameter evaluation is enabled by setting the flag in
ulComponentInitialization, this value can be changed by the configuration parameter. If the
configuration parameter usBootstrapMbxSize is set to zero, it deactivates the Bootstrap
Mailbox. If the parameter is set to a value different from zero, it overwrites the default value. The
minimum possible value is 128 Byte.

EtherCAT Slave V5 | Protocol API

Device Info configuration parameter

The Device Info configuration parameter data structure ECAT_SET_CONFIG_DEVICEINFO_T
contains the following parameters:
Parameter Type Meaning Range of values
bGroupIdxLength uint8_t Length of char array szGroupIdx[] 0 = value “Not Set”
1 – 127 = length
szGroupIdx[127] uint8_t ASCII code of the group name of the device Length = 127 Byte
SII entry GrouIdx
related to the ESI entry DeviceType: Group
Type
bImageIdxLength uint8_t reserved set to 0
(Length of char array szImageIdx[])
szImageIdx[255] uint8_t reserved Length = 255 Byte,
set to 0
bOrderIdxLength uint8_t Length of char array szOrderIdx[] 0 = value “Not Set”
1 – 127 = length
szOrderIdx[127] uint8_t ASCII code of the order name of the device Length = 127 Byte
SII entry OrderIdx
related to ESI entry DeviceType: Type
bNameIdxLength uint8_t Length of char array szNameIdx[] 0 = value “Not Set”
1 – 127 = length
szNameIdx[127] uint8_t ASCII code of the name of the device Length = 127 Byte
SII entry NameIdx
related to ESI entry DeviceType: Name
Table 44: DeviceInfo configuration parameters

If the component parameter evaluation is enabled by setting the appropriate flag in

ulComponentInitialisation, the Device Info can be set by the configuration parameters. If not, the
Hilscher default values of the target will be used. It is possible to set only the needed values and
deactivate parameters by setting their length to zero.

Attention: Despite the length information, the parameters have to be set in the maximum array
length, even if the parameter length is shorter than possible or if the length is set to
zero. The strings can be filled up with zeros.

EtherCAT Slave V5 | Protocol API

Sm Length configuration parameter

The SyncManager mailboxes can be configured for SM0 and SM1 as well as the start addresses
for SM2 and SM3.
The Sm Length configuration parameter data structure ECAT_ESM_CONFIG_SMLENGTH_T
contains the following parameters:
Parameter Type Meaning Range of values
usMailboxSize uint16_t Size of the standard mailboxes min = 128
This value is used for the output (SM0) and max = available process-
for the input mailbox (SM1) as well. memory byte size / 2
usSM2StartAddress uint16_t Sets the start address of the address space min = 0x1000
for output data in netX. max = chip dependent
usSM3StartAddress uint16_t Sets the start address of the address space min = 0x1004
for input data in netX. max = chip dependent
Table 45: SyncManager length configuration parameters

The mailbox sizes for SM0 and SM1 have a default value of 128 bytes. The SM2/3 default start
addresses dependent on the chip. To change the default settings, the component parameter
evaluation has to be set to enabled (flag in ulComponentInitialization).
If the configuration parameter usMailboxSize is set to a value less than 128 bytes, the minimum
possible value of 128 byte is used. The maximum configurable size is chip dependent. It also
depends on the needed process data size.
3200 bytes minus processdata size (three times counted because of triple buffer) for each
direction.
Mailboxes always have the same size for both directions and the size has to be 4 byte aligned.
The configuration parameter usSM2StartAddress defines the start address for the output
(master/network -> slave) process data image. The address must be set directly after the mailbox
data image to utilize space. If e.g. the mailbox has the default value of 128 Byte, the start address
has to be 0x1100, because the mailboxes start at 0x1000 and have a length of 2 * 0x80 byte.
The configuration parameter usSM3StartAddress defines the start address for the input (slave
-> master/network) process data image. The address can be set directly after the output data
image to utilize space. If e.g. the output image is 256 byte long and usSM2StartAddress starts
at 0x1100, the start address for the input image has to be at minimum 0x1400, because the
process data uses triple buffers. The rest of the address space can be used for input data.
It is necessary to configure both sync manager addresses even for devices, which only have input
data. As well as the mailboxes, also the process data sync managers have to be 4 byte aligned.
This means the triple buffers must each be 4 byte aligned. Values have to follow the calculatuion:
usSM2StartAddress + 3 * ((ulProcessDataOutput
Size + 3) & (~3)) < = usSM3StartAddress.
If this component is used, the configured values are automatically written to the virtual EEPROM
by the EtherCAT stack. The values for the default syncmanager length are defined by the amount
of configured process data (set in ECAT_SET_CONFIG_REQ_DATA_BASIC_T of the configuration
packet). This replaces the standard value 200 bytes used for Hilscher devices. Take care to adapt
the ESI file to the values you use in ECAT_ESM_CONFIG_SMLENGTH_T.

EtherCAT Slave V5 | Protocol API

6.2.1.2 Set Configuration confirmation

The stack sends this confirmation to the application.

Packet structure reference

/* confirmation packet */
typedef __ struct ECAT_SET_CONFIG_CNF_Ttag
{
HIL_PACKET_HEADER_T tHead;
/* no data part */
} ECAT_SET_CONFIG_CNF_T;

typedef struct ECAT_SET_CONFIG_CNF_Ttag

{
HIL_PACKET_HEADER_T tHead;
/* no data part */
} ECAT_SET_CONFIG_CNF_T;

Packet description

Variable Type Value / Range Description

ulLen uint32_t 0 Packet Data Length in bytes
ulSta uint32_t See section Status and error codes
ulCmd uint32_t 0x2CCF ECAT_SET_CONFIG_CNF
Table 46: ECAT_SET_CONFIG_CNF_T – Set Configuration confirmation packet

EtherCAT Slave V5 | Protocol API

6.2.2 Set Trigger Type service

The application can use this service to configure the mode of operation of the process data and
synchronization handshake. The Set Trigger Type service is optional.

Trigger Type EtherCAT Slave

HIL_TRIGGER_TYPE_PDIN_NONE Free-run
HIL_TRIGGER_TYPE_PDIN_RX_DATA_RECEIVED SM2 event
HIL_TRIGGER_TYPE_PDIN_TIMED_ACTIVATION Sync0
HIL_TRIGGER_TYPE_PDOUT_NONE Free-run
HIL_TRIGGER_TYPE_PDOUT_READY_FOR_TX_DATA SM3 event
HIL_TRIGGER_TYPE_PDOUT_TIMED_LATCH Sync1
HIL_TRIGGER_TYPE_SYNC_NONE Free-run
HIL_TRIGGER_TYPE_SYNC_RX_DATA_RECEIVED SM2 event
HIL_TRIGGER_TYPE_SYNC_READY_FOR_TX_DATA SM3 event
HIL_TRIGGER_TYPE_SYNC_TIMED_LATCH Sync1
HIL_TRIGGER_TYPE_SYNC_TIMED_ACTIVATION Sync0
Table 47: Trigger Types of the EtherCAT Slave stack

The handshake configuration is also adjustable with the Sync Modes configuration parameter
(page 62) of the Set Configuration service. The Set Trigger Type request is only needed if the
Configuration can be changed.
The application must not send this service when the slave is in a process data exchange mode.

Set Trigger Type request and confirmation

For a description, see reference [2].

6.2.3 Get Trigger Type service

Using this service the application can read out
 the trigger mode (handshake behavior) for IO handshake and Sync handshake
 the fastest allowed DPM update time
of a protocol stack related to a specific DPM Communication Channel.

Get Trigger Type request and confirmation

For a description, see reference [2].

EtherCAT Slave V5 | Protocol API

6.2.4 Set IO Size service

The application can use this service to change the input length and/or the output length of the
process data. This service does not affect any other parameter.
The main use case for this service is to set new data length for dynamic process data
configuration. Section Dynamic PDO mapping (page 45) shows the necessary sequences and the
location where in the sequence the application has to use the Set IO Size service.

6.2.4.1 Set IO Size request

The application can use this service to change the size of the I/O image.

Packet structure reference

/*******************************************************************************
* ECAT_DPM_SET_IO_SIZE_REQ
*/

/* request packet */
typedef struct ECAT_DPM_SET_IO_SIZE_REQ_DATA_Ttag
{
uint32_t ulProcessDataOutputSize;
uint32_t ulProcessDataInputSize;
} ECAT_DPM_SET_IO_SIZE_REQ_DATA_T;

typedef struct ECAT_DPM_SET_IO_SIZE_REQ_Ttag

{
HIL_PACKET_HEADER_T tHead;
ECAT_DPM_SET_IO_SIZE_REQ_DATA_T tData;
} ECAT_DPM_SET_IO_SIZE_REQ_T;

Packet description

Variable Type Value / Range Description

ulDest uint32_t Destination address / handle
ulLen uint32_t 8 Packet Data Length in bytes
ulCmd uint32_t 0x2CC0 ECAT_DPM_SET_IO_SIZE_REQ
Data
ulProcessDataOu uint32_t 0..1024 Process Data Output Length
tputSize
ulProcessDataIn uint32_t 0..1024 Process Data Input Length
putSize
Table 48: ECAT_DPM_SET_IO_SIZE_REQ_T – Set IO Size request packet

EtherCAT Slave V5 | Protocol API

6.2.4.2 Set IO Size confirmation

The stack will send this confirmation to the application.

Packet structure reference

/*******************************************************************************
* ECAT_DPM_SET_IO_SIZE_CNF
*/

/* confirmation packet */
typedef struct ECAT_DPM_SET_IO_SIZE_CNF_Ttag
{
HIL_PACKET_HEADER_T tHead;
/* no data part */
} ECAT_DPM_SET_IO_SIZE_CNF_T;

Packet description

Variable Type Value / Range Description

ulLen uint32_t 0 Packet Data Length in bytes
ulSta uint32_t See section Status and error codes
ulCmd uint32_t 0x2CC1 ECAT_DPM_SET_IO_SIZE_CNF
Table 49: ECAT_DPM_SET_IO_SIZE_CNF_T – Set IO Size confirmation packet

EtherCAT Slave V5 | Protocol API

DOC181005API01EN | Revision 1| English | 2019-04 | Released | Public © Hilscher, 2018-2019
Application interface 72/127
6.2.5 Set Station Alias service
This service allows setting a station alias to the register 0x0012 in the EtherCAT Slave. Take the
station alias to be set from variable usStationAlias of the request packet.
In the past, the application had to use several packets in order to set the Station Alias Address.
Now, the EtherCAT Slave stack executes the handling of the Station Alias Address. The Station
Alias Address (Second Station Address) is saved non-volatile and afterwards set to the ESC
register by the EtherCAT stack. As a result, the application does not need to handle the Station
Alias Address anymore compared to earlier EtherCAT Slave stack versions.
In case the Station Alias Address handling is implemented within the application, the application
overwrites the values set by the firmware (SII and ESC register value). We recommend to remove
the Station Alias Address handling from the application.

6.2.5.1 Set Station Alias request

To set a station alias, the application has to send this request to the stack

Packet structure reference

/*******************************************************************************
* ECAT_DPM_SET_STATION_ALIAS_REQ
*/

/* request packet */
typedef struct ECAT_DPM_SET_STATION_ALIAS_REQ_DATA_Ttag
{
uint16_t usStationAlias;
} ECAT_DPM_SET_STATION_ALIAS_REQ_DATA_T;

typedef struct ECAT_DPM_SET_STATION_ALIAS_REQ_Ttag

{
HIL_PACKET_HEADER_T tHead;
ECAT_DPM_SET_STATION_ALIAS_REQ_DATA_T tData;
} ECAT_DPM_SET_STATION_ALIAS_REQ_T;

Packet description

Variable Type Value / Range Description

ulDest uint32_t Destination address / handle
ulLen uint32_t 2 Packet Data Length in bytes
ulCmd uint32_t 0x2CC6 ECAT_DPM_SET_STATION_ALIAS_REQ
Data - ECAT_DPM_SET_STATION_ALIAS_REQ_DATA_T
usStationAlias uint16_t 0 ... 65535 Configured station alias
Table 50: ECAT_DPM_SET_STATION_ALIAS_REQ_T – Set Station Alias request packet

EtherCAT Slave V5 | Protocol API

Packet structure reference

/*******************************************************************************
* ECAT_DPM_SET_STATION_ALIAS_CNF
*/

/* confirmation packet */
typedef struct ECAT_DPM_SET_STATION_ALIAS_CNF_Ttag
{
HIL_PACKET_HEADER_T tHead;
/* no data part */
} ECAT_DPM_SET_STATION_ALIAS_CNF_T;

Packet description

Variable Type Value / Range Description

ulLen uint32_t 0 Packet Data Length in bytes
ulSta uint32_t See section Status and error codes
ulCmd uint32_t 0x2CC7 ECAT_DPM_SET_STATION_ALIAS_CNF
Table 51: ECAT_DPM_SET_STATION_ALIAS_CNF_T – Set Station Alias confirmation packet

EtherCAT Slave V5 | Protocol API

6.2.6 Get Station Alias service

This service is used to request a formerly set station alias from the protocol stack. Take the desired
station alias from variable usStationAlias of the confirmation packet.

6.2.6.1 Get Station Alias request

To read the station alias, the application has to send this request to the stack.

Packet structure reference

/*******************************************************************************
* ECAT_DPM_GET_STATION_ALIAS_REQ
*/

/* request packet */
typedef struct ECAT_DPM_GET_STATION_ALIAS_REQ_Ttag
{
HIL_PACKET_HEADER_T tHead;
/* no data part */
} ECAT_DPM_GET_STATION_ALIAS_REQ_T;

typedef struct ECAT_DPM_GET_STATION_ALIAS_REQ_Ttag

{
HIL_PACKET_HEADER_T tHead;
/* no data part */
} ECAT_DPM_GET_STATION_ALIAS_REQ_T;

Packet description

Variable Type Value / Range Description

ulDest uint32_t Destination address / handle
ulLen uint32_t 0 Packet Data Length in bytes
ulSta uint32_t 0 See section Status and error codes
ulCmd uint32_t 0x2CC8 ECAT_DPM_GET_STATION_ALIAS_REQ
Table 52: ECAT_DPM_GET_STATION_ALIAS_REQ_T – Get Station Alias request packet

EtherCAT Slave V5 | Protocol API

6.2.6.2 Get Station Alias confirmation

The stack will send this confirmation to the application.

Packet structure reference

/*******************************************************************************
* ECAT_DPM_GET_STATION_ALIAS_CNF
*/

/* confirmation packet */
typedef struct ECAT_DPM_GET_STATION_ALIAS_CNF_DATA_Ttag
{
uint16_t usStationAlias;
} ECAT_DPM_GET_STATION_ALIAS_CNF_DATA_T;

typedef struct ECAT_DPM_GET_STATION_ALIAS_CNF_Ttag

{
HIL_PACKET_HEADER_T tHead;
ECAT_DPM_GET_STATION_ALIAS_CNF_DATA_T tData;
} ECAT_DPM_GET_STATION_ALIAS_CNF_T;

Packet description

Variable Type Value / Range Description

ulLen uint32_t 2 Packet Data Length in bytes
ulSta uint32_t See section Status and error codes
ulCmd uint32_t 0x2CC9 ECAT_DPM_GET_STATION_ALIAS_CNF
Data - ECAT_DPM_GET_STATION_ALIAS_CNF_DATA_T
usStationAlias uint16_t 0 … 65535 Configured station alias
Table 53: ECAT_DPM_GET_STATION_ALIAS_CNF_T - Get Station Alias confirmation packet

EtherCAT Slave V5 | Protocol API

6.3 EtherCAT State Machine

Overview over the EtherCAT State Machine related Packets of the EtherCAT Slave Stack
Service Command code Page
Register for AL Control Changed Indications service 0x1B18, 0x1B19 76
Unregister From AL Control Changed Indications service 0x1B1A, 0x1B1B 79
AL Control Changed service 0x1B1C, 0x1B1D 81
AL Status Changed service 0x19DE, 0x19DF 85
Set AL Status service 0x1B48, 0x1B49 88
Get AL Status service 0x2CD0, 0x2CD1 90
Table 54: Overview over the EtherCAT State Machine related packets of the EtherCAT Slave stack

6.3.1 Register for AL Control Changed Indications service

In EtherCAT, usually the master controls the state of all slaves. The master can request state
changes from the slave. Each time the master requests such a state change of the EtherCAT State
Machine (ESM), the slave must receive an indication (AL Control Changed Indication, see
description in section AL Control Changed Indication on page 81) informing it about the master’s
state change request. Then the slave can decide on its own, whether to perform or deny the state
change requested by the master.
However, in order to receive these indications, it is necessary that the application first has to
register for the AL Control Changed Indications Service.
For more information on this service, refer to table Figure 6 and Figure 7 in section Handling and
controlling the EtherCAT State Machine on page 20.

EtherCAT Slave V5 | Protocol API

6.3.1.1 Register for AL Control Changed Indications request

The application has to send this request to the stack in order to register for the reception of AL
Control Changed Indications signaling a state change request by the EtherCAT Master. This
packet is extended with a data part and supports the mechanism to activate indications for state
changes from BOOT up to INIT. This mechanism is compliant to the Semiconductor specification
ETG5003-2.
After successful registration on state change requests, the ESM component of the stack will send
AL Control Changed Indications to the registered application.

Packet structure reference

/*******************************************************************************
* ECAT_ESM_REGISTER_FOR_ALCONTROL_INDICATIONS_REQ
*/

/* request packet */
typedef struct ECAT_ESM_REGISTER_FOR_ALCONTROL_INDICATIONS_REQ_DATA_Ttag
{
uint32_t fEnableBootToInitHandling;
} ECAT_ESM_REGISTER_FOR_ALCONTROL_INDICATIONS_REQ_DATA_T;

typedef struct ECAT_ESM_REGISTER_FOR_ALCONTROL_INDICATIONS_REQ_Ttag

{
HIL_PACKET_HEADER_T tHead;
ECAT_ESM_REGISTER_FOR_ALCONTROL_INDICATIONS_REQ_DATA_T tData;
} ECAT_ESM_REGISTER_FOR_ALCONTROL_INDICATIONS_REQ_T;

Packet description

Variable Type Value / Range Description

ulDest uint32_t Destination address / handle
ulLen uint32_t 0… 4 Packet Data Length in bytes
ulSta uint32_t 0 See section Status and error codes
ulCmd uint32_t 0x1B18 ECAT_ESM_REGISTER_FOR_ALCONTROL_INDICATI
ONS_REQ
Data - ECAT_ESM_REGISTER_FOR_ALCONTROL_INDICATIONS_REQ_DATA_T
fEnableBootToInitHandling uint32_t 0 ... 232-1 0 disables the indication mechanism, other enables
Table 55: ECAT_ESM_REGISTER_FOR_ALCONTROL_INDICATIONS_REQ_T – Register For AL Control Changed
Indications request packet

EtherCAT Slave V5 | Protocol API

6.3.1.2 Register For AL Control Changed Indications confirmation

The stack will send this confirmation to the application. It confirms that the stack is ready to
process AL Control Changed indications.

Packet structure reference

/*******************************************************************************
* ECAT_ESM_REGISTER_FOR_ALCONTROL_INDICATIONS_CNF
*/

/* confirmation packet */
typedef struct ECAT_ESM_REGISTER_FOR_ALCONTROL_INDICATIONS_CNF_Ttag
{
HIL_PACKET_HEADER_T tHead;
/* no data part */
} ECAT_ESM_REGISTER_FOR_ALCONTROL_INDICATIONS_CNF_T;

Packet description

Variable Type Value / Range Description

ulLen uint32_t 0 Packet Data Length in bytes
ulSta uint32_t See section Status and error codes
ulCmd uint32_t 0x1B19 ECAT_ESM_REGISTER_FOR_ALCONTROL_INDICATIONS_CNF
Table 56: ECAT_ESM_REGISTER_FOR_ALCONTROL_INDICATIONS_CNF_T – Register For AL Control Changed
Indications confirmation packet

EtherCAT Slave V5 | Protocol API

6.3.2 Unregister From AL Control Changed Indications service

This service unregisters from AL Control Changed Indications. The stack will not generate AL
Control Changed Indications any more. For more information on this service, refer to Figure 6 and
Figure 7 in section Handling and controlling the EtherCAT State Machine on page 20.

6.3.2.1 Unregister From AL Control Changed Indications request

To unregister from the reception of AL Control Changed Indications, the application has to send
this request to the stack. After unregistration, on state change requests the ESM component will
discontinue sending AL Control Changed Indications to the unregistered application.

Packet structure reference

/*******************************************************************************
* ECAT_ESM_UNREGISTER_FROM_ALCONTROL_INDICATIONS_REQ
*/

/* request packet */
typedef struct ECAT_ESM_UNREGISTER_FROM_ALCONTROL_INDICATIONS_REQ_Ttag
{
HIL_PACKET_HEADER_T tHead;
/* no data part */
} ECAT_ESM_UNREGISTER_FROM_ALCONTROL_INDICATIONS_REQ_T;

Packet description

Variable Type Value / Range Description

ulLen uint32_t 0 Packet Data Length in bytes
ulCmd uint32_t 0x1B1A ECAT_ESM_UNREGISTER_FROM_ALCONTROL_INDICATIONS_R
EQ
Table 57: ECAT_ESM_UNREGISTER_FROM_ALCONTROL_INDICATIONS_REQ_T – Unregister from AL Control Changed
Indications request packet

EtherCAT Slave V5 | Protocol API

6.3.2.2 Unregister from AL Control Changed Indications confirmation

The stack will send this confirmation to the application. It confirms that the stack is aware about no
longer receiving AL Control Changed indications.

Packet structure reference

/*******************************************************************************
* ECAT_ESM_UNREGISTER_FROM_ALCONTROL_INDICATIONS_CNF
*/

/* confirmation packet */
typedef struct ECAT_ESM_UNREGISTER_FROM_ALCONTROL_INDICATIONS_CNF_Ttag
{
HIL_PACKET_HEADER_T tHead;
/* no data part */
} ECAT_ESM_UNREGISTER_FROM_ALCONTROL_INDICATIONS_CNF_T;

Packet description

Variable Type Value / Range Description

ulDest uint32_t Destination address / handle
ulLen uint32_t 0 Packet Data Length in bytes
ulSta uint32_t See section Status and error codes
ulCmd uint32_t 0x1B1B ECAT_ESM_UNREGISTER_FROM_ALCONTROL_INDICATIONS_CNF
Table 58: ECAT_ESM_UNREGISTER_FROM_ALCONTROL_INDICATIONS_CNF_T – Unregister From AL Control Changed
Indications confirmation packet

EtherCAT Slave V5 | Protocol API

6.3.3 AL Control Changed service

In EtherCAT, usually the master controls the state of all slaves. Therefore, the EtherCAT Master
can request state changes from the slave. Then the slave can decide on its own whether to
perform or deny the state change requested by the master.
Each time the master requests such a state change of the EtherCAT State Machine (ESM), an
indication must inform the application at the slave about the master’s state change request. This is
done by the AL Control Changed Indication service.

Note: It is necessary to register the application by using the Register for AL Control Changed
Indications service in order to receive an AL Control Changed Indication.

For more information on this service, also refer to section AL Control Register and AL Status
Register, especially Figure 6 (page 21) and Figure 7 (page 22).

6.3.3.1 AL Control Changed Indication

The stack will send this indication to the application when the master requests a state change of
the ESM. The structure tAlControl contains information depending on the AL Control Register:
typedef struct ECAT_ALCONTROL_tag
{
uint8_t uState : 4;
uint8_t fAcknowledge : 1;
uint8_t reserved : 3;
uint8_t bApplicationSpecific : 8;
} ECAT_ALCONTROL_T;
The lowest four bits of the first byte of this structure ECAT_ALCONTROL_T contain the state, which
is requested by the master. The following values are possible:
Value State
1 „Init“ state
2 „Pre-Operational“ state
3 „Bootstrap“ state
4 „Safe-Operational“ state
8 „Operational“ state
Table 59: Coding of EtherCAT state

The master will set the flag fAcknowledge to 0x01 if the state change happens because of a
previous error situation of the slave. The master tries to reset this error situation with this state
change. In case of a regular state change (e.g. during system Startup), the flag fAcknowledge
will be set to 0x00.
For more information regarding fAcknowledge see reference [10].
According to reference [10], the last bits of the structure are reserved, respectively application-
specific.

EtherCAT Slave V5 | Protocol API

DOC181005API01EN | Revision 1| English | 2019-04 | Released | Public © Hilscher, 2018-2019
Application interface 82/127
The variable usErrorLed contains a code for the current state of the error LED. Chapter Error
LED status explains the meaning of the possible codes. The meaning behind each LED signal is
also defined in reference [10].
 Variable usSyncControl contains information regarding the PDI (sync signal) activation, it
reflects the content of ESC register 0x0980.
 Variable usSyncImpulseLength contains the currently defined length of the sync impulse
in units of 10 nanoseconds.
 Variable ulSync0CycleTime contains the register entry (reg. 0x9A0) for the cycle time of
the Sync0 signal in nanoseconds.
 Variable ulSync1CycleTime contains the register entry (reg. 0x9A4) for the cycle time of
the Sync1 signal in nanoseconds. You can calculate the real cycle time from the entries as
follows:
Cycle Time of SYNC1 = ((DcCycTime1 div DcCycTime0) + 1) * DcCycTime0.
Shift Time of SYNC1 = DcCycTime1 mod DcCycTime0)
 Variable bSyncPdiConfig contains information regarding the PDI (sync signal)
configuration, it reflects the content of ESC register 0x0151.
You can use the objects 0x1C32 (Sync Manager 2) or 0x1C33 (Sync Manager 3) for choosing and
adjusting the synchronization mode of the EtherCAT Slave (free running, synchronized to SM2/3
event or synchronized to Distributed Clocks Sync Event). For more information, see reference
[12]).

Packet structure reference

/*******************************************************************************
* ECAT_ESM_ALCONTROL_CHANGED_IND
*/

/* indication packet */
typedef struct ECAT_ESM_ALCONTROL_CHANGED_IND_DATA_Ttag
{
ECAT_ALCONTROL_T tAlControl;
uint16_t usErrorLed;
uint16_t usSyncControl;
uint16_t usSyncImpulseLength;
uint32_t ulSync0CycleTime;
uint32_t ulSync1CycleTime;
uint8_t bSyncPdiConfig;
uint8_t bOriginState;
} ECAT_ESM_ALCONTROL_CHANGED_IND_DATA_T;

typedef struct ECAT_ESM_ALCONTROL_CHANGED_IND_Ttag

{
HIL_PACKET_HEADER_T tHead;
ECAT_ESM_ALCONTROL_CHANGED_IND_DATA_T tData;
} ECAT_ESM_ALCONTROL_CHANGED_IND_T;

EtherCAT Slave V5 | Protocol API

Packet description

Variable Type Value / Description

Range
ulLen uint32_t 18 Packet Data Length in bytes
ulCmd uint32_t 0x1B1C ECAT_ESM_ALCONTROL_CHANGED_IND
Data - ECAT_ESM_ALCONTROL_CHANGED_IND_DATA_T
tAlControl ECAT_ALCONTROL_T 0-0xFFFF Structure representing the AL Control register
described in the IEC 61158-6-12 norm. See above.
usErrorLed uint16_t 0-8 LED error state. Explanations of the meaning of the
various values see above in this section.
usSyncControl uint16_t 0-0xFFFF Sync Control
usSyncImpulseLength uint16_t 0-0xFFFF Length of Sync Impulse (in units of 10 nanoseconds)
ulSync0CycleTime uint32_t Sync0 Cycle Time (in units of 1 nanoseconds)
ulSync1CycleTime uint32_t Sync1 Cycle Time (in units of 1 nanoseconds)
bSyncPdiConfig uint8_t 0-0xFF Sync PDI Configuration
bOriginState uint8_t 0-0xFF Original state
Table 60: ECAT_ESM_ALCONTROL_CHANGED_IND_T – AL Control Changed indication packet

EtherCAT Slave V5 | Protocol API

DOC181005API01EN | Revision 1| English | 2019-04 | Released | Public © Hilscher, 2018-2019
Application interface 84/127
6.3.3.2 AL Control Changed response
Every time the application receives an ECAT_ESM_ALCONTROL_CHANGED_IND indication, it has to send
this response to the stack.

Packet structure reference

/*******************************************************************************
* ECAT_ESM_ALCONTROL_CHANGED_RES
*/

/* response packet */
typedef struct ECAT_ESM_ALCONTROL_CHANGED_RES_Ttag
{
HIL_PACKET_HEADER_T tHead;
/* no data part */
} ECAT_ESM_ALCONTROL_CHANGED_RES_T;

Packet description

Variable Type Value / Range Description

ulDest uint32_t Destination, use value from Indication
ulLen uint32_t 0 Packet Data Length in bytes
ulSta uint32_t See section Status and error codes
ulCmd uint32_t 0x1B1D ECAT_ESM_ALCONTROL_CHANGED_RES
Table 61: ECAT_ESM_ALCONTROL_CHANGED_RES_T – AL Control Changed response packet

EtherCAT Slave V5 | Protocol API

6.3.4 AL Status Changed service

With this service, the stack indicates to the application that the AL status (register 0x0130) of the
EtherCAT Slave has changed. The new EtherCAT State and the change bit is indicated.

Note: It is necessary to register the application by HIL_REGISTER_APP_REQ (see reference

[1] for more information on this packet) in order to receive an AL Status Changed
Indication.

For more information on this service, also refer to section Handling and controlling the EtherCAT
State Machine, especially Figure 5: Sequence diagram of state change with indication to
application/host and Figure 7: Sequence diagram of state change controlled by application/host
with additional AL Status Changed indications.

6.3.4.1 AL Status Changed Indication

This indication is sent to an application each time a change of the AL status has happened. An
application registers for this packet via HIL_REGISTER_APP_REQ. The structure
ECAT_ALSTATUS_T is quite similar to those defined in reference [10].
typedef struct ECAT_ALSTATUS_Ttag
{
uint8_t uState : 4;
uint8_t fChange : 1;
uint8_t reserved : 3;
uint8_t bApplicationSpecific : 8;
}
The lowest four bits of the first byte of this structure are mapped to variable uState in the
following manner:
Value State
1 „Init“
2 „Pre-Operational“
3 „Bootstrap“
4 „Safe-Operational“
8 „Operational“
Table 62: Variable uState of Structure ECAT_ALSTATUS_T

If flag fChange is set to 0x01, the cause of the state change was the slave itself, which means that
the state change happened without request of the master because of an error situation of the slave
itself. To get more information check the usAlStatusCode field.
According to reference [10], the last bits of the structure are reserved, respectively application-
specific. The variable usErrorLed contains a code for the current state of the error LED. The
meaning of the possible codes is described in chapter Error LED status. The meaning behind each
LED signal is also defined in reference [10].
usAlStatusCode contains the current AL Status Code of the slave. For listings of supported
general and vendor specific AL Status Codes see chapter AL status codes.

EtherCAT Slave V5 | Protocol API

DOC181005API01EN | Revision 1| English | 2019-04 | Released | Public © Hilscher, 2018-2019
Application interface 86/127
Packet structure reference
/*******************************************************************************
* ECAT_ESM_ALSTATUS_CHANGED_IND
*/

typedef struct ECAT_ESM_ALSTATUS_CHANGED_IND_DATA_Ttag

{
ECAT_ALSTATUS_T tAlStatus;
uint16_t usErrorLed;
uint16_t usAlStatusCode;
} ECAT_ESM_ALSTATUS_CHANGED_IND_DATA_T;

typedef struct ECAT_ESM_ALSTATUS_CHANGED_IND_Ttag

{
HIL_PACKET_HEADER_T tHead;
ECAT_ESM_ALSTATUS_CHANGED_IND_DATA_T tData;
} ECAT_ESM_ALSTATUS_CHANGED_IND_T;

Packet description

Variable Type Value / Description

Range
ulLen uint32_t 6 Packet Data Length in bytes
ulCmd uint32_t 0x19DE ECAT_ESM_ALSTATUS_CHANGED_IND
Data - ECAT_ESM_ALSTATUS_CHANGED_IND_DATA_T
tAlStatus ECAT_ALSTATUS_T See above Structure representing the AL Status register described in
the norm IEC 61158-6-12 (reference [10]) See above.
usErrorLed uint16_t 0...9 Error LED Status
usAlStatusCode uint16_t AL Status Code
Table 63: ECAT_ESM_ALSTATUS_CHANGED_IND_T – AL Status Changed indication packet

EtherCAT Slave V5 | Protocol API

Packet structure reference

/*******************************************************************************
* ECAT_ESM_ALSTATUS_CHANGED_RES
*/

typedef struct ECAT_ESM_ALSTATUS_CHANGED_RES_Ttag

{
HIL_PACKET_HEADER_T tHead;
/* no data part */
} ECAT_ESM_ALSTATUS_CHANGED_RES_T;

Packet description

Variable Type Value / Range Description

ulDest uint32_t Destination, use value from Indication
ulLen uint32_t 0 Packet Data Length in bytes
ulSta uint32_t See section Status and error codes
ulCmd uint32_t 0x19DF ECAT_ESM_ALSTATUS_CHANGED_RES
Table 64: ECAT_ESM_ALSTATUS_CHANGED_RES_T – AL Status Changed response packet

EtherCAT Slave V5 | Protocol API

6.3.5 Set AL Status service

For more information on this service, also refer to section AL Control Register and AL Status
Register, especially Figure 6: Sequence diagram of EtherCAT state change controlled by
application/host and Figure 7: Sequence diagram of state change controlled by application/host
with additional AL Status Changed indications

6.3.5.1 Set AL Status request

The application has to send this request to the stack to trigger or request an ESM state transition.
The request is used in the following cases:
 Case 1: Signaling an error to the master
 Case 2: Signaling to continue the EtherCAT state machine as reaction to a AL Control
Changed Indication
Case 1:
For signaling an error to the master, the usAlStatusCode has to be set to the appropriate error
code, see section AL status codes on page 112.
Case 2:
If it signals to continue the EtherCAT state machine as reaction to an
ECAT_ESM_ALCONTROL_CHANGED_REQ, the usAlStatusCode has to be set to zero and
the field uState in tAlStatus must be set to the state given in the equivalent
ECAT_ESM_ALCONTROL_CHANGED_IND field tAlControl.uState.

Packet structure reference

/*******************************************************************************
* ECAT_ESM_SET_ALSTATUS_REQ
*/

/* request packet */
typedef struct ECAT_ESM_SET_ALSTATUS_REQ_DATA_Ttag
{
uint8_t bAlStatus;
uint8_t bErrorLedState;
uint16_t usAlStatusCode;
} ECAT_ESM_SET_ALSTATUS_REQ_DATA_T;

typedef struct ECAT_ESM_CHANGE_SET_ALSTATUS_REQ_Ttag

{
HIL_PACKET_HEADER_T tHead;
ECAT_ESM_SET_ALSTATUS_REQ_DATA_T tData;
} ECAT_ESM_SET_ALSTATUS_REQ_T;

EtherCAT Slave V5 | Protocol API

Packet description

Variable Type Value / Range Description

ulDest uint32_t Destination address / handle
ulLen uint32_t 4 Packet Data Length in bytes
ulCmd uint32_t 0x1B48 ECAT_ESM_SET_ALSTATUS_REQ
Data - ECAT_ESM_SET_ALSTATUS_REQ_DATA_T
bAlStatus uint8_t 1-4,8 AL Status(as formatted in EtherCAT register AL status, coded
according to Table 62: Variable uState of Structure
ECAT_ALSTATUS_T)
Note: The application does not have to set the error bit in case of a
failure. If usAlStatusCode is used, the error is implicit.
bErrorLedState uint8_t 1-8 Error LED states (described in section Error LED status page 115)
usAlStatusCod uint16_t 0 or valid AL status AL status code to set or 0 for success. For more information about
e code the available AL status codes see subsection AL status codes on
page 112 or the EtherCAT specification.
Table 65: ECAT_ESM_SET_ALSTATUS_REQ_T – Set AL Status request packet

6.3.5.2 Set AL Status confirmation

The stack will send this confirmation to the application after a Set AL Status Request has been
issued.

Packet structure reference

/*******************************************************************************
* ECAT_ESM_SET_ALSTATUS_CNF
*/

/* confirmation packet */
typedef struct ECAT_ESM_SET_ALSTATUS_CNF_Ttag
{
HIL_PACKET_HEADER_T tHead;
/* no data part */
} ECAT_ESM_SET_ALSTATUS_CNF_T;

Packet description

Variable Type Value / Range Description

ulDest uint32_t Destination address / handle
ulLen uint32_t 0 Packet Data Length in bytes
ulSta uint32_t See section Status and error codes
ulCmd uint32_t 0x1B49 ECAT_ESM_SET_ALSTATUS_CNF
Table 66: ECAT_ESM_SET_ALSTATUS_CNF_T – Set AL Status confirmation packet

EtherCAT Slave V5 | Protocol API

DOC181005API01EN | Revision 1| English | 2019-04 | Released | Public © Hilscher, 2018-2019
Application interface 90/127
6.3.6 Get AL Status service
This service allows retrieving the current contents of the AL Status register.
6.3.6.1 Get AL Status request
To retrieve the current contents of the AL Status register, the application has to send this request
to the stack.

Packet structure reference

/*******************************************************************************
* ECAT_ESM_GET_ALSTATUS_REQ
*/

/* request packet */
typedef struct ECAT_ESM_GET_ALSTATUS_REQ_Ttag
{
HIL_PACKET_HEADER_T tHead;
/* no data part */
} ECAT_ESM_GET_ALSTATUS_REQ_T;

Packet description

Variable Type Value / Range Description

ulDest uint32_t Destination address / handle
ulLen uint32_t 0 Packet Data Length in bytes
ulCmd uint32_t 0x2CD0 ECAT_ESM_GET_ALSTATUS_REQ
Table 67: ECAT_ESM_GET_ALSTATUS_REQ_T – Get AL Status request packet

EtherCAT Slave V5 | Protocol API

6.3.6.2 Get AL Status confirmation

The stack will send this confirmation to the application if the current contents of the AL Status
register have been requested.

Packet structure reference

/*******************************************************************************
* ECAT_ESM_GET_ALSTATUS_CNF
*/

/* confirmation packet */
typedef struct ECAT_ESM_GET_ALSTATUS_CNF_DATA_Ttag
{
uint8_t bAlStatus;
uint8_t bErrorLedState;
uint16_t usAlStatusCode;
} ECAT_ESM_GET_ALSTATUS_CNF_DATA_T;

typedef struct ECAT_ESM_GET_ALSTATUS_CNF_Ttag

{
HIL_PACKET_HEADER_T tHead;
ECAT_ESM_GET_ALSTATUS_CNF_DATA_T tData;
} ECAT_ESM_GET_ALSTATUS_CNF_T;

Packet description

Variable Type Value / Range Description

ulLen uint32_t 4 Packet Data Length in bytes
ulSta uint32_t See section Status and error codes
ulCmd uint32_t 0x2CD1 ECAT_ESM_GET_ALSTATUS_CNF
Data - ECAT_ESM_GET_ALSTATUS_CNF_DATA_T
bAlStatus uint8_t 1-4, 8 AL Status(as formatted in EtherCAT register AL status, coded
according to Table 62: Variable uState of Structure
ECAT_ALSTATUS_T)
bErrorLedState uint8_t 1-8 Error LED states as described in section Error LED status on page
115.
usAlStatusCode uint16_t AL status code to set or 0 for success. For more information about
the available AL status codes see subsection AL status codes on
page 112 or the EtherCAT specification.
Table 68: ECAT_ESM_GET_ALSTATUS_CNF_T – Get AL Status confirmation packet

EtherCAT Slave V5 | Protocol API

6.4 CoE
Overview over the CoE packets of the EtherCAT Slave stack
Packet Command code Page
Send CoE Emergency service 0x1994, 0x1995 92
Table 69: Overview over the CoE packets of the EtherCAT Slave stack

6.4.1 Send CoE Emergency service

This service allows sending a CoE emergency mailbox message to notify about internal device
errors. Since this is a one-way service, there is no defined response from the remote station. The
emergency massage can only be transferred if the mailbox is active (all states except Init). The
station address usStationAddress can be used for two purposes:
 For addressing a master, it is always set to the value 0.
 For addressing a slave, additional preparations at the master are necessary. For more
information on this topic, refer to the master’s documentation. Set usStationAddress to the
value that has been assigned to the respective slave to be addressed by the EtherCAT
Master.

Figure 16: Send CoE Emergency service

6.4.1.1 Send CoE Emergency request

To signal an emergency event within the slave to the master, the application has to send this
request to the stack.
For a list of possible values of usErrorCode see chapter CoE Emergency codes of this
document or Table 50 of reference [10].
For a list of possible values of bErrorRegister see below.

# Name Bit mask

D0 Generic error 0x0001
D1 Current error 0x0002
D2 Voltage error 0x0004
D3 Temperature error 0x0008
D4 Communication error 0x0010
D5 Device profile specific error 0x0020
D6 Reserved 0x0040
D7 Manufacturer specific error 0x0080
Table 70: Bit Mask bErrorRegister

EtherCAT Slave V5 | Protocol API

DOC181005API01EN | Revision 1| English | 2019-04 | Released | Public © Hilscher, 2018-2019
Application interface 93/127
The following rules apply for the relationship between usErrorCode, bErrorRegister and
abDiagnosticData:
1. At error codes (hexadecimal values) 10xx bit D0 (Generic error) of Bit Mask
bErrorRegister should be set, otherwise reset.
2. At error codes (hexadecimal values) 2xxx bit D1 (Current error) of Bit Mask
bErrorRegister should be set, otherwise reset.
3. At error codes (hexadecimal values) 3xxx bit D2 (Voltage error) of Bit Mask
bErrorRegister should be set, otherwise reset.
4. At error codes (hexadecimal values) 4xxx bit D3 (Temperature error) of Bit Mask
bErrorRegister should be set, otherwise reset.
5. At error codes (hexadecimal values) 81xx bit D4 (Communication error) of Bit Mask
bErrorRegister should be set, otherwise reset.
The relationship between usErrorCode, bErrorRegister and abDiagnosticData may also
depend on the used profile.

Packet structure reference

/*******************************************************************************
* ECAT_COE_SEND_EMERGENCY_REQ/
*/

/* request packet */
typedef struct ECAT_COE_SEND_EMERGENCY_REQ_DATA_Ttag
{
uint16_t usStationAddress;
uint16_t usPriority;
uint16_t usErrorCode;
uint8_t bErrorRegister;
uint8_t abDiagnosticData[5];
} ECAT_COE_SEND_EMERGENCY_REQ_DATA_T;

typedef struct ECAT_COE_SEND_EMERGENCY_REQ_Ttag

{
HIL_PACKET_HEADER_T tHead;
ECAT_COE_SEND_EMERGENCY_REQ_DATA_T tData;
} ECAT_COE_SEND_EMERGENCY_REQ_T;

Packet description

Variable Type Value / Range Description

ulDest uint32_t Destination address / handle
ulLen uint32_t 12 Packet Data Length in bytes
ulCmd uint32_t 0x1994 ECAT_COE_SEND_EMERGENCY_REQ
Data - ECAT_COE_SEND_EMERGENCY_REQ_DATA_T
usStationAddress uint16_t 0 or valid slave Station address
address The station address is assigned to the slave by the master during
ESM State Init and further on used to identify the slave.
usPriority uint16_t 0-3 Priority of the mailbox message
0 lowest , 3 highest
usErrorCode uint16_t 0-0xFFFF Error code as defined by IEC 61158 Part 2-6 Type 12 (or ETG
1000.6). See Table 94: CoE Emergencies codes on page 114.
bErrorRegister uint8_t Bit mask Error register as defined by IEC 61158 Part 2-6 Type 12 (or ETG
1000.6)
abDiagnosticData uint8_t[5] Diagnostic Data specific to error code
Table 71: ECAT_COE_SEND_EMERGENCY_REQ_T – Send CoE Emergency request packet

EtherCAT Slave V5 | Protocol API

Packet structure reference

/*******************************************************************************
* ECAT_COE_SEND_EMERGENCY_CNF
*/

/* confirmation packet */
typedef struct ECAT_COE_SEND_EMERGENCY_CNF_Ttag
{
HIL_PACKET_HEADER_T tHead;
/* no data part */
} ECAT_COE_SEND_EMERGENCY_CNF_T;

Packet description

Variable Type Value / Range Description

ulLen uint32_t 0 Packet Data Length in bytes
ulSta uint32_t See section Status and error codes
ulCmd uint32_t 0x1995 ECAT_COE_SEND_EMERGENCY_CNF command
Table 72: ECAT_COE_SEND_EMERGENCY_CNF_T – Send CoE Emergency confirmation packet

EtherCAT Slave V5 | Protocol API

6.5 Packets for Object Dictionary access

All packets for object dictionary access are described in reference [3] within chapters 3 to 5.

6.6 Slave Information Interface (SII)

Overview over the SII Packets of the EtherCAT Slave Stack
Service Command code Page
SII Read service 0x1914, 0x1915 95
SII Write service 0x1912, 0x1913 97
Register for SII Write Indications service 0x1B82, 0x1B83 99
Unregister from SII Write Indications service 0x1B84, 0x1B85 101
SII Write Indication service 0x1B80, 0x1B81 103
Table 73: Overview over the SII packets of the EtherCAT Slave stack

6.6.1 SII Read service

6.6.1.1 SII Read request
This packet performs an SII read request. This means reading information that has been stored in
the Slave Information Interface (SII) of the device. The SII holds information about the slave, which
the master needs for administrative purposes. For more details, see chapter Slave Information
Interface (SII) of this document on page 22.
A data block of the size ulSize (= n) is read from the location with the specified offset ulOffset
and is returned with the confirmation packet.

Packet structure reference

/*******************************************************************************
* ECAT_ESM_SII_READ_REQ
*/

/* request packet */
typedef struct ECAT_ESM_SII_READ_REQ_DATA_Ttag
{
uint32_t ulOffset;
uint32_t ulSize;
} ECAT_ESM_SII_READ_REQ_DATA_T;

typedef struct ECAT_ESM_SII_READ_REQ_Ttag

{
HIL_PACKET_HEADER_T tHead;
ECAT_ESM_SII_READ_REQ_DATA_T tData;
} ECAT_ESM_SII_READ_REQ_T;

Packet description

Variable Type Value / Range Description

ulDest uint32_t Destination address / handle
ulLen uint32_t 8 Packet Data Length in bytes
ulCmd uint32_t 0x1914 ECAT_ESM_SII_READ_REQ
Data - ECAT_ESM_SII_READ_REQ_DATA_T
ulOffset uint32_t Offset value
ulSize uint32_t Size of data block to read
Table 74: ECAT_ESM_SII_READ_REQ_T – SII Read request packet

EtherCAT Slave V5 | Protocol API

Packet structure reference

/*******************************************************************************
* ECAT_ESM_SII_READ_CNF
*/

/* confirmation packet */
typedef struct ECAT_ESM_SII_READ_CNF_DATA_Ttag
{
uint8_t abData[ECAT_ESM_SII_READ_DATA_BYTESIZE];
} ECAT_ESM_SII_READ_CNF_DATA_T;

typedef struct ECAT_ESM_SII_READ_CNF_Ttag

{
HIL_PACKET_HEADER_T tHead;
ECAT_ESM_SII_READ_CNF_DATA_T tData;
} ECAT_ESM_SII_READ_CNF_T;

Packet description

Variable Type Value / Range Description

ulLen uint32_t 1024 Packet Data Length in bytes
ulSta uint32_t See section Status and error codes
ulCmd uint32_t 0x1915 ECAT_ESM_SII_READ_CNF
Data
abData[1024] uint8_t[1024] Field for read data
Table 75: ECAT_ESM_SII_READ_CNF_T – SII Read confirmation packet

EtherCAT Slave V5 | Protocol API

6.6.2 SII Write service

6.6.2.1 SII Write request
This packet performs an SII write request. This means sending information to be stored in the
Slave Information Interface (SII) of the device. The SII holds information about the slave, which the
master needs for administrative purposes. For more details, see chapter Slave Information
Interface (SII) of this document on page 22.

Packet structure reference

/*******************************************************************************
* ECAT_ESM_SII_WRITE_REQ
*/

/* request packet */
typedef struct ECAT_ESM_SII_WRITE_REQ_DATA_Ttag
{
uint32_t ulOffset;
uint8_t abData[ECAT_ESM_SII_WRITE_DATA_BYTESIZE];
} ECAT_ESM_SII_WRITE_REQ_DATA_T;

typedef struct ECAT_ESM_SII_WRITE_REQ_Ttag

{
HIL_PACKET_HEADER_T tHead;
ECAT_ESM_SII_WRITE_REQ_DATA_T tData;
} ECAT_ESM_SII_WRITE_REQ_T;

Packet description

Variable Type Value / Description

Range
ulDest uint32_t Destination address / handle
ulLen uint32_t 4+n Packet Data Length in bytes
ulCmd uint32_t 0x1912 ECAT_ESM_SII_WRITE_REQ
Data - ECAT_ESM_SII_WRITE_REQ_DATA_T
ulOffset uint32_t Offset value (byte address within the SII image)
abData uint8_t[1024] Data to be written
Table 76: ECAT_ESM_SII_WRITE_REQ_T – SII Write request packet

6.6.2.2 SII Write confirmation

The stack will send this confirmation to the application.

Packet structure reference

/*******************************************************************************
* ECAT_ESM_SII_WRITE_REQ/
* ECAT_ESM_SII_WRITE_CNF
*/

/* confirmation packet */
typedef struct ECAT_ESM_SII_WRITE_CNF_Ttag
{
HIL_PACKET_HEADER_T tHead;
/* no data part */
} ECAT_ESM_SII_WRITE_CNF_T;

EtherCAT Slave V5 | Protocol API

Packet description

Variable Type Value / Range Description

ulLen uint32_t 0 Packet Data Length in bytes
ulSta uint32_t See section Status and error codes
ulCmd uint32_t 0x1913 ECAT_ESM_SII_WRITE_CNF
Table 77: ECAT_ESM_SII_WRITE_CNF_T – SII Write confirmation packet

EtherCAT Slave V5 | Protocol API

DOC181005API01EN | Revision 1| English | 2019-04 | Released | Public © Hilscher, 2018-2019
Application interface 99/127
6.6.3 Register for SII Write Indications service
6.6.3.1 Register for SII Write Indications request
The application has to send this request to the stack to register for indications. Such indications
occur, when the EtherCAT master writes to the SII.
This service is only required for writing to the SII during the production process.
This service is not required for setting the station alias.

Packet structure reference

/*******************************************************************************
* ECAT_ESM_REGISTER_FOR_SIIWRITE_INDICATIONS_REQ
*/

/* request packet */
typedef struct ECAT_ESM_REGISTER_FOR_SIIWRITE_INDICATIONS_REQ_DATA_Ttag
{
uint32_t ulIndicationFlags;
} ECAT_ESM_REGISTER_FOR_SIIWRITE_INDICATIONS_REQ_DATA_T;

typedef struct ECAT_ESM_REGISTER_FOR_SIIWRITE_INDICATIONS_REQ_Ttag

{
HIL_PACKET_HEADER_T tHead;
ECAT_ESM_REGISTER_FOR_SIIWRITE_INDICATIONS_REQ_DATA_T tData;
} ECAT_ESM_REGISTER_FOR_SIIWRITE_INDICATIONS_REQ_T;

Packet description

Variable Type Value / Range Description

ulDest uint32_t Destination address / handle
ulLen uint32_t 4 Packet Data Length in bytes
ulCmd uint32_t 0x1B82 ECAT_ESM_REGISTER_FOR_SIIWRITE_INDICATIONS_REQ
Data - ECAT_ESM_REGISTER_FOR_SIIWRITE_INDICATIONS_REQ_DATA_T
ulIndicationFlags uint32_t Indication flags
Table 78: ECAT_ESM_REGISTER_FOR_SIIWRITE_INDICATIONS_REQ_T – Register for SII Write Indications request
packet

EtherCAT Slave V5 | Protocol API

Packet structure reference

/*******************************************************************************
* ECAT_ESM_REGISTER_FOR_SIIWRITE_INDICATIONS_CNF
*/

/* confirmation packet */
typedef struct ECAT_ESM_REGISTER_FOR_SIIWRITE_INDICATIONS_CNF_Ttag
{
HIL_PACKET_HEADER_T tHead;
/* no data part */
} ECAT_ESM_REGISTER_FOR_SIIWRITE_INDICATIONS_CNF_T;

Packet description

Variable Type Value / Range Description

ulDest uint32_t Destination address / handle
ulLen uint32_t 0 Packet Data Length in bytes
ulSta uint32_t See section Status and error codes
ulCmd uint32_t 0x1B83 ECAT_ESM_REGISTER_FOR_SIIWRITE_INDICATIONS_CNF
Table 79: ECAT_ESM_REGISTER_FOR_SIIWRITE_INDICATIONS_CNF_T – Register For SII Write Indications
confirmation packet

EtherCAT Slave V5 | Protocol API

6.6.4 Unregister from SII Write Indications service

6.6.4.1 Unregister from SII Write Indications request
The application has to send this request to the stack to unregister from indications, which occur
when the EtherCAT master writes to the SII.

Packet structure reference

/*******************************************************************************
* ECAT_ESM_UNREGISTER_FROM_SIIWRITE_INDICATIONS_REQ
*/

/* request packet */
typedef struct ECAT_ESM_UNREGISTER_FROM_SIIWRITE_INDICATIONS_REQ_Ttag
{
HIL_PACKET_HEADER_T tHead;
/* no data part */
} ECAT_ESM_UNREGISTER_FROM_SIIWRITE_INDICATIONS_REQ_T;

Packet description

Variable Type Value / Range Description

ulDest uint32_t Destination address / handle
ulLen uint32_t 0 Packet Data Length in bytes
ulCmd uint32_t 0x1B84 ECAT_ESM_UNREGISTER_FROM_SIIWRITE_INDICATIONS_REQ
Table 80: ECAT_ESM_UNREGISTER_FROM_SIIWRITE_INDICATIONS_REQ_T – Unregister from SII Write Indications
request packet

EtherCAT Slave V5 | Protocol API

Packet structure reference

/*******************************************************************************
* ECAT_ESM_UNREGISTER_FROM_SIIWRITE_INDICATIONS_REQ/
* ECAT_ESM_UNREGISTER_FROM_SIIWRITE_INDICATIONS_CNF
*/

/* confirmation packet */
typedef struct ECAT_ESM_UNREGISTER_FROM_SIIWRITE_INDICATIONS_CNF_Ttag
{
HIL_PACKET_HEADER_T tHead;
/* no data part */
} ECAT_ESM_UNREGISTER_FROM_SIIWRITE_INDICATIONS_CNF_T;

typedef struct ECAT_ESM_UNREGISTER_FROM_SIIWRITE_INDICATIONS_CNF_Ttag

{
HIL_PACKET_HEADER_T tHead;
/* no data part */
} ECAT_ESM_UNREGISTER_FROM_SIIWRITE_INDICATIONS_CNF_T;

Packet description

Variable Type Value / Range Description

ulLen uint32_t 0 Packet Data Length in bytes
ulSta uint32_t See section Status and error codes
ulCmd uint32_t 0x1B85 ECAT_ESM_UNREGISTER_FROM_SIIWRITE_INDICATIONS_CNF
Table 81: ECAT_ESM_UNREGISTER_FROM_SIIWRITE_INDICATIONS_CNF_T – Unregister from SII Write Indications
confirmation packet

EtherCAT Slave V5 | Protocol API

6.6.5 SII Write Indication service

If the stack writes data to the SII, it sends this indication to the application.

Note: It is necessary to register the application by using the Register for SII Write Indications
Request in order to receive an SII Write Indication

Figure 17: SII Write Indication service

6.6.5.1 SII Write indication

The stack will send this indication to the application when the EtherCAT Master has written to the
SII.

Permanent SII EEPROM storage

If the AP task requires implementing permanent SII EEPROM storage, it is possible to react on an
SII Write Indication with a SII Read Request. This allows storing the SII image in any kind of
permanent storage on the host side. The stored data can be written back on power up to the SII
image with the SII Write Request.

Packet structure reference

/*******************************************************************************
* ECAT_ESM_SII_WRITE_IND
*/

/* indication packet */
typedef struct ECAT_ESM_SII_WRITE_IND_DATA_Ttag
{
uint32_t ulSiiWriteStartAddress;
uint8_t abData[2];
} ECAT_ESM_SII_WRITE_IND_DATA_T;

typedef struct ECAT_ESM_SII_WRITE_IND_Ttag

{
HIL_PACKET_HEADER_T tHead;
ECAT_ESM_SII_WRITE_IND_DATA_T tData;
} ECAT_ESM_SII_WRITE_IND_T;

EtherCAT Slave V5 | Protocol API

Packet description

Variable Type Value / Range Description

ulLen uint32_t 6 Packet Data Length in bytes
ulCmd uint32_t 0x1B80 ECAT_ESM_SII_WRITE_IND
Data - ECAT_ESM_SII_WRITE_IND_DATA_T
ulSiiWriteStartAddress uint32_t Address to which was written in SII
abData uint8_t[2] Data which was written to SII
Table 82: ECAT_ESM_SII_WRITE_IND_T – SII Write Indication packet

6.6.5.2 SII Write response

The application has to send this response to the stack.

Packet structure reference

/*******************************************************************************
* ECAT_ESM_SII_WRITE_RES
*/

/* response packet */
typedef struct ECAT_ESM_SII_WRITE_RES_Ttag
{
HIL_PACKET_HEADER_T tHead;
/* no data part */
} ECAT_ESM_SII_WRITE_RES_T;

Packet description

Variable Type Value / Range Description

ulDest uint32_t Destination, use value from indication
ulLen uint32_t 0 Packet Data Length in bytes
ulSta uint32_t 0 -
ulCmd uint32_t 0x1B81 ECAT_ESM_SII_WRITE_RES
Table 83: ECAT_ESM_SII_WRITE_RES_T – SII Write response packet

EtherCAT Slave V5 | Protocol API

6.7 Ethernet over EtherCAT (EoE)

EoE is a tunnel protocol which is tunneled via the EtherCAT mailbox for Ethernet frames. All EoE
communication is passed through the master. There is no direct communication path. This causes
the achievable bandwidth to be largely decreased compared to the actual bandwidth on the cable.
EoE requires the EtherCAT Slave stack to be at least in Pre-Operational state in order to be able to
communicate via the EtherCAT mailbox.
It is also necessary that the EtherCAT Master supports EoE since all tunneled Ethernet frames are
transported through the master.
6.7.1 Socket interface
The socket concept is a common communication method between applications. Sockets can
typically be used for local communication and communication over across networks.
The firmware provides a socket interface for accessing TCP or UDP transport layers. This socket
interface is provided by an LWIP stack integrated within the firmware.
For more information on the socket interface, see reference [4].
6.7.2 Ethernet interface
Direct access to the Ethernet is provided on frame level by the Ethernet interface. In detail, the
application can use the Ethernet interface API to
 send and receive Ethernet frames
 send and receive Multicast Ethernet frames
This feature requires a specific taglist entry to be set in order to operate.
For more information on the Ethernet interface, see reference [5].

6.8 Remanent data services

6.8.1 Set Remenent Data
In case the application is responsible to store remanent data (section Remanent data handling on
page 50), the application must use this service during startup to provide the remenent data to the
firmware. For a description of this service and the indication and respone packet, see reference [2].
For a state diagram, see section General initialization sequence on page 38.

Value for ulComponentID

#define HIL_COMPONENT_ID_ECSV5_GCI ((uint32_t)0x010D0000L)

6.8.2 Store Remenent Data

In case the application is responsible to store remanent data (section Remanent data handling on
page 50), the application must handle his service. For a description of this service and the
indication and respone packet, see reference [2].

Value for ulComponentID

#define HIL_COMPONENT_ID_ECSV5_GCI ((uint32_t)0x010D0000L)

EtherCAT Slave V5 | Protocol API

7 Resource and feature configuration via tag list

Loadable firmware supports the feature to configure firmware parameters. During startup of the
firmware, it reads the configuration parameters from the tag list of the firmware.
The firmware reads the tag list parameters
 to customize the resource allocation, and/or
 to configure features.

Tag list parameter

Tag list Parameter / Tag Value Description

Remanent Data Remanent Data Disabled Communication firmware stores remanent data (default).
Responsibility stored by Host
Enabled Application stores remanent data. For a description, see
section Remanent data handling on page 50.
Ethernet NDIS Enable NDIS Disabled NDIS support is disabled (default).
Support Support
Enabled NDIS support is enabled.
servX TCP Port Webserver TCP 0 …65535 Configures the port number for the web server.
Number Port Number 80 = default port number,
0 = web server is deactivated,
If changed, use a valid port number.
UART Diagnostics UART number 0 UART/serial port 0 (not changeable).
Interface Enable unchecked Interface is disabled.
checked Interface is enabled.
This interface is not usable for the APP CPU.
Table 84: Tag list parameter

EtherCAT Slave V5 | Protocol API

8 Status and error codes

8.1 Stack-specific error codes
8.1.1 General
Hexadecimal Definition
Value Description
0x00000000 HIL_S_OK
Status ok
0x00AF0001 HIL_DIAG_S_ECSV4_ESM_STATE_INIT
Slave is in state INIT.
0x00AF0002 HIL_DIAG_S_ECSV4_ESM_STATE_PREOP
Slave is in state PREOP.
0x00AF0003 HIL_DIAG_S_ECSV4_ESM_STATE_SAFEOP
Slave is in state SAFEOP.
0x00AF0004 HIL_DIAG_S_ECSV4_ESM_STATE_OP
Slave is in state OP.
0x80AF0005 HIL_DIAG_W_ECSV4_ESM_STATE_ERR_INIT
Slave is in state ERR INIT.
0x80AF0006 HIL_DIAG_W_ECSV4_ESM_STATE_ERR_PREOP
Slave is in state ERR PREOP.
0x80AF0007 HIL_DIAG_W_ECSV4_ESM_STATE_ERR_SAFEOP
Slave is in state ERR SAFEOP.
0x80AF0008 HIL_DIAG_W_ECSV4_ESM_STATE_ERR_OP
Slave is in state ERR OP.
0x00AF0009 HIL_DIAG_S_ECSV4_ESM_STATE_BOOTING
Slave is booting.
Table 85: Diagnostic codes of the ESM component (Base component)

8.1.2 Set Configuration

Hexadecimal Definition
Value Description
0xC04C0001 HIL_E_ECAT_DPM_COMMAND_INVALID
Invalid command received.
0xC04C0002 HIL_E_ECAT_DPM_INVALID_IO_SIZE
Invalid I/O size
0xC04C0003 HIL_E_ECAT_DPM_WATCHDOG_TIMEOUT_EXPIRED
Watchdog timeout expired.
0xC04C0004 HIL_E_ECAT_DPM_INVALID_WATCHDOG_TIME
Invalid watchdog time
0xC04C0005 HIL_E_ECAT_DPM_INVALID_IO_SIZE_2
Invalid output size
0xC04C0006 HIL_E_ECAT_DPM_INVALID_IO_SIZE_3
Invalid input size
0xC04C0007 HIL_E_ECAT_DPM_INVALID_IO_SIZE_4
Error in DWORD alignment of configuration
0xC04C0008 HIL_E_ECAT_DPM_BUS_SYNCHRONOUS_NOT_SUPPORTED
Bus Synchronous Mode is not supported.

EtherCAT Slave V5 | Protocol API

Hexadecimal Definition
Value Description
0xC04C0009 HIL_E_ECAT_DPM_UPDATE_CFG_SM2_UPDATE_PARAMETER_IS_INVALID
Sm2 Update Parameter is invalid.
0xC04C000A HIL_E_ECAT_DPM_UPDATE_CFG_SM3_UPDATE_PARAMETER_IS_INVALID
Sm2 Update Parameter is invalid.
0xC04C000B HIL_E_ECAT_DPM_UPDATE_CFG_BUS_SYNC_UPDATE_PARAMETER_IS_INVALID
Bus-Sync Update Parameter is invalid.
Table 86: Status / error codes of ECAT_SET_CONFIG_REQ

8.1.3 ESM
Hexadecimal Definition
Value Description
0xC0AF000A HIL_E_ECSV4_ESM_TOO_MANY_APPLICATIONS_ALREADY_REGISTERED
Too many applications already registered for indications.
0xC0AF000B HIL_E_ECSV4_ESM_INPUTSIZE_AND_OUTPUSIZE_ZERO
Invalid I/O size: input size and output size both are 0.
0xC0AF000C HIL_E_ECSV4_ESM_OUTPUTSIZE_EXCEEDS_MAX
Invalid I/O size: output size exceeds maximum (depends on chip type).
0xC0AF000D HIL_E_ECSV4_ESM_INPUTSIZE_EXCEEDS_MAX
Invalid I/O size: input size exceeds maximum (depends on chip type).
0xC0AF000E HIL_E_ECSV4_ESM_SUM_OF_INPUTSIZE_AND_OUTPUSIZE_EXCEEDS_MAX
Invalid I/O size: sum of input size and output size exceeds maximum (depends on chip type).
Table 87: Status / error codes of the ESM (Base component)

8.1.4 MBX
Hexadecimal Definition
Value Description
0xC0B00001 HIL_E_ECSV4_MBX_INITIALIZATION_INVALID
Mailbox initialization invalid.
0xC0B00002 HIL_E_ECSV4_MBX_MAILBOX_NOT_ACTIVE
Mailbox is not active.
Table 88: Status / error codes of the MBX (Base component)

8.1.5 CoE
Hexadecimal Definition
Value Description
0xC0B10001 HIL_E_ECSV4_COE_SDOABORT_TOGGLE_BIT_NOT_CHANGED
Toggle bit was not changed.
0xC0B10002 HIL_E_ECSV4_COE_SDOABORT_SDO_PROTOCOL_TIMEOUT
SDO protocol timeout.
0xC0B10003 HIL_E_ECSV4_COE_SDOABORT_CLIENT_SERVER_COMMAND_SPECIFIER_NOT_VALID
Client/Server command specifier not valid or unknown.
0xC0B10004 HIL_E_ECSV4_COE_SDOABORT_OUT_OF_MEMORY
Out of memory.

EtherCAT Slave V5 | Protocol API

Hexadecimal Definition
Value Description
0xC0B10005 HIL_E_ECSV4_COE_SDOABORT_UNSUPPORTED_ACCESS_TO_AN_OBJECT
Unsupported access to an object.
0xC0B10006 HIL_E_ECSV4_COE_SDOABORT_ATTEMPT_TO_READ_A_WRITE_ONLY_OBJECT
Attempt to read a write only object.
0xC0B10007 HIL_E_ECSV4_COE_SDOABORT_ATTEMPT_TO_WRITE_TO_A_READ_ONLY_OBJECT
Attempt to write to a read only object.
0xC0B10008 HIL_E_ECSV4_COE_SDOABORT_OBJECT_DOES_NOT_EXIST
The object does not exist in the object dictionary.
0xC0B10009 HIL_E_ECSV4_COE_SDOABORT_OBJECT_CAN_NOT_BE_MAPPED_INTO_THE_PDO
The object cannot be mapped into the PDO.
0xC0B1000A HIL_E_ECSV4_COE_SDOABORT_NUMBER_AND_LENGTH_OF_OBJECTS_WOULD_EXCEE
D_PDO_LENGTH
The number and length of the objects to be mapped would exceed the PDO length.
0xC0B1000B HIL_E_ECSV4_COE_SDOABORT_GENERAL_PARAMETER_INCOMPATIBILITY_REASON
General parameter incompatibility reason.
0xC0B1000C HIL_E_ECSV4_COE_SDOABORT_GENERAL_INTERNAL_INCOMPATIBILITY_IN_DEVICE
General internal incompatibility in the device.
0xC0B1000D HIL_E_ECSV4_COE_SDOABORT_ACCESS_FAILED_DUE_TO_A_HARDWARE_ERROR
Access failed due to a hardware error.
0xC0B1000E HIL_E_ECSV4_COE_SDOABORT_DATA_TYPE_DOES_NOT_MATCH_LEN_OF_SRV_PARAM
_DOES_NOT_MATCH
Data type does not match, length of service parameter does not match.
0xC0B1000F HIL_E_ECSV4_COE_SDOABORT_DATA_TYPE_DOES_NOT_MATCH_LEN_OF_SRV_PARAM
_TOO_HIGH
Data type does not match, length of service parameter too high.
0xC0B10010 HIL_E_ECSV4_COE_SDOABORT_DATA_TYPE_DOES_NOT_MATCH_LEN_OF_SRV_PARAM
_TOO_LOW
Data type does not match, length of service parameter too low.
0xC0B10011 HIL_E_ECSV4_COE_SDOABORT_SUBINDEX_DOES_NOT_EXIST
Subindex does not exist.
0xC0B10012 HIL_E_ECSV4_COE_SDOABORT_VALUE_RANGE_OF_PARAMETER_EXCEEDED
Value range of parameter exceeded (only for write access).
0xC0B10013 HIL_E_ECSV4_COE_SDOABORT_VALUE_OF_PARAMETER_WRITTEN_TOO_HIGH
Value of parameter written too high.
0xC0B10014 HIL_E_ECSV4_COE_SDOABORT_VALUE_OF_PARAMETER_WRITTEN_TOO_LOW
Value of parameter written too low.
0xC0B10015 HIL_E_ECSV4_COE_SDOABORT_MAXIMUM_VALUE_IS_LESS_THAN_MINIMUM_VALUE
Maximum value is less than minimum value.
0xC0B10016 HIL_E_ECSV4_COE_SDOABORT_GENERAL_ERROR
General error.
0xC0B10017 HIL_E_ECSV4_COE_SDOABORT_DATA_CANNOT_BE_TRANSFERRED_OR_STORED_TO_T
HE_APP
Data cannot be transferred or stored to the application.
0xC0B10018 HIL_E_ECSV4_COE_SDOABORT_DATA_CANNOT_BE_TRANSFERRED_OR_STORED_DUE_
TO_LOCAL_CONTROL
Data cannot be transferred or stored to the application because of local control.
0xC0B10019 HIL_E_ECSV4_COE_SDOABORT_DATA_CANNOT_BE_TRANSFERRED_OR_STORED_DUE_
TO_PRESENT_DEVICE_STATE
Data cannot be transferred or stored to the application because of the present device state.
0xC0B1001A HIL_E_ECSV4_COE_SDOABORT_NO_OBJECT_DICTIONARY_PRESENT
Object dictionary dynamic generation fails or no object dictionary is present.

EtherCAT Slave V5 | Protocol API

Hexadecimal Definition
Value Description
0xC0B1001B HIL_E_ECSV4_COE_SDOABORT_UNKNOWN_ABORT_CODE
Unknown SDO abort code.
0xC0B1001C HIL_E_ECSV4_COE_EMERGENCY_MESSAGE_COULD_NOT_BE_SENT
CoE emergency message could not be sent.
0xC0B1001D HIL_E_ECSV4_COE_EMERGENCY_MESSAGE_HAS_INVALID_PRIORITY
CoE emergency message has invalid priority.
0xC0B1001E HIL_E_ECSV4_COE_SDOABORT_SUBINDEX_CANNOT_BE_WRITTEN_SI0_MUST_BE_0
Subindex cannot be written, Subindex 0 must be 0 for write access.
0xC0B1001F HIL_E_ECSV4_COE_SDOABORT_COMPLETE_ACCESS_NOT_SUPPORTED
Complete Access not supported.
0xC0B10020 HIL_E_ECSV4_COE_SDOABORT_OBJECT_MAPPED_TO_RXPDO_DOWNLOAD_BLOCKED
Object mapped to RxPDO. SDO Download blocked.
0xC0B10021 HIL_E_ECSV4_COE_SDOABORT_OBJECT_LENGTH_EXCEEDS_MAILBOX_SIZE
Object length exceeds mailbox size.
Table 89: Status / error codes of the CoE component

8.1.6 DPM
Hexadecimal Definition
Value Description
0xC0AE0001 HIL_DIAG_E_ECSV4_DPM_WATCHDOG_TRIGGERED
DPM watchdog triggered.
0xC0AE0002 HIL_E_ECSV4_DPM_REQUEST_ABORTED
Request has been aborted.
0xC0AE0003 HIL_E_ECSV4_DPM_NXD_GENERAL_ERROR
Unknown error while parsing database.
0xC0AE0004 HIL_E_ECSV4_DPM_NXD_NOT_AVAILABLE
No database available.
0xC0AE0005 HIL_E_ECSV4_DPM_NXD_INVALID_NXD_TYPE
Not an EtherCAT slave database.
0xC0AE0006 HIL_E_ECSV4_DPM_NXD_INVALID_STRUCTURE
Invalid database structure.
0xC0AE0007 HIL_E_ECSV4_DPM_NXD_INVALID_NXD_VERSION
Invalid database version.
0xC0AE0008 HIL_E_ECSV4_DPM_NXD_INVALID_ECS_CONFIG
Invalid EtherCAT slave stack configuration.
0xC0AE0009 HIL_E_ECSV4_DPM_NXD_INVALID_SM_CONFIG
Invalid Sync Manager configuration.
0xC0AE000A HIL_E_ECSV4_DPM_NXD_INVALID_SM0_CONFIG
Invalid Sync Manager 0 configuration.
0xC0AE000B HIL_E_ECSV4_DPM_NXD_INVALID_SM1_CONFIG
Invalid Sync Manager 1 configuration.
0xC0AE000C HIL_E_ECSV4_DPM_NXD_INVALID_SM2_CONFIG
Invalid Sync Manager 2 configuration.
0xC0AE000D HIL_E_ECSV4_DPM_NXD_INVALID_SM3_CONFIG
Invalid Sync Manager 3 configuration.
Table 90: Status / error codes of the DPM

EtherCAT Slave V5 | Protocol API

DOC181005API01EN | Revision 1| English | 2019-04 | Released | Public © Hilscher, 2018-2019
Status and error codes 111/127
8.1.7 EoE
Hexadecimal Definition
Value Description
0xC0B20001 HIL_E_ECSV4_EOE_INVALID_TIMEOUT_PARAMS
Invalid timeout parameters.
0xC0B20002 HIL_E_ECSV4_EOE_PARAM_UNSUPPORTED_FRAME_TYPE
Unsupported frame type.
Table 91: Status / error codes of the EoE

8.1.8 ODV3
See reference [3].

EtherCAT Slave V5 | Protocol API

8.2 EtherCAT-specific error codes

8.2.1 AL status codes
8.2.1.1 Standard AL status codes
The following AL Status Codes are defined in the standard (within reference [10], Table 11 – AL
Status Codes) and supported by the EtherCAT Slave Protocol Stack V5:

AL Status Codes supported by the EtherCAT Slave Stack

Numeric value AL Status Code

0x0000 ECAT_AL_STATUS_CODE_NO_ERROR
0x0001 ECAT_AL_STATUS_CODE_UNSPECIFIED_ERROR
0x0011 ECAT_AL_STATUS_CODE_INVALID_REQUESTED_STATE_CHANGE
0x0012 ECAT_AL_STATUS_CODE_UNKNOWN_REQUESTED_STATE
0x0013 ECAT_AL_STATUS_CODE_BOOTSTRAP_NOT_SUPPORTED
0x0014 ECAT_AL_STATUS_CODE_NO_VALID_FIRMWARE
0x0015 ECAT_AL_STATUS_CODE_INVALID_MAILBOX_CONFIGURATION_BOOTSTRAP
0x0016 ECAT_AL_STATUS_CODE_INVALID_MAILBOX_CONFIGURATION_PREOP
0x0017 ECAT_AL_STATUS_CODE_INVALID_SYNC_MANAGER_CONFIGURATION
0x0018 ECAT_AL_STATUS_CODE_NO_VALID_INPUTS_AVAILABLE
0x0019 ECAT_AL_STATUS_CODE_NO_VALID_OUTPUTS
0x001A ECAT_AL_STATUS_CODE_SYNCHRONIZATION_ERROR
0x001B ECAT_AL_STATUS_CODE_SYNC_MANAGER_WATCHDOG
0x001D ECAT_AL_STATUS_CODE_INVALID_OUTPUT_CONFIGURATION
0x001E ECAT_AL_STATUS_CODE_INVALID_INPUT_CONFIGURATION
0x001F ECAT_AL_STATUS_CODE_INVALID_WATCHDOG_CONFIGURATION
0x0020 ECAT_AL_STATUS_CODE_SLAVE_NEEDS_COLD_START
0x0021 ECAT_AL_STATUS_CODE_SLAVE_NEEDS_INIT
0x0022 ECAT_AL_STATUS_CODE_SLAVE_NEEDS_PREOP
0x0023 ECAT_AL_STATUS_CODE_SLAVE_NEEDS_SAFEOP
0x0024 ECAT_AL_STATUS_CODE_INVALID_INPUT_MAPPING
0x0025 ECAT_AL_STATUS_CODE_INVALID_OUTPUT_MAPPING
0x0026 ECAT_AL_STATUS_CODE_INCONSISTENT_SETTINGS
0x0027 ECAT_AL_STATUS_CODE_FREERUN_NOT_SUPPORTED
0x0028 ECAT_AL_STATUS_CODE_SYNCMODE_NOT_SUPPORTED
0x0029 ECAT_AL_STATUS_CODE_FREERUN_NEEDS_3BUFFER_MODE
0x002A ECAT_AL_STATUS_CODE_BACKGROUND_WATCHDOG
0x002B ECAT_AL_STATUS_CODE_NO_VALID_INPUTS_AND_OUTPUTS
0x002C ECAT_AL_STATUS_CODE_FATAL_SYNC_ERROR
0x002D ECAT_AL_STATUS_CODE_NO_SYNC_ERROR
0x002E ECAT_AL_STATUS_CODE_CYCLE_TIME_TOO_SMALL
0x0030 ECAT_AL_STATUS_CODE_INVALID_DC_SYNC_CONFIGURATION
0x0031 ECAT_AL_STATUS_CODE_INVALID_DC_LATCH_CONFIGURATION
0x0032 ECAT_AL_STATUS_CODE_PLL_ERROR
0x0033 ECAT_AL_STATUS_CODE_DC_SYNC_IO_ERROR
0x0034 ECAT_AL_STATUS_CODE_DC_SYNC_TIMEOUT_ERROR
0x0035 ECAT_AL_STATUS_CODE_DC_INVALID_SYNC_CYCLE_TIME
0x0036 ECAT_AL_STATUS_CODE_DC_SYNCO_CYCLE_TIME
0x0037 ECAT_AL_STATUS_CODE_DC_SYNC1_CYCLE_TIME
EtherCAT Slave V5 | Protocol API
DOC181005API01EN | Revision 1| English | 2019-04 | Released | Public © Hilscher, 2018-2019
Status and error codes 113/127
0x0041 ECAT_AL_STATUS_CODE_MBX_AOE
0x0042 ECAT_AL_STATUS_CODE_MBX_EOE
0x0043 ECAT_AL_STATUS_CODE_MBX_COE
0x0044 ECAT_AL_STATUS_CODE_MBX_FOE
0x0045 ECAT_AL_STATUS_CODE_MBX_SOE
0x004F ECAT_AL_STATUS_CODE_MBX_VOE
0x0050 ECAT_AL_STATUS_CODE_EEPROM_NO_ACCESS
0x0051 ECAT_AL_STATUS_CODE_EEPROM_ERROR
0x0052 ECAT_AL_STATUS_CODE_EXTERNAL_HARDWARE_NOT_READY
0x0060 ECAT_AL_STATUS_CODE_SLAVE_RESTARTED_LOCALLY
0x0061 ECAT_AL_STATUS_CODE_DEVICE_ID_VALUE_UPDATED
0x0070 ECAT_AL_STATUS_CODE_DETECTED_MODULE_IDENT_LIST_DOES_NOT_MATCH
0x00F0 ECAT_AL_STATUS_CODE_APPLICATION_CONTROLLER_AVAILABLE
Table 92: Supported AL status codes

8.2.1.2 Vendor-specific AL status codes

The following vendor-specific AL Status Codes have been defined additionally:

Vendor-specific AL Status Codes supported by the EtherCAT Slave Stack

Numeric value AL Status Code

0x8000 ECAT_AL_STATUS_CODE_HOST_NOT_READY
0x8001 ECAT_AL_STATUS_CODE_IO_DATA_SIZE_NOT_CONFIGURED
0x8002 ECAT_AL_STATUS_CODE_DPM_HOST_WATCHDOG_TRIGGERED
0x8003 ECAT_AL_STATUS_CODE_DC_CFG_INVALID
0x8004 ECAT_AL_STATUS_CODE_FIRMWARE_IS_BOOTING
0x8005 ECAT_AL_STATUS_CODE_WARMSTART_REQUESTED
0x8006 ECAT_AL_STATUS_CODE_CHANNEL_INIT_REQUESTED
0x8007 ECAT_AL_STATUS_CODE_CONFIGURATION_CLEARED
0x8008 ECAT_AL_STATUS_CODE_PDI_WATCHDOG_TIME_CONFIGURATION_ERROR
Table 93: Vendor-specific AL status codes

EtherCAT Slave V5 | Protocol API

DOC181005API01EN | Revision 1| English | 2019-04 | Released | Public © Hilscher, 2018-2019
Status and error codes 114/127
8.2.2 CoE Emergency codes
Error Code (hexadecimal) Meaning of code
00xx Error Reset or No Error
10xx Generic Error
20xx Current
21xx Current, device input side
22xx Current inside the device
23xx Current, device output side
30xx Voltage
31xx Mains Voltage
32xx Voltage inside the device
33xx Output Voltage
40xx Temperature
41xx Ambient Temperature
42xx Device Temperature
50xx Device Hardware
60xx Device Software
61xx Internal Software
62xx User Software
63xx Data Set
70xx Additional Modules
80xx Monitoring
81xx Communication
82xx Protocol Error
8210 PDO not processed due to length error
8220 PDO length exceeded
90xx External Error
A0xx EtherCAT State Machine Transition Error
F0xx Additional Functions
FFxx Device specific
Table 94: CoE Emergencies codes

EtherCAT Slave V5 | Protocol API

8.2.3 Error LED status

Value Error LED status Meaning
0 LED off No error i.e. EtherCAT communication is in working condition.
1 LED permanently on Application controller failure, for instance a PDI Watchdog timeout has
occurred (Application controller is not responding any more).
2 LED flickering Booting error
3 LED flickers only once Reserved for future use
4 LED blinking Invalid Configuration: General Configuration Error
Example: State change commanded by master is impossible due to
register or object settings.
It is recommended to check and correct settings and hardware options.
5 LED single flash Local error / Unsolicited State Change: Slave device application has
changed the EtherCAT state autonomously: Parameter Change in the AL
status register is set to 0x01: change/error
Example: Synchronization Error, device enters Safe-Operational
automatically.
6 LED double flash Watchdog error
for instance, a Process Data Watchdog Timeout, EtherCAT Watchdog
Timeout or Sync Manager Watchdog Timeout occurred.
7 LED triple flash Reserved for future use
8 LED quadruple flash Reserved for future use
9 LED quintuple flash Reserved for future use
Table 95: Error LED status

The meaning of each LED signal is defined in reference [11].

EtherCAT Slave V5 | Protocol API

8.2.4 SDO Abort codes

Return codes are generally structured into the following elements:
 Error Class
 Error Code
 Additional Code

Error class
The element Error Class (1 byte) generally classifies the kind of error, see table:
Class (hex) Name Description
1 vfd-state Status error in virtual field device
2 application-reference Error in application program
3 definition Definition error
4 resource Resource error
5 service Error in service execution
6 access Access error
7 od Error in object dictionary
8 other Other error
Table 96: SDO Abort codes: Error class

Error code
The element Error Code (1 byte) accomplishes the more precise differentiation of the error cause
within an Error Class. For Error Class = 8 (Other error) only Error Code = 0 (Other error code) is
defined, for more detailing the Additional Code is available.

Additional code
The additional code contains the detailed error description

EtherCAT Slave V5 | Protocol API

8.2.4.1 SDO Abort codes

SDO Abort code Error Error code Additional Description
Class code
0x00000000 0 0 0 No error
0x05030000 5 3 0 Toggle bit not changed – Error in toggle bit at
segmented transfer
0x05040000 5 4 0 SDO Protocol Timeout (at service execution)
0x05040001 5 4 1 Unknown command specifier (for SDO Service)
0x05040005 5 4 5 Out of memory - Memory overflow occurred at SDO
Service execution
0x06010000 6 1 0 Unsupported access to an index
0x06010001 6 1 1 Write –only entry (Index may only be written but not
read)
0x06010002 6 1 2 Read –only entry (Index may only be read but not
written- parameter lock active)
0x06010003 6 1 3 Subindex cannot be written, subindex 0 must be 0 for
write access
0x06010004 6 1 4 SDO Complete access not supported for objects of
variable length such as ENUM object types
0x06010005 6 1 5 Object length exceeds mailbox size
0x06010006 6 1 6 Download blocked because object mapped to RxPDO
0x06020000 6 2 0 Object not existing – wrong index.
0x06040041 6 4 41 Object cannot be PDO-mapped – The index may not be
mapped into a PDO
0x06040042 6 4 42 The number of mapped objects exceeds the capacity of
the PDO
0x06040043 6 4 43 Parameter is incompatible (The data format of the
parameter is incompatible for the index)
0x06040047 6 4 47 Internal device incompatibility (Device-internal error)
0x06060000 6 6 0 Hardware error (Device-internal error)
0x06070010 6 7 10 Parameter length error – data format for index has
wrong size
0x06070012 6 7 12 Parameter length too long – Data format to large for
index
0x06070013 6 7 13 Parameter length too short – Data format to small for
index
0x06090011 6 9 11 Subindex not existing (has not been implemented)
0x06090030 6 9 30 Value exceeded a limit (value is invalid)
0x06090031 6 9 31 Value is too large
0x06090032 6 9 32 Value is too small
0x06090036 6 9 36 The maximum value is less than the minimum value
0x08000000 8 0 0 General error
0x08000020 8 0 20 Data cannot be read or stored – error in data access
0x08000021 8 0 21 Data cannot be read or stored because of local control
– error in data access
0x08000022 8 0 22 Data cannot be read or stored in this state – error in
data access
0x08000023 8 0 23 There is no object dictionary present.
Table 97: SDO Abort Codes

EtherCAT Slave V5 | Protocol API

DOC181005API01EN | Revision 1| English | 2019-04 | Released | Public © Hilscher, 2018-2019
Status and error codes 118/127
8.2.4.2 Correspondence of SDO Abort codes and status / error codes
The following table explains the correspondence between the SDO abort code on one hand and
the status/error code of the EtherCAT Slave protocol stack on the other hand:
SDO Abort Status / error Description
code code
0x00000000 0x0000 HIL_S_OK
Status ok
0x05030000 0xC0B10001 HIL_E_ECSV4_COE_SDOABORT_TOGGLE_BIT_NOT_CHANGED
Toggle bit was not changed.
0x05040000 0xC0B10002 HIL_E_ECSV4_COE_SDOABORT_SDO_PROTOCOL_TIMEOUT
SDO protocol timeout.
0x05040001 0xC0B10003 HIL_E_ECSV4_COE_SDOABORT_CLIENT_SERVER_COMMAND_SPECIFIER
_NOT_VALID
Client/Server command specifier not valid or unknown.
0x05040005 0xC0B10004 HIL_E_ECSV4_COE_SDOABORT_OUT_OF_MEMORY
Out of memory.
0x06010000 0xC0B10005 HIL_E_ECSV4_COE_SDOABORT_UNSUPPORTED_ACCESS_TO_AN_OBJEC
T
Unsupported access to an object.
0x06010001 0xC0B10006 HIL_E_ECSV4_COE_SDOABORT_ATTEMPT_TO_READ_A_WRITE_ONLY_OB
JECT
Attempt to read a write only object.
0x06010002 0xC0B10007 HIL_E_ECSV4_COE_SDOABORT_ATTEMPT_TO_WRITE_TO_A_READ_ONLY
_OBJECT
Attempt to write to a read only object.
0x06020000 0xC0B10008 HIL_E_ECSV4_COE_SDOABORT_OBJECT_DOES_NOT_EXIST
The object does not exist in the object dictionary.
0x06040041 0xC0B10009 HIL_E_ECSV4_COE_SDOABORT_OBJECT_CAN_NOT_BE_MAPPED_INTO_T
HE_PDO
The object cannot be mapped into the PDO.
0x06040042 0xC0B1000A HIL_E_ECSV4_COE_SDOABORT_NUMBER_AND_LENGTH_OF_OBJECTS_W
OULD_EXCEED_PDO_LENGTH
The number and length of the objects to be mapped would exceed the PDO
length.
0x06040043 0xC0B1000B HIL_E_ECSV4_COE_SDOABORT_GENERAL_PARAMETER_INCOMPATIBILIT
Y_REASON
General parameter incompatibility reason.
0x06040047 0xC0B1000C HIL_E_ECSV4_COE_SDOABORT_GENERAL_INTERNAL_INCOMPATIBILITY_I
N_DEVICE
General internal incompatibility in the device.
0x06060000 0xC0B1000D HIL_E_ECSV4_COE_SDOABORT_ACCESS_FAILED_DUE_TO_A_HARDWARE
_ERROR
Access failed due to a hardware error.
0x06070010 0xC0B1000E HIL_E_ECSV4_COE_SDOABORT_DATA_TYPE_DOES_NOT_MATCH_LEN_O
F_SRV_PARAM_DOES_NOT_MATCH
Data type does not match, length of service parameter does not match.
0x06070012 0xC0B1000F HIL_E_ECSV4_COE_SDOABORT_DATA_TYPE_DOES_NOT_MATCH_LEN_O
F_SRV_PARAM_TOO_HIGH
Data type does not match, length of service parameter too high.
0x06070013 0xC0B10010 HIL_E_ECSV4_COE_SDOABORT_DATA_TYPE_DOES_NOT_MATCH_LEN_O
F_SRV_PARAM_TOO_LOW
Data type does not match, length of service parameter too low.
0x06090011 0xC0B10011 HIL_E_ECSV4_COE_SDOABORT_SUBINDEX_DOES_NOT_EXIST
Subindex does not exist.

EtherCAT Slave V5 | Protocol API

SDO Abort Status / error Description

code code
0x06090030 0xC0B10012 HIL_E_ECSV4_COE_SDOABORT_VALUE_RANGE_OF_PARAMETER_EXCEE
DED
Value range of parameter exceeded (only for write access).
0x06090031 0xC0B10013 HIL_E_ECSV4_COE_SDOABORT_VALUE_OF_PARAMETER_WRITTEN_TOO_
HIGH
Value of parameter written too high.
0x06090032 0xC0B10014 HIL_E_ECSV4_COE_SDOABORT_VALUE_OF_PARAMETER_WRITTEN_TOO_
LOW
Value of parameter written too low.
0x06090036 0xC0B10015 HIL_E_ECSV4_COE_SDOABORT_MAXIMUM_VALUE_IS_LESS_THAN_MINIM
UM_VALUE
Maximum value is less than minimum value.
0x08000000 0xC0B10016 HIL_E_ECSV4_COE_SDOABORT_GENERAL_ERROR
General error.
0x08000020 0xC0B10017 HIL_E_ECSV4_COE_SDOABORT_DATA_CANNOT_BE_TRANSFERRED_OR_
STORED_TO_THE_APP
Data cannot be transferred or stored to the application.
0x08000021 0xC0B10018 HIL_E_ECSV4_COE_SDOABORT_DATA_CANNOT_BE_TRANSFERRED_OR_
STORED_DUE_TO_LOCAL_CONTROL
Data cannot be transferred or stored to the application because of local control.
0x08000022 0xC0B10019 HIL_E_ECSV4_COE_SDOABORT_DATA_CANNOT_BE_TRANSFERRED_OR_
STORED_DUE_TO_PRESENT_DEVICE_STATE
Data cannot be transferred or stored to the application because of the present
device state.
0x08000023 0xC0B1001A HIL_E_ECSV4_COE_SDOABORT_NO_OBJECT_DICTIONARY_PRESENT
Object dictionary dynamic generation fails or no object dictionary is present.
Table 98: Correspondence of SDO Abort codes and status / error codes

EtherCAT Slave V5 | Protocol API

9 Appendix
9.1 Legal notes
Copyright
© Hilscher Gesellschaft für Systemautomation mbH
All rights reserved.
The images, photographs and texts in the accompanying materials (in the form of a user's manual,
operator's manual, Statement of Work document and all other document types, support texts,
documentation, etc.) are protected by German and international copyright and by international
trade and protective provisions. Without the prior written consent, you do not have permission to
duplicate them either in full or in part using technical or mechanical methods (print, photocopy or
any other method), to edit them using electronic systems or to transfer them. You are not permitted
to make changes to copyright notices, markings, trademarks or ownership declarations.
Illustrations are provided without taking the patent situation into account. Any company names and
product designations provided in this document may be brands or trademarks by the
corresponding owner and may be protected under trademark, brand or patent law. Any form of
further use shall require the express consent from the relevant owner of the rights.

Important notes
Utmost care was/is given in the preparation of the documentation at hand consisting of a user's
manual, operating manual and any other document type and accompanying texts. However, errors
cannot be ruled out. Therefore, we cannot assume any guarantee or legal responsibility for
erroneous information or liability of any kind. You are hereby made aware that descriptions found
in the user's manual, the accompanying texts and the documentation neither represent a
guarantee nor any indication on proper use as stipulated in the agreement or a promised attribute.
It cannot be ruled out that the user's manual, the accompanying texts and the documentation do
not completely match the described attributes, standards or any other data for the delivered
product. A warranty or guarantee with respect to the correctness or accuracy of the information is
not assumed.
We reserve the right to modify our products and the specifications for such as well as the
corresponding documentation in the form of a user's manual, operating manual and/or any other
document types and accompanying texts at any time and without notice without being required to
notify of said modification. Changes shall be taken into account in future manuals and do not
represent an obligation of any kind, in particular there shall be no right to have delivered
documents revised. The manual delivered with the product shall apply.
Under no circumstances shall Hilscher Gesellschaft für Systemautomation mbH be liable for direct,
indirect, ancillary or subsequent damage, or for any loss of income, which may arise after use of
the information contained herein.

Liability disclaimer
The hardware and/or software was created and tested by Hilscher Gesellschaft für
Systemautomation mbH with utmost care and is made available as is. No warranty can be
assumed for the performance or flawlessness of the hardware and/or software under all application
conditions and scenarios and the work results achieved by the user when using the hardware
and/or software. Liability for any damage that may have occurred as a result of using the hardware
and/or software or the corresponding documents shall be limited to an event involving willful intent
or a grossly negligent violation of a fundamental contractual obligation. However, the right to assert

EtherCAT Slave V5 | Protocol API

DOC181005API01EN | Revision 1| English | 2019-04 | Released | Public © Hilscher, 2018-2019
Appendix 121/127
damages due to a violation of a fundamental contractual obligation shall be limited to contract-
typical foreseeable damage.
It is hereby expressly agreed upon in particular that any use or utilization of the hardware and/or
software in connection with
 Flight control systems in aviation and aerospace;
 Nuclear fission processes in nuclear power plants;
 Medical devices used for life support and
 Vehicle control systems used in passenger transport
shall be excluded. Use of the hardware and/or software in any of the following areas is strictly
prohibited:
 For military purposes or in weaponry;
 For designing, engineering, maintaining or operating nuclear systems;
 In flight safety systems, aviation and flight telecommunications systems;
 In life-support systems;
 In systems in which any malfunction in the hardware and/or software may result in physical
injuries or fatalities.
You are hereby made aware that the hardware and/or software was not created for use in
hazardous environments, which require fail-safe control mechanisms. Use of the hardware and/or
software in this kind of environment shall be at your own risk; any liability for damage or loss due to
impermissible use shall be excluded.

Warranty
Hilscher Gesellschaft für Systemautomation mbH hereby guarantees that the software shall run
without errors in accordance with the requirements listed in the specifications and that there were
no defects on the date of acceptance. The warranty period shall be 12 months commencing as of
the date of acceptance or purchase (with express declaration or implied, by customer's conclusive
behavior, e.g. putting into operation permanently).
The warranty obligation for equipment (hardware) we produce is 36 months, calculated as of the
date of delivery ex works. The aforementioned provisions shall not apply if longer warranty periods
are mandatory by law pursuant to Section 438 (1.2) BGB, Section 479 (1) BGB and Section 634a
(1) BGB [Bürgerliches Gesetzbuch; German Civil Code] If, despite of all due care taken, the
delivered product should have a defect, which already existed at the time of the transfer of risk, it
shall be at our discretion to either repair the product or to deliver a replacement product, subject to
timely notification of defect.
The warranty obligation shall not apply if the notification of defect is not asserted promptly, if the
purchaser or third party has tampered with the products, if the defect is the result of natural wear,
was caused by unfavorable operating conditions or is due to violations against our operating
regulations or against rules of good electrical engineering practice, or if our request to return the
defective object is not promptly complied with.

Costs of support, maintenance, customization and product care

Please be advised that any subsequent improvement shall only be free of charge if a defect is
found. Any form of technical support, maintenance and customization is not a warranty service, but
instead shall be charged extra.

EtherCAT Slave V5 | Protocol API

DOC181005API01EN | Revision 1| English | 2019-04 | Released | Public © Hilscher, 2018-2019
Appendix 122/127
Additional guarantees
Although the hardware and software was developed and tested in-depth with greatest care,
Hilscher Gesellschaft für Systemautomation mbH shall not assume any guarantee for the suitability
thereof for any purpose that was not confirmed in writing. No guarantee can be granted whereby
the hardware and software satisfies your requirements, or the use of the hardware and/or software
is uninterruptable or the hardware and/or software is fault-free.
It cannot be guaranteed that patents and/or ownership privileges have not been infringed upon or
violated or that the products are free from third-party influence. No additional guarantees or
promises shall be made as to whether the product is market current, free from deficiency in title, or
can be integrated or is usable for specific purposes, unless such guarantees or promises are
required under existing law and cannot be restricted.

Confidentiality
The customer hereby expressly acknowledges that this document contains trade secrets,
information protected by copyright and other patent and ownership privileges as well as any related
rights of Hilscher Gesellschaft für Systemautomation mbH. The customer agrees to treat as
confidential all of the information made available to customer by Hilscher Gesellschaft für
Systemautomation mbH and rights, which were disclosed by Hilscher Gesellschaft für
Systemautomation mbH and that were made accessible as well as the terms and conditions of this
agreement itself.
The parties hereby agree to one another that the information that each party receives from the
other party respectively is and shall remain the intellectual property of said other party, unless
provided for otherwise in a contractual agreement.
The customer must not allow any third party to become knowledgeable of this expertise and shall
only provide knowledge thereof to authorized users as appropriate and necessary. Companies
associated with the customer shall not be deemed third parties. The customer must obligate
authorized users to confidentiality. The customer should only use the confidential information in
connection with the performances specified in this agreement.
The customer must not use this confidential information to his own advantage or for his own
purposes or rather to the advantage or for the purpose of a third party, nor must it be used for
commercial purposes and this confidential information must only be used to the extent provided for
in this agreement or otherwise to the extent as expressly authorized by the disclosing party in
written form. The customer has the right, subject to the obligation to confidentiality, to disclose the
terms and conditions of this agreement directly to his legal and financial consultants as would be
required for the customer's normal business operation.

Export provisions
The delivered product (including technical data) is subject to the legal export and/or import laws as
well as any associated regulations of various countries, especially such laws applicable in
Germany and in the United States. The products / hardware / software must not be exported into
such countries for which export is prohibited under US American export control laws and its
supplementary provisions. You hereby agree to strictly follow the regulations and to yourself be
responsible for observing them. You are hereby made aware that you may be required to obtain
governmental approval to export, reexport or import the product.

EtherCAT Slave V5 | Protocol API

9.2 EtherCAT summary concerning vendor ID, conformance

test, membership and network logo
Vendor ID
The communication interface product is shipped with Hilscher’s secondary vendor ID, which has to
be replaced by the Vendor ID of the company shipping end products with the integrated
communication interface. End Users or Integrators may use the communication interface product
without further modification if they re-distribute the interface product (e.g. PCI Interface card
products) only as part of a machine or machine line or as spare part for such a machine. In case of
questions, contact Hilscher and/or your nearest ETG representative. The ETG Vendor-ID policies
apply.

Conformance
EtherCAT Devices have to conform to the EtherCAT specifications. The EtherCAT Conformance
Test Policies apply, which can be obtained from the EtherCAT Technology Group (ETG,
www.ethercat.org).
Hilscher range of embedded network interface products are conformance tested for network
compliance. This simplifies conformance testing of the end product and can be used as a
reference for the end product as a statement of network conformance (when used with standard
operational settings). It must however be clearly stated in the product documentation that this
applies to the network interface and not to the complete product.
Conformance Certificates can be obtained by passing the conformance test in an official EtherCAT
Conformance Test lab. Conformance Certificates are not mandatory, but may be required by the
end user.

Certified Product vs. Certified Network Interface

The EtherCAT implementation may in certain cases allow one to modify the behavior of the
EtherCAT network interface device in ways which are not in line with EtherCAT conformance
requirements. For example, certain communication parameters are set by a software stack, in
which case the actual software implementation in the device application determines whether or not
the network interface can pass the EtherCAT conformance test. In such cases, conformance test
of the end product must be passed to ensure that the implementation does not affect network
compliance.
Generally, implementations of this kind require in-depth knowledge in the operating fundamentals
of EtherCAT. To find out whether or not a certain type of implementation can pass conformance
testing and requires such testing, contact EtherCAT Technology Group (“ETG”, www.ethercat.org)
and/or your nearest EtherCAT conformance test centre. EtherCAT may allow the combination of
an untested end product with a conformant network interface. Although this may in some cases
make it possible to sell the end product without having to perform network conformance tests, this
approach is generally not endorsed by Hilscher. In case of questions, contact Hilscher and/or your
nearest ETG representative.

Membership and Network Logo

Generally, membership in the network organization and a valid Vendor-ID are prerequisites in
order to be able to test the end product for conformance. This also applies to the use of the
EtherCAT name and logo, which is covered by the ETG marking rules.
Vendor ID Policy accepted by ETG Board of Directors, November 5, 2008

EtherCAT Slave V5 | Protocol API

9.3 List of tables

Table 1: List of revisions ..................................................................................................................................................... 5
Table 2: Technical data ....................................................................................................................................................... 6
Table 3: Terms, abbreviations and definitions ..................................................................................................................... 8
Table 4: Component configuration parameters ................................................................................................................. 12
Table 5: Input and output data .......................................................................................................................................... 14
Table 6: EtherCAT Slave stack functions .......................................................................................................................... 17
Table 7: Slave Information Interface structure................................................................................................................... 23
Table 8: Definition of categories in SII ............................................................................................................................... 24
Table 9: Available standard categories ............................................................................................................................. 24
Table 10: CoE Communication Area - General overview .................................................................................................. 27
Table 11: Minimal Object Directory ................................................................................................................................... 28
Table 12: CoE Communication Area - Device Type .......................................................................................................... 28
Table 13: CoE Communication Area – Identity Object ...................................................................................................... 28
Table 14: CoE Communication Area – Identity Object - Number of entries ...................................................................... 28
Table 15: CoE Communication Area – Identity Object - Vendor ID ................................................................................... 29
Table 16: CoE Communication Area – Identity Object - Product Code ............................................................................. 29
Table 17: CoE Communication Area – Identity Object - Revision Number ....................................................................... 29
Table 18: CoE Communication Area – Identity Object - Serial Number ............................................................................ 29
Table 19: Default Object Dictionary ................................................................................................................................... 31
Table 20: Ethernet MAC addresses .................................................................................................................................. 35
Table 21: abParameter................................................................................................................................................... 41
Table 22: Request Packet HIL_SET_FW_PARAMETER_REQ_T ........................................................................................ 41
Table 23: Confirmation Packet HIL_SET_FW_PARAMETER_CNF_T ................................................................................. 42
Table 24: Overview over the general packets of the EtherCAT Slave stack ..................................................................... 52
Table 25: Configuration packets overview......................................................................................................................... 53
Table 26: ECAT_SET_CONFIG_REQ_T – Set Configuration request packet ..................................................................... 56
Table 27: Basic configuration data .................................................................................................................................... 57
Table 28: Values for the parameters ulVendorId, ulProductCode and ulRevisionNumber ................................................ 58
Table 29: Parameter ulComponentInitialization ................................................................................................... 59
Table 30: Component configuration parameters ............................................................................................................... 60
Table 31: CoE configuration parameters ........................................................................................................................... 60
Table 32: Flags for CoE configuration ............................................................................................................................... 60
Table 33: Flags for CoE details ......................................................................................................................................... 60
Table 34: EoE configuration parameters ........................................................................................................................... 61
Table 35: FoE configuration parameters ........................................................................................................................... 61
Table 36: SoE configuration parameters ........................................................................................................................... 61
Table 37: Synchronization Modes configuration parameters ............................................................................................ 62
Table 38: Flags for EtherCAT synchronization sources .................................................................................................... 62
Table 39 Example for SM2 synchronous mode................................................................................................................. 63
Table 40: Sync PDI configuration parameters ................................................................................................................... 63
Table 41: Description of flags for the variable bSyncPdiConfig ......................................................................................... 64
Table 42: Unique Identification configuration parameters ................................................................................................. 64
Table 43: Bootstrap Mailbox configuration parameters ..................................................................................................... 65
Table 44: DeviceInfo configuration parameters ................................................................................................................. 66
Table 45: SyncManager length configuration parameters ................................................................................................. 67
Table 46: ECAT_SET_CONFIG_CNF_T – Set Configuration confirmation packet .............................................................. 68
Table 47: Trigger Types of the EtherCAT Slave stack ...................................................................................................... 69
Table 48: ECAT_DPM_SET_IO_SIZE_REQ_T – Set IO Size request packet .................................................................... 70
Table 49: ECAT_DPM_SET_IO_SIZE_CNF_T – Set IO Size confirmation packet ............................................................ 71
Table 50: ECAT_DPM_SET_STATION_ALIAS_REQ_T – Set Station Alias request packet ............................................... 72
Table 51: ECAT_DPM_SET_STATION_ALIAS_CNF_T – Set Station Alias confirmation packet ....................................... 73
Table 52: ECAT_DPM_GET_STATION_ALIAS_REQ_T – Get Station Alias request packet ............................................. 74
Table 53: ECAT_DPM_GET_STATION_ALIAS_CNF_T - Get Station Alias confirmation packet ........................................ 75
Table 54: Overview over the EtherCAT State Machine related packets of the EtherCAT Slave stack .............................. 76
Table 55: ECAT_ESM_REGISTER_FOR_ALCONTROL_INDICATIONS_REQ_T – Register For AL Control Changed
Indications request packet ....................................................................................................................................... 77
Table 56: ECAT_ESM_REGISTER_FOR_ALCONTROL_INDICATIONS_CNF_T – Register For AL Control Changed
Indications confirmation packet ............................................................................................................................... 78
Table 57: ECAT_ESM_UNREGISTER_FROM_ALCONTROL_INDICATIONS_REQ_T – Unregister from AL Control Changed
Indications request packet ....................................................................................................................................... 79
Table 58: ECAT_ESM_UNREGISTER_FROM_ALCONTROL_INDICATIONS_CNF_T – Unregister From AL Control Changed
Indications confirmation packet ............................................................................................................................... 80
Table 59: Coding of EtherCAT state ................................................................................................................................. 81
Table 60: ECAT_ESM_ALCONTROL_CHANGED_IND_T – AL Control Changed indication packet ...................................... 83
Table 61: ECAT_ESM_ALCONTROL_CHANGED_RES_T – AL Control Changed response packet ...................................... 84

EtherCAT Slave V5 | Protocol API

DOC181005API01EN | Revision 1| English | 2019-04 | Released | Public © Hilscher, 2018-2019
Appendix 125/127
Table 62: Variable uState of Structure ECAT_ALSTATUS_T........................................................................................... 85
Table 63: ECAT_ESM_ALSTATUS_CHANGED_IND_T – AL Status Changed indication packet ......................................... 86
Table 64: ECAT_ESM_ALSTATUS_CHANGED_RES_T – AL Status Changed response packet.......................................... 87
Table 65: ECAT_ESM_SET_ALSTATUS_REQ_T – Set AL Status request packet ............................................................. 89
Table 66: ECAT_ESM_SET_ALSTATUS_CNF_T – Set AL Status confirmation packet....................................................... 89
Table 67: ECAT_ESM_GET_ALSTATUS_REQ_T – Get AL Status request packet .............................................................. 90
Table 68: ECAT_ESM_GET_ALSTATUS_CNF_T – Get AL Status confirmation packet ...................................................... 91
Table 69: Overview over the CoE packets of the EtherCAT Slave stack .......................................................................... 92
Table 70: Bit Mask bErrorRegister ............................................................................................................................. 92
Table 71: ECAT_COE_SEND_EMERGENCY_REQ_T – Send CoE Emergency request packet ........................................... 93
Table 72: ECAT_COE_SEND_EMERGENCY_CNF_T – Send CoE Emergency confirmation packet ..................................... 94
Table 73: Overview over the SII packets of the EtherCAT Slave stack ............................................................................. 95
Table 74: ECAT_ESM_SII_READ_REQ_T – SII Read request packet............................................................................... 95
Table 75: ECAT_ESM_SII_READ_CNF_T – SII Read confirmation packet ....................................................................... 96
Table 76: ECAT_ESM_SII_WRITE_REQ_T – SII Write request packet ........................................................................... 97
Table 77: ECAT_ESM_SII_WRITE_CNF_T – SII Write confirmation packet ..................................................................... 98
Table 78: ECAT_ESM_REGISTER_FOR_SIIWRITE_INDICATIONS_REQ_T – Register for SII Write Indications request
packet ...................................................................................................................................................................... 99
Table 79: ECAT_ESM_REGISTER_FOR_SIIWRITE_INDICATIONS_CNF_T – Register For SII Write Indications
confirmation packet................................................................................................................................................ 100
Table 80: ECAT_ESM_UNREGISTER_FROM_SIIWRITE_INDICATIONS_REQ_T – Unregister from SII Write Indications
request packet ....................................................................................................................................................... 101
Table 81: ECAT_ESM_UNREGISTER_FROM_SIIWRITE_INDICATIONS_CNF_T – Unregister from SII Write Indications
confirmation packet................................................................................................................................................ 102
Table 82: ECAT_ESM_SII_WRITE_IND_T – SII Write Indication packet ....................................................................... 104
Table 83: ECAT_ESM_SII_WRITE_RES_T – SII Write response packet ........................................................................ 104
Table 84: Tag list parameter ........................................................................................................................................... 106
Table 85: Diagnostic codes of the ESM component (Base component) ......................................................................... 107
Table 86: Status / error codes of ECAT_SET_CONFIG_REQ ........................................................................................ 108
Table 87: Status / error codes of the ESM (Base component) ........................................................................................ 108
Table 88: Status / error codes of the MBX (Base component) ........................................................................................ 108
Table 89: Status / error codes of the CoE component .................................................................................................... 110
Table 90: Status / error codes of the DPM ...................................................................................................................... 110
Table 91: Status / error codes of the EoE ....................................................................................................................... 111
Table 92: Supported AL status codes ............................................................................................................................. 113
Table 93: Vendor-specific AL status codes ..................................................................................................................... 113
Table 94: CoE Emergencies codes ................................................................................................................................. 114
Table 95: Error LED status .............................................................................................................................................. 115
Table 96: SDO Abort codes: Error class ......................................................................................................................... 116
Table 97: SDO Abort Codes............................................................................................................................................ 117
Table 98: Correspondence of SDO Abort codes and status / error codes ...................................................................... 119

EtherCAT Slave V5 | Protocol API

9.4 List of figures

Figure 1: Use case: Loadable Firmware ........................................................................................................................... 10
Figure 2: Set Configuration / Channel Init ......................................................................................................................... 13
Figure 3: Structure of EtherCAT Slave stack..................................................................................................................... 17
Figure 4: State Diagram of EtherCAT State Machine (ESM)............................................................................................. 19
Figure 5: Sequence diagram of state change with indication to application/host .............................................................. 20
Figure 6: Sequence diagram of EtherCAT state change controlled by application/host .................................................... 21
Figure 7: Sequence diagram of state change controlled by application/host with additional AL Status Changed indications
................................................................................................................................................................................ 22
Figure 8: PDO Mapping..................................................................................................................................................... 32
Figure 9: Sequence within the application ......................................................................................................................... 37
Figure 10: Initialization sequence with placing of registrations and object dictionary creation .......................................... 38
Figure 11: Initialization sequence for Explicit Device Identification ................................................................................... 39
Figure 12: SDO download with Complete Access (successful) ......................................................................................... 43
Figure 13: Dynamic PDO assignment: One application registered for write indications (successful) ................................ 46
Figure 14: Dynamic PDO assignment: One application registered for write indications (not successful) .......................... 48
Figure 15 Dynamic PDO assignment: One application registered for write indications, successful (Complete Access) ... 49
Figure 16: Send CoE Emergency service ......................................................................................................................... 92
Figure 17: SII Write Indication service ............................................................................................................................. 103

EtherCAT Slave V5 | Protocol API

9.5 Contacts

Headquarters

Germany
Hilscher Gesellschaft für
Systemautomation mbH
Rheinstrasse 15
65795 Hattersheim
Phone: +49 (0) 6190 9907-0
Fax: +49 (0) 6190 9907-50
E-Mail: [email protected]
Support
Phone: +49 (0) 6190 9907-99
E-Mail: [email protected]

Subsidiaries

China Japan
Hilscher Systemautomation (Shanghai) Co. Ltd. Hilscher Japan KK
200010 Shanghai Tokyo, 160-0022
Phone: +86 (0) 21-6355-5161 Phone: +81 (0) 3-5362-0521
E-Mail: [email protected] E-Mail: [email protected]
Support Support
Phone: +86 (0) 21-6355-5161 Phone: +81 (0) 3-5362-0521
E-Mail: [email protected] E-Mail: [email protected]

France Korea
Hilscher France S.a.r.l. Hilscher Korea Inc.
69500 Bron Seongnam, Gyeonggi, 463-400
Phone: +33 (0) 4 72 37 98 40 Phone: +82 (0) 31-789-3715
E-Mail: [email protected] E-Mail: [email protected]
Support
Phone: +33 (0) 4 72 37 98 40 Switzerland
E-Mail: [email protected] Hilscher Swiss GmbH
4500 Solothurn
India Phone: +41 (0) 32 623 6633
Hilscher India Pvt. Ltd. E-Mail: [email protected]
Pune, Delhi, Mumbai Support
Phone: +91 8888 750 777 Phone: +49 (0) 6190 9907-99
E-Mail: [email protected] E-Mail: [email protected]

Italy USA
Hilscher Italia S.r.l. Hilscher North America, Inc.
20090 Vimodrone (MI) Lisle, IL 60532
Phone: +39 02 25007068 Phone: +1 630-505-5301
E-Mail: [email protected] E-Mail: [email protected]
Support Support
Phone: +39 02 25007068 Phone: +1 630-505-5301
E-Mail: [email protected] E-Mail: [email protected]

EtherCAT Slave V5 | Protocol API

AW46 - VS5 Service Manual - 5396255-100 - r4 - A4
0% (1)
AW46 - VS5 Service Manual - 5396255-100 - r4 - A4
262 pages
Slave Information: Specification
No ratings yet
Slave Information: Specification
99 pages
ACS550 User Manual
No ratings yet
ACS550 User Manual
320 pages
ETG2010 S R V1i0i0 EtherCATSIISpecification
No ratings yet
ETG2010 S R V1i0i0 EtherCATSIISpecification
15 pages
CANopen Blockset Eng
No ratings yet
CANopen Blockset Eng
30 pages
Honor 9 Lite PDF SCHEMATIC
100% (1)
Honor 9 Lite PDF SCHEMATIC
68 pages
Status Console Schematic Drawings: First Edition
No ratings yet
Status Console Schematic Drawings: First Edition
39 pages
CP-series Function Block Practices Guide
No ratings yet
CP-series Function Block Practices Guide
30 pages
SSD1325 2.1 PDF
No ratings yet
SSD1325 2.1 PDF
61 pages
Nvis 5585A: Scope of Learning Features
100% (1)
Nvis 5585A: Scope of Learning Features
1 page
ETG1500 V1i0i2 D R MasterClasses
No ratings yet
ETG1500 V1i0i2 D R MasterClasses
31 pages
Canopen Interface Technical Reference Manual: For Encoder Products Company'S Absolute Encoders
No ratings yet
Canopen Interface Technical Reference Manual: For Encoder Products Company'S Absolute Encoders
52 pages
Certkitiec Ug
100% (1)
Certkitiec Ug
112 pages
EtherCAT Diagnosis For Users
No ratings yet
EtherCAT Diagnosis For Users
38 pages
SUPMETER BST100 B11 B21 v3 6 EN
No ratings yet
SUPMETER BST100 B11 B21 v3 6 EN
75 pages
Fuzzy Based Reconfigurable Controller For BLDC Motor
No ratings yet
Fuzzy Based Reconfigurable Controller For BLDC Motor
7 pages
Mechatronic Engineering
No ratings yet
Mechatronic Engineering
17 pages
ENG 32bit Micro Controller ARM7 LPC2148 Manual
100% (2)
ENG 32bit Micro Controller ARM7 LPC2148 Manual
109 pages
Es582.1 Ug en
No ratings yet
Es582.1 Ug en
40 pages
TM4C123G LaunchPad Workshop Workbook
No ratings yet
TM4C123G LaunchPad Workshop Workbook
336 pages
Automotive Embedded Systems Toc
No ratings yet
Automotive Embedded Systems Toc
3 pages
Development of Hardware-In-The-loop Simulation System For Electri
No ratings yet
Development of Hardware-In-The-loop Simulation System For Electri
83 pages
PCB Footprint Expert Output To Xpedition
No ratings yet
PCB Footprint Expert Output To Xpedition
11 pages
Vxworks Cli Tools Users Guide 6.2
No ratings yet
Vxworks Cli Tools Users Guide 6.2
100 pages
Ksj Ethercat Fpga Master 【Introduction】
No ratings yet
Ksj Ethercat Fpga Master 【Introduction】
4 pages
Simulink Coder™ Release Notes
No ratings yet
Simulink Coder™ Release Notes
84 pages
XLR UserGuide
No ratings yet
XLR UserGuide
209 pages
Emulation of Automotive Communication Protocol Single Edge Nibble Transmission (SENT) Using Aurix Family of Microcontrollers
No ratings yet
Emulation of Automotive Communication Protocol Single Edge Nibble Transmission (SENT) Using Aurix Family of Microcontrollers
4 pages
Electronics 09 01494 With Cover
No ratings yet
Electronics 09 01494 With Cover
45 pages
CCA163 - PowerFlex 700 Maintenance and Troubleshooting
No ratings yet
CCA163 - PowerFlex 700 Maintenance and Troubleshooting
2 pages
Robot Programming in "C": Tak Auyeung, Ph.D. February 15, 2006
No ratings yet
Robot Programming in "C": Tak Auyeung, Ph.D. February 15, 2006
160 pages
Codesys Motion
No ratings yet
Codesys Motion
12 pages
Maab Styleguide PDF
No ratings yet
Maab Styleguide PDF
110 pages
Types of Automotive Braking Systems: Brake Components
No ratings yet
Types of Automotive Braking Systems: Brake Components
5 pages
STM32F7xxx - Hardware Development PDF
No ratings yet
STM32F7xxx - Hardware Development PDF
54 pages
E94A - Servo Drives 9400 HighLine - v11-0 - EN PDF
No ratings yet
E94A - Servo Drives 9400 HighLine - v11-0 - EN PDF
644 pages
Front Axle - Steering Geometry
0% (1)
Front Axle - Steering Geometry
50 pages
Gate Driver Design - From Basics To Details: Wei Zhang
No ratings yet
Gate Driver Design - From Basics To Details: Wei Zhang
33 pages
Industrial Networks Connecting Controllers Via OPC: Master's Thesis
No ratings yet
Industrial Networks Connecting Controllers Via OPC: Master's Thesis
93 pages
Beckhoff El5021
No ratings yet
Beckhoff El5021
40 pages
KACO Blueplanet 150 TL3
No ratings yet
KACO Blueplanet 150 TL3
115 pages
ControlDeskIntroductionAndOverview 5c9cfe49 A7c6 4205 8df0 C317b9a28dea
No ratings yet
ControlDeskIntroductionAndOverview 5c9cfe49 A7c6 4205 8df0 C317b9a28dea
206 pages
White Paper On Hybrid Approach For ADAS Data Fusion Algorithm Development
No ratings yet
White Paper On Hybrid Approach For ADAS Data Fusion Algorithm Development
15 pages
WR VX Simulator Users Guide 6.1
No ratings yet
WR VX Simulator Users Guide 6.1
114 pages
AUTOSAR PRS SOMEIPServiceDiscoveryProtocol
No ratings yet
AUTOSAR PRS SOMEIPServiceDiscoveryProtocol
74 pages
Energies 17 01696
No ratings yet
Energies 17 01696
39 pages
ACS800 SystemControlProgram FW
No ratings yet
ACS800 SystemControlProgram FW
318 pages
KR 6 16 en
No ratings yet
KR 6 16 en
144 pages
Atmel 8390 WIRELESS AVR2054 Serial Bootloader User Guide Application Note
100% (1)
Atmel 8390 WIRELESS AVR2054 Serial Bootloader User Guide Application Note
23 pages
Osek Os: Session Speaker Deepak V
No ratings yet
Osek Os: Session Speaker Deepak V
60 pages
Display Connection Simulator
No ratings yet
Display Connection Simulator
25 pages
C1373
No ratings yet
C1373
3 pages
Pepper Fuchs Asi PDF
No ratings yet
Pepper Fuchs Asi PDF
192 pages
RAX711-C-R: Raisecom Technology Co., LTD
No ratings yet
RAX711-C-R: Raisecom Technology Co., LTD
6 pages
EtherCAT ET1200 Datasheet All V1i7
No ratings yet
EtherCAT ET1200 Datasheet All V1i7
271 pages
Full download Embedded Software The Works 1st edition Edition Colin Walls pdf docx
No ratings yet
Full download Embedded Software The Works 1st edition Edition Colin Walls pdf docx
55 pages
An Online Battery Impedance Measurement Method Using DCDC Power Converter Control
No ratings yet
An Online Battery Impedance Measurement Method Using DCDC Power Converter Control
9 pages
Smart Health Monitoring System
No ratings yet
Smart Health Monitoring System
6 pages
Manual Axpert KING PYLON
No ratings yet
Manual Axpert KING PYLON
59 pages
Thomson Electrac HD Linear Actuator Motion Control per CAN Bus
From Everand
Thomson Electrac HD Linear Actuator Motion Control per CAN Bus
Wilfried Voss
No ratings yet
DeviceNet The Ultimate Step-By-Step Guide
From Everand
DeviceNet The Ultimate Step-By-Step Guide
Gerardus Blokdyk
No ratings yet
ISO 31-0 Standard Requirements
From Everand
ISO 31-0 Standard Requirements
Gerardus Blokdyk
No ratings yet
EtherCAT Master V4 Protocol API 02 EN 4
No ratings yet
EtherCAT Master V4 Protocol API 02 EN 4
240 pages
Ethercat For Factory Networking: Ethercat Automation Protocol (Eap)
No ratings yet
Ethercat For Factory Networking: Ethercat Automation Protocol (Eap)
23 pages
Netx 90 - Production Guide PG 03 EN
No ratings yet
Netx 90 - Production Guide PG 03 EN
70 pages
NetX Studio CDT - NetX 90 Development OI 01 en
No ratings yet
NetX Studio CDT - NetX 90 Development OI 01 en
298 pages
NetX Studio CDT - NetX 90 Development GS 08 en
No ratings yet
NetX Studio CDT - NetX 90 Development GS 08 en
220 pages
MXConfigurator
No ratings yet
MXConfigurator
550 pages
Pranav Mistry - Innovator of Sixth Sense Technology - Technology That Makes Sense
No ratings yet
Pranav Mistry - Innovator of Sixth Sense Technology - Technology That Makes Sense
4 pages
Description Activity
No ratings yet
Description Activity
1 page
On Memory
No ratings yet
On Memory
34 pages
Embedded System Unit V (Prepared by N.Shanmugasundaram)
71% (7)
Embedded System Unit V (Prepared by N.Shanmugasundaram)
18 pages
BR700
No ratings yet
BR700
2 pages
RS232 Quick Guide: EIA/TIA-232-F Standard
No ratings yet
RS232 Quick Guide: EIA/TIA-232-F Standard
2 pages
DC 330 Component Control List
No ratings yet
DC 330 Component Control List
2 pages
Snapdragon 615 Processor Product Brief
No ratings yet
Snapdragon 615 Processor Product Brief
2 pages
Simulating Oracle I/O Workloads To Configure Storage: James F. Koopmann Nocoug Fall Conference 2007 4:00 - 5:00
No ratings yet
Simulating Oracle I/O Workloads To Configure Storage: James F. Koopmann Nocoug Fall Conference 2007 4:00 - 5:00
70 pages
TV - LAPTOP - PHONE - Haier Fault Code Trascoding - EN - v3
No ratings yet
TV - LAPTOP - PHONE - Haier Fault Code Trascoding - EN - v3
6 pages
Install
No ratings yet
Install
1 page
Holy Mary Institute of Technology and Science (: Affiliated To JNTU Hyderabad) Bogaram (V), Keesara (M), Medchal (D) - 501 301
No ratings yet
Holy Mary Institute of Technology and Science (: Affiliated To JNTU Hyderabad) Bogaram (V), Keesara (M), Medchal (D) - 501 301
12 pages
Software Manual V2.6 - English (ICON100)
No ratings yet
Software Manual V2.6 - English (ICON100)
53 pages
3 Design Challenges, 05-01-2024
No ratings yet
3 Design Challenges, 05-01-2024
74 pages
Traffic Light Controller
No ratings yet
Traffic Light Controller
16 pages
Axi4-Stream Infrastructure Ip Suite V3.0: Logicore Ip Product Guide
No ratings yet
Axi4-Stream Infrastructure Ip Suite V3.0: Logicore Ip Product Guide
83 pages
Running Head: The Evolution of The Iphone 1
No ratings yet
Running Head: The Evolution of The Iphone 1
8 pages
Nano 8050
No ratings yet
Nano 8050
1 page
DS18B20 Programmable Resolution 1-Wire Digital Thermometer: Features Pin Assignment
No ratings yet
DS18B20 Programmable Resolution 1-Wire Digital Thermometer: Features Pin Assignment
27 pages
Cisco UCS 101: Installation and Basic Config: Speak
No ratings yet
Cisco UCS 101: Installation and Basic Config: Speak
31 pages
Pid20a Pid20c Pid30a Pid30c Pid20c Pid30c Pid30a Pid20a: MCBSTM32F200/F400
No ratings yet
Pid20a Pid20c Pid30a Pid30c Pid20c Pid30c Pid30a Pid20a: MCBSTM32F200/F400
15 pages
IT - 4201, HCI, Lecture - 2
No ratings yet
IT - 4201, HCI, Lecture - 2
50 pages
Ipa15 e 054
No ratings yet
Ipa15 e 054
10 pages
NetBackup 7x 8x in Virtual Environments
No ratings yet
NetBackup 7x 8x in Virtual Environments
41 pages
Game
No ratings yet
Game
14 pages