Modbus RTU communication failures almost always trace back to one of four root causes: mismatched serial settings (baud rate, parity, data bits, stop bits), incorrect RS-485 wiring or polarity, wrong slave ID configuration, or register addressing errors (0-based vs 1-based offset confusion). Work through the physical layer first, then serial parameters, then protocol settings—this order eliminates the most common failures fastest.
Modbus RTU Communication Failure Symptoms
Before working through the checklist, confirm what you're seeing. Modbus RTU failures present differently depending on whether the problem is physical, configuration, or protocol-related:
- No response at all — The master sends a request and receives nothing back. The timeout expires on every poll. This typically points to wiring faults, wrong slave ID, reversed polarity, or a completely mismatched baud rate.
- CRC errors / garbled responses — The master receives data but the CRC-16 check fails. The response frame appears corrupted. This usually indicates a partial baud rate mismatch, wrong parity or stop bit settings, electrical noise, or improper termination.
- Intermittent communication — The device responds to some polls but drops others. Common causes include loose wiring, marginal cable lengths, missing bias resistors, or ground potential differences between devices.
- Illegal function or illegal data address exceptions — The slave responds with an exception code (0x01 or 0x02). The physical and serial layers are working correctly, but the master is requesting a function code the slave doesn't support or addressing a register that doesn't exist.
- Wrong data values — Communication succeeds with no errors, but the values read from the slave don't match expected readings. This points to register addressing offset errors (off by one), byte order (endianness) mismatches, or reading the wrong register type (holding vs input).
Physical Layer Checks
Modbus RTU runs over RS-485, a differential signaling standard that uses two wires (A and B) plus an optional signal ground. Physical layer problems account for roughly half of all Modbus RTU field failures. Check these items first:
RS-485 Wiring and Polarity
- Verify A/B polarity at every device. RS-485 uses differential signaling on two conductors. Unfortunately, labeling is inconsistent across manufacturers—some label the non-inverting line as A+ and others label it as B+. The TIA/EIA-485 standard defines A as the inverting terminal and B as the non-inverting terminal, but many device manufacturers (including some BAS controllers) reverse this. When in doubt, use an oscilloscope or check the manufacturer's wiring diagram. A single polarity reversal at any device will prevent communication on the entire bus.
- Confirm daisy-chain topology. RS-485 requires a linear daisy-chain (bus) topology. Star wiring and T-tap connections create signal reflections and impedance mismatches. Each device must be wired in series along the bus, not tapped off a central junction.
- Check for signal ground. A third conductor for signal reference ground (SG or GND) is not required by RS-485 but is strongly recommended, especially for runs longer than 15 meters (50 feet) or where devices are powered from different electrical panels. Without a common ground reference, voltage differences between device grounds can exceed the RS-485 common-mode range (±7V), causing communication failures.
Termination and Bias
- Install 120-ohm termination resistors at both ends of the bus only. Place one resistor across A and B at the first device on the bus, and another at the last device. Do not install termination at intermediate devices. Missing termination causes signal reflections on longer runs; excess termination reduces signal amplitude below the RS-485 receiver threshold (200 mV differential).
- Add bias resistors if the bus is idle between polls. When no device is transmitting, the RS-485 bus enters a high-impedance (tri-state) condition. Without bias resistors, electrical noise can cause receivers to interpret random data. A 390–560 ohm pull-up resistor from B to Vcc and a matching pull-down resistor from A to GND at the master device ensures the bus rests in a known state. Many RS-485 converters and BAS controllers have built-in bias—check before adding external resistors.
Cable Specifications and Length
- Maximum cable length: 1,200 meters (4,000 feet) at 9600 baud. Higher baud rates reduce the maximum reliable distance. At 115200 baud, keep runs under 300 meters (1,000 feet) unless using low-capacitance cable.
- Cable type: Use shielded twisted-pair cable (STP), 24 AWG minimum, with one twisted pair for A/B and the shield connected to ground at one end only. Belden 9841 (or equivalent) is a standard choice for RS-485 in building automation installations.
- Maximum devices per bus: Standard RS-485 supports up to 32 unit loads on a single bus segment. High-impedance (1/4 or 1/8 unit load) RS-485 transceivers—common in modern BAS controllers—allow up to 128 or 256 devices per segment. Check transceiver specifications when loading a bus beyond 32 devices.
Serial Configuration Checks
Every device on a Modbus RTU bus must use identical serial port settings. A mismatch in any single parameter will cause communication to fail. The four parameters that must match:
Baud Rate
Standard Modbus RTU baud rates: 9600, 19200, 38400, 57600, and 115200 bps. The original Modbus specification defaults to 19200 bps. Many BAS field devices (energy meters, VFDs, sensors) ship with a factory default of 9600 bps. The master and every slave on the bus must use the same baud rate. There is no auto-negotiation in Modbus RTU.
# Common baud rate defaults by device type
# -----------------------------------------------
# Energy meters (Schneider PM5xxx, ABB M4M) : 9600
# Variable frequency drives (ABB, Danfoss) : 9600 or 19200
# Tridium Niagara (JACE) serial port : 9600 (configurable)
# Honeywell Spyder controllers : 9600 (configurable)
# ICP DAS I/O modules : 9600 (DIP switch selectable)
# Veris power meters : 9600Parity, Data Bits, and Stop Bits
The Modbus RTU specification defines the default serial frame as 8 data bits, even parity, 1 stop bit (8E1). However, many devices ship configured for 8 data bits, no parity, 1 stop bit (8N1) or 8 data bits, no parity, 2 stop bits (8N2). The Modbus specification requires that when parity is set to "none," an additional stop bit be used (8N2) to maintain the 11-bit character frame, but in practice most devices and masters work with 8N1.
The critical rule: every device on the bus must use the same combination. If even one device is set to 8E1 while the rest use 8N1, that device will either fail to respond or generate CRC errors.
# Serial frame configuration - all devices must match
# -----------------------------------------------
# Common configurations (pick ONE for the entire bus):
#
# 8E1 = 8 data bits, Even parity, 1 stop bit (Modbus default)
# 8O1 = 8 data bits, Odd parity, 1 stop bit
# 8N2 = 8 data bits, No parity, 2 stop bits (spec-compliant alt)
# 8N1 = 8 data bits, No parity, 1 stop bit (widely used in BAS)
#
# If unsure, try 8N1 first - it is the most common in BAS field devicesProtocol Settings Checks
Slave ID (Unit Address)
Each Modbus slave device must have a unique address on the bus, ranging from 1 to 247. Address 0 is reserved for broadcast (write-only, no response). Addresses 248–255 are reserved. Duplicate slave IDs cause exactly the same symptoms as duplicate BACnet MAC addresses: intermittent responses, garbled data, and bus collisions.
- Verify that no two devices share the same slave ID on the bus.
- Confirm the master is polling the correct slave ID for the target device.
- Check factory default addresses—many devices ship with a default slave ID of 1. After installing multiple devices of the same model, at least one will need its address changed.
Function Codes
Ensure you are using the correct Modbus function code for the register type you are trying to access:
| Function Code | Name | Register Type | Access |
|---|---|---|---|
| 01 (0x01) | Read Coils | Coils (0xxxx) | Read |
| 02 (0x02) | Read Discrete Inputs | Discrete Inputs (1xxxx) | Read |
| 03 (0x03) | Read Holding Registers | Holding Registers (4xxxx) | Read |
| 04 (0x04) | Read Input Registers | Input Registers (3xxxx) | Read |
| 05 (0x05) | Write Single Coil | Coils (0xxxx) | Write |
| 06 (0x06) | Write Single Holding Register | Holding Registers (4xxxx) | Write |
| 15 (0x0F) | Write Multiple Coils | Coils (0xxxx) | Write |
| 16 (0x10) | Write Multiple Holding Registers | Holding Registers (4xxxx) | Write |
A common mistake: using function code 03 (Read Holding Registers) when the device maps a value to an input register (function code 04). The slave will return an Illegal Function exception (0x01) or an Illegal Data Address exception (0x02).
Register Addressing: 0-Based vs 1-Based
This is the single most common source of Modbus RTU configuration errors in building automation. Modbus documentation uses two different numbering conventions, and confusing them produces an off-by-one error that returns data from the wrong register:
- Modbus register number (1-based, documentation convention) — The register number printed in the device's data sheet. Holding registers start at 40001. For example, a data sheet listing "Zone Temperature = Register 40101" means holding register number 40101.
- Modbus protocol address (0-based, wire-level) — The actual address transmitted in the Modbus RTU frame. This is always the register number minus 1 (and minus the 40000 prefix for holding registers). Register 40101 becomes protocol address 100 (0x0064) on the wire.
# Register addressing example
# -----------------------------------------------
# Device data sheet says: "Zone Temp = Holding Register 40101"
#
# In Modbus poll software or BAS driver configuration:
#
# If the tool uses 1-based (register number): enter 40101 or 101
# If the tool uses 0-based (protocol address): enter 100
#
# The Modbus RTU frame on the wire always uses 0-based:
# Slave ID | Func 03 | Start Addr Hi | Start Addr Lo | ...
# 0x01 | 0x03 | 0x00 | 0x64 | ...
# ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
# 0x0064 = 100 decimal = register 40101
#
# Getting this wrong by 1 means you read register 40102 or 40100
# instead of 40101. The data comes back with no error - just wrong values.Always check whether your BAS controller's Modbus driver or integration software expects 0-based addresses or 1-based register numbers. Tridium Niagara, for example, typically uses 0-based addressing in its Modbus driver configuration. Honeywell and Schneider Electric platforms vary by product line—consult the integration guide for the specific controller.
Using Diagnostic Tools
When the checklist above doesn't resolve the issue, connect diagnostic tools to observe the actual data on the wire:
Serial Port Monitors and Modbus Master Tools
A serial port monitor captures raw bytes on the RS-485 bus through the master's COM port. Free Serial Port Monitor (HHD Software) shows hex data with timestamps. CAS Modbus Scanner (CHIPKIN, free) scans for devices and tests communication parameters.
Dedicated Modbus master tools let you manually poll registers independent of your BAS controller. Modbus Poll (Witte Software, 30-day trial) supports RTU, ASCII, and TCP. QModMaster (open-source) handles basic register reads and writes on Windows and Linux. mbpoll is a command-line option for Linux-based BAS servers.
# Example: Using mbpoll on Linux to read 5 holding registers
# starting at address 100 from slave ID 1 at 9600 baud, 8N1
#
# mbpoll -m rtu -a 1 -b 9600 -P none -r 100 -c 5 /dev/ttyUSB0
#
# Expected output (if communication works):
# [100]: 2350 (zone temp = 23.50°C scaled by 100)
# [101]: 5500 (humidity = 55.00% scaled by 100)
# [102]: 1 (occupancy = occupied)
# [103]: 0 (alarm = no alarm)
# [104]: 720 (CO2 = 720 ppm)Common Modbus RTU Troubleshooting Mistakes
- Swapping A and B without checking the manufacturer's definition. There is no universal standard for which wire is "positive" in RS-485. TIA-485 defines A as inverting and B as non-inverting, but many manufacturers (notably several BAS and HVAC equipment vendors) label them in reverse. Always verify against the specific device's wiring diagram rather than assuming A is A across all brands.
- Confusing Modbus register numbers with protocol addresses. A data sheet listing "Register 40001" means holding register #1, which translates to protocol address 0 on the wire. Entering 40001 into a BAS driver that expects a 0-based address will attempt to read address 40001—well outside the valid 0–65535 range—and either return an exception or read from a completely wrong location.
- Not respecting inter-frame silence (3.5 character times). Modbus RTU uses timing—not start/stop delimiters—to separate frames. The gap between frames must be at least 3.5 character periods (approximately 4 ms at 9600 baud). USB-to-RS-485 converters with poor timing control can split a single Modbus frame into two transmissions, causing CRC failures. FTDI-based converters are generally more reliable than Prolific PL2303-based adapters for Modbus RTU.
- Adding termination resistors at intermediate devices. Just as with BACnet MS/TP, RS-485 termination resistors (120 ohm) belong only at the two physical endpoints of the bus. Installing them at middle-of-run devices reduces signal amplitude and creates reflections. On short runs (under 30 meters at 9600 baud), termination may not be needed at all.
- Polling too fast for the slave device. Some BAS field devices (especially older energy meters and VFDs) require a turnaround delay of 10–100 ms between receiving a request and sending a response. If the master times out before the slave responds, the poll appears to fail. Increase the response timeout in the master's Modbus driver configuration before assuming the slave is faulty.
Platform/Version Compatibility
Modbus RTU is a protocol-level standard (Modbus Organization, modbus.org) supported by virtually every BAS platform. The troubleshooting steps in this checklist apply across all major building automation equipment that supports Modbus RTU integration:
| Platform / Equipment | Modbus RTU Interface | Typical Role | Notes |
|---|---|---|---|
| Tridium Niagara (JACE, Supervisor) | Built-in serial port or USB-RS485 | Master | Modbus driver uses 0-based addressing; configure under Drivers > ModbusNetwork |
| Schneider Electric AS-P / SmartX | RS-485 port | Master or Slave | EcoStruxure supports both Modbus master and slave configurations |
| Johnson Controls FEC / CGM | RS-485 port | Master | Metasys Modbus integration via CGM (Communications Gateway Module) |
| Honeywell Spyder / WEB-8000 | RS-485 port | Master or Slave | Spyder supports Modbus slave; WEB-8000 acts as Modbus master via serial |
| Schneider Electric PM5xxx meters | RS-485 port | Slave | Default: 9600, 8E1, slave ID 1. Register map in PM5xxx user manual. |
| ABB ACS580 / ACH580 VFDs | RS-485 (embedded) or fieldbus adapter | Slave | Default: 9600, 8N1, slave ID 1. Requires parameter group 58 configuration. |
| ICP DAS I-7000 / M-7000 modules | RS-485 port | Slave | DIP switch selectable baud rate and address. Detailed troubleshooting in ICP DAS FAQ. |
| Veris E5x / H8000 power meters | RS-485 port | Slave | Default: 9600, 8N1, slave ID 1. Commonly integrated for energy monitoring. |
Sources and Attribution
The technical guidance in this entry is informed by the following sources:
- Modbus RTU Troubleshooting Discussions — control.com Forums. Field technician threads covering RS-485 wiring errors, baud rate mismatches, and register addressing confusion in BAS integrations.
- Modbus Troubleshooting FAQ — ICP DAS. Detailed troubleshooting guide for RS-485 communication failures including wiring diagrams, termination guidance, and DIP switch configuration for I-7000/M-7000 series modules.
- Honeywell Building Technologies Support — Honeywell. Technical articles covering Modbus RTU integration with Spyder controllers, WEB-8000 supervisors, and serial communication parameter configuration.
- Modbus Application Protocol Specification v1.1b3 — Modbus Organization. The definitive protocol specification defining function codes, register addressing conventions, exception codes, and serial line framing for Modbus RTU.
- RS-485 Design Guide (SLLA272) — Texas Instruments. Application note covering RS-485 physical layer design including termination, bias resistors, cable length limits, and common wiring mistakes.
Was this article helpful?
Related Articles
Need to do this remotely? SiteConduit supports Modbus remote access with the same protocol-level controls as BACnet. Join the waitlist.
SiteConduit Technical Team
Idea Networks Inc.
SiteConduit builds managed remote access for building automation. Our knowledge base is maintained by BAS professionals with hands-on experience deploying and troubleshooting BACnet, Niagara, Modbus, and Facility Explorer systems.