Modbus RTU Timeout No Response
Trace a Modbus RTU timeout from power and RS-485 wiring through A/B, address, serial settings, request validity and response timing in a safe fault tree.
A Modbus RTU timeout means the master sent, or believes it sent, a unicast request but accepted no valid reply before its configured deadline. Work from power and port status through RS-485 wiring, A/B identity, device address and serial settings, then prove the request and set a documented response timeout before testing one isolated server.
What a timeout does and does not prove
“No response” does not identify a bad register. It says only that the master did not accept a reply in time. The Modbus Serial Line guide says that a master starts a response timeout after a unicast request. A server that detects a transmission error does not act on that message or construct a response; a request to a non-existent address also times out.
First confirm that the request was unicast. Address zero is reserved for broadcast, and servers do not reply to broadcasts. A received Modbus exception, CRC error or reply from an unexpected address is different evidence from total silence. Preserve those diagnostics rather than reducing every symptom to “timeout”.
Use this layered fault tree
Change one layer at a time and keep a record of the original wiring and settings. Do not start by scanning arbitrary addresses or trying guessed registers.
1. Prove power and the correct port
Identify the low-voltage communications circuit from current drawings and manuals. Obtain the required permit, isolate under the site procedure, and confirm instrument mode, terminals, polarity and loop-power arrangement before connecting anything.
Verify by the manufacturer’s approved method that the server, master and RS-485 interface are powered and operating. Check documented status indications, fuses and supply terminals; an illuminated display alone may not prove that the communications port is enabled. Confirm that software has opened the intended physical or virtual serial port and that another application has not claimed it.
If power or port selection is wrong, correct that before moving down the tree.
2. Check the RS-485 physical layer
With the circuit safely isolated, inspect for loose conductors, damaged cable, unintended joints and loss of continuity. Confirm that every interface is the required two-wire RS-485 type, not RS-232 or a four-wire arrangement. Compare the trunk, common, shield, termination and bias arrangements with the complete system manuals.
Do not add a guessed terminating or bias resistor. Termination belongs at the documented physical ends, while biasing has a different purpose and may already be built into an interface. The two-wire Modbus RTU wiring guide explains these distinctions.
After authorised restoration, use documented LEDs or an appropriate isolated analyser to establish whether the master actually transmits.
3. Resolve A/B by function
A and B labels are not consistent across all manufacturers. Map each terminal to the manual’s D1/D0, positive/negative or idle-state definition, then connect like functions. Record connector orientation and common separately. Never repeatedly swap conductors while energised, and do not treat the shield as signal common.
If transmit activity exists but no server receives it, an A/B mapping error, open pair, wrong interface or common-mode problem remains likely.
4. Confirm the server address
Read the configured server address using its documented local method and make the master target that value. Each server address must be unique. Do not poll address zero expecting a reply, and do not infer an address from a similar unit or an old project file.
Where an approved tool offers discovery, follow its manual: discovery still depends on a valid request, serial settings and a supported function. It cannot overcome incorrect wiring.
5. Match baud rate, parity and framing
Set RTU mode, baud rate, data bits, parity and stop bits to the values documented for that server and make all bus-wide settings agree. Confirm whether a changed setting needs saving or a controlled restart. Do not assume a default from another model.
The MR9270-series instructions expose baud rate, check bit, stop bit and device-address controls, but that is not evidence of the connected server’s settings.
6. Prove the master request
Pause automatic polling and send one documented, read-only request to one server. In the master log or an authorised trace, verify that bytes leave the correct adapter and that the target address, function, data length and CRC match the request you intended. Check that frame spacing and adapter transmit/receive direction follow the equipment documentation, and exclude a second master competing for the line.
Use only a function and data location in the exact server register map. A working 4–20mA signal does not prove its digital interface or map is correct; see 4–20mA correct but Modbus not working for that boundary.
7. Set response timeout from evidence
The official guide makes response timeout application-dependent and requires it to be long enough for the server to process a unicast request and reply. The MR9270-series instructions also show timeout duration and time-between-communications controls. Neither source justifies inventing a universal value.
Use the connected-device and master manuals, then extend the timeout temporarily only after proving a valid request. If a reply then appears, investigate documented processing delay and polling load. Extra retries may hide the symptom and increase bus traffic; they do not repair a rejected frame.
8. Isolate one master and one server
If the fault remains, isolate and make safe under the approved procedure. Disconnect other nodes and test one powered server with one master through a short, known-good, approved RS-485 connection. Retain the manuals’ required common, bias, termination and isolation arrangements; a “bench test” is not permission to bypass them.
If the pair communicates, restore the trunk in controlled sections until the fault returns. Then inspect the last added cable, node, address and loading. If the pair still fails, substitute only one verified component at a time and document the result. Escalate with request and reply traces, wiring records, firmware details and exact model numbers.
Where the MR9270S+ may fit
The current MR9270S+ HART product page lists Modbus RTU support and an RS485 adapter. Its manufacturer instructions describe a Modbus master interface with serial, address, request, polling and timeout controls. That can support compatible fault-finding, but it does not establish universal wiring, settings, register maps or protocol-analysis capability. Check the supplied instructions, firmware and connected-device manual before use.
No hands-on result is claimed here. The MR9270S+ is for process-signal work, not mains-voltage testing. Never connect it to 230V mains, an unidentified circuit or unsupported terminals; follow the site isolation procedure and every connected-device manual.