Unlike a timeout, a Modbus exception code 02 means the device is alive, talking, and deliberately refusing your request because the register you asked for does not exist as far as it is concerned. Illegal data address is the device's way of saying the address, or the range you asked to read, falls outside its map. That is good news for troubleshooting, because it turns an addressing puzzle into a solvable reconciliation between what your driver requested and what the device actually maps. This guide walks the fix in order: line up the vendor register map against the driver, kill the common 40001 off-by-one, confirm the function code matches the register type, and handle reads that run off the end of a valid block.
Clear a Modbus illegal data address exception in one line: A Modbus illegal data address exception, code 02, means the device received your request cleanly but the register address, or the span you asked to read, is not part of its map, so it refuses rather than returning data. Clear it by reconciling the vendor register map against what the driver requests, fixing the 40001 versus zero-based off-by-one, confirming the function code matches the register type you are addressing, and making sure a multi-register read does not run past the last valid register in a block. The exception is the device telling you exactly where to look.
Modbus exception codes are the device's structured way of rejecting a request it understood but cannot fulfil, and telling the three most common apart points you straight at the fix. Code 01, illegal function, means the device does not support the function code you sent at all. Code 02, illegal data address, means the function is fine but the specific register address or range does not exist in the device's map. Code 03, illegal data value, means the address is valid but the value or quantity you supplied is out of the allowed range, such as asking to read more registers in one request than the device permits. A code 02 therefore narrows the problem to addressing, not to the function or the data itself.
It helps to picture what the device is doing. When it receives a read request it checks the requested starting address and count against the block of registers it actually implements, and if any part of that range is outside the implemented block it returns 02 instead of data. So the exception is not random; it is a precise statement that your address, your count, or the combination of the two reached beyond what the device maps. Because the device is responding, you have ruled out wiring, unit ID, and reachability, and you can focus entirely on the numbers in the request.
This is where the exception-code and register-map concept pages pay off as background, because they define the vocabulary the fix uses. The practical takeaway for a code 02 is that the device is handing you a diagnostic gift: it has confirmed it is reachable and speaking the right function, and told you that the only thing wrong is which address you named. The rest of the procedure is systematically finding where your requested address and the device's real map disagree.
Begin by putting the vendor register map next to what your driver is actually requesting. The vendor documentation lists which registers exist, what each holds, and often the register type. Compare the exact starting address your driver sends against that map, and confirm the register you want is genuinely implemented; a surprising number of code 02 faults come from reading a register the device simply does not have, such as an optional feature register or an address that belongs to a different model in the same manual. Get the intended register nailed down from the map before adjusting anything, because the rest of the fix is about representing that same register correctly on the wire.
The most frequent code 02 in practice is the 40001 off-by-one. Documentation and configuration tools often refer to holding registers as 40001, 40002, and so on, but the address placed on the wire is zero-based, so 40001 corresponds to wire address 0, 40002 to address 1, and the whole map is shifted by one. If your driver expects the zero-based wire address but you typed the 40001-style number, or the driver expects the one-based number and you gave it the raw offset, every request lands one register off, and a request for the register just past the end of the map returns 02. The 40001-offset concept page covers this mapping in detail; the fix in the field is to establish which convention your driver's address field expects and to enter the address in that convention consistently.
Confirm the fix by testing a register you can predict. Read a value the device documents with a known content, such as a fixed device identifier or a slow-moving measurement, and check whether the returned number and its position match. If the value you expected shows up one register away from where you asked, you have proven an off-by-one and can shift the whole map. If it appears exactly where the vendor map says it should once you use the driver's expected convention, the addressing is reconciled and the code 02 will clear for every tag that follows the same rule.
Addressing is only half of a valid request; the function code has to match the register type, or you can hit an address error even with the right number. Holding registers are read with function code 03 and input registers with function code 04, coils with 01 and discrete inputs with 02, and these are separate address spaces. Reading a holding register with the input-register function, or vice versa, addresses a table where that number may not exist, producing a code 02. Confirm from the vendor map which table your value lives in and that your driver is configured to read it with the matching function; a value that reads fine under one function and throws code 02 under another is a classic register-type mismatch rather than a wrong number.
Span-crossing reads are the last common trap. A single Modbus request reads a contiguous block starting at your address for a given count, and if that block runs past the last valid register in the device's implemented range, the device rejects the whole request with code 02 even though the first registers are perfectly valid. This bites when a driver groups many tags into one efficient bulk read and the group reaches beyond the end of a block, or straddles a gap between two separate blocks the device implements. The fix is to trim or split the read so every request stays within a contiguous, implemented range, reading the two blocks separately rather than one span across the gap.
In a SCADA context these code 02 faults are best caught at commissioning, because they are deterministic: a misaddressed tag fails every single poll, so it shows as permanently bad quality rather than intermittently. A cloud SCADA platform such as Merobix will report the exception per tag, and the discipline is to resolve every code 02 before a site goes live rather than leaving a handful of bad tags that operators learn to ignore. Because the exception pinpoints the address, and because it only appears once comms are otherwise healthy, clearing it is usually a one-time reconciliation of driver configuration against the vendor map, after which those tags stay good.
Code 02 is illegal data address. It means the device received and understood your request but the specific register address, or the range you asked to read, is not part of its implemented map, so it refuses rather than returning data. Because the device is responding, wiring and unit ID are ruled out, and the fix is entirely about matching your requested address to the device's real register map.
Documentation often numbers holding registers as 40001, 40002, and so on, while the address on the wire is zero-based, so 40001 maps to wire address 0. Establish which convention your driver's address field expects, enter the address in that convention consistently, then verify by reading a register with known content and checking that the value appears exactly where the vendor map says it should.
A single request reads a contiguous block from your starting address for a given count, and if that block runs past the last valid register or across a gap between two implemented blocks, the device rejects the whole request with code 02 even though the first registers are valid. Trim or split the read so every request stays within one contiguous, implemented range, reading separate blocks with separate requests.
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.