Modbus Function Code 01 (Read Coils)
Function code 01 is the Modbus command that reads coils, the single-bit read-write values that usually represent outputs or control flags. An integrator mapping a device needs to know exactly what FC01 targets, how it packs its reply, and why it is the wrong code for reading a sensor input. This reference covers the request and response shape of FC01 and where it fits among the four read codes.
Modbus Function Code 01 Read Coils in one line: Modbus function code 01 reads coils: the read-write single-bit values, typically outputs or control flags. The request names a starting coil address and a quantity of coils to read, and the device replies with those coils packed eight to a byte, least-significant bit first. It reads only the coil table, never discrete inputs or registers, so pointing it at the wrong table returns nothing useful.
What FC01 Reads and How It Replies
Coils are the Modbus data table of single read-write bits, historically the relay outputs of a controller and now any on/off value a device chooses to expose, such as a run command or an enable flag. Function code 01 reads a contiguous block of them. The request carries a starting coil address and a quantity, and the device returns a byte count followed by the coil states packed eight bits to a byte, with the first coil in the least significant bit of the first byte.
Because the reply is bit-packed, reading nine coils returns two bytes, with the unused high bits of the last byte set to zero. Function code 01 is bound to the coil table only. If the value you want is a read-only input, FC01 is the wrong verb and you want function code 02 instead. The full set of tables is laid out in the Modbus register types reference.
Where FC01 Fits Among the Read Codes
Modbus has four read codes, one per table, and function code 01 is the one bound to coils. Its read-only sibling is function code 02 for discrete inputs, while function code 03 and function code 04 read sixteen-bit registers rather than bits. Choosing the code is really choosing the table, so the first question when a read fails is whether the value lives in the coil table at all. The distinction between reading and writing the same table is why FC01 pairs with the coil write codes covered in the Modbus function code overview.
A request that names a valid coil address under the wrong function code can still fail with an exception, because the address does not exist in the table that code reads. When FC01 returns an illegal data address exception, the usual cause is either a genuinely out-of-range coil or a coil map expressed in a different addressing base, a point the Modbus register addressing reference untangles.
A Worked FC01 Exchange, Byte by Byte
Suppose the master wants 12 coils starting at coil offset 19. The request PDU is five bytes: function 0x01, starting address 0x00 0x13, quantity 0x00 0x0C. The device answers with function 0x01, a byte count of 0x02 (twelve bits need two bytes), and then the two data bytes. Nothing in the reply repeats the starting address or quantity, so the master must remember what it asked for to interpret the bits - a detail that matters when you are decoding a capture by hand.
Now decode a first data byte of 0x35, which is 0011 0101 in binary. The least significant bit is the first requested coil, so bit 0 is offset 19, bit 1 is offset 20, and so on. Bits 0, 2, 4, and 5 are set, meaning the coils at offsets 19, 21, 23, and 24 are ON and the others in that byte are OFF. The second byte carries the remaining four coils, offsets 27 through 30, in its low four bits, with the top four bits zero-padded because the quantity was not a multiple of eight. Walking one exchange like this once makes every future capture readable.
Quantity Limits and Poll Design
The specification caps a single FC01 request at 2000 coils, and a request for zero or more than that earns an illegal data value exception before the device even looks at its map. Within that ceiling, poll design is a packing problem: every request carries fixed framing overhead, so one read of a contiguous block beats a dozen single-coil reads. The catch is that a block read is all-or-nothing - if the range spans an address the device has not mapped, many devices reject the entire request, so a map with gaps sometimes forces several smaller reads around the holes.
It also pays to group coils by how fast they change. Feedback bits that confirm a command deserve a quick poll; configuration flags that change once a season do not, and putting them in separate blocks lets each poll at its own rate. The write-side pairing matters here too: after commanding a coil with write single coil or a block of them with write multiple coils, a follow-up FC01 read of the same offsets is the standard way to confirm the device really took the state.
Field Diagnostics When FC01 Misbehaves
The three standard exceptions carry most of the diagnostic load. Illegal function (exception 01) means the device does not implement FC01 at all, which is common on register-only devices that expose their bits packed into holding registers instead. Illegal data address (exception 02) means the range is not in the coil map - wrong table, wrong base, or genuinely absent. Illegal data value (exception 03) points at the quantity field. A timeout is a different animal entirely: nothing answered, so suspect the unit ID, the wiring or TCP path, or a device that is simply not listening.
The classic soft failure is the off-by-one map: documentation numbers coils from one while the wire carries offsets from zero, so every value reads one position shifted. If a whole block looks plausible but wrong, adjust the base before doubting the device. To pin a mapping down definitively, observe a single coil whose state you can change through a known, authorized action - and any test that toggles a real output belongs under site procedures with qualified personnel, never as an improvised experiment on a live process.
Frequently Asked Questions
What is the difference between function code 01 and 02?
Function code 01 reads coils, which are read-write single bits, while function code 02 reads discrete inputs, which are read-only single bits. They differ only in which table they target. If a value can be both read and written it lives in the coil table and uses FC01; if it is a status input the device only reports, it lives in the discrete-input table and uses FC02.
How are the coils packed in an FC01 response?
The device returns a byte count and then the coil states packed eight to a byte, least-significant bit first. The first requested coil is the low bit of the first byte. If the quantity is not a multiple of eight, the unused high bits of the final byte are zero. So reading ten coils returns a two-byte payload with six padding bits.
Why does FC01 fail on a register address?
Because FC01 reads only the coil table. A holding-register or input-register address does not exist in the coil table, so the device replies with an illegal data address exception. To read a sixteen-bit value you need function code 03 or 04, not 01. The mismatch between the code and the table is the actual fault, not the address itself.
How many coils can one FC01 request read?
The Modbus specification allows 1 to 2000 coils per FC01 request. Asking for zero or more than 2000 returns an illegal data value exception. Individual devices may enforce lower limits or reject ranges spanning unmapped addresses, so the practical ceiling for a given product is per the manufacturer's documentation, and larger reads are split across multiple requests.
Is FC01 the same over Modbus RTU and Modbus TCP?
The PDU is identical: same function code, same starting address and quantity, same bit-packed reply. Only the framing around it differs - RTU adds a slave address and CRC on the serial line, while TCP wraps the PDU in an MBAP header. That is why a register map and decode logic proven on serial carry over unchanged when the device moves to Ethernet.
Sources and verification
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.
- Modbus Application Protocol Specification - Modbus Organization
Merobix is not affiliated with, endorsed by, or sponsored by these organizations; their names are used only to identify the standards and products discussed.
Automation services
Need help turning this into a working system?
Merobix integrates SCADA, programs Allen-Bradley and Siemens PLCs, and designs and fabricates industrial control panels.
Meeting requests are reviewed before confirmation.