Modbus Troubleshooting: Common Errors and Fixes

Modbus communication issues are a daily reality for automation engineers. Timeout errors, garbled data, exception codes, and intermittent failures can be frustrating to diagnose, especially on busy serial networks or complex TCP installations.

This guide covers the most common Modbus errors, their root causes, and practical steps to fix them. Whether you're dealing with a device that won't respond, data that looks wrong, or intermittent communication drops, you'll find the answer here.

Modbus Exception Codes

When a Modbus slave receives a valid request but can't fulfill it, it responds with an exception code. Understanding these codes is the first step in troubleshooting.

Code	Name	Meaning
01	Illegal Function	The function code is not supported by the device
02	Illegal Data Address	The requested register address doesn't exist
03	Illegal Data Value	The value in the request is out of range
04	Slave Device Failure	The device encountered an internal error
05	Acknowledge	Request accepted, but processing will take time
06	Slave Device Busy	The device is busy processing another request
08	Memory Parity Error	Device detected a parity error in its internal memory
0A	Gateway Path Unavailable	Gateway can't reach the target device
0B	Gateway Target Failed	Target device behind gateway didn't respond

Error 1: Timeout (No Response)

A timeout occurs when the master sends a request and receives no response within the configured time limit. This is the single most common Modbus issue.

Possible Causes

• Wrong slave ID — The device has a different address than configured
• Wrong serial settings — Baud rate, parity, data bits, or stop bits don't match
• Cable problem — Loose connection, broken wire, or wrong wiring (swapped A/B on RS-485)
• Wrong IP address or port — For TCP connections
• Device not powered — The slave device is off or not ready
• Firewall blocking port 502 — For TCP connections
• RS-485 termination — Missing termination resistors on long serial buses

How to Fix

1. Verify the device is powered and the link LED (if present) is active
2. Check physical cable connections — for RS-485, verify A/B polarity
3. Confirm the slave ID matches the device configuration
4. For serial: double-check baud rate, parity, data bits, and stop bits against the device manual
5. For TCP: verify IP address, port, and network connectivity (try ping first)
6. Try increasing the timeout value — some devices respond slowly
7. Use an address scanner to discover devices on the serial bus

Error 2: CRC/LRC Errors

CRC errors in RTU mode (or LRC errors in ASCII mode) mean the received data is corrupted — the error-check value doesn't match the data.

Possible Causes

• Serial parameter mismatch — Most commonly wrong parity or stop bits
• Electrical noise — EMI from motors, VFDs, or power lines interfering with the serial signal
• Cable too long — RS-485 signal degradation beyond recommended distance
• Missing termination — RS-485 networks over ~50m need 120-ohm termination resistors at both ends
• Baud rate mismatch — Sending at 19200 while device expects 9600 will produce garbage data
• Multiple masters — Two masters transmitting simultaneously on the same serial bus

How to Fix

1. Verify all serial parameters match exactly between master and slave
2. Check for sources of electrical noise near the serial cable — route away from power cables and VFDs
3. Use shielded cable for RS-485 runs, especially in industrial environments
4. Add 120-ohm termination resistors at both ends of the RS-485 bus
5. Ensure only one master is active on the serial bus
6. Use the communication logger in your testing tool to view the raw TX/RX data and identify where corruption occurs

Error 3: Illegal Function (Exception Code 01)

The device received the request but doesn't support the requested function code.

Possible Causes

• Using FC03 (Read Holding Registers) on a device that only supports FC04 (Read Input Registers) for that data
• Trying an advanced function code (FC22, FC23, FC43) on a device that only implements basic functions
• Firmware version doesn't support the requested function

How to Fix

1. Check the device documentation for supported function codes
2. Try the alternative function code — if FC03 fails, try FC04 and vice versa
3. Stick to basic function codes (FC01–FC06, FC15, FC16) for maximum compatibility

Error 4: Illegal Data Address (Exception Code 02)

The device doesn't have a register at the requested address.

Possible Causes

• Off-by-one error — Device documentation uses 1-based addressing (40001) but you entered 0-based address (0) when it should be 1, or vice versa
• Address out of range — Requesting register 500 when the device only has registers 0–99
• Quantity too large — Starting at address 90 and requesting 20 registers goes beyond the device's address space
• Wrong register type — Trying to read a coil address as a holding register

How to Fix

1. Check whether the device documentation uses 0-based or 1-based addressing
2. Verify the register address exists in the device's register map
3. Reduce the quantity to stay within the valid address range
4. Try reading a small range (1–5 registers) starting from address 0 to confirm basic communication works

For more on addressing conventions, see Modbus register types explained.

Error 5: Data Looks Wrong or Random

Communication succeeds but the values don't make sense — they look random, are way too large, or don't change when they should.

Possible Causes

• Wrong display format — Viewing a 32-bit float as two unsigned 16-bit integers
• Wrong byte order — The device uses Little Endian but you're reading Big Endian (or vice versa)
• Wrong register — You're reading the right address but it holds different data than expected
• Scaling not applied — Raw value 2345 might mean 23.45 with a scale factor of 0.01

How to Fix

1. Try different display formats: unsigned, signed, hex, float32
2. For 32-bit values, cycle through all 4 byte orders (AB CD, CD AB, BA DC, DC BA) until the value makes sense
3. Check the device documentation for scaling factors and apply them
4. Write a known value to a holding register, then read it back to verify the byte order

Error 6: Intermittent Communication Drops

Communication works but drops out periodically — some polls succeed, others timeout.

Possible Causes

• Poll rate too fast — Slave device can't respond fast enough, especially on slow serial links
• Bus contention — Multiple masters or devices conflicting on RS-485
• Loose connections — Intermittent contact in terminals or connectors
• Network congestion — For TCP, high network traffic causing delays
• Device overload — Polling too many registers in a single request

How to Fix

1. Slow down the scan rate (increase the interval between polls)
2. Reduce the number of registers per request
3. Check and tighten all terminal connections
4. For TCP, increase the response timeout
5. Monitor with a communication logger to see if requests are being sent correctly but responses are missing or late

Error 7: Gateway Errors (Exception Codes 0A/0B)

These errors occur when using a Modbus TCP-to-serial gateway to reach RTU devices over Ethernet.

Gateway Path Unavailable (0A)

The gateway itself can't establish a connection to the serial port or the target network. Check the gateway's serial port configuration, cable, and ensure the serial port isn't being used by another application.

Gateway Target Failed to Respond (0B)

The gateway successfully received the TCP request and forwarded it to the serial bus, but the target slave didn't respond. This is essentially a timeout on the serial side. Check the slave ID, serial settings, and physical connection between the gateway and the slave device.

Troubleshooting Workflow

When you encounter a Modbus issue, follow this systematic approach:

1. Check the physical layer first — Power, cables, LEDs, connectors
2. Verify connection parameters — IP/port or COM port and serial settings
3. Try the simplest request — Read 1 holding register at address 0 from slave ID 1
4. Check the error message — Timeout means no response; exception code tells you what went wrong
5. Enable communication logging — View raw TX/RX data to see exactly what's on the wire
6. Try an address scan — Discover which slave IDs respond on the bus
7. Isolate the problem — Test with one device at a time, one function at a time
8. Check the device manual — Verify supported function codes, address ranges, and communication parameters

For general background on the protocol, see What is Modbus Protocol. For help choosing the right testing tool, check our Modbus simulator comparison.