Modbus Troubleshooting: No Response, CRC Errors, and Wrong Values — Fixed

Modbus RTU looks simple on paper. Two wires, a frame format, function codes. Then you get on site and nothing talks to anything. This guide is the troubleshooting process we actually use in the field — systematic, fast, and it works.

There are four failure modes. Each has a different root cause and fix.

1. No response at all — slave doesn't answer
2. CRC error — response arrives but frames are corrupt
3. Timeout / partial response — response starts but doesn't complete
4. Wrong values — communication works but data is incorrect

Before You Start: The Baseline Test¶

Don't start debugging a full system. Reduce to minimum first.

Baseline setup: - One master (your gateway or laptop with USB-RS485 adapter + Modbus Poll) - One slave device - Short cable, same room, no other equipment on the bus - Known-good baud rate (check device datasheet — 9600 is common default)

If this doesn't work, the problem is in the basics. If it does work, you can add complexity back one piece at a time.

Failure 1: No Response At All¶

The master sends a request. Nothing comes back. No error frame, no partial response — silence.

Work through this list in order:

1. Modbus isn't enabled on the slave¶

This kills most first-time setups. Energy meters, VFDs, and PLCs often ship with RS485 enabled but Modbus protocol disabled — or Modbus enabled but in a different mode (ASCII instead of RTU).

Fix: Go into the device's configuration menu. Find the communication or serial settings. Verify: - Protocol = Modbus RTU (not ASCII, not proprietary) - RS485 enabled - Some devices require a restart after changing protocol

2. Wrong slave ID¶

Modbus RTU uses slave addresses 1–247. Address 0 is broadcast only. The master must use exactly the same address the slave is configured for.

Verify: Check the slave's address setting from its keypad or dip switches. Set your master to match.

Common mistake: Factory default is often address 1. After someone configures multiple devices they bump addresses to 2, 3, etc. but forget to update the master.

3. Baud rate or parity mismatch¶

Modbus RTU requires both sides to use identical serial settings. A mismatch means the receiver decodes garbage — it may not even recognise the frame as a valid Modbus packet, so no response is generated.

Common defaults by device type:

If the manual says 8N1, that means 8 data bits, No parity, 1 stop bit. 8E1 = 8 data bits, Even parity, 1 stop bit. These are not interchangeable.

4. A and B are swapped¶

RS485 uses differential signaling on two wires called A and B (also labeled D+/D- or Tx+/Rx+). Unfortunately, manufacturers don't agree on which wire is positive.

Some use A = D+ (non-inverting). Others use A = D- (inverting).

Fix: Swap the A and B connections between master and slave. This will not damage anything. If Modbus immediately starts working after swapping, you've found your problem.

5. GND is not connected¶

RS485 is differential — theoretically you don't need ground. In practice, a floating common-mode voltage between devices will overwhelm the differential signal and prevent communication. This is especially common on long runs and multi-vendor setups.

Fix: Run a third wire connecting GND/earth between all devices on the bus.

6. Half-duplex direction control issue¶

RS485 is half-duplex. The master must switch from transmit to receive mode fast enough to catch the slave's response. Some USB-RS485 adapters have a hardware bug here — they de-assert the transmit enable too late, causing the first byte of every response to be missed.

Symptom: Reliable communication at 9600 baud but failures at higher speeds, or intermittent timeouts even with correct settings.

Fix: Increase the response timeout in your master configuration. Try a different USB-RS485 adapter — FTDI-based adapters generally handle this better than CH340-based ones.

Failure 2: CRC Errors¶

You're getting responses, but they contain CRC errors. The frame structure is visible but the checksum doesn't match.

Wiring noise¶

CRC errors almost always mean electrical noise is corrupting the data on the wire.

Sources of noise in industrial environments: - RS485 cable running parallel to AC power cables - RS485 cable running near VFD output cables (the worst — PWM switching noise, 3–20kHz) - Unshielded cable in an EMI-heavy environment - Ground loops from shield grounded at both ends

Fixes: - Use shielded twisted pair cable (Belden 9841, Alpha 5461, or equivalent) - Ground the shield at one end only (typically the gateway/master end) - Route RS485 cable physically separated from power wiring — minimum 30cm - If cable crosses power cables, cross at 90° angle - Clip a ferrite core on the RS485 cable close to the VFD or inverter

Missing or wrong termination¶

Long RS485 runs (> 100m) without proper termination create signal reflections. The reflection arrives at the receiver shortly after the main signal and corrupts it.

Termination: 120Ω resistor between A and B at the last device on the bus. Not every device — just the one at the physical end of the cable run.

Most gateways and some devices have a built-in termination switch. Enable it only if the device is at the end of the bus.

Over-termination is also a problem: If you have resistors at every device, you're loading the bus too heavily and the signal swing isn't enough for reliable communication.

Too many devices without a repeater¶

Standard RS485 drivers support up to 32 unit loads on a bus. Most modern devices are 1/4 unit load (supporting 128), but older devices may be full unit loads. Exceeding the limit causes weak signal levels and CRC errors.

Fix: Use an RS485 repeater or hub if you have many devices on one bus.

Failure 3: Timeout / Partial Response¶

The master sends a request. The slave starts responding but the frame never completes — or the master times out waiting.

Timeout set too short¶

Modbus RTU requires a 3.5-character silent gap between frames to signal start/end. At 9600 baud, each character takes ~1ms, so 3.5 characters = ~3.5ms. But some devices add processing delay before responding.

Fix: Increase the master's response timeout. Start with 500ms. If that works, try tuning it down. Some devices (especially older PLCs) need 1–2 seconds.

Bus collision¶

If another master is polling the same bus simultaneously, frames collide and neither gets a complete response.

Fix: There should be exactly one master on an RS485 Modbus RTU bus. If you have two devices that need to query the same slaves, use a gateway that aggregates for you — or use Modbus TCP at the top level.

Baud rate close but not exact¶

A device claiming 9600 baud might actually be running at 9615 baud due to clock tolerance. Individually this is fine, but in a large frame the accumulated bit error causes the last few bytes to be misread.

Symptom: Short frames work, longer frames fail.

Fix: Move to a lower baud rate (4800 baud tolerates more clock error) or verify device oscillator accuracy.

Failure 4: Wrong Values¶

Communication is working — no errors — but the numbers don't make sense. The energy meter reads 4835000 instead of 483.5 kWh.

Scaling / data type mismatch¶

Modbus registers are 16-bit unsigned integers (0–65535). To represent floating-point values, devices pack floats across 2 registers (32-bit IEEE754) or use fixed-point scaling.

You must check the datasheet for each parameter. Common patterns:

If you get a value of 4835000 when you expect 483.5 kWh, the register is likely uint16 with ×0.1 scaling.

Register address off-by-one¶

Modbus addresses are specified two ways in device manuals:

• Protocol address (0-indexed): What goes in the Modbus frame. Register 0 = first register.
• Datasheet address (1-indexed): 40001, 40002, etc. for holding registers. Subtract 40001 to get the protocol address.

If the datasheet says "Active Power: register 40011" — the Modbus address is 10 (40011 - 40001 = 10).

Getting this wrong by one reads the adjacent register instead. The value will look plausible but slightly wrong, or wrong by a factor of some consistent offset.

Wrong function code¶

Modbus has four register types: - FC01: Coils (discrete outputs) - FC02: Discrete inputs - FC03: Holding registers (most parameters) - FC04: Input registers (read-only measurements)

Some devices put measured values in FC04 input registers, not FC03 holding registers. If you poll FC03 addresses that the device uses as FC04, you'll get an exception response — or worse, different data entirely.

Always check the manual for function code.

Word order for 32-bit registers¶

When a float spans two 16-bit registers, different manufacturers order them differently:

ABB typically uses ABCD. Schneider uses ABCD on most meters, CDAB on some drives. Selec uses ABCD.

If your float value is wildly wrong (like 3.4e38 or some huge number), you have the word order wrong. Try swapping and recalculate.

Quick Checklist¶

Before calling for help, run through this:

• [ ] Modbus RTU protocol enabled on the slave (not just RS485 hardware)
• [ ] Slave address matches on both ends
• [ ] Baud rate, parity, stop bits identical on master and slave
• [ ] A and B wired correctly (try swapping if no response)
• [ ] GND connected between all devices
• [ ] Shielded cable, shield grounded at one end
• [ ] RS485 cable not running parallel to power cables
• [ ] 120Ω termination at the last device only
• [ ] Response timeout ≥ 500ms to start
• [ ] Only one Modbus master on the bus
• [ ] Register address is 0-indexed in your master configuration
• [ ] Correct function code (FC03 vs FC04)
• [ ] Scaling factor applied per datasheet
• [ ] Word order correct for 32-bit registers

Work through the list. Modbus is reliable once the basics are right — most issues come down to five minutes of parameter verification that gets skipped in a hurry.