Of all the faults on a Modbus network, this is the one an integrator sees most: the master sends a request and simply gets nothing back before its patience runs out. The device reports slave not responding, the point goes to a comm fault, and someone has to figure out why. A Modbus timeout is not one problem but a symptom with a handful of usual causes, and knowing them turns a frustrating hunt into a short checklist. This page focuses specifically on the no-reply case on a Modbus link - what the timeout actually is, what makes a slave go silent, and how repeated timeouts turn into a comms-fail alarm.
Modbus timeout / slave not responding in one line: A Modbus timeout happens when the master sends a request to a slave and no valid response arrives before the master's response-timeout window expires. The master then reports the slave as not responding. It means the request-reply exchange did not complete at all - as opposed to the slave replying with an error - and it points to problems like a wrong unit ID, a wiring or bus fault, a powered-down device, mismatched serial settings, or an overloaded gateway.
Modbus is strictly request-reply: the master sends a query to one slave address and waits for that slave to answer. The response timeout is the maximum time the master will wait for a reply before giving up on that request. If the full, valid response arrives in time, the exchange succeeds. If the window elapses with no answer, the master declares a timeout and moves on, usually after a set number of retries. A timeout is therefore the absence of a reply, which is a very different failure from a slave that answers with an exception code - there the device is present and talking, just refusing the specific request.
That distinction is the first diagnostic fork. If you get exception responses, the physical and serial link is basically working and the problem is in the request itself, such as an address the device does not have. If you get timeouts, the request-reply loop never closed - so the fault is more likely in the path to the device, the device's ability to answer, or whether the master is even talking to the right device at all. Recognizing timeout versus exception immediately narrows where to look.
The single most common cause is a wrong unit ID, also called the slave address. Modbus requires an exact match between the address in the request and the address configured on the device; poll address 3 for a device set to address 4 and it will never answer, and the master reports a timeout even though the device is perfectly healthy. Because the slave stays completely silent on any address that is not its own, an address mismatch and a dead device look identical from the master's side, which is why confirming the ID is usually step one.
On serial RTU links, mismatched line settings are the next suspect: if the master and slave disagree on baud rate, parity, data bits, or stop bits, the slave either never recognizes a valid request or replies in a framing the master cannot parse, and the result is a timeout either way. Physical layer faults come next - a broken or miswired RS-485 pair, reversed A and B lines, missing or wrong bus termination, a ground problem, or simply a device that has lost power. On Modbus TCP the address question becomes wrong IP or port and unreachable network paths. And a saturated serial-to-TCP gateway can drop or delay requests under load, so a device that answers fine when polled slowly starts timing out when the poll rate climbs. Working the list in order - ID, serial settings, wiring and power, then gateway load - resolves the large majority of no-reply faults.
A single timeout rarely triggers anything on its own, because momentary glitches happen on real networks. Instead the master applies a retry-and-count policy: it retries the failed request a configured number of times, and only after a run of consecutive failures does it mark the device as failed and raise a communications-fault alarm. That threshold exists to separate a one-off hiccup from a device that is genuinely gone, so operators are alerted to real losses without being flooded by transient noise. When communication is restored, the counter resets and the alarm clears.
For a cloud SCADA platform, exposing this behavior clearly is what makes Modbus timeouts diagnosable rather than mysterious. It helps operators when the platform shows which specific device timed out, how long it has been failing, and whether the retry count is climbing, so a wrong unit ID or a failing gateway stands out instead of appearing as a vague loss of data. A platform such as Merobix polls field devices over Modbus, applies the retry logic, and presents each device's communication health - so a slave that stops responding surfaces as a clear, timestamped comms-fault event tied to that exact device, giving the technician a starting point rather than a shrug.
The most common reason is a wrong unit ID - Modbus needs an exact match between the address in the request and the address set on the device, and a slave stays completely silent on any address that is not its own. On serial links, mismatched baud rate or parity produces the same silence, as does reversed A and B wiring or missing bus termination. Confirm the unit ID first, then the serial settings and wiring.
A timeout means no reply arrived at all before the master's wait window expired, pointing to the path, the device's power, or a wrong address. An exception response means the device did answer but rejected the specific request, which tells you the link works and the problem is in the request itself. Timeouts point to connectivity; exceptions point to the request contents.
It depends on the configured retry-and-count policy - a master typically retries a failed request a set number of times and only raises a communications-fault alarm after a run of consecutive failures. This threshold separates a momentary glitch from a device that is truly gone, so operators are not flooded by transient noise. When communication returns, the counter resets and the alarm clears.
This page references the protocol specifications published by the organizations below. Editions, product capabilities, and documentation change over time - confirm current requirements and specifications directly with the source.
Last reviewed: July 27, 2026. Merobix is not affiliated with, endorsed by, or sponsored by these organizations; their names are used only to identify the standards and products discussed.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.