A Modbus RTU timeout tells you one simple thing: the master sent a request and did not receive a usable reply before its response timer expired.
Unfortunately, that does not tell you why.
The slave may be switched off. The address could be wrong. A and B may be reversed. The master might be sending the wrong parity, or the reply may be reaching the cable but failing its CRC check.
Replacing hardware at random rarely helps. A better approach is to divide the problem into three layers:
- Is the request actually being transmitted?
- Can the electrical signal reach the slave and return?
- Is the request valid for that device?
Work through those questions in order and most Modbus RTU faults become much easier to isolate.
First, Understand What “No Response” Means
A valid Modbus request can produce three broad results:
- A normal response
- A Modbus exception response
- No accepted response at all
An exception response is not the same as a timeout. If the slave returns exception code 01, 02 or 03, communication is already working. The device received the request and understood enough of it to report an illegal function, illegal address or illegal value.
A timeout usually points toward one of the following:
- No request was transmitted
- The wrong slave address was used
- Serial settings do not match
- RS-485 wiring is incorrect
- The slave is not powered or communication is disabled
- The request frame is corrupted
- The reply arrives too late
- The master receives bytes but rejects them
That distinction matters. Do not troubleshoot register addressing before proving that basic communication exists.
Step 1: Check Whether the Master Is Transmitting
Begin at the master.
Look for transmit and receive indicators on the PLC communication module, converter, gateway or device. Many adapters have separate TX and RX LEDs.
When a request is made:
- The TX light should flash
- The master’s transmitted-message counter should increase
- The communication block should become busy briefly
- A timeout or error should appear only after the response timer expires
If nothing is transmitted, the fault is on the master side.
Check whether:
- The correct serial port is selected
- The port has been initialised
- The communication block is being executed
- The request trigger receives a rising edge if one is required
- Another program or application has locked the COM port
- The correct RS-485 adapter is selected
- The port is configured for Modbus RTU rather than Modbus ASCII or another protocol
For PLC applications, watch the communication block online. Confirm that its request input changes, its busy output operates and its status code updates.
Step 2: Reduce the Network to One Slave
A large RS-485 network introduces too many possible causes at once.
Disconnect the other slave devices and test only:
- One master
- One slave
- One short cable
Temporarily use a slower, common baud rate such as 9,600 or 19,200 bit/s if both devices support it.
This simple test removes problems caused by duplicate addresses, excessive termination, damaged field cabling, long stubs and interference from another device.
Once the single device communicates reliably, reconnect the remaining network one section at a time.
Step 3: Confirm the Slave Is Powered and Enabled
Do not assume the device is ready simply because its display is illuminated.
Check the slave’s local menu or parameter list. Confirm:
- Modbus RTU is enabled
- The correct communication port is active
- The device is operating as a slave/server
- The RS-485 option card is detected
- Changes have been saved
- A restart is not required after changing settings
Some drives, meters and instruments can assign their serial port to several protocols. If the port is set to USS, BACnet, proprietary ASCII communication or “None,” it will ignore a Modbus request completely.
Also check whether communication is disabled while the device is in a setup, bootloader or fault state.
Step 4: Verify the Slave Address
Every device on the serial network needs a unique address.
Standard Modbus serial slave addresses run from 1 to 247. Address 0 is reserved for broadcast requests. A slave does not return a response to a broadcast, so polling address 0 will produce what looks like a permanent timeout.
Read the address directly from the slave rather than trusting an old drawing or PLC comment.
Be especially careful when the address is selected using DIP switches. Check:
- Whether the switches use binary values
- Whether ON means 1 or 0
- Whether the switch positions are read only during startup
- Whether a software parameter overrides the physical switches
Duplicate slave addresses can also create strange results. Two devices may reply at the same time, corrupting both responses.
Step 5: Match Every Serial Setting
The master and slave must use the same communication format.
Compare these settings one by one:
- Baud rate
- Number of data bits
- Parity
- Number of stop bits
- RTU or ASCII mode
Common configurations include:
- 9,600, 8E1
- 19,200, 8E1
- 9,600, 8N1
- 19,200, 8N2
There is no universal setting that works with every device. Use the manufacturer’s manual.
A difference as small as even parity on one device and no parity on the other can prevent communication. Official equipment guidance likewise requires the protocol, baud rate, parity and stop-bit settings to match across the serial network.
After changing the slave settings, cycle its power when the manual requires it. Some devices display the new value immediately but continue using the old setting until restarted.
Step 6: Inspect the RS-485 Wiring
For a two-wire RS-485 connection, the devices normally need:
- One differential data pair
- A signal common or reference conductor where specified
- A shield where required by the installation instructions
The difficult part is the terminal naming.
Manufacturers do not always use A and B consistently. One manual may describe A as positive, while another device uses A for the opposite signal. You may also see:
- D+ and D–
- Data+ and Data–
- D1 and D0
- P and N
- A/+ and B/–
Do not connect terminals based only on the letters. Compare the signal descriptions in both manuals.
If the settings are correct but there is still no response, reversing the two data conductors is a useful diagnostic test. Isolate power first where necessary and make sure the RS-485 terminals are not accidentally exposed to the device’s supply voltage.
Check for loose terminals, broken conductors and connections landed one position away from the correct terminal. It happens more often than anyone likes to admit.
Step 7: Check the Common Reference and Shield
RS-485 uses a differential signal, but that does not mean the devices can tolerate an unlimited difference in ground potential.
Where the manufacturers provide a signal-common terminal, connect the reference conductor according to their wiring diagrams. Siemens documentation, for example, specifies connecting the potential references of externally supplied RS-485 devices for reliable operation.
The cable shield is normally used to control electrical noise. Follow the equipment and site grounding instructions rather than treating the shield as the signal common.
Never assume that protective earth, cable shield and communication common are interchangeable.
Step 8: Correct the Topology and Termination
RS-485 works best as a bus or daisy chain, not as a star network.
The main cable should run from device to device, with short branches. Long star branches create reflections and distorted signals, particularly at higher baud rates and over longer cable distances.
Termination belongs at the two physical ends of the RS-485 bus—not on every device. The Modbus serial implementation guide requires termination near both ends and warns against installing more than two terminating networks on one passive pair.
Many devices have built-in termination switches. Check all of them. A network with five enabled terminators can be just as troublesome as one with none.
Bias or polarization resistors may also be required to hold the idle bus in a known state. Normally only one network location should provide this bias. Enabling biasing in several devices unnecessarily loads the bus.
Step 9: Test a Simple, Known Register
Once the physical connection looks correct, use the simplest valid request supported by the slave.
A good starting point is often:
- Read Holding Registers, function 03
- Read Input Registers, function 04
- One register only
- A documented, always-available address
Do not begin with a 50-register write command or a rarely used diagnostic function.
Check the device’s Modbus register map carefully. A value shown in the manual as register 40001 may need to be entered into the software as:
- 40001
- 1
- 0
Modbus protocol addresses begin at zero, while many manufacturer tables number displayed registers from one. The official Modbus addressing model shows that data item X is transmitted in the protocol as address X minus one.
This offset causes countless commissioning delays.
Also verify that you selected the correct function code. Register 30001 normally suggests an input register, while 40001 normally suggests a holding register, but manufacturer documentation takes priority over assumptions.
Step 10: Use a PC Test Tool
A USB-to-RS-485 converter and a Modbus polling application can quickly separate a PLC programming problem from a field-device problem.
Connect the PC directly to the slave and enter:
- Slave address
- Baud rate
- Parity
- Stop bits
- Function code
- Register address
- Quantity
If the PC communicates but the PLC does not, the slave and basic wiring are probably functional. Focus on the PLC configuration, request format and communication-block logic.
If neither the PC nor PLC receives a reply, concentrate on the slave settings, wiring and physical network.
A serial analyser is even more useful because it shows the raw transmitted and received bytes.
Step 11: Check Timing and Response Timeout
Modbus RTU identifies frame boundaries using silent intervals.
At baud rates up to 19,200 bit/s, frames should be separated by at least 3.5 character times, and a gap longer than 1.5 character times inside a frame can cause the receiver to reject it as incomplete.
Timing problems may appear when:
- A USB converter delays individual bytes
- A gateway adds processing time
- The PLC sends requests too rapidly
- The slave is slow while processing a command
- Two masters attempt to use the same bus
- The response timeout is set too low
Increase the timeout temporarily and insert a reasonable delay between requests. Do not continuously trigger a new request while the previous one is still busy.
Step 12: Look Beyond the Timeout Message
A master may physically receive a response and still report “no response” because the frame was rejected.
Possible reasons include:
- CRC failure
- Wrong slave address in the reply
- Incorrect response length
- Parity or framing errors
- The reply arrived after the timeout
- Noise corrupted one or more bytes
- The master was still controlling the RS-485 transmitter when the slave began replying
Check receive counters and diagnostic buffers. An increasing RX counter with no valid responses is a major clue: wiring may be partly correct, but the returned frames are unusable.
A Fast Troubleshooting Order
When time is limited, use this sequence:
- Confirm the master transmits.
- Connect only one slave.
- Verify that the slave is powered and Modbus RTU is enabled.
- Confirm the slave address is not 0 and matches the request.
- Match baud rate, parity, data bits and stop bits.
- Check A/B or D+/D– wiring.
- Confirm signal common and shield wiring.
- Check termination and bias settings.
- Poll one documented register with the correct function.
- Test with a PC and USB-to-RS-485 adapter.
- Increase the response timeout.
- Inspect raw frames or diagnostic counters.
Final Thoughts
A Modbus RTU timeout is not a diagnosis. It is only the result of a failed transaction.
Start by proving that the master sends a request. Then verify the slave address and serial format. After that, inspect the RS-485 wiring, termination and register request.
Most no-response faults are caused by something small: one reversed pair, one parity mismatch, address 0, or a register entered with the wrong offset.
Work methodically. Change one thing at a time. Otherwise, you may accidentally fix the communication without ever discovering what was wrong—and the same fault will return on the next machine.