Use a UDP network variable list when every runtime is CODESYS and all PCs share one subnet. Use Modbus TCP on port 502 or OPC UA on port 4840 when a router separates the ends, a third-party device joins, or the link needs a visible failure signal. Raw sockets are for a peer that dictates its own telegram.
Every PC on the line runs CODESYS V3.5, and values have to move between the runtimes. Four transports inside CODESYS do that job: UDP network variable lists, Modbus TCP, OPC UA, and raw TCP or UDP sockets. The choice comes down to three questions. Are both ends CODESYS? Do the runtimes share one subnet? Does the link have to announce its own failure? One subnet with both ends CODESYS points to a UDP network variable list. A router between the ends, a third-party device in the path, or a required link alarm points to Modbus TCP on port 502 or OPC UA on port 4840. Raw sockets are for the rare case where the peer dictates a fixed telegram format.
The four transports side by side
Each option moves the same values differently: a shared variable list, mapped registers, browsable symbols, or a telegram you define. The table is the decision.
| Method | Transport and port | Data model | Crosses a router | Link failure visible | Setup effort |
|---|---|---|---|---|---|
| Network variables (UDP) | UDP, port set in the list's settings | One global variable list, identical on both sides | No, broadcast stays inside one subnet | No, a lost frame is replaced by the next send; add a heartbeat counter to notice a dead link | Lowest, project configuration, no communication code |
| Modbus TCP | TCP port 502 | Registers and coils mapped to variables | Yes | Yes, a timed-out poll raises an error on the client channel | Low, server device on the side that owns the data, client on the consumer |
| OPC UA | TCP, port 4840 unless changed | Symbols published through a symbol configuration | Yes | Yes, the client sees the session drop | Medium, server with certificate exchange, client function on the consumer |
| Raw sockets | TCP or UDP on a port you choose | A telegram you define byte for byte | Yes | TCP only, and only if your reconnect code reports it | Highest, framing, timeouts and reconnection are your code |
Where each transport wins
UDP network variables. Every node is CODESYS, all nodes sit on one subnet with no router between them, and the data is cyclic process values: setpoints, run flags, counts, temperatures. You configure the list in both projects and the runtime does the sending. Set the send interval from the process need; 200 ms is a sensible default for supervisory values. Build link supervision into the list, because UDP delivers no confirmation: add a counter the sender increments on every send, and a receiver check that flags the link stale when the counter stops moving.
Modbus TCP. The ends sit on different subnets, a non-CODESYS device joins, or you want the transport to report a dead link. Modbus TCP is a documented open protocol on TCP port 502; HMIs, SCADA packages, third-party PLCs and small controllers speak it, and an Arduino Mega set up as a Modbus TCP slave is the low end of that range. The runtime that owns the data serves registers and coils; the consumer polls them. A poll that times out raises a visible error on the client channel, which is the link alarm UDP never gives you.
OPC UA. The same routing case as Modbus TCP, plus a client that should browse: SCADA or an HMI that discovers tags instead of mapping register numbers. OPC UA is standardized as IEC 62541 and runs on TCP port 4840 unless you change it. The producing project publishes a symbol configuration; the consumer connects as a client. Expect a certificate exchange between client and server before data moves; setting up a CODESYS OPC UA server for HMI clients walks through that side.
Raw sockets. Only when the peer dictates a telegram format you cannot change, for example a fixed-length frame to a legacy system. You own framing, timeouts and reconnection. Sending a REAL value in a 12-byte TCP telegram shows that work at its smallest.
Timing on Windows
Windows is not a real-time operating system. Every transport in the table inherits scheduling jitter from the Windows IP stack and the runtime task, so size the exchange for soft timing: hundreds of milliseconds between updates is the normal band for supervisory data. Keep an interlock that needs hard timing inside a single runtime, where one task scan decides it. Before you promise an update rate to anyone, measure the runtime's cycle time limit with a load sweep.
Example: three runtimes on one subnet, then a fourth across a router
Three Windows PCs run CODESYS V3.5 on 192.168.10.0/24, one subnet with no router between them. PC1 runs line A, PC2 runs line B, PC3 collects values.
PC1 and PC2 each publish a UDP network variable list holding three INT setpoints, one BOOL run flag at 1 byte, and one UDINT heartbeat counter. Declared payload per send is 3 × 2 bytes + 1 byte + 4 bytes = 11 bytes. Cyclic transmission at 200 ms gives 1000 / 200 = 5 sends per second per sender, so 2 senders × 5 = 10 datagrams per second arrive at PC3, carrying 10 × 11 = 110 bytes per second of application payload. Each datagram adds 28 bytes of IPv4 and UDP headers, so the wire load is about 10 × (11 + 28) = 390 bytes per second. Any switch carries that without measurable effort.
Link supervision: each sender increments its heartbeat counter on every send, so the counter steps 5 per second. PC3 compares the counter with its previous value every scan and raises a stale-link flag when it has not moved for 3 × 200 ms = 600 ms. The same check runs on the list from PC2.
Then a fourth PC joins on 192.168.20.0/24, behind a router. UDP broadcast stops at the router, so the lists never reach it; UDP broadcast forwarding across subnets is a router feature you would have to engineer in, and the simpler move is to change protocol. PC3 keeps receiving both lists, maps their values to registers and coils, and serves them as a Modbus TCP server on TCP port 502, with that port open to incoming connections on PC3 for the runtime process. The fourth PC polls PC3 as a Modbus TCP client every 250 ms, and a timed-out poll now raises the visible error a routed link needs. If the fourth PC had to exchange values with PC1 and PC2 directly, each of those links would be a Modbus TCP or OPC UA link in its own right.
When values never arrive
Work from the wire upward, in this order.
- Ping both ways. Different subnets or a wrong mask is the usual reason a UDP list never arrives: broadcast does not leave the local subnet.
- Windows Firewall. Allow incoming traffic on the list's UDP port for the runtime process, on the network profile that adapter actually uses. A rule on the wrong profile blocks the datagram with no error message anywhere.
- List identity. The list identifier and UDP port must match on both sides, and the layout must match name for name and type for type. Export the list from the sender project and import it on the receiver so the two definitions cannot drift.
- Heartbeat. Frames arrive and values still look stale: the receiving check is running in a task that never executes, or the counter is missing from the sent list.
- Capture. A packet capture on the receiving NIC, filtered on the configured port, settles whether frames arrive at all and at what cadence.
Where the values go next
Values that cross runtimes usually end up in front of people too. A read-only status board is its own specification exercise; specifying a read-only process display for a plant lists what to pin down before buying a screen. When the board is a shop-floor notice screen fed with its own playback or app, our shop-floor signage displays are built for that side of the job.
Recommendation: use a UDP network variable list when both ends are CODESYS and share one subnet: send cyclically at 200 ms, put a heartbeat counter in the list, and check it on the receiver with a staleness timer of three send intervals, 600 ms at the 200 ms default. Change the link to Modbus TCP on port 502 the moment a router separates the ends or a non-CODESYS device joins, and to OPC UA on port 4840 when the client has to browse the data model. Keep raw sockets for a peer that dictates its own telegram, and keep hard-timed interlocks inside one runtime on every path.
Questions
Can one plant mix UDP network variables and Modbus TCP?
Yes, and it is the common pattern. Keep a UDP list inside each cell subnet where both ends are CODESYS, then carry the cell's values upward with Modbus TCP on port 502 or OPC UA. The runtime that receives the lists holds the values and maps them to registers or symbols for the upward link. Keep a heartbeat counter in every UDP list you depend on.
What happens to a network variable when a UDP frame is lost?
UDP has no retransmission, so a lost frame is gone and the receiver holds the last value until the next cyclic send replaces it. At a 200 ms interval the gap is one interval long, which suits setpoints and statuses. It also means a steady value and a dead link look identical to the receiver, which is why the heartbeat counter and its staleness timer belong in the design.
Which send interval should a UDP network variable list use?
Start from the process. 200 ms covers setpoints, run statuses and counts on a line. 1 s is enough for slow values such as temperatures and tank levels. Setting 50 ms buys nothing unless a consumer acts on the value that fast. Load grows with the interval and the number of receivers: at 200 ms one sender puts 5 datagrams per second on the wire to each peer.
Do I need communication code for a UDP network variable list?
No. Once the list is configured on both sides, the runtime handles sending and receiving, so the code you write is the application logic plus, if you want link supervision, the heartbeat increment on the sender and the staleness check on the receiver. The list identifier, the UDP port and the send interval live in the list's settings, and sender and receiver must carry the same identifier and port.
Planning information, not legal or engineering advice. Rules differ by place: check codes and permits with your local authority and your licensed trades.