Modbus Exception Code 06 (Device Busy)
Exception code 06, server device busy, is the Modbus response a device sends when it is occupied with a long-running command and cannot service a new request right now. It is a request-to-retry, not a fault in your request. This reference explains when a device raises exception 06, why the correct response is to wait and retry, and how it differs from a device-failure exception.
Modbus Exception Code 06 Server Device Busy in one line: Modbus exception code 06, server device busy, means the device is engaged in a long-duration command, such as a program or store operation, and cannot process the new request yet. The device is asking the master to retransmit later. It is a transient condition, not a permanent error, so the correct response is to wait briefly and retry rather than change the request.
When a Device Raises Exception 06
A device returns exception 06 when it is in the middle of a command that takes appreciable time and cannot accept another request until it finishes. Historically this arose with program or configuration-store operations that occupied the device for a while, during which any new request would be answered with busy rather than serviced or dropped. The device is explicitly telling the master to come back, which is more helpful than silence because it distinguishes a busy device from a dead one.
This makes exception 06 fundamentally transient. The request itself is valid and would succeed once the device is free, so there is nothing to fix in the request. Where it sits among the standard error responses is described in the Modbus exception code reference, which lists the request-side and device-side exceptions together.
Handling Exception 06 Versus Exception 04
The right handling of exception 06 is a short backoff and retry: wait a moment, then resend the same request, since the device should be free shortly. Treating a busy response as a hard failure, or hammering the device with immediate retries, is the wrong reflex, especially on a slow serial link where crowding a device is what caused problems in the first place, a dynamic covered in the Modbus serial response delay reference.
It is worth contrasting exception 06 with exception 04, slave device failure. Code 06 says the device is fine but temporarily occupied and will be ready soon; code 04 says the device hit an internal fault and the same request may keep failing. A retry is appropriate for 06 and often futile for 04 until the underlying fault clears, a distinction drawn in the Modbus exception 04 reference. Reading the exact code, rather than treating every exception the same, is what makes the difference.
Designing the Retry and Backoff Policy
The retry policy for exception 06 has three parts: how long to wait before the first retry, how the wait grows on repeated busy answers, and when to stop retrying and raise an alarm. A workable pattern is a short delay for the first retry and a growing delay after that: if the first wait is T, the second becomes T multiplied by some factor k, the third T times k squared, and so on up to a ceiling. The actual values are site-specific and depend on the link speed and how long the device's slow commands genuinely run, but the shape - bounded, growing, capped - is what matters.
The other half of the policy is a retry budget. Unlimited retries turn a stuck device into an endless silent loop where the master looks healthy but a point quietly stops updating. Cap the attempts, and when the budget is exhausted, mark the affected points' quality bad and raise a communications alarm so a person investigates. On a shared serial line, also make sure retries to the busy device do not starve the other nodes on the same channel: the poller should continue its scan rotation and come back to the busy device, not block the whole schedule waiting on one node.
Busy Response Versus No Response at All
An exception 06 and a timeout look similar in a trend - the value did not update - but they are diagnostically opposite. A busy response proves the physical link, wiring, addressing, and framing all work: the device heard the request, decoded it, and answered. A timeout proves none of those things. A device that answers busy has a narrow problem, usually one long internal operation, while a silent device could have anything from a broken conductor to a wrong baud rate, a distinction that bites hardest on serial links, as the Modbus TCP versus RTU comparison explains.
This is why logging the exception byte matters. A driver that collapses every failed transaction into a generic comm-fail flag throws away the one piece of evidence that separates wait it out from go check the wiring. Keep counters per exception code and per device: a rising count of code 06 on one node points at that node's workload, while rising timeouts across every node points at the shared medium.
When Busy Never Clears
A device that answers busy for an extended period is telling you its long-running operation never finished, and at that point the retry loop stops being the answer. A short field checklist:
- Confirm no other master or engineering tool is holding the device in a program or configuration session.
- Check whether a firmware update or configuration commit was started and never completed.
- Read the device's own diagnostics where supported, for example the function code 08 diagnostics, for an internal fault indication.
- If the device offers a second port or a local display, query its status there to see whether the whole device or only one interface is affected.
- Only then consider a controlled restart, following the site's procedures and with qualified personnel deciding whether the process can tolerate it.
The last step deserves the caution. A device stuck in a busy state may be mid-write to nonvolatile memory, and cutting power at the wrong moment can corrupt its configuration. Escalating to the manufacturer's support with the exception history in hand is often the better move than an immediate power cycle.
Frequently Asked Questions
What should the master do when it gets exception 06?
Wait briefly and retry the same request. Exception 06 is a transient busy signal, not a request error, so the request should succeed once the device finishes its long-running command. Avoid immediate rapid retries, which only crowd the device; a short backoff before retransmitting is the correct handling, especially on slow serial links.
Is exception 06 the same as a device failure?
No. Exception 06 server device busy means the device is temporarily occupied and will be ready soon, so retrying works. Exception 04 slave device failure means the device hit an internal fault, so the same request may keep failing until the fault clears. Reading the specific code tells you whether a retry is worthwhile.
What kind of command makes a device return busy?
Historically, long-running operations such as writing a program or committing a configuration to nonvolatile storage occupied the device long enough that it could not service other requests. During that window the device answers new requests with exception 06. Once the operation completes, normal responses resume, which is why a brief wait usually clears it.
How many retries are reasonable after exception 06?
There is no universal number; it is site-specific and depends on how long the device's slow operations genuinely run. The principle is a bounded budget: a few retries with a growing delay between them, then a communications alarm and bad quality on the affected points so the condition becomes visible instead of silently looping. The budget should be long enough to ride through a normal configuration store and short enough that a genuinely stuck device is noticed the same day, not the same week.
Does exception 06 mean the serial line is congested?
No. Exception 06 is raised by one device about its own internal state, not about the shared medium. Line congestion shows up as timeouts, corrupted frames, or slow turnaround across many devices, while code 06 comes back well-formed from a single node that is simply occupied. If several unrelated devices start answering busy at once, suspect a common cause such as an engineering tool touching them all rather than the line itself.
Sources and verification
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.
- Modbus Application Protocol Specification - Modbus Organization
Merobix is not affiliated with, endorsed by, or sponsored by these organizations; their names are used only to identify the standards and products discussed.
Automation services
Need help turning this into a working system?
Merobix integrates SCADA, programs Allen-Bradley and Siemens PLCs, and designs and fabricates industrial control panels.
Meeting requests are reviewed before confirmation.