"Timeout" means your Modbus master sent a request and the slave never answered. This is the single most common Modbus problem, and frustratingly, it can be caused by dozens of different things — from a crossed wire to a wrong slave ID. This guide gives you a systematic way to find the cause.
A timeout means nothing came back. Not an error, not bad data — absolute silence. This rules out all data-level problems (byte order, wrong registers) and points exclusively to physical layer, configuration, or addressing issues.
What a Timeout Actually Means
Your master sent a correctly formed Modbus frame on the wire (or over TCP) and waited for the configured timeout period without receiving any bytes in response. The slave either didn't hear the request, heard it but didn't recognise it as addressed to itself, or heard it but couldn't respond.
RS485 RTU — Check These First
1. Wiring polarity
RS485 A/B labelling is not consistent between manufacturers. ABB calls them A(+) and B(-), but Schneider and some Phoenix Contact devices use the opposite convention. If you're getting complete silence, try swapping A and B. It won't damage anything and it's the cause roughly 30% of the time.
2. Slave address
Modbus slaves only respond to their own address. If the device is set to ID 3 and you're polling ID 1, you'll get silence. Check the device's front panel or configuration software for the actual slave ID. Don't assume it's 1 — many devices default to higher numbers or even 0 (which is the broadcast address and never gets a response by definition).
3. Communication parameters
Baud rate, parity, data bits, and stop bits must match exactly on both ends. The most common RS485 settings are 9600/8/N/1 or 19200/8/E/1. Some devices won't apply parameter changes until power-cycled.
4. Termination resistors
For cable runs over 10 metres, you need 120Ω termination resistors at both ends of the RS485 bus. Missing termination causes reflections that corrupt frames, and the slave won't respond to a corrupted request.
5. Signal ground
RS485 is often called "2-wire" but actually needs a ground reference. Without a common ground between master and slave, the differential signal has no reference and communication fails intermittently or completely.
TCP/IP — Check These First
1. Ping the device
If you can't ping the slave's IP address, Modbus TCP won't work either. Check IP address, subnet mask, and gateway. Ensure you're on the same VLAN/subnet.
2. Port 502
Modbus TCP defaults to port 502. Some devices use non-standard ports. Check the device's network configuration.
3. Unit ID
Modbus TCP still uses a Unit ID in the MBAP header. Most standalone devices expect Unit ID 1, but gateways and multi-device systems need the correct ID for each slave behind the gateway.
4. Maximum connections
Many Modbus TCP devices have a limit on simultaneous TCP connections (often 2-5). If your SCADA system, an engineer's laptop, and a commissioning tool are all connected, the device may reject new connections silently.
Diagnostic Flowchart
For RTU: check wiring continuity with a multimeter. For TCP: can you ping it?
Many devices have Modbus disabled by default. Check the device's communication settings menu.
RTU: baud rate, parity, data bits, stop bits. TCP: IP, port, Unit ID.
Send a simple read request (FC03, register 0, quantity 1) to every slave ID from 1-247.
Find any slave in seconds
ModBus Pro's network scanner probes slave addresses across configurable address ranges to find connected devices quickly. What takes 30 minutes manually takes seconds with Auto-Scan.
Download FreeAdvanced Diagnostics
Use a USB-to-RS485 analyser
If you can see your master's TX frames but no RX, the problem is between the wire and the slave. If you can't even see TX, the problem is your master's serial port or driver.
Check for bus contention
If you have multiple masters on the same RS485 bus, their transmissions will collide. Modbus RS485 supports only one master. Use a Modbus TCP gateway if you need multiple clients polling the same devices.
Increase timeout value
Some slow devices (especially older power meters) need 1-2 seconds to respond. If your timeout is 100ms, the response arrives after the master has given up. Start with a 2-second timeout and reduce once communication is stable.