Basic principles

Structure of an EAP Publisher

An EAP Publisher consists of a number of nested elements, as illustrated in the following illustration. The basic element at the lowest level is a Tx variable. It defines an output variable, which is linked to a process variable and has several further properties, such as a data type. The data type can be freely selected; it may be a complex data type, with a size of several hundred bytes. The only condition is that the maximum size of an EAP frame is not exceeded (the size of an EAP frame corresponds to that of a standard Ethernet frame). During operation, the process variable provides the values to be sent by the Publisher.

At the next higher level, TxVariables are referenced in the TxPDO elements (TxPDO = TxProcessDataObjects). A TxPDO can reference several TxVariables, thereby consolidating them in an object. The TxPDO then defines an ordered set of TxVariables. The condition that the maximum size of an EAP frame must not be exceeded also applies to a TxPDO.

The TxData element (TxProcessData = TxPD) is located at the next higher level. It represents a Publisher variable and is understood as communication unit of the Publisher in EAP. The TxData element references a certain TxPDO and defines a number of properties, such as the ID of the Publisher variable, their version and the clock cycle, based on which the Publisher variable is sent in the first place. Based on these properties, the Publisher variable defines an object on the sender side, for which a suitable Subscriber variable must be defined on the receiver side, so that successful data exchange can take place.

The data transfer takes place network-based via the Ethernet protocol or via UDP/IP. Similarly, a TxFrame is then assigned a list of TxData, which are to be sent to the same destination address. A TxFrame is limited to a maximum data length per data packet. For sending a Publisher variable, at least the following properties must be defined:

Destination address:
The destination address is usually a multicast address, so that the Publisher variable is automatically sent to a group of receivers. It is also possible to enter the address of an individual receiver.

ID:
For each Publisher variable a number is defined, which must be unique across the network. Based on this number, the Publisher variable can be identified by a Subscriber.

Clock cycle:
The clock cycle defines the interval at which the Publisher variable is sent. EAP cycle times generally range between a few milliseconds up to several 100 milliseconds.

Link to a process variable:
Last but not least, a link between the Publisher variable and a process variable is required, to ensure that process data are actually sent with the aid of the Publisher variable. Otherwise the value of the Publisher variable would always remain zero.

Structure of an EAP Subscriber

The structure of an EAP Subscriber is analogous to that of a Publisher and is illustrated in the following illustration. The basic element at the lowest level of a Subscriber is referred to as RxVariable. The RxVariable defines an input variable, which is also linked to a process variable and contains several properties, such as the data type. During operation, the process variable obtains the values, which the Subscriber receives.

Accordingly, the elements at the level above are referred to as RxPDOs (RxProcessDataObjects). Each element defines an ordered set of RxVariables.

The RxData element (RxProcessData = RxPD) is located at the next higher level. It represents a Subscriber variable and is understood as communication unit of the Subscriber in EAP. The RxData element references a certain RxPDO and defines the required properties (ID and version), which must match the Publisher variable to be received. For a successful data exchange, the data types of the referenced RxVariable and its order in the RxPDO must be identical to the TxPDO of the Publisher variable. The Subscriber variable thus defines an object on the receiving side, for which a matching Publisher variable must be defined on the sender side, in order for data exchange to take place.

Due to the design of the EtherCAT Automation Protocol, for a Subscriber it is irrelevant from which sender the received data originate. In particular, it is irrelevant which Publisher variables are sent within a frame. For this reason the Subscriber has no frame element or similar, which would consolidate certain Subscriber variables as a unit, so that they would only be received en bloc. Nevertheless, RxData offers an option to define an AMS NetID as a filter address, in cases where a Subscriber should only receive the Publisher variables of a certain sender. In this case, at least the following properties must be defined for a Subscriber variable:

ID:
The ID of a Subscriber variable defines which Publisher variable should receive it. The ID is a number, which should be unique for each Publisher variable across the whole network. It is used to identify the Publisher variable at the receiving end.

Link to a process variable:
Finally, using a Subscriber variable only makes sense if it is linked to a process variable. Only then will the received data actually be applied by the process variable and taken into account in the machine control.