Modbus Troubleshooting Guide

Overview

This guide covers the most common Modbus failures in gateway integrations: no communication, wrong values, intermittent serial faults, off-by-one addressing, and value mismatches after conversion into BACnet or another target protocol. Use it with the Modbus protocol guide, the Modbus Addressing & Register Reference, and the Modbus Data Types & Byte Order Reference.

Diagnostic Flow

Confirm whether the job is Modbus RTU or Modbus TCP.
Confirm transport settings first: serial settings or TCP reachability.
Validate one known-good point with an independent scanner.
Check addressing convention and register type.
Check datatype, scaling, and word order.

Symptoms & Solutions

Symptom	Likely Cause	Action	Related KB
No response at all	Wiring, serial mismatch, wrong Unit ID, or TCP path issue	Verify physical layer and transport settings first	Modbus
Values are wrong but plausible	Off-by-one addressing or wrong register type	Re-check zero-based versus reference-style addresses	Modbus
Register shows exactly 32768 on every poll	Sentinel — device has no valid data, or Modbus output not enabled	Check device configuration and register map; see Modbus 32768 Explained	0x8000 Magic Number
32-bit values are zeros, negatives, or nonsense	Wrong datatype or word order	Test ABCD, CDAB, BADC, and DCBA interpretations	Word Order
Communication works then fails intermittently	RS-485 topology or polling-rate problem	Check bus layout, duplicate IDs, and request volume	RS-485
Modbus values look right but BACnet values are wrong	Mapping or target-side datatype issue	Verify the source with a scanner, then inspect gateway mapping	BACnet

No Communication

Check the Physical Layer First

On Modbus RTU links, reversed A and B wiring, missing common reference, or bad terminations are still the fastest way to get complete silence. On Modbus TCP links, start with IP path, port 502 reachability, and whether the device supports more than one client.

[!TIP] If the device is serial, swap A and B once before spending time on mapping theory. If the device is TCP, capture one connection attempt before changing register addresses.

Verify Serial Parameters Exactly

All nodes on the same RS-485 trunk must agree on baud rate, parity, data bits, and stop bits. A one-field mismatch behaves like total communication failure.

Parameter	Typical Values	Failure Pattern
Baud rate	9600, 19200, 38400, 115200	Silence or CRC errors
Data bits	Usually 8	Silent failure on some legacy devices
Parity	None or Even	Silence or CRC errors
Stop bits	1 or 2	Inconsistent replies on some devices

Confirm Unit ID or Slave ID

A good wire and correct serial settings still fail if the request goes to the wrong device address. Many tools default to common IDs that are not actually in use onsite.

Wrong Values

Check Off-by-One Addressing First

This is still the most common Modbus data problem. Vendor documents often show 40001-style reference addresses while the client expects zero-based offsets. If the value is close but wrong, try subtracting 1 from the documented address.

Check Register Type Next

A documented value might live in holding registers, input registers, coils, or discrete inputs. Reading the right address with the wrong function code can look like a dead point.

Check Datatype and Word Order

If 32-bit floats or integers look impossible, the source data is often fine and the interpretation is wrong. Test the byte and word order before assuming the device is broken.

Raw Pattern	Likely Problem	Next Check
Plausible but shifted value	Address offset error	Try address -1
Tiny scientific notation number	Wrong float word order	Try CDAB or DCBA
Value is exactly 10x or 100x off	Missing scaling	Check engineering-unit divisor
Correct bits, wrong sign	Signedness mismatch	Confirm signed or unsigned type

Intermittent Timeouts

Verify Bus Topology

RS-485 expects a bus, not a star. Long stubs and mid-run terminations create a link that can appear healthy during light testing and fail later under sustained polling.

Check for Duplicate IDs

Two devices with the same Unit ID produce a bus that seems haunted: replies collide, timing drifts, and diagnostics are inconsistent.

Reduce Polling Load

Some devices cannot handle aggressive block reads or fast poll intervals. If the link stabilizes when you slow the scan, the device likely needs a gentler request profile.

Source Good, Target Wrong

When the Modbus scan is correct but BACnet or another target protocol shows wrong values, stop changing source registers and inspect the mapping layer.

Validate the source point directly with a scanner.
Confirm datatype, scaling, and engineering units in the gateway.
Confirm the target object type and presentation.

This is especially common when 32-bit values are converted into BACnet objects with the wrong datatype assumption.

CRC and Serial Integrity Issues

CRC errors usually mean the frame is being damaged before it is interpreted.

Cause	Action
Parity mismatch	Match parity on every node
Baud mismatch	Reconfirm the real device setting
Electrical noise	Improve shielding, grounding, and cable routing
Excess cable length	Reduce speed or shorten the path
Missing end termination	Add 120 ohm resistors only at the two physical ends

Quick Diagnostic Decision Tree

If there is no communication:
- For RTU: check A/B polarity, serial settings, Unit ID, and bus topology.
- For TCP: check the IP path, port 502 access, and client-session limits.
- Then validate one point with an independent scanner before revising the config.
If values are wrong:
- Try address offset -1 where documentation ambiguity exists.
- Verify register type and function code.
- Test datatype and word order assumptions.
- Check scaling and signedness mismatches.
If failures are intermittent:
- Look for duplicate IDs.
- Inspect RS-485 topology and termination.
- Slow the polling rate.
- Compare live diagnostics against a known-good baseline.