Test a Modbus TCP gateway before you trust the data

What the gateway adds to the path

The client sends each request over Ethernet to TCP port 502, the port reserved for Modbus TCP. A gateway that bridges TCP to downstream serial devices commonly uses the Unit ID field of that request to select which downstream device hears it, then forwards the function code and register reference onto the serial bus and carries the answer back.

That builds three failure points into one read: the network path, the gateway's routing, and the register map. No amount of settings review separates them. One real read of one documented register does, because each failure answers differently.

What you need

• The gateway's Ethernet address, and confirmation from the network owner that the engineering workstation has a route to it. Coordinate any firewall change with them before you touch anything.
• Gateway mode enabled on the logger for the downstream device, with the routing fields its own documentation names.
• For one downstream device: its Unit ID (its serial address), one register with a documented address, data type, word order where it applies, scale and unit, plus that device's serial settings.
• A value you can check independently: the device's own display, or a known load you can switch on.
• A Modbus TCP client on the workstation: your HMI or SCADA driver, or a standalone poll tool.

Run the pilot read on one logger

1. Confirm the endpoint. Ping the gateway's address, then test a TCP connection on the Modbus TCP port. A green port test clears the network path and nothing else; a passing port test with a dead data path is its own pattern, covered in red offline link indicator when the TCP port test passes.
2. Collect the register facts. From the downstream device's documentation, write down its Unit ID, one register address with its data type, scale and unit, and the serial settings. If the datasheet prints references in the 4xxxx convention, read them the right way; why a 4xxxx register is not function code 04 covers that trap.
3. Configure the client. Point the driver at the gateway's address on the Modbus TCP port, in Modbus TCP mode. Use the gateway's documented fields for protocol mode and downstream routing; settings copied from a plain serial connection don't apply here.
4. Read one register. One request: the Unit ID, the function code, the register address, quantity 1. Record exactly what you sent and exactly what came back, including any exception text.
5. Compare the value. Apply the documented scale and check the result against the device's own display.
6. Enable storage. Turn on the client's logging for that one point and confirm records arrive with timestamps advancing. A working poll and a working archive are two different jobs; prove each.
7. Stop here until step 5 agrees. No tag-building, no second register, no rollout until the pilot value is right.

Read the failure before you change anything

Each result points one way:

Work down the table in order: reachability first, routing second, interpretation last. And resist the restart loop. Cycling the loggers fixes none of the three failure points, and it interrupts collection from devices that are healthy.

Example: first read through logger 1 of 7

Inputs:

• Seven loggers on the plant Ethernet, logger 1 first; this is the case this page addresses.
• Gateway at 10.4.2.31 (illustrative address) on TCP port 502, the documented Modbus TCP port.
• One downstream power meter on logger 1's serial bus at Unit ID 5, taken from the device's own address setting (illustrative).
• Holding register 6, printed as 40007 in the datasheet's 4xxxx convention, read as one register, scale 0.1 V per count, line-to-line volts (illustrative values in the pattern a meter datasheet gives; the convention itself is standard).
• Rule: engineering value = raw count × scale. The read shows the path is good when the scaled result sits within 1% of the device's own display.

Arithmetic: the client returns raw count 2394. 2394 counts × 0.1 V/count = 239.4 V. The meter's own display reads 239 V. The gap is 0.4 V on 239 V, about 0.2%, inside the 1% threshold.

Two probe reads show routing and mapping working separately:

• Same register, Unit ID 6: timeout. Nothing is configured at 6, so the empty answer shows the Unit ID field is what steers the request downstream.
• Undocumented address 199: an Illegal Data Address exception, code 02 in the Modbus specification, meaning the requested address sits outside the range the responder supports. The request reached something that understood it, so this probe tests the map.

Decision: at 0.2% agreement, logger 1's path checks out end to end; reachability, routing and mapping have each answered with a distinct result. At or under 1% agreement, move to logger 2. Above 1%, fix interpretation before you add a single tag.

Roll out to the remaining six

Prove one documented register per downstream device, each checked against its own display. Copy the method, not the values: endpoints, Unit IDs and register maps differ unless the hardware and configurations genuinely match, and one read per device is the test of that. Keep a point list that maps each tag to its logger, Unit ID, register, unit and scale, with the logging setting written beside it. Polling seven endpoints from one client is a layout question as much as a data one; an HMI as Modbus TCP master to seven CODESYS IPCs works at the same scale.

Flag stale separately from wrong: a register frozen at yesterday's value is a different fault from one reading 20% off, and the archive check catches the first.

Recommendation: Prove one documented register on one logger first, and accept the path only when the scaled read sits within 1% of the device's own display. Roll the same five checks across the other six loggers one device at a time, keeping the point list from the first day.

How to check it worked

• The pilot read agrees with the device's own display after scaling, with the arithmetic written into the point list.
• The archive holds records for the tested point with timestamps advancing across at least one hour of watching, and no unexplained gaps.
• The point list names logger, Unit ID, register, unit, scale and logging setting for every tag added after the pilot.

Put the checked numbers on a shop-floor screen

Once the values are checked and logged, the same numbers can go where people walk. A signage display does not join this data path; it plays files. Export the shift summary as an image or video, load it on a memory card or USB stick, and an offline signage screen plays it with no route into the plant network at all. If you need the live register value redrawn at every poll, a signage screen is the wrong tool; that job stays in the HMI client.

For a cabinet or back-of-panel install, a DIN-rail 24 V DC supply keeps the screen's low-voltage wiring inside the cabinet; match the display's accepted input range, printed on its product page, before you buy the supply. Cabinet power and mounting accessories lists that supply and the low-profile VESA bracket.

Questions