You cannot poll a Modbus device by guessing where its data lives; you have to read the map the manufacturer publishes. That map, usually a table in the device manual, tells you the address of every value, what kind of value it is, how it is scaled, and whether you can write to it. Reading that table correctly is the foundation of every Modbus integration, and misreading it is the most common cause of garbage data. This guide walks through the columns of a register map, shows how to turn the table into a working poll configuration, and covers the pitfalls - zero-based addressing and mislabeled data types chief among them - that trip up otherwise correct setups.
Register Map Address Table in one line: A Modbus register map is the vendor-published table that documents every value a device exposes over Modbus - the address of each point, its register type, its data type, its scaling and units, and whether it is read-only or read-write. It is the device's data dictionary, and you use it to build a poll by translating each row into a point in your polling configuration. Reading it accurately, especially the addressing convention and data types, determines whether the values you collect are correct or meaningless.
A register map is a table, and each column answers one question about a value. The address column says where the value lives in the device's memory. The register type column says which of the four Modbus tables it belongs to - a coil or discrete input for single-bit data, or an input register or holding register for 16-bit data - which in turn determines the function code you use to read it. The data type column says how to interpret the raw bits: a single register might be an unsigned or signed 16-bit integer, or a value might span two registers as a 32-bit integer or an IEEE-754 float. Getting the data type right is essential, because the same raw bytes mean completely different numbers depending on how they are decoded.
The remaining columns tell you how to turn the raw number into a real measurement and what you are allowed to do with it. A scaling or multiplier column, sometimes paired with a units column, says how the stored number maps to an engineering value - a register might hold tenths, so a raw 235 means 23.5, or carry a multiplier that converts counts to a pressure in the correct units. The access column says whether the point is read-only, like a live measurement, or read-write, like a setpoint you can command. A good register map also names each point in plain language, so the row ties an address to a meaning: this register, of this type, decoded this way, scaled like so, is the discharge pressure, and it is read-only. All of that lives in the table, and reading it is a matter of walking each row across its columns.
Building a poll is essentially translating each row of the register map into a point in your configuration. For every value you want, you take its address, its register type, and its data type from the map and enter them into the poller so it knows where to read, which function code to use, and how many registers the value occupies. You add the scaling so the raw number is converted to the correct engineering value and units, and you note the access so you configure it as a read point or, where appropriate, as a writable one. Done for every point you care about, this produces a poll that reads the device and delivers correctly interpreted, correctly scaled data.
The efficient way to do this is to read the map with an eye on layout as well as meaning. Because a single Modbus read can return a contiguous block of registers, values that sit next to each other in the address space can be gathered in one request, while scattered values force more, smaller reads. Skimming the map for the contiguous runs that contain the points you need lets you configure block reads that pull many values per request, which matters for poll speed - especially when a cloud SCADA platform such as Merobix is reaching remote sites over links where each round trip costs latency and data. The map is not only the key to what each value means but also the guide to how efficiently the device can be polled, so it pays to read it for structure and not just point by point.
The single most common register-map mistake is an addressing offset caused by the difference between how registers are numbered in documentation and how they are addressed on the wire. Many vendors document holding registers with numbers starting at 40001, a one-based convention, while the actual Modbus request uses a zero-based address, so the value documented as 40001 is read at address 0, 40002 at address 1, and so on. If you enter the documented number directly where the poller expects the wire address, every point is off by one and you read neighboring values instead of the ones you wanted. The fix is to know which convention the map uses and convert consistently, and the telltale symptom of getting it wrong is that all your values are shifted by one register.
The second recurring trap is data types that are mislabeled, ambiguous, or silently assume a byte and word order the map does not state. A value that is actually a 32-bit float read as two separate integers comes out as nonsense; a signed value read as unsigned reads correctly for small positive numbers and wildly wrong for negative ones; and a 32-bit value can have its two registers or its bytes ordered in ways the map fails to specify, so the number looks like garbage until you try the other ordering. The defense is to verify against reality: read a value you can independently confirm - a pressure you can compare to a gauge, a status you can toggle - and check that your decoding produces the expected number before trusting the rest of the map. An accurate register map read carefully is the foundation of every Modbus integration, but even a good map has to be validated against a few known values, because the gap between what the table says and what the device actually returns is exactly where these pitfalls hide.
A register map documents every value a device exposes over Modbus, with a row per point and columns for the address, the register type - coil, discrete input, input register, or holding register - the data type that says how to decode the raw bits, the scaling and units that convert the raw number to an engineering value, and the access that says whether the point is read-only or read-write. Good maps also name each point in plain language, so a row ties a specific address to a specific meaning.
This is almost always an addressing convention mismatch. Many vendors number holding registers starting at 40001, a one-based convention, while the actual request uses a zero-based address, so the register documented as 40001 is read at address 0. If you enter the documented number where the poller expects the wire address, every point shifts by one and you read the neighboring value instead. The fix is to identify which convention the map uses and convert consistently between the documented number and the wire address.
Usually because the data type or byte and word order is wrong for that value. A 32-bit float read as two integers, a signed value read as unsigned, or a two-register value with its registers or bytes in the wrong order all produce numbers that look like garbage even when the address is right. The register map may not fully specify the ordering, so the fix is to verify against a value you can independently confirm - a pressure against a gauge, for instance - and adjust the decoding until it matches reality.
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.