Modbus TCP Connects but Reads Zeros: How to Fix It

Back to Blog

First Checks: Prove You Are Reading Real Data

Start by finding one register you can guarantee is not zero and making it your reference. A live process value shown on the device's local display, a firmware version register, or a device ID from the register map all work. If you can read that reference correctly, addressing fundamentally works and the zeros elsewhere are a mapping detail. If even the reference reads zero, the problem is structural - wrong area, wrong offset, or wrong target - and you have narrowed the search before changing anything.

The fastest structural test is to try the same address with the other read function. Many devices keep their process data in input registers, read with function code 4, while the master defaults to holding registers with function code 3. Both reads can succeed, because both areas exist, but one of them is empty. Swapping FC3 for FC4, or the reverse, instantly reveals whether you have been polling a valid but vacant area the whole time.

Off-by-One and the 40001 Convention

Modbus documentation traditionally numbers holding registers from 40001, but the address transmitted on the wire is zero-based: register 40001 is address 0 in the protocol frame. Vendors split on which convention their documentation and their driver configuration use, so the same map can be entered two ways, one of them wrong by exactly one register. The tell is data that looks shifted rather than absent: a value you expect in one tag shows up in its neighbor, or a block read returns plausible numbers starting one slot late.

When the surrounding registers happen to be empty, an off-by-one shows up as zeros rather than shifted data, which is why it belongs in the zeros investigation too. The test is cheap: offset the polled address by one in each direction and see whether the reference value appears. Once one register lines up, apply the same correction to the whole map rather than hunting tag by tag, because the convention error is uniform.

Unit ID Routing and Wrong-Target Traps

On a plain Modbus TCP device the unit ID field is often ignored - the device answers whatever ID the master sends. Behind a gateway the story reverses: the gateway uses the unit ID to select which downstream serial device receives the request. Send an ID the gateway maps to nothing and, depending on its design, you may get an exception, a timeout, or a locally generated answer full of zeros. If your polls traverse any serial gateway or protocol converter, verify the unit ID against the gateway's mapping table rather than the end device's documentation alone.

The last trap is answering hardware that is not your device at all. A duplicated IP address, a stale ARP entry after a device swap, a NAT rule pointing at the wrong internal host, or a test simulator someone left running can each accept your connection convincingly and return empty data. Reading a device identification or serial number register and comparing it against the physical unit's label settles the question. This is worth doing early at sites with many similar controllers, where an address list error puts you on the wrong wellpad entirely.

When to Escalate

If the reference register reads correctly through every function code and offset combination and still no process data appears, the register map itself is the remaining suspect. Vendor documentation does drift from firmware reality, especially across firmware versions, and some devices require a configuration step before they populate their Modbus map at all. At that point the productive escalation is to the device vendor with specifics: the exact function code, wire-level address, unit ID, and response you observed, which is a five-minute capture with any Modbus test client.

Zeros that reach the historian are worse than gaps, because they look like data. A SCADA platform such as Merobix helps contain the damage by making communication status visible per device and by letting you sanity-check new tags against live values during commissioning, so a map error is caught while someone is still looking at it rather than weeks later in a report. The habit that prevents the whole class of problem is validating one known-nonzero reference register at every new device before trusting the rest of its map.

Frequently Asked Questions