HMI as Modbus TCP master to seven CODESYS IPCs

The rule that decides the layout: the client dials, the server answers

In Modbus TCP, the client opens a TCP connection to port 502 on the server's address and sends its request; the server answers on that same session and never initiates one. That is the whole rule, straight from the Modbus messaging specification, and it sorts the job into two layouts.

• Layout A: the HMI is the server. Each IPC's CODESYS application runs a Modbus TCP client that opens one session to the HMI on port 502 and writes its values. The HMI only receives. The number to check is how many client sessions the HMI accepts at the same time; it is a per-model limit printed in the HMI manual, and this job needs seven.
• Layout B: the HMI is the master. Each IPC carries a Modbus TCP slave device, and the HMI holds a device list with one entry per IPC. All seven sessions open from the HMI, so the HMI also owns the polling timing.

Sessions run one client per session on the server side; a second client connects on its own session. That is why layout A's only structural limit is the server's session count.

The two layouts side by side

The same seven stations look like this under each layout.

Where each layout wins

Layout A wins when the HMI manual shows a session count of 7 or more and a heartbeat register satisfies the comm-loss question. Its weak spot is stale data: a server never learns that a client stopped; it just goes quiet. Give each IPC a heartbeat counter register that increments on every write cycle and alarm on the HMI when a counter stops changing, and the gap closes. If the seven client programs already run, layout A is the zero-change answer.

Layout B wins when operators need a comm-fail lamp per station, because the master driver reports the timeout on the exact entry that stopped answering. It puts the scan rate in one place, and with an identical register map on every IPC one screen template serves all seven stations, the same approach as reusable HMI screens for multiple devices. The HMI itself becomes a plain shop-floor screen: it shows what the loop gathered and drives an alarm line from the per-station error bits.

A third layout sidesteps the roles question altogether: run an OPC UA server in each CODESYS runtime and connect the HMI as an OPC UA client, which brings connection status per server with the protocol. That is the answer when the IPC programs are being rewritten anyway; the setup is in CODESYS OPC UA server for HMI clients.

Example: seven IPCs, one offline, a 500 ms target

Inputs. Seven device entries in one sequential loop, one entry per IPC, all read in a single scan; 16 contiguous holding registers per station, an example map size that sits under the 125-register maximum one Modbus read request carries, so each station takes one request per cycle; 15 ms per request round trip on a healthy switched network, an example value to read from the driver's device diagnostics on your own wire; 1,000 ms response timeout with 1 retry per entry, example settings whose allowed ranges the driver manual prints; 500 ms refresh target for the screen.

The rule in words. A sequential loop's cycle time is the sum of the round trips of the stations that answer, plus the timeout for every station that does not answer, counted once more for each retry.

Arithmetic. All 7 up: 7 × 15 ms = 105 ms per cycle, so the screen refreshes about every 0.1 s. One IPC down, no retry: 6 × 15 ms + 1 × 1,000 ms = 90 ms + 1,000 ms = 1,090 ms per cycle; every station's values now age about 1.1 s, roughly 10 times slower than healthy. One IPC down with the retry: 6 × 15 ms + 2 × 1,000 ms = 90 ms + 2,000 ms = 2,090 ms, about 20 times the healthy loop.

Result. One stopped IPC taxes all 7 stations, and each retry adds a full timeout to every cycle. The same summed-timeout behavior governs any single client that polls several PLCs from one small Ethernet box.

Decision. With these settings a single timeout of 1,000 ms already doubles the 500 ms target, and the retry case reaches 2,090 ms, more than four times the target, so one sequential loop cannot hold the refresh through a failure. Split the seven entries across two poll groups so a dead node stalls only its half, drop the retry on the group that must stay fast, or stay on layout A, where a stopped IPC only stales its own values. Keep the timeout above the worst-case healthy response: cutting it to 50 ms to shrink the loop turns a slow-but-alive IPC into a false comm-fail. When the stopped IPC returns, the master has to rebuild that session, which is its own job; see make a Modbus master reconnect after a slave outage.

What changes on each side for layout B

1. Give each IPC a static address in the same subnet as the HMI, or put a router between them that passes TCP on port 502, and write the seven addresses down before touching either tool.
2. In each CODESYS project, add the Modbus TCP slave device under the Ethernet interface in the device tree and leave the listening port at 502; if site policy moves it, set the same port in every HMI device entry.
3. Map one identical register set on all 7 IPCs: start address, length, and the variable bound to each register. Identical maps are what let a single HMI tag template serve every station.
4. On the HMI, select the Modbus TCP master driver in the external-device settings and add 7 entries, one per IPC address on port 502. Set each entry's unit ID to the value the IPC slave device answers with; a CODESYS Modbus TCP slave commonly answers to unit ID 255, so that is the first value to try when ID 1 returns nothing.
5. Group each station's tags into contiguous blocks so the driver reads one block per cycle. A 16-register block is 1 request; 16 scattered words are 16 requests, and 7 stations of scattered words mean 112 requests, about 1,680 ms per cycle at 15 ms each, over the 500 ms target with every IPC healthy.
6. Download and run, watch the per-entry comm status before building screen logic, then check the wire from a mirror port filtered to TCP port 502: one session per IPC from the HMI, request/response pairs at the set cadence, and no exception responses. Compare the loop time with all 7 up against 6 to see the offline penalty directly.

PROFINET between an IPC and the plant PLC

An IPC running CODESYS can sit on a PROFINET network as an IO device under one precondition: the runtime on that IPC must include the PROFINET device component with its license activated. CODESYS sells that function as a single-device software license tied to the machine the runtime runs on. The plant PLC takes the IO controller role and treats the IPC like any other remote IO station. Export the GSDML device description from CODESYS, import it into the PLC engineering tool, and install it in the controller's device configuration.

A base runtime with a standard Ethernet port does not include the device function, so check the runtime's feature list and the installed licenses before promising the link. Without it, Modbus TCP is the working fallback: choose the client side, open TCP to the other box on port 502, and carry over the same register-map discipline of one agreed map and a wire check. If the plant standard demands a fieldbus other than Modbus, look for a slave stack the CODESYS project already accepts; choosing a PROFIBUS DP slave for a CODESYS runtime walks through that selection. And when a configured PROFINET port is not detected after a ping test, work the checks in fixing CODESYS PROFINET ports not detected after a ping.

The decision

• Seven client programs already push, and the HMI manual shows 7 or more client sessions: stay on layout A. Add a heartbeat counter per IPC and alarm when a counter stops changing; nothing else moves.
• Operators need a comm-fail lamp per station, or seven programs each carrying their own timing has become the maintenance burden: move to layout B, with one device entry per IPC on port 502, an identical register map, and a timeout sized above the worst-case response with retries charged at one full timeout each.
• The screen must hold its 500 ms refresh through a station failure: split the entries across two poll groups or drop the retries, because one sequential loop with these example settings spends more than the target on a single timeout.
• PROFINET to the plant PLC: only with the licensed PROFINET device component in the IPC runtime; otherwise run Modbus TCP and keep the map discipline.

Recommendation: Stay on layout A while the HMI's session count covers all seven IPCs and a heartbeat counter per station answers the operators. Start layout B when you need a per-station comm-fail signal or one poll configuration, built with an identical 16-register map on every IPC, one device entry per station on port 502, and the loop budgeted from the example above; if the refresh has to survive a stopped station, split the entries across two poll groups before anything else.

Questions