When a Modbus device answers a request but rejects it with exception code 02, it is telling you something precise and useful: the register you asked for does not exist in this device. Unlike a timeout, which leaves you guessing, an illegal-data-address exception is a clear pointer at an addressing bug. The device is present, powered, talking, and correctly configured on the bus - it simply has nothing at the location you polled. This page focuses purely on diagnosing the 02 case: what the device is actually saying, the addressing mistakes that produce it, and why it is such a helpful error to get.
Modbus illegal-data-address exception in one line: Modbus exception code 02, illegal data address, is a response a slave sends when it accepts the request format but the register or coil address you asked for is not present in its memory map. It confirms the device is alive and communicating and narrows the fault to the address itself - a wrong offset, a register outside the device's valid range, or a function code aimed at the wrong table.
The most important thing about exception 02 is that it is a reply. The device received your request, understood it well enough to process it, and deliberately sent back an error saying the requested address is out of bounds. That immediately rules out an entire category of problems: the wiring is fine, the device has power, the serial settings match, the unit ID is correct, and the master is talking to the right device. If any of those were broken you would get a timeout, not an exception. Getting an exception means the conversation is working; only the content of the request is wrong.
So exception 02 is one of the more welcome faults to encounter, because it points straight at the address. The device is essentially handing you the diagnosis: I am here, I heard you, and I have nothing at that location. That narrows the search dramatically compared with a timeout, where the device could be silent for a dozen different reasons. With an 02, the fix almost always lives in the point configuration - the register number you told the master to poll - rather than anywhere in the physical or serial layer.
The classic culprit is an off-by-one from the register-numbering offset. Documentation often lists holding registers in the 4xxxx convention, where 40001 refers to the register the protocol actually addresses as 0. Mix the two numbering styles - polling the wire address as if it were the documentation number, or vice versa - and you land one position off or far outside the map, and the device answers 02. Any tag map built by transcribing a vendor register table by hand is a candidate for exactly this slip.
The other common causes are just as address-focused. Polling a register beyond the device's actual range - asking for a count of registers that runs past the end of a valid block, or reading a point that simply is not implemented in that model or firmware - produces 02. So does using the wrong function code for the data you want, since holding registers, input registers, coils, and discrete inputs are separate address spaces; a read aimed at the coil table for something that only exists as a holding register lands on nothing. And reading across a gap - a block that spans past the end of one contiguous range into unmapped territory - triggers it too. In every case the fix is to reconcile the polled address, count, and function code against the device's real register map, not to touch wiring or serial settings.
The practical value of exception 02 in day-to-day operations is that it cleanly separates an addressing bug from a connectivity bug. A timeout says the exchange never completed and sends you hunting through wiring, power, IDs, and serial settings. An 02 says the exchange completed and the request itself was wrong, so you go straight to the point configuration. Treating those two symptoms differently saves a lot of wasted troubleshooting, and the worst outcome is a system that lumps them together as a generic comm fault and hides which one you actually have.
This is where surfacing the specific exception matters. It helps a technician when the platform records not just that a poll failed but that it failed with illegal data address on a named tag, because that turns a vague fault into a pinpoint: this one register is misconfigured while every other point on the same device reads fine. A cloud SCADA platform such as Merobix polls devices over Modbus and can report the exact exception returned, so a code 02 shows up as an addressing problem on a specific tag rather than being blurred into the same bucket as a dead link. That lets whoever built the tag map fix the offset or function code directly, and confirm the fix the moment the exception stops.
It means illegal data address - the slave accepted and understood your request but the register or coil you asked for is not present in its memory map. Because the device replied at all, it confirms the link, power, unit ID, and serial settings are fine, and the fault is in the address you polled. It is a targeted pointer at a configuration mistake rather than a connectivity failure.
Because the fault is specific to that address, not the device. The most common cause is an off-by-one from the 40001 register-numbering offset, but it can also be a register beyond the device's valid range, a point not implemented in that model, or the wrong function code aimed at the wrong address table. Reconcile that single tag's address, count, and function code against the device's register map.
A timeout means no reply arrived at all, so the problem is in connectivity - wiring, power, unit ID, or serial settings. Exception 02 means the device did reply, rejecting the request because the address does not exist, so the problem is in the request itself. Getting an exception proves the link works and sends you straight to the point configuration.
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.