Modbus organizes everything a device exposes into just four tables, and knowing which table a value lives in is the first step to reading it correctly. Two of the tables hold single bits, two hold sixteen-bit words, and each has its own rule about whether a master can only read it or can also write to it. This guide walks through all four Modbus register types, what belongs in each, and how an integrator maps a wellsite RTU's statuses, levels, and setpoints into the right table so a cloud SCADA poll pulls the right values.
Modbus Register Types (Coils, Discrete Inputs, Input Registers, Holding Registers) in one line: Modbus defines four data tables: coils (single read-write bits, often digital outputs), discrete inputs (single read-only bits, often digital inputs), input registers (sixteen-bit read-only words, often measurements), and holding registers (sixteen-bit read-write words, often setpoints and general-purpose values). Coils and discrete inputs carry on/off states, while input and holding registers carry numbers. The two read-only tables reflect field conditions the master should not change, and the two read-write tables let the master command outputs and adjust settings.
The four tables split along two axes: bit versus word, and read-only versus read-write. Coils are single bits that a master can both read and write, historically representing physical relay outputs, so a coil is where you would map a command such as start a pump or open a valve. Discrete inputs are single bits that a master can only read, historically representing physical digital inputs, so they hold field states like a pump running contact, a high-level float switch, or a door-open sensor - conditions the master observes but must not overwrite.
The two word-sized tables carry numbers rather than on/off states. Input registers are sixteen-bit values a master can only read, well suited to measurements coming from the field: a tank level, a flow rate, a pressure, a temperature. Holding registers are sixteen-bit values a master can both read and write, making them the home for setpoints, configuration values, and any number the master might need to change, such as a target level or a scaling factor. A holding register can of course also be read back, which is why many devices expose measurements there too even though an input register would be the stricter choice.
The historical names matter because they explain the read-write rules that still apply. Coils and discrete inputs got their names from relay coils and discrete field inputs; input registers were read-only measured inputs; holding registers were read-write memory the controller held. Modern devices no longer map one-to-one onto relays and floats, but the read-only versus read-write distinction survives: discrete inputs and input registers are read-only by protocol, coils and holding registers are read-write, and a master that tries to write to a read-only table gets an error rather than a change.
The read-only versus read-write split is not a suggestion - it is enforced by which function codes the protocol allows against each table. There are read functions for all four tables, but write functions exist only for coils and holding registers. This is why the distinction is worth getting right at mapping time: a field measurement placed in an input register is protected from accidental writes because no write function can reach it, while a setpoint the master must adjust has to live in a coil or holding register or the master will have no legal way to change it.
Each table also has its own address space, and the classic Modbus reference numbers reflect this: coils are the 0x range, discrete inputs the 1x range, input registers the 3x range, and holding registers the 4x range. These leading digits are a human convention for naming which table an address belongs to, not part of the address sent on the wire, and confusing the reference number with the wire address is a common source of off-by-one errors. What matters for mapping is that the same numeric offset in two different tables refers to two entirely different pieces of data - coil 5 and holding register 5 have nothing to do with each other.
Because the tables are independent, a device can populate them in whatever way its designer chose, and there is no guarantee that a value lives where intuition suggests. A vendor might expose a pump run status as a discrete input on one product and as a bit packed into a holding register on another. This is why an integrator always works from the device's register map rather than assumptions: the map states, for each value, which table it is in, what offset, and whether it is read-only or read-write, and that is the authoritative source for building a correct poll.
When a cloud SCADA polls a wellsite RTU, it is reading specific tables at specific offsets, so the integrator's job is to line up each field signal with the right table. A pump run status is a single on/off state that the SCADA only needs to observe, so it maps naturally to a discrete input. A tank level is a measured number that the SCADA reads but should not change, so it belongs in an input register, or in a holding register if the device exposes measurements there. A control setpoint the SCADA needs to push down to the RTU - a target level or a timer value - has to be a holding register, because only holding registers accept a write from the master.
Getting the table right is what makes the poll return correct values and lets writes actually take effect. If a level is mapped as a coil, the poll will read a single bit instead of a full sixteen-bit number and the reading will be meaningless. If a setpoint is mistakenly mapped as an input register, the SCADA will be able to read it but every attempt to change it will fail because the table is read-only. A platform such as Merobix reads these tables over Modbus and turns each into a live tag - a run indicator, a level trend, a writable setpoint - and the tag only behaves correctly when it points at the right table.
The practical workflow is to take the RTU's register map, group its signals by type - digital statuses, digital commands, analog measurements, adjustable settings - and assign each group to the matching table before building the poll. Digital field states go to discrete inputs, digital commands to coils, measurements to input registers, and settings to holding registers. Doing this deliberately, rather than dumping everything into holding registers because they are read-write and forgiving, keeps the map self-documenting and prevents the class of bugs where a SCADA can technically read a value but the value it reads is the wrong shape or in the wrong place.
Both are single-bit values, but a coil is read-write and a discrete input is read-only. Coils historically represented relay outputs, so they are where a master writes commands such as start a pump or open a valve. Discrete inputs historically represented field digital inputs, so they hold observed states like a running contact or a level switch that the master reads but is not allowed to change.
Strictly, a measurement the master only reads belongs in an input register, because input registers are read-only and cannot be accidentally overwritten. In practice many devices place measurements in holding registers as well, since holding registers can be read too, but the cleaner mapping puts read-only measurements in input registers and reserves holding registers for values the master needs to write, such as setpoints.
The four Modbus tables are independent address spaces, so offset 5 in the coil table and offset 5 in the holding register table refer to completely different pieces of data. The leading digit in the classic reference numbering - 0x, 1x, 3x, 4x - identifies which table an address belongs to, but that digit is not sent on the wire. Because of this, an integrator must always know both the table and the offset for each value, taken from the device's register map.
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.