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 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 switched mode (MAC addressing) communication cycles of approx. 10 ms and below can be achieved, in routed mode (IP addressing) a few 100 ms may be achievable in some cases.

	Diagnostic variable "quality" If the processing tasks operate with different cycle times or the user changes the DataExchangeDivider, 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 CycleIndex.

Basic principles of Beckhoff network variables

Quality:
Time in [100 µs] by which arrival of the NWV at the Publisher was delayed.
Relative arrival location:
Input process image of the TwinCAT system
Relative arrival time:
Time at which the next cycle is loaded into the input image

Note:
The reason for determining the delay so precisely is that the NWVs are managed directly by the IO driver, independent of the cycle. Nevertheless, the data of an NWV that is delayed by a few percent of the cycle time will not be taken into account until the input process image is read during the next task cycle.

Note regarding EL6601/EL6614:
Even with the EL66xx the NWV arrival time is defined as the time when the data are available in the input process image of the RT device, not the time of arrival at the EL66xx or in the input image of the EtherCAT device.

Beckhoff network variables - Settings 3: — Interrelationship between quality and delayed network variable

Variable ID
The variable ID (16 bit) is used for global identification of the individual process data. Therefore, an ID in the Publisher or Subscriber group may only be used once within a TwinCAT device, see Fig. Example for communication via network variables: Publishers 1 and 2 on PC1 must have different IDs (10 and 8), although the same ID (8) may be used in Publisher 2 and Subscriber 1.

	Selecting the variable ID In order to achieve unambiguous allocation we recommend using different IDs for each data communication between connected PCs. Reason: In Fig. Example for communication via network variables, PC2/subscriber2 not only receives the designed ID=8-variable from PC1/Publisher2, but, since it is sent as a broadcast (!), it also receives the NWV from PC3/Publisher1. Differentiation is then no longer possible in PC2.

Cycle Index
The 16-bit cycle index is a counter sent by the Publisher together with the data. It is generally incremented with each transmission and can therefore be used as an indicator for flawless transfer. It can be read on the subscriber side as CycleIndex. Its appearance depends on the Publisher platform:

Publisher on a PC: The variable CycleIndex is not visible and is automatically and cyclically incremented by the System Manager
Publisher on an EL66xx: The variable CycleIndex is visible and must be incremented/served by the user such that it is not equal 0 on the subscriber side.

Beckhoff network variables - Settings 5: — Example for communication via network variables

	Data representation on different platforms Please note that simple and complex data (WORD, ARRAYs, REAL, STRING, user-defined structures) are represented internally in a different manner on different platforms! x86 platforms use byte-alignment, others (ARM) 2-byte or 4-byte alignment. This means that if a complex structure is created in an x86/PC PLC project and an ARM PLC project, they can each have a different effective size and a different internal structure. In Fig. Example for different size and structure in PC and CX, the structure in the CX (and hence the network variable to be created there) is larger than in the PC; also the word and real variables do not match each other because a variable can begin at any byte position in the PC, but only at every even-numbered one in the CX. Recommendation for structures that are identical on both end devices - firstly, all 4-byte variables (must lie at an address that is divisible by 4) - then all 2-byte variables (must lie at an address that is divisible by 2) - then all 1-byte variables Further recommendations - if STRING(x) is used, the "EndOfString" zero is also interpreted as a character, otherwise x+1 must be divisible by 4 - the above rules also apply to sub-structures. Please refer to the notes in the Structure section of the Infosys. Use of Bus Terminal Controllers (BCxxxx, BXxxxx) Since the representation of floating point numbers (REAL) on Bus Terminal Controllers (BCxxxx, BXxxxx) differs from that in the x86, these cannot be transmitted. "SINT", for example, can be used for signed values.

Beckhoff network variables - Settings 7: — Example for different size and structure in PC and CX

Settings in the System Manager

	Appearance of the variables Depending on the platform used (PC or EL66xx), the publisher/subscriber will appear differently. A Publisher/Subscriber can be created. On a PC network interface, see Fig. Publisher settings - RT Ethernet on an EL66xx, see Beckhoff network variables - Settings

The following settings options are available in the Beckhoff System Manager TwinCAT 2.10 build 1328:

Publisher, Box

Beckhoff network variables - Settings 9: — Publisher RT Ethernet settings

RT Ethernet settings:

MAC-Broadcast: Sent to all network devices, destination MAC FF:FF:FF:FF:FF:FF.
Multicast: A destination MAC address becomes a multicast address if the first bit in the first byte of the MAC (the so-called group bit) is set. With the Beckhoff ID "00 01 05" the default target address "01 01 05 04 00 00" is formed, as shown in Fig. Publisher RT Ethernet settings.
The MAC range 01:00:5E:00:00:00 to 01:00:5E:FF:FF:FF is intended for general multicast application, with the first 3 bytes specified by the IEEE and the last 3 bytes derived from the lower part of the IP address of the destination PC. The resulting destination MAC therefore never physically exists in the network. Instead, the destination network card detects Ethernet frames formed in this way as multicast frames sent to it, although the Ethernet port itself can have another, unique MAC address. Please refer to the relevant literature for further rules relating to the formation of multicast MAC/IP addresses.
Unicast: Either direct entry of the destination MAC or via the AMS Net ID of the destination device, e.g. 123.456.123.456.1.1, in which case this route must be entered in the local AMS router (right-click on the TwinCAT icon in the taskbar --> Properties --> AMS router)

	Use of broadcast and multicast Network variables sent as broadcast or multicast at MAC or IP level can generate high network load (depending on the cycle time), since they are multiplied into the whole connected network. This may cause simple network devices such as printers to crash. With short cycle times all network traffic may become blocked. We strongly recommend using unicast addressing, taking into account variable identification, as described above.

Advanced Settings:

Data exchange: The task cycle time * divider is the rhythm at which this network variable is sent. (not for EL66xx)
VLAN support: In conjunction with manageable switches the Ethernet frame parameterized here can be assigned a fixed route via VLAN tagging (Virtual Local Area Network).

Beckhoff network variables - Settings 11: — Publisher settings - UDP/IP

UDP/IP settings - the addressing technique of the IP network layer with IP addresses is used. UDP is a connection-less protocol without feedback.

Broadcast: Sent to all device with destination IP (v4) 255.255.255.255
Multicast: The destination IP must be specified, see notes on MAC multicast
Unicast: Specify the target device (e.g.: 192.168.0.1), making sure that it can be reached through the subnet mask

	Use of broadcast and multicast Network variables sent as broadcast or multicast at MAC or IP level can generate high network load (depending on the cycle time), since they are multiplied into the whole connected network. This may cause simple network devices such as printers to crash. With short cycle times all network traffic may become blocked. We strongly recommend using unicast addressing, taking into account variable identification, as described above.

Advanced Settings:

"ARP Retry Interval": In order to ascertain the presence of the recipient, the publisher sends an ARP request to the target device at these intervals. If the network administration of the recipient is operational, it sends an ARP reply. This is only meaningful with unicast.
In the event of an error bit 3 is set (0x0004) in the diagnostic FrameState variable.
Note: ARP handling (ARP = Address Resolution Protocol: allocation of hardware/MAC addresses to network addresses [IP]) is managed by the operating system (Windows).
"Disable Subscriber Monitoring": Deactivates the procedure described above
"Target Address changeable": In this case the destination IP can be changed dynamically

Publisher, Variable

Settings:

"Variable ID": Identification number with which the variable is sent. Can be changed online via PLC where appropriate
"Data exchange": see above (not for EL66xx)
"On change only": NWV is only sent if the value changes (not for EL66xx)

Subscriber, Box

Settings:

"Receiving Options": Only permits NWVs from a certain publisher for this subscriber
"Multicast Configuration": ditto

Process data:

"VarId": If activated, the variable ID can be modified online

Subscriber, variable

Settings:

"Variable ID": Only permits NWVs with a certain ID for this subscriber. Can be changed dynamically via PLC where appropriate
"Ignore Data Type Hash": Hash calculation is currently not supported

Process data:

"Quality": See explanatory notes above
"CycleIndex": This index is incremented with each successful transfer, IF this is done by the opposite side, i.e. the publisher. If the publisher is an EL66x, the user must increment CycleIdx there.
"VarData": Transferred data