A common Modbus configuration pitfall is pointing the wrong read function at a register: a value that only exists as an input register will not answer a holding-register read, and vice versa, even though the address is right. Function code 3 reads holding registers and function code 4 reads input registers, and these are two separate address spaces that happen to look similar. This page explains the difference between an FC3 holding-register read and an FC4 input-register read, how to tell which table a value lives in from a vendor map, and how to set the correct read function for each tag so the value comes back instead of an exception.
Modbus FC4 vs FC3 read in one line: Modbus function code 3 reads holding registers and function code 4 reads input registers, which are two distinct tables even though both hold sixteen-bit words. If a device maps a value only as an input register and you try to read it with FC3, you can get an exception or no valid value, because you are reading the wrong table. Identify from the vendor map which table each value lives in, often shown by a 3xxxx prefix for input registers or 4xxxx for holding registers, and configure the read function to match per tag.
Modbus does not keep all its numeric values in one place. It defines separate data tables, and two of them carry sixteen-bit numeric words: holding registers and input registers. Holding registers are read-write and are used for setpoints, configuration, and general-purpose values the master may both read and change. Input registers are read-only and are typically used for measurements and status the device produces, values the master should read but not write. They are genuinely different tables with their own address spaces, not two names for the same storage.
Because they are different tables, they are accessed with different function codes. Function code 3, read holding registers, addresses the holding-register table, and function code 4, read input registers, addresses the input-register table. The function code you send is what selects which table the device looks in, so the same numeric address can point to two entirely different values depending on whether you asked with FC3 or FC4. The register-types and function-code concept pages define these tables and codes; the key operational point is that the function code is not a formality, it chooses the table.
This is why a value can read perfectly with one function and fail with the other. If a device implements a measurement only in its input-register table and you read the corresponding address with FC3, you are looking in the holding-register table where that value does not exist, so the device may return an illegal data address exception or simply not the value you wanted. Nothing is wrong with the address or the wiring; you have aimed the right number at the wrong table. Reading it with FC4 instead points at the table where the value actually lives, and it comes back correctly.
The vendor register map is where you learn which table each value belongs to, and there are a few common conventions to recognise. Many manuals use a leading digit to signal the table: numbers in the 30000 range, such as 30001, denote input registers, while numbers in the 40000 range, such as 40001, denote holding registers. So a value documented as 30005 is an input register you must read with FC4, and a value documented as 40005 is a holding register you read with FC3. That leading digit is a labelling convention for the table, not part of the wire address, but it is a reliable signpost when the manual uses it.
Not every manual uses the 3xxxx and 4xxxx convention, so also look for explicit wording. A good register map states the register type, read-only versus read-write, or names the function code to use for each block, and read-only measurement values are frequently the input registers while writable setpoints are the holding registers. When the documentation lists a value as read-only and calls it an input register or gives its function code as 4, that is your instruction to use FC4 for that tag. Matching each tag to the table the map assigns it is the whole task; the map is telling you which read function to use.
Ambiguity does arise, because some devices deliberately expose the same value in both tables for compatibility, and others document a value in a way that does not make the table obvious. When it is unclear, the empirical test is simple: read the address with FC3 and with FC4 and see which returns the correct value and which returns an exception or nonsense. The function that returns the right number tells you the table, and you can then fix the tag's read function permanently. This is a distinct question from an off-by-one address or a byte-order problem; here the address may be fine and only the function code, and therefore the table, is wrong.
Because a single device usually exposes both input and holding registers, the read function is a per-tag setting, not a device-wide one. A flow meter, for example, might report its measured flow as input registers and hold its configuration and setpoints as holding registers, so a correct configuration reads the measurements with FC4 and the settings with FC3 on the very same device. Good Modbus drivers let you choose the function code, or an address prefix that implies it, for each tag or each block, and the discipline is to set that from the vendor map as you build the tag list rather than assuming everything is a holding register.
Defaulting everything to FC3 is a common cause of this fault, because holding registers are the most familiar table and many people reach for them by habit. A device that maps its live measurements only as input registers will refuse those FC3 reads while its writable settings read fine, producing the confusing situation where some tags on a device work and others throw exceptions. Recognising that the working tags are holding registers and the failing tags are input registers, and switching just those failing tags to FC4, resolves it without touching addresses or wiring. This targeted fix is why identifying the table per tag matters.
In a cloud SCADA system these are deterministic commissioning-time issues, because a tag pointed at the wrong table fails every poll, showing permanently bad quality rather than intermittently. A cloud SCADA platform such as Merobix will report the exception per tag, so the practice is to resolve each register-type mismatch before the site goes live by confirming, from the vendor map, whether each tag is an input register read with FC4 or a holding register read with FC3. Getting the read function right per tag once means those tags stay good, and it keeps the failure cleanly separated from address and decode problems, which have their own distinct fixes.
Function code 3 reads holding registers, which are read-write and hold setpoints and general values, while function code 4 reads input registers, which are read-only and typically hold measurements. They address two separate tables, so the function code you send selects which table the device looks in. The same numeric address can point to different values depending on whether you read it with FC3 or FC4.
Because the value only exists in one of the two tables. If a device maps a measurement only as an input register and you read it with FC3, you are looking in the holding-register table where it does not exist, so you get an exception or no valid value. The address and wiring are fine; you aimed the right number at the wrong table. Reading it with the matching function code points at the table where the value actually lives.
Many manuals use a leading digit: 30000-range numbers like 30001 denote input registers read with FC4, and 40000-range numbers like 40001 denote holding registers read with FC3. Where that convention is not used, look for explicit wording, read-only measurements are usually input registers and writable setpoints are holding registers, or the map may name the function code per block. If it is unclear, read the address with both functions and see which returns the correct 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.