Slave Configuration

The application has to tell the master about the expected bus topology. This can
be done by creating \slave con gurations". A slave con guration can be seen as an
expected slave. When a slave con guration is created, the application provides the
bus position (see below), vendor id and product code.
When the bus con guration is applied, the master checks, if there is a slave with
the given vendor id and product code at the given position. If this is the case,
the slave con guration is \attached" to the real slave on the bus and the slave is
con gured according to the settings provided by the application. The state of a slave
con guration can either be queried via the application interface or via the command-
line tool (see sec. 7.1.3).

Slave Position The slave position has to be speci ed as a tuple of \alias" and
\position". This allows addressing slaves either via an absolute bus position, or a
stored identi er called \alias", or a mixture of both. The alias is a 16-bit value stored
in the slave's E2PROM. It can be modi ed via the command-line tool (see sec. 7.1.2).
Table 3.1 shows, how the values are interpreted.
Table 3.1: Specifying a Slave Position
Alias Position Interpretation
0 0 { 65535 Position addressing. The position pa-
rameter is interpreted as the absolute
ring position in the bus.
1 { 65535 0 { 65535 Alias addressing. The position param-
eter is interpreted as relative position
after the rst slave with the given alias
address.
Figure 3.2 shows an example of how slave con gurations are attached. Some of the
con gurations were attached, while others remain detached. The below lists gives the
reasons beginning with the top slave con guration.
1. A zero alias means to use simple position addressing. Slave 1 exists and vendor
id and product code match the expected values.
2. Although the slave with position 0 is found, the product code does not match,
so the con guration is not attached.

3. The alias is non-zero, so alias addressing is used. Slave 2 is the rst slave with
alias 0x2000. Because the position value is zero, the same slave is used.
4. There is no slave with the given alias, so the con guration can not be attached.
5. Slave 2 is again the rst slave with the alias 0x2000, but position is now 1, so
slave 3 is attached.

VoE Handlers

During the con guration phase, the application can create handlers for the VoE mail-
box protocol described in sec. 6.3. One VoE handler always belongs to a certain slave
con guration, so the creation function is a method of the slave con guration.
A VoE handler manages the VoE data and the datagram used to transmit and receive
VoE messages. Is contains the state machine necessary to transfer VoE messages.

The VoE state machine can only process one operation at a time. As a result, either
a read or write operation may be issued at a time1. After the operation is initiated,
the handler must be executed cyclically until it is nished. After that, the results of
the operation can be retrieved.
A VoE handler has an own datagram structure, that is marked for exchange after each
execution step. So the application can decide, how many handlers to execute before
sending the corresponding EtherCAT frame(s).
For more information about the use of VoE handlers see the documentation of the
application interface functions and the example applications provided in the examples/
directory.