Modbus Gateway Exceptions 0A and 0B: How to Fix Them

Back to Blog

First Checks: Read Which Code You Are Getting

Establish precisely which exception is returned, for which unit IDs, and how consistently, because the two codes send you to different places. Code 0B pointing at one unit ID while its neighbors answer is a single downstream device problem. Code 0A on one unit ID is a mapping problem for that ID. Either code across every unit ID suggests the gateway's serial port or its whole mapping table. A master log that lumps all failures together as generic errors hides these distinctions, so if yours does, run a handful of manual polls with a Modbus test client and record the exception per unit ID yourself - it takes minutes and structures the entire investigation.

Note also what these exceptions rule out. An exception is a valid Modbus response: it traveled from the gateway back through the TCP connection to your master. Network reachability, the TCP session, and the gateway's Modbus engine are all demonstrably working. Time spent on switches, firewalls, and cabling to the gateway is wasted for this symptom - the investigation starts at the gateway's configuration and continues downstream.

Exception 0A: The Gateway Cannot Route the Request

Gateway path unavailable means the request never made it onto a serial line because the gateway had no path for it. The dominant cause is unit ID mapping: multiport gateways route each incoming unit ID to a specific serial port and downstream address per their mapping table, and an ID missing from the table, or pointing at a port that is disabled or unconfigured, has nowhere to go. Mapping tables drift out of date when devices are added or re-addressed in the field without the gateway being updated, which is why 0A so often appears immediately after a site visit that touched addressing.

The second cause is capacity. Gateways handle a finite number of simultaneous requests, and a master polling aggressively - or several masters sharing one gateway - can exhaust the internal buffers, at which point some gateways reject the overflow with 0A. The signature is intermittency that scales with load: the same poll succeeds in quiet periods and fails when polling is dense. The fixes are slowing the poll rate, consolidating masters, or spreading devices across more gateway capacity. Checking the gateway's own diagnostics page or status registers, where provided, confirms an overload directly instead of by inference.

Exception 0B: Silence on the Serial Side

Target device failed to respond means the gateway transmitted the request downstream and its own response timer expired with no reply. The gateway is telling you, honestly, that something past its serial port did not answer. The cause list is exactly the classic serial one: the device is powered down or failed, the wiring between gateway and device is broken or landed with swapped polarity, the device's actual address differs from the one the mapping targets, or baud, parity, and stop bits disagree between the gateway's serial port and the device so the request arrives as noise.

Work it like any serial fault, with the gateway as your fixed reference point. If every device on one serial port returns 0B, suspect the shared elements: that port's settings, its wiring trunk, or its termination. If one device fails among working neighbors, suspect that device's address, drop wiring, or power. Where possible, take a laptop with a serial adapter to the gateway's downstream side and poll the silent device directly with the same settings - a device that answers a direct poll but not the gateway pins the fault to the gateway's port configuration or that port's connection to the trunk, and one that stays silent confirms a field problem to chase with a meter.

One tuning parameter matters here: the gateway's downstream response timeout. A slow device - or one at the end of a long, slow serial link - can answer correctly but late, after the gateway has already given up and issued 0B. Gateways expose this timeout precisely because downstream response times vary by device and baud; where a device is known to be slow, lengthening the gateway's serial timeout, within what the master's own timeout allows, eliminates false 0B errors without touching hardware.

When to Escalate

Escalate gateway-internal problems - 0A that persists with a verified mapping table and light load - to the gateway vendor, with the firmware version, the mapping configuration, and a capture of the failing request. Escalate persistent 0B on a device that also fails direct serial polling to whoever maintains the field device, with the serial settings and addressing you verified. The exception code, plus the one cross-check poll from the gateway's position, is the evidence that keeps either conversation short.

Fleets of serial devices behind gateways benefit from having this visibility permanently. A SCADA platform such as Merobix polling through gateways can distinguish and record exception types per device over time, so a mapping error introduced by a field change shows up as a burst of gateway exceptions with a timestamp - and the correlation with that day's work order usually names the fix before anyone drives to site.

Frequently Asked Questions