A Modbus poll comes back not with data but with an exception whose code is 01, illegal function. Unlike a bad address or a bad value, this one is the slave telling you it does not implement the function code you asked it to perform. Searchers often lump it together with exceptions 02 and 03, but the fix is different, because the problem is the operation itself, not where it points or what it carries. This page clarifies what exception 01 means, the common triggers behind it, and a clear decision path to get your poll or write working against a device that only supports certain functions.
Modbus Illegal Function (Exception 01) in one line: Modbus exception code 01, illegal function, means the slave does not implement or support the function code contained in your request, so it cannot perform the operation at all. It is different from exception 02, which is a bad address, and exception 03, which is a bad value; here the device simply does not do that function. Common causes are polling with function code 03 against a device that only supports 04, using write-multiple function code 16 on a device that only accepts single-register writes with 06, or a protocol gateway that filters certain functions. You fix it by matching your request's function code to what the device actually supports.
The symptom is that the slave answers, but its answer is a rejection carrying exception code 01. In the response the device echoes your function code with its high bit set and returns 01, which specifically means it does not recognize or does not implement the function code you sent. Note that it did answer, so communication, wiring, the unit address, and framing are all working well enough for the device to reply; the device just refuses to do the particular operation you requested. This narrows the problem sharply to the function code itself rather than to the link or the target.
This is what separates exception 01 from the other common exceptions people confuse it with. Exception 02, illegal data address, means the function is supported but the register you asked for is not valid on the device. Exception 03, illegal data value, means the function and address are fine but the value or quantity you supplied is out of range. Exception 01 is more fundamental than either: the device is not even getting to the question of which register or what value, because it does not perform the function you named at all. So if you see 01, checking the register map for the right address or clamping your value is beside the point, since the operation itself is the thing being rejected.
Because the device did reply, it is worth confirming you are actually talking to the intended device before assuming the function is unsupported. A misrouted request, where the unit identifier lands on a different device than you expect, can produce an exception 01 if that other device does not support the function even though your intended device would. This is especially easy to hit behind a gateway or on a shared serial line with multiple slaves. So part of reading the symptom correctly is verifying that the response is coming from the device whose function support you are relying on, not from a neighbor that happens to answer that unit id.
The classic trigger is polling the wrong read function for the register type. Modbus separates holding registers, read with function code 03, from input registers, read with function code 04, and a device that exposes its data as input registers will reject a function code 03 poll with exception 01, and vice versa. A poller configured for 03 against an input-register-only device, or for 04 against a holding-register-only device, produces a clean illegal-function rejection even though the data is right there under the other function. This is one of the most frequent real causes and is easy to fix once you know the register type the device uses.
Writes have their own version of the same problem. Modbus offers single-register writes with function code 06 and multiple-register writes with function code 16, and not every device implements both. A device that only accepts single-register writes will reject a function code 16 write-multiple with exception 01, so a master that always uses 16, even to write one register, fails against that device. The same applies to coil functions, where a device might support single-coil write 05 but not multiple-coil write 15, or might not implement coil access at all. Choosing a write function the device does not implement gives you an illegal function every time regardless of the address or value.
Protocol gateways are the third common trigger and the sneakiest, because the device behind the gateway may support the function perfectly well while the gateway does not pass it through. A Modbus TCP-to-serial gateway, a serial converter, or a protocol bridge can be configured or built to forward only a subset of function codes, filtering or refusing the rest, so a request that would succeed if sent directly to the device comes back as exception 01 from the gateway. This is worth suspecting whenever a function that the device's documentation clearly supports is nonetheless rejected, because the rejection may be coming from the box in the middle rather than from the device itself.
Work through it in order. First, open the device's register map and note which functions it supports and which register type each block of data uses, because that document is the authority on what will and will not work. If your data is in input registers, poll with function code 04; if it is in holding registers, poll with 03; and match coil and discrete-input reads the same way. Second, if the failing request is a write, check whether the device implements the write function you are using, and switch a function code 16 write-multiple to a function code 06 single write if the device only supports single-register writes. Simply aligning the function code to the device's supported set resolves the large majority of exception 01 cases.
If aligning the function code does not fix it, verify the routing and the path. Confirm the unit identifier is reaching the device you think it is, since a misrouted request can draw an exception 01 from a different slave that lacks the function. If there is a gateway or converter in the path, check whether it forwards the function code you need, and test by talking to the device as directly as your setup allows to see whether the rejection follows the device or stays with the gateway. If the direct path works and the gatewayed path does not, the gateway's function filtering is your culprit, and the fix is in the gateway configuration rather than in the device or the poll.
The way to avoid ever hand-picking function codes is to let the platform choose them from the register type, which is what a well-designed cloud SCADA does. In a platform such as Merobix, drivers select the correct function code per register type automatically, using function code 04 for input registers and 03 for holding registers on reads, and choosing an appropriate write function for the register, so an engineer defines what a point is rather than which raw function to send. That removes the most common source of exception 01, since the mismatch between the function you sent and the register type simply does not arise, and it keeps the configuration readable because points are described by what they represent instead of by protocol mechanics. Matching the function to the device by hand fixes the immediate rejection, and letting the platform auto-select the function keeps illegal-function errors from coming back.
It means the slave does not implement or support the function code in your request, so it cannot perform the operation at all. The device did reply, which shows communication and addressing are working, but it echoed your function code with an error and returned 01 to say it does not do that function. This is more fundamental than a bad address (exception 02) or a bad value (exception 03), because the device is rejecting the operation itself rather than the register or the data.
Most often because you are using the wrong read function for the register type. Modbus reads holding registers with function code 03 and input registers with function code 04, and a device that exposes its data as input registers rejects a function code 03 poll with exception 01, even though the data exists under function code 04. Check the device's register map to see which register type it uses, then match your poll's function code to it, and the same principle applies in reverse for holding-register devices.
Yes. A Modbus gateway, serial converter, or protocol bridge can be configured to forward only a subset of function codes and refuse the rest, so a request that the end device supports perfectly well is rejected with exception 01 by the box in the middle. Suspect this whenever the device's documentation clearly lists the function as supported but the request still fails. Test by talking to the device as directly as possible; if the direct path works and the gatewayed path does not, the gateway's function filtering is the cause.
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.