Your Modbus master sends a request, the slave answers, but instead of the data you expected it returns an exception with code 03, illegal data value. It is easy to confuse this with the far more common code 02, illegal data address, and chase the wrong problem for an hour. Exception 03 is specifically about the value in your request being out of range, not about the register you addressed. This page explains what exception 03 really means, walks through the causes that actually produce it, shows how to isolate it, and contrasts it with exception 02 so you fix the right thing.
Modbus Illegal Data Value (Exception 03) in one line: Modbus exception code 03, illegal data value, means the slave received a request whose data field contains a value it will not accept, because that value is outside the range the slave allows for that operation. It is not about a bad register address, which is exception 02, and it is not about the register not existing. Common causes include writing a value outside a register's allowed minimum or maximum, a byte count that does not match the quantity on a write-multiple, or a word-order mistake that turns a valid number into an enormous one. You fix it by reading the register back, checking the device's range specification, and testing a known-good value.
The symptom is precise: the slave received and understood your request, recognized the function code, accepted the address, and then rejected the request because a value in its data field was not allowed. In the Modbus exception response the slave echoes the function code with its high bit set and returns the exception code 03. The key word is value. The device is telling you that something in the numeric content of the request is out of the range it permits, not that it could not find the register and not that it does not support the operation.
This is exactly why exception 03 is so often confused with exception 02, illegal data address. Both come back as a rejection to a read or write, and both can look identical from the outside if you are only watching the request fail. But they mean opposite things. Exception 02 says the address or the range of addresses you asked for is not valid on this device, so the problem is where you are pointing. Exception 03 says the address was fine but the value or the quantity you supplied is not acceptable, so the problem is what you are sending. Fixing an exception 03 by hunting through the register map for the right address, as you would for an 02, gets you nowhere, because the address was never the issue.
It helps to notice which requests tend to produce which code. Exception 03 shows up most on writes, especially single-register writes with function code 06 and multiple-register writes with function code 16, because those carry a value or a quantity that the slave validates against its own limits. A read that asks for too many registers at once can also draw an exception 03 from some devices, because the requested quantity exceeds what the protocol or the device allows in one transaction. In every case the code is pointing at the numeric content of the request, so that is where the investigation should focus.
The most direct cause is writing a value outside the register's allowed minimum or maximum. Many device registers accept only a defined range, such as a setpoint that must lie between engineering limits, a mode register that accepts only a handful of enumerated codes, or a percentage that must be zero to one hundred. Send something outside that range, even a value that is perfectly valid as a number, and a well-behaved slave rejects it with exception 03 rather than accepting an invalid setting. This is common when a higher-level system pushes a setpoint the operator entered without clamping it to what the field device will accept.
A second cause is a malformed write-multiple request, most often on function code 16. That function carries both a quantity of registers and a byte count, and the byte count has to equal twice the quantity for sixteen-bit registers. If those disagree, or if the quantity is zero or larger than the device allows in one write, the slave sees an inconsistent or out-of-range request and returns exception 03. This can come from a driver bug, a hand-built frame, or an off-by-one in how a value is packed, and it is easy to overlook because the address is correct and only the framing of the data is wrong.
A more subtle cause is word order, or endianness, on multi-register values. A thirty-two-bit value spans two registers, and if the master sends the two words in the order the device does not expect, a value that should be small can be reassembled by the slave into an enormous number that is far outside the register's range. The write then fails with exception 03 even though your intended value was perfectly reasonable, because the device is validating the garbled value it actually received. The same happens with floating-point values split across registers when the byte or word order is wrong. This is why a setpoint that looks fine on your screen can still trigger an illegal data value: the number on the wire is not the number you think it is.
Start by reading the register back before you try to write it. Reading the current value tells you the register exists and is accessible, which immediately rules out an address problem and confirms you are dealing with a value problem, and it often shows you the scale and format the device uses. If the read succeeds and only the write fails with exception 03, you have proven the address is good and the value is the issue, which is the single most useful thing to establish first because it separates 03 from 02 conclusively. Then find the device's range specification in its register map or manual, the allowed minimum, maximum, and any enumerated codes for that register, so you know exactly what it will accept.
Next, test a known-good value. Write a value you are certain is in range, a mid-scale setpoint or a documented valid code, and see if it is accepted. If the known-good value works and your original value does not, the problem is your value being out of range, and you either need to clamp it or correct the scaling. If even the known-good value fails, suspect the framing instead: check the byte count and quantity on a function code 16 write, and check the word order by writing a value and reading it back to see whether the device reassembled it as you intended. A value that reads back as a wildly different or huge number is the fingerprint of a word-order problem, and swapping the word order usually resolves it.
The durable fix is to stop bad values from reaching the field device in the first place, which is where configuring write limits in a cloud SCADA platform pays off. In a platform such as Merobix you can define the acceptable range, scaling, and word order for each register once, so a setpoint entered by an operator or pushed by logic is validated and clamped before any command is sent, and the correct byte order is applied automatically. That turns exception 03 from a runtime failure at the device into something the platform catches or prevents up front, and it means the same limits are enforced consistently no matter who or what issues the write. Isolating the immediate cause gets the current write working, and encoding the register's real limits in the platform keeps illegal data values from recurring.
Exception 02, illegal data address, means the register or range of addresses you requested is not valid on the device, so the problem is where you are pointing. Exception 03, illegal data value, means the address was accepted but the value or quantity in your request is out of the range the device allows, so the problem is what you are sending. They are opposite diagnoses, and treating an 03 like an 02 by hunting for the right address gets you nowhere because the address was never the issue.
Often because the number on the wire is not the number you think it is. A thirty-two-bit or floating-point value spans two registers, and if the word order or byte order is wrong, the device reassembles your small, reasonable value into an enormous one that is far outside the register's range, which it rejects with exception 03. It can also happen if the value is genuinely outside the register's allowed minimum or maximum, such as a setpoint beyond the device's engineering limits, even though it is a valid number in the abstract.
Read the register back first. If the read succeeds and returns a value, the address is valid and accessible, which rules out an address problem and confirms you are dealing with a value problem. Then write a known-good value that you are sure is in range; if it is accepted and your original value is not, the original value was out of range or wrongly scaled. If even the known-good value fails, check the byte count and word order of the request, since a framing or endianness error can garble the value.
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.