Beckhoff Network Variables - Settings - Beckhoff CU2508 Documentation

Commissioning
Fig. 77: Incrementing of the CycleIndex variables
4.3.4

Beckhoff network variables - Settings

Beckhoff network variables (NWV) can be used for cyclic or acyclic sending of data between Windows-based
PCs. In a device declared as a publisher (sender), such a network variable is received on the other side by a
subscriber declared as the same type. As the name suggests, this data traffic is network-based, and the
configuration is directly based on the protocols used.
A choice of two protocols is available:
• MAC: An ISO Layer 2 frame is sent with a sender and receiver MAC address, Ethertype 0x0806. An IP
part with the destination IP address (e.g. 192.168.0.1) is not included. The telegram can therefore be
further processed via a switch, but usually not via a router.
MAC stands for media access control and in this case refers to the (unique) hardware address
assigned to each Ethernet device during production. For example, the Ethernet port of a Beckhoff PC
might have the MAC ID 00:01:05:34:05.84, with "00:01:05" representing the Beckhoff ID and the rest
assigned during production. The route of each Ethernet telegram between two Ethernet cable ends is
determined by the source MAC and the destination MAC.
The Ethernet telegram is identified as Beckhoff real-time Ethernet by the Ethertype 0x88A4. As a real-
time Ethernet telegram (RT Ethernet) it bypasses the regular Windows TCP stack and is sent with
higher priority, i.e. "immediately", via the specified Ethernet port of the PC.
An option is available for configuring whether the sent telegram is received by all (broadcast), many
(multicast) or a single subscriber (unicast).
• UDP/IP: The recipient is identified via an additional IP header in the Ethernet telegram. The UDP
Ethernet frame can thus be further processed via a router.
Once again, broadcast, multicast and unicast are available as options. The Ethernet telegram is
identified as Beckhoff real-time Ethernet through the Ethertype 0x88A4 and treated as an RT protocol
in the TwinCAT PC.
In contrast to TCP, as a connection-less protocol UDP requires no acknowledgement of receipt for the
message, i.e. the publisher does not know whether the subscriber has received the message. The ARP
protocol [} 60] is therefore used for remote terminal monitoring in TwinCAT.
The telegram with the process data arrives at the recipient device (network port) via these addressing
modes. In the Ethernet device/TwinCAT several transported process data are allocated via a variable ID
56 Version: 2.6 Real-time Ethernet port multiplier