Modbus Slave Not Responding — 8 Causes and Fixes (2026)

You send a Modbus request. The timeout fires. No response. You send it again. Same result. If you're commissioning a new device or debugging a system that worked last week, the silence from the slave is frustrating precisely because it gives you nothing to work with — no error message, no exception code, just a dead channel.

This guide covers the eight most common reasons a Modbus slave stops responding, in order from most frequent to least, with exact diagnostic steps and fixes for each. Both RTU and TCP variants are covered. At the end, there's a section on using ModbusSimulator as a controlled slave to isolate whether the problem is in your master configuration, the physical layer, or the actual field device.

How "No Response" Differs from an Exception Code

Before getting into causes, it's important to separate two fundamentally different failure modes that get lumped together as "slave not responding."

No response / timeout: The master sent a request and received nothing within the timeout window. The slave either didn't receive the request, didn't recognize it as addressed to itself, or couldn't process it in time. On Modbus RTU, this is silence on the wire. On Modbus TCP, the TCP connection may be established but no Modbus response PDU arrives.

Exception response: The slave did respond, but with an error. Exception Code 01 (Illegal Function), Exception Code 02 (Illegal Data Address), Exception Code 03 (Illegal Data Value), Exception Code 04 (Slave Device Failure). These are not timeouts — they are valid Modbus responses indicating a specific problem. An exception response is actually useful: it tells you exactly what the slave rejected and why.

Distinguishing these two is the first step in any diagnosis. Enable raw communication logging in your master software and check whether you're getting any bytes back at all.

Cause 1: Wrong Unit ID / Slave Address

This is the single most common cause of Modbus RTU "no response" on a newly commissioned system. In Modbus RTU, every request frame starts with a one-byte slave address (1–247). The slave only processes frames addressed to its own ID. If you send to unit ID 1 and the device is configured for unit ID 5, it silently discards your frame. You get a timeout.

On Modbus TCP, the unit ID field exists in the MBAP header (byte 7 of the header) but most TCP-native devices accept any unit ID (typically ignore it or respond to ID 255 and ID 1). However, Modbus TCP-to-RTU gateways use the unit ID to route requests to the correct serial slave behind the gateway — and here, a wrong unit ID produces exactly the same silent failure as on RTU.

What you see: Request transmitted, no response, timeout exception in the master log. No exception code from the slave. If you enable a bus monitor on RS-485, you can see your TX frame on the wire but no RX frame follows.

Fix: Verify the slave's configured address from its physical configuration — DIP switches on the front panel, rotary address switch, or the device configuration menu. If you don't know the address, run a unit ID scan: poll each address from 1 to 247 with a short timeout (300ms) and log which ones respond. Most Modbus master tools include an address scan feature. Once you find the correct ID, update your master configuration.

Note on Exception Code 01 vs. silence: Some devices return Exception Code 01 (Illegal Function) for unknown unit IDs rather than staying silent. This behavior is non-standard, but you'll encounter it on certain energy meters and gateway devices. If you see Exception 01 but you know you're using a supported function code, check the unit ID first.

Cause 2: Wrong Register Address (Exception Code 02)

If the slave responds but with Exception Code 02 (Illegal Data Address), the unit ID is correct and the function code is supported, but the register or coil address you requested doesn't exist in the slave's address map.

The single biggest source of register address errors in Modbus is the difference between PDU addressing (zero-based, 0x0000–0xFFFF, what goes on the wire) and display addressing (the 40001, 30001, etc. notation used in most documentation and tools). The "4" prefix in 40001 means holding register; the register PDU address is 40001 minus 40001 = 0, or more generally, the last four digits minus 1.

This means "holding register 40001" has PDU address 0x0000. "Holding register 40100" has PDU address 0x0063. If your master sends PDU address 100 (0x0064) for what you think is register 40100, you're actually requesting register 40101 in display notation. Off-by-one errors in Modbus register addressing are endemic.

Fix: Check the device's register map documentation and confirm whether addresses are listed as PDU (zero-based) or display (one-based with type prefix). Enable raw TX/RX logging in your master and verify the exact hex bytes being sent. The register address in an FC03 request is bytes 3–4 of the PDU (after the function code byte). Cross-reference this against the device manual's "Register Address" column — and confirm whether that column lists PDU addresses or display addresses.

For a deeper explanation of register types and addressing conventions, see Modbus register types explained.

Cause 3: Serial Port Misconfiguration (RTU)

Modbus RTU runs over serial. Every device on the bus must use identical serial parameters: baud rate, parity, data bits, and stop bits. One parameter out of sync and the receiving device sees garbage instead of a valid Modbus frame. It either silently discards the garbage or the CRC check fails and it ignores the frame. Either way, you get no response.

The Modbus specification recommends Even parity with 1 stop bit as the default, but the most common real-world default across industrial devices is 9600 baud, 8 data bits, No parity, 1 stop bit (9600 8N1). Many drives, energy meters, and I/O modules ship with different defaults. Always verify against the specific device manual — don't assume.

Parameter	Common Values	Notes
Baud rate	9600, 19200, 38400, 57600, 115200	Must match exactly — a 9600/19200 mismatch gives framing errors or silence
Data bits	8 (RTU), 7 (ASCII mode only)	Always 8 for Modbus RTU; 7 is only valid for Modbus ASCII
Parity	None, Even, Odd	Even is the spec default; None is the most common field default
Stop bits	1, 2	Use 2 stop bits when parity is None (per spec); 1 when parity is Even or Odd

Fix: Start with 9600 8N1 as the baseline. If no response, try 9600 8E1 (Even parity). If still no response, consult the device manual for the factory default and match it exactly. On a USB-to-RS485 adapter, verify the COM port is not also configured with the wrong settings in Windows Device Manager (right-click the COM port → Properties → Port Settings).

Cause 4: RS-485 Wiring Issues

RS-485 is a differential signaling standard, robust in theory, but the physical layer in the field is a common source of intermittent and complete communication failures. Four specific wiring problems account for most field issues.

A/B Polarity Reversal

RS-485 uses two wires: A (negative, D−) and B (positive, D+). The Modbus specification defines A as the negative conductor, but many industrial device manufacturers reverse this labeling — their "A" terminal is the positive wire. When you mix devices from different manufacturers on the same bus, you can easily end up with inverted polarity.

Reversed polarity produces complete communication failure: no response at all, even though every other parameter is correct. The fix is simple — swap the two wires. In the field, if you've verified everything else and still have no response, swapping A and B is a valid and fast diagnostic step.

Missing Termination Resistors

RS-485 buses longer than approximately 10–15 meters require 120-ohm termination resistors at both physical ends of the cable run. Without termination, the signal reflects off the end of the cable and interferes with subsequent bits, causing framing errors, CRC failures, and intermittent no-response conditions. The problem worsens at higher baud rates.

Place one 120-ohm resistor between A and B at each physical end of the bus. Many PLCs and RS-485 converters include a switchable onboard termination resistor — enable it only on the two endpoints. Never enable termination on intermediate nodes.

Missing Bias Resistors

When no device on the RS-485 bus is transmitting (bus idle state), the differential pair floats. A floating bus can pick up electrical noise and generate false start bits, corrupting the next legitimate frame. Bias resistors (typically 560 ohms, pull-up on B, pull-down on A) hold the bus in a defined idle state between transmissions.

Many RS-485 converters include bias resistors internally. If you are building a custom circuit or using bare RS-485 transceivers, add bias resistors at one point on the bus (typically at the master end). Do not add them at every node — the combined parallel resistance would be too low.

Missing Signal Ground

RS-485 is a differential pair but still requires a common reference ground between all devices. Without a third conductor (signal GND), the common-mode voltage can exceed the RS-485 receiver's input range (±7V for standard RS-485), causing intermittent errors or complete failure. Use three-conductor cable (A, B, GND) and connect the GND to the chassis or signal ground at each device. Ground the cable shield at one point only to avoid ground loops.

Cause 5: TCP Firewall Blocking Port 502

For Modbus TCP, the TCP connection itself may succeed (the TCP handshake completes, which is why this is different from a connection refused error) but the slave application is blocked from sending Modbus responses back by a firewall rule. This is less common but happens in enterprise environments where bidirectional rules are applied asymmetrically.

More commonly on Modbus TCP: the firewall blocks the initial connection attempt on port 502. If your master can ping the slave IP but can't establish a Modbus session, the firewall on the slave host (Windows Defender, iptables) or a network-layer device (managed switch ACL, router firewall) is blocking port 502.

Fix: On the slave machine (Windows), open Windows Defender Firewall → Advanced Settings → Inbound Rules and verify there is an explicit "Allow" rule for TCP port 502. If no such rule exists, create one. On Linux, check iptables or ufw rules. For network-layer firewalls, work with your network team to add a permit rule for TCP port 502 between the master and slave IP addresses.

Quick test from the master: Test-NetConnection -ComputerName 192.168.1.100 -Port 502 in PowerShell. If TcpTestSucceeded is False, the port is blocked before you even send a Modbus frame. For a complete guide to TCP connectivity issues, see Modbus TCP/IP setup guide.

Cause 6: Slave Response Timeout Too Short on the Master

The master waits for a slave response for a configured period — the response timeout. If the slave processes the request and sends a valid response, but the master's timeout expires before the response arrives, the master logs a "no response" error even though the slave did everything correctly.

This is common in three scenarios:

• PLC with a slow scan cycle: A PLC running a 200ms scan cycle may take up to 200ms just to process the incoming request before formulating a response. Add the serial transmission time and you can easily exceed a 300ms master timeout.
• Energy meters and analyzers: Devices performing real-time power calculations sometimes pause request processing during a measurement cycle. Response times of 500ms–1500ms are not unusual for certain energy meter models.
• High-latency TCP paths: Modbus TCP over WAN links, VPNs, or cellular gateways introduces latency. A 1-second master timeout may be insufficient for a cellular-connected device with 200–400ms round-trip time.

Fix: Increase the master's response timeout. Start with 2000ms and observe whether the slave starts responding. Check the device datasheet for the maximum expected response time. If the device specifies a maximum processing time of, for example, 800ms, set your master timeout to at least 1500ms to leave margin. Do not set the timeout lower than the device's specified maximum response time.

Cause 7: Broadcast Address Confusion (Unit ID 0)

In Modbus RTU, unit ID 0 is the broadcast address. A request sent to unit ID 0 is addressed to all slaves simultaneously. The Modbus specification states that slaves do not respond to broadcast messages. This is intentional — with multiple slaves on a bus, simultaneous responses would collide and destroy each other.

If your master is configured with unit ID 0 (or if a configuration tool interprets an empty/default unit ID field as 0), you'll transmit frames that every slave receives but none replies to. The result looks identical to a complete communication failure.

What you see: If you enable a bus monitor on the RS-485 line, you can see the TX frame with source address 00 in byte 1. But no RX frame follows, because broadcast responses are prohibited.

Fix: Set the unit ID to the slave's actual configured address (1–247). Unit ID 0 should only be used intentionally for write-only broadcast operations where you need to write the same value to all slaves simultaneously and don't need confirmation. It is never valid for read requests or any request where you expect a response.

Cause 8: Master Polling Too Fast (Slave Can't Keep Up)

Modbus RTU is a strict master-slave, half-duplex protocol. The master sends a request and must wait for the slave to respond before sending the next request. If the master is polling multiple slaves or multiple registers in a tight loop with no inter-request delay, it may transmit a new request to a slave before that slave has finished processing and transmitting its response to the previous request. The collision destroys both frames.

On Modbus TCP, some embedded devices have limited Modbus application layer processing capacity. If your master is sending requests at 10 per second and the slave can only process 2 per second, the slave's request queue fills up and it starts dropping requests silently.

What you see: Intermittent responses at high polling rates. Lowering the poll rate dramatically improves response rates. On RTU, a bus monitor may show overlapping TX and RX frames.

Fix: Add an inter-request delay between Modbus transactions. For RTU, the Modbus specification defines a minimum silent interval of 3.5 character times between frames — most well-implemented masters handle this automatically, but some aggressive implementations violate it. A practical starting point is a 50ms inter-request delay on RTU and 100ms on slow embedded TCP devices. Check the device datasheet for the minimum inter-request gap if specified.

Step-by-Step Troubleshooting Checklist

1. Enable raw communication logging in your master software. Confirm TX bytes are being sent. If TX is present but RX is empty, the slave isn't responding. If TX is absent, your COM port or TCP connection isn't working at all — fix that first.
2. Check the unit ID. Verify the slave's configured address from its physical hardware (DIP switches, rotary switch, display menu). Confirm your master is using that exact ID. Run an address scan (1–247) if unknown.
3. For Modbus TCP: confirm connectivity. Ping the slave IP. Run Test-NetConnection -ComputerName <ip> -Port 502. If the TCP port isn't reachable, resolve the network or firewall issue before troubleshooting Modbus.
4. For Modbus RTU: verify serial parameters. Baud rate, parity, data bits, stop bits must all match the device's documented settings. Try 9600 8N1 as a starting point if unknown.
5. Check RS-485 wiring. Verify A/B polarity. If uncertain, swap the two wires and retry. Confirm 120-ohm termination resistors are present at both physical ends of the bus. Confirm signal GND is connected between master and slave.
6. Increase the master response timeout to 2000ms or higher. If the slave starts responding, the previous timeout was too short. Check device datasheet for the specified maximum response time.
7. Verify the register address. If you're getting Exception Code 02, confirm the PDU address vs. display address conversion. Check the device register map for the exact PDU address of the register you need.
8. Check that unit ID is not 0. If set to 0, change it to the actual slave address. Slaves never respond to broadcasts.
9. Reduce polling rate. If responses are intermittent, add 100ms inter-request delay and observe whether reliability improves. For RTU, ensure your master enforces the 3.5-character silent interval between frames.
10. Substitute ModbusSimulator as the slave. Configure it with the same unit ID and a basic register map. If your master reads from the simulator but not from the real device, your master configuration is correct and the problem is in the field device or physical connection. If the master fails against the simulator too, the problem is in your master software or configuration.

Symptom → Likely Cause → Fix

Symptom	Likely Cause	First Fix
Timeout, no bytes received on RTU	Wrong unit ID, wrong baud rate, or A/B polarity reversed	Verify unit ID from hardware; try swapping A/B wires
Exception Code 01 (Illegal Function)	Function code not supported by this slave, or unit ID mismatch on some devices	Confirm supported FCs in device manual; verify unit ID
Exception Code 02 (Illegal Data Address)	Register address out of range or PDU vs. display address confusion	Cross-check device register map; verify zero-based PDU address
Intermittent responses on RTU	Missing termination or bias resistors, marginal wiring, or master polling too fast	Add 120-ohm termination at bus ends; add inter-request delay
TCP connection succeeds but no Modbus response	Wrong unit ID (on gateway), slave overloaded, or firewall blocking response	Check unit ID in MBAP header; check slave CPU/connection load
Works at slow poll rate, fails at fast poll rate	Slave can't process requests fast enough; response collisions on RTU	Increase inter-request delay; check slave's minimum inter-request gap
Unit ID 0, no response to any request	Broadcast address — slaves are prohibited from responding	Change unit ID to actual slave address (1–247)
Timeout only on long cable runs at higher baud rates	Signal reflections from missing termination; cable attenuation	Install 120-ohm resistors at both cable ends; reduce baud rate

Python pymodbus Example: Catching Modbus Exceptions

When diagnosing Modbus issues programmatically, proper exception handling lets you distinguish between a timeout (no response) and an exception response (slave responded with an error code). The following example uses pymodbus 3.x:

from pymodbus.client import ModbusTcpClient
from pymodbus.exceptions import ModbusException, ConnectionException
from pymodbus.pdu import ExceptionResponse

SLAVE_IP = "192.168.1.100"
SLAVE_PORT = 502
UNIT_ID = 1
REGISTER_ADDRESS = 0      # PDU address (zero-based)
REGISTER_COUNT = 10
TIMEOUT = 2.0             # seconds — increase if slave is slow

client = ModbusTcpClient(
    host=SLAVE_IP,
    port=SLAVE_PORT,
    timeout=TIMEOUT
)

try:
    if not client.connect():
        print(f"[ERROR] TCP connection failed to {SLAVE_IP}:{SLAVE_PORT}")
        print("Check: IP address, port 502, firewall rules.")
    else:
        print(f"[OK] Connected to {SLAVE_IP}:{SLAVE_PORT}")

        result = client.read_holding_registers(
            address=REGISTER_ADDRESS,
            count=REGISTER_COUNT,
            slave=UNIT_ID
        )

        if result is None:
            # No response — timeout
            print(f"[TIMEOUT] No response from unit ID {UNIT_ID}")
            print("Check: unit ID, baud rate/parity (RTU), RS-485 wiring, response timeout.")

        elif isinstance(result, ExceptionResponse):
            # Slave responded with a Modbus exception code
            exc_code = result.exception_code
            exc_map = {
                1: "Illegal Function — FC not supported by this slave",
                2: "Illegal Data Address — register address out of range",
                3: "Illegal Data Value — quantity or value out of range",
                4: "Slave Device Failure — internal slave error",
            }
            reason = exc_map.get(exc_code, f"Unknown exception code {exc_code}")
            print(f"[EXCEPTION] Modbus Exception Code 0{exc_code}: {reason}")
            print(f"  Unit ID: {UNIT_ID}  |  Register: {REGISTER_ADDRESS}  |  Count: {REGISTER_COUNT}")

        elif result.isError():
            print(f"[ERROR] Modbus error response: {result}")

        else:
            # Success
            registers = result.registers
            print(f"[OK] Read {len(registers)} registers from unit {UNIT_ID}:")
            for i, val in enumerate(registers):
                print(f"  Register {REGISTER_ADDRESS + i} (display {40001 + REGISTER_ADDRESS + i}): {val}")

except ConnectionException as e:
    print(f"[CONNECTION ERROR] {e}")
    print("Check: network path, port 502 not blocked by firewall.")

except ModbusException as e:
    print(f"[MODBUS ERROR] {e}")

finally:
    client.close()

The key distinction in this code is between a None result (timeout — no response from the slave at all), an ExceptionResponse (the slave responded with an error code), and a valid result with register data. These three outcomes point to completely different root causes and require different diagnostic paths.

Using ModbusSimulator to Verify Your Master Configuration

When you're dealing with a slave that isn't responding, one of the fastest ways to narrow down the cause is to replace the slave with a known-good simulation. ModbusSimulator runs as a Modbus TCP or RTU slave on your Windows PC, giving you a controllable baseline to test against.

Scenario: Master Can't Read from the Real Device

Start ModbusSimulator in Slave mode. Set the unit ID to match what you're using in your master. Configure a few holding registers with test values. For TCP, set it to listen on port 502. For RTU, connect a USB-to-RS485 adapter and configure the matching serial parameters.

Now run your master against the simulator instead of the real device. If the master reads successfully from the simulator, your master configuration (unit ID, register addresses, function codes, serial settings) is correct. The problem is in the real device or the physical path to it. If the master fails even against the simulator, the problem is in the master software, its COM port configuration, or its TCP connectivity.

This split eliminates half the variable space in a single test. It's faster than chasing individual settings one at a time in the field.

ModbusSimulator's communication log shows every raw TX and RX frame in hex, which lets you verify the exact bytes being exchanged. You can confirm the unit ID byte, function code, register address, and CRC directly from the log without needing a separate bus analyzer.

Frequently Asked Questions

What does "Modbus slave not responding" mean?

The master sent a valid Modbus request and received no reply within the configured timeout period. The cause can be anywhere in the stack: wrong unit ID (the slave ignored the request because it wasn't addressed to it), physical layer failure (RS-485 wiring, baud rate mismatch), network layer failure (firewall, wrong IP), or the slave device being overloaded. A timeout is different from an exception response — exception codes mean the slave did respond, but with an error.

What is Modbus Exception Code 01 and what causes it?

Exception Code 01 (Illegal Function) means the slave received the request but does not support the function code used. Requesting FC03 from a device that only supports FC01/FC02 returns Exception 01. Some devices also return Exception 01 when the unit ID matches but the request is otherwise invalid — check the device manual for its specific behavior.

What is Modbus Exception Code 02 and what causes it?

Exception Code 02 (Illegal Data Address) means the register or coil address you requested doesn't exist in the slave's address map. This is frequently caused by off-by-one errors from PDU vs. display address confusion. The PDU address is zero-based; display addresses like 40001 require subtracting 40001 to get PDU address 0. Verify the exact PDU address in your master's raw communication log and compare it against the device's register table.

How do I find the correct unit ID of a Modbus slave?

Check the device's physical configuration: DIP switches, rotary address switches, or the device configuration menu. If the ID is unknown, run a Modbus address scan — poll unit IDs 1 through 247 sequentially with a short timeout and record which ones respond. Most Modbus master tools include a scan function. ModbusSimulator's address scanner automates this.

Why does my Modbus slave respond intermittently?

Intermittent responses on RTU are almost always RS-485 wiring: missing termination causing signal reflections, missing bias resistors causing bus float, or marginal common-mode voltage from a missing signal ground. On Modbus TCP, intermittent failures usually point to the slave running out of connection slots, or its CPU being overloaded by too many concurrent requests. Reduce polling frequency and check the slave's active connection count.

What is the correct response timeout for Modbus RTU?

The specification doesn't mandate a specific value. Common practice starts at 1000ms. Slow PLC scan cycles and energy meters with complex calculations can require 1500ms or more. If you see intermittent timeouts, increase the master timeout to 2000ms first and observe. Never go below 500ms without vendor confirmation of the device's maximum response time.

Can I use ModbusSimulator to test my master configuration before connecting to the real device?

Yes. Configure ModbusSimulator as a slave with the same unit ID and register map as your target device, then connect your master to it. If the master reads correctly from the simulator but not from the real device, the master configuration is correct and the problem is in the real device or physical connection. Download the free trial to get started.