Commissioning
EL6601, EL6614
105
Version: 4.2
5.4.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 sample, 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
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
All network variables must be declared in the System Manager before they can be used.
The following intervention options are then available during operation:
• Sending of a configured network variable can be blocked dynamically
• The destination IP or destination MAC can be changed dynamically
• The variable ID "variable ID" can be changed dynamically
• The NWV content can be changed, but not the size (bit size)
Diagnostic variables on the publisher and subscriber side provide information about the connection quality.
If network variables are used, the temporal boundary conditions for the network topology used must be taken
into account: in the case of IP addressing (routed) on a case-by-case basis several 100 ms communications
cycle can be achieved, in the case of MAC addressing (switched) approximately 10 ms and less.
Diagnostic variable "quality"
If the processing tasks operate with different cycle times or the user changes the DataExchangeDi-
vider, this must be taken into account in the analysis of the diagnostic variables. In conjunction with
a fast Subscriber (e.g. 10 ms), a slow Publisher (e.g. 100 ms) leads to poor connection quality (as
reported by the diagnostic variable "Quality").
Dynamic temporary blocking of sending a Publisher must also be taken into account. In this case
the Subscriber registers poor quality.
Diagnostic variable "CycleIndex"
Please note the following information in order to decide whether you have to serve the variable Cy-
cleIndex.
