Communication methods

The TwinCAT EAP device supports two communication types: cyclic process data communication (EtherCAT type 4), and acyclic EtherCAT mailbox communication (EtherCAT type 5). For mailbox communication, the TwinCAT EAP device only supports the AoE protocol (AoE – ADS over EtherCAT). The specification of the AoE protocol is described in the EtherCAT Protocol Enhancements (ETG 1020). For process data communication, a distinction is made between two communication modes:

Pushed Data Exchange mode, in which an EAP sender sends its process information to the network either cyclically or when a change in status is detected, and an EAP receiver expects this process information and receives it accordingly. This mode corresponds to the Publisher/Subscriber principle of the network variables (NWV) of TwinCAT 2.
Polled Data Exchange mode, in which an EAP client sends a request telegram with its process information to an EAP server, which then sends its process information back to the EAP client in a response telegram.

In addition, the TwinCAT EAP device supports different connection types and different addressing modes during process data communication. The supported connection types are:

Unicast: The EAP message is sent from one end point to another end point, in other words: the message is addressed to precisely one PC.
Multicast: The EAP message is sent from one end point to several other end points, in other words: the message is addressed to a group of PCs.
Broadcast: The EAP message is sent from one end point to all accessible end points, in other words: the message is addressed to all devices.

MAC addresses, AMS NetIDs or IP addresses can be used. Depending on the configuration of the connection type and the addressing mode, a particular network protocol is activated for the EAP process data communication. The exact assignment is shown in the following table.

Network protocols
Addressing mode Connection type	MAC address	AMS NetID	IP Address
Unicast	Ethernet protocol	Ethernet protocol	UDP/IP
Multicast	Ethernet protocol	Not possible	UDP/IP
Broadcast	Ethernet protocol	Not possible	UDP/IP

Depending on the different addressing modes (MAC, AMS NetID and IP), the connection types’ unicast, multicast and broadcast are supported as follows:

MAC addressing:
The EAP message is transferred based on the Ethernet protocol. The MAC address of the network adapter that is to receive the message is configured as destination address. With this addressing mode, the EAP message cannot be relayed from a router to another subnet, since it operates based on IP addresses. The message can therefore only be sent within a subnet via switches.

Broadcast and multicast

Special MAC addresses are reserved for a broadcast or multicast message:

Broadcast MAC: FF-FF-FF-FF-FF-FF

Multicast MAC: A multicast MAC address must meet the following conditions.

The lowest-order bit (bit 1) of the first byte has the value 1 (group bit).

The following bit 2 has the value 0, if the MAC address is globally unique;
or the value 1, if the address is only locally unique.

The first 24 bits (bits 3 to 24) correspond to the manufacturer ID, referred to as Organizationally Unique Identifier (OUI). The OUI for Beckhoff is "00-01-05".

The remaining 24 bits (bits 25 to 48) can be specified individually for each interface. The sequence "04-00-00" is defined for the EtherCAT Automation Protocol.

The resulting standard multicast MAC address for TwinCAT EAP devices is 01:01:05:04:00:00.

AMS NetID addressing:
The EAP message is transferred based on a type 4 EtherCAT protocol (EAP). The required target MAC address is determined based on the Address Resolution Protocol (ARP) and the configured AMS NetID. As with MAC addressing, the EAP message can only be sent within the subnet.

Communication via AMS NetID

Using an AMS NetID as destination address has the advantage that it is a logical address. The MAC address of the target device is determined with the aid of a special ARP request, using the configured AMS NetID.

The configuration of an EAP connection does not have to be adapted, even if a control computer or a network adapter of a computer is replaced, resulting in a change of MAC address, for example. The only condition is that the new control computer is assigned the original AMS NetID.

If the connection type Unicast is configured, the Subscriber Monitoring mechanism is also configured by default (see Remote station monitoring via ARP).

IP addressing:
For the EAP message, the Internet protocol (IP) is used in conjunction with the User Datagram Protocol (UDP) for relaying and addressing of the recipient. The required destination MAC address is determined based on the Address Resolution Protocol (ARP) and the configured IP address. With UDP/IP addressing, a router can relay the EAP message to other subnets (including the internet, for example).

Special IP addresses are reserved for a broadcast or multicast message:

Broadcast IP: 255.255.255.255 is specified as broadcast IP address. The broadcast MAC address FF-FF-FF-FF-FF-FF is derived directly from this IP address.

Multicast IP: A multicast IP address must be in the range 224.0.0.0 to 239.255.255.255 (IPv4). In the EAP device, TwinCAT generates a compliant multicast MAC address for each configured multicast IP address, which is used when TwinCAT starts up (i.e. when the Run mode is activated).

Pushed Data Exchange (n:m connection)

The Pushed Data Exchange mode is based on the same model as the NWV transfer (Publisher/Subscriber principle). It offers the option of an n:m connection in a network. Each EAP device can send one or several EAP telegrams, together with its output process data (TxData). Each EAP device can “listen” to ascertain whether the process data contained in a received EAP telegram match its input process data (RxData), so that they can be processed, if applicable. One and the same EAP device can therefore send and receive process data. In this way a bidirectional communication can be established.

With Pushed Data Exchange, the addressing mode (unicast, multicast or broadcast) for each configured EAP telegram can be freely selected as required.

Polled Data Exchange (1:1 connection)

The Polled Data Exchange mode is subject to the client/server architecture principle. With the aid of this architecture, it enables “soft” synchronization. An EAP device can act as client and server at the same time.

Connection type for Polled mode

For the Polled Data Exchange mode, only the connection type unicast is defined uniquely.

Unicast (1:1 connection)
A client sends an EAP telegram together with its output process data to a server, which then returns its input process data to the client in a separate EAP telegram.

Network protocols

Ethernet protocol
The Ethernet protocol is responsible for switching the data packets in the network. It handles the tasks of OSI layers 1 and 2 (physical layer and data link layer). The Ethernet protocol header should contain a sender address, a receiver address and an Ethernet type, which specifies which protocol is used for the next higher OSI layer. The sender and receiver addresses are entered in the form of a MAC address. MAC stands for media access control and in this case refers to the unique hardware address assigned to each Ethernet device during production. The Ethernet port of a Beckhoff PC could be assigned the MAC address 00:01:05:34:05:84, for example; "00:01:05" is the Beckhoff ID, and the second part is specified during production. The sender and receiver MAC addresses determine the route of each Ethernet telegram between two PCs in the network. An Ethernet telegram can be processed further via a switch, but usually not via a router.

User Datagram Protocol / Internet Protocol (UDP/IP)
The receiver is identified via an additional IP header in the Ethernet telegram, so that it can be processed further by a router. The telegram has the Ether type 0x0800, which specifies that it is an IP telegram. In the subsequent UDP header, the port number 0x88A4 is used for the source port as well as the destination port. Based on this port number, the TwinCAT system detects that the telegram is a real-time based user datagram.

TwinCAT identifies an EAP telegram either on the basis of Ether type 0x88A4 (if the Ethernet protocol is used) or on the basis of the destination port 0x88A4 (for UDP/IP). Accordingly, the TwinCAT Ethernet driver makes a received EAP telegram bypass the NDIS stack of the operating system, so that TwinCAT treats it preferentially as a Beckhoff real-time Ethernet telegram. When an EAP telegram is sent, the NDIS stack of the operating system is also bypassed.
Once an EAP telegram has been received by a TwinCAT PC and identified as such, during further processing of the telegram the process data (PD) transported in the telegram are assigned to the RxData configured in the EAP device. This assignment is based on the PD ID. The received PD is discarded, if no RxData with matching PD ID were configured at the receiver.

Finally, the values of the individual process variables (PV) of a PD are only applied if, in addition, the data length and the version number of the received PD match the expected data length and version number.