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 x88A4 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 considered 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 Quality variable). Dynamic temporary blocking of sending a publisher must also be considered. In this case the subscriber registers poor quality. |
| Diagnostic variable "CycleIndex" Please note the following information to decide whether you have to serve the variable CycleIndex. |
Basic principles of Beckhoff network variables
- Quality:
Time in [100 µs] by which this NWV arrived too late at the publisher.
Referred arrival location:
Input process image of the TwinCAT system
Referred arrival time:
Time that the input image will be loaded in the next cycle,
The displayed "delay" is determined in such a finely scaled manner because the NWV management is managed directly by the I/O driver, independent of the cycle. Regardless of this, the data of an NWV that arrived too late by a few percent of the cycle time is only taken into account in the next task cycle when the input process image is read.
EL6601/EL6614: Even when using the EL66xx, the arrival time of the NWV is when the data is present in the input process image of the RT device, not when it arrives at the EL66xx or in the input image of the EtherCAT device. 
- Variable ID
The variable ID (16-bit) is used for global identification of the individual process data – therefore an ID may not be used more than once within a TwinCAT device in the publisher or subscriber group, see Fig. 2: Publisher 1 and 2 on PC1 must have different IDs (10 and 8), but both Publisher 2 and Subscriber 1 may have ID = 8.
In order to achieve unambiguous allocation we recommend using different IDs for each data transmission between connected PCs. Justification: In Fig. 2, PC2/Subscriber2 not only receives the designated 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 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 occurrence differs depending on the publisher platform:
- Publisher on a PC: the variable CycleIndex is not visible and is automatically incremented cyclically by the System Manager
- Publisher on an EL66xx: the variable CycleIndex is visible and must be incremented/operated by the user so that it is not equal to 0 on the subscriber side.
Data representation on different platforms
| Please note that the depictions of simple and complex data (WORD, ARRAYs, REAL, STRING, user-defined structures) may vary internally on different platforms! |
x86 platforms use byte-alignment, others use (ARM) 2-byte or 4-byte alignment.
This means that if a complex structure is created in an x86/PC PLC project and in an ARM PLC project, they can each have a different effective size and a different internal structure.
Recommendation for structures that are identical on both end devices
- firstly, all 4-byte variables (must be on an address that is divisible by 4)
- then all 2-byte variables (must be on an address that is divisible by 2)
- then all 1-byte variables
Further recommendation
- if STRING(x) is used, then the "EndOfString" null is also considered to be a sign; hence, x+1 must be divisible by 4
- the above rules also apply to substructures.
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.
Settings in the System Manager
| Appearance of the variables
|
Publisher, Box
The following settings options are available in the Beckhoff System Manager TwinCAT 2.10 build 1328:
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. 3.
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, considering 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).
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. |
| ARP handling (ARP = Address Resolution Protocol: allocation of hardware/MAC addresses to network addresses [IP]) is managed by the operating system (Windows). |
Advanced Settings:
- "ARP Retry Interval": 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. - "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 when 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