How to Map a Modbus Device in SCADA

Creating the Connection and Setting the Unit ID

Modbus comes in two common transports, and the first thing to establish is which one this device uses, because the connection settings are completely different. Modbus RTU runs over a serial line, typically RS-485, and to talk to it you have to match the device's serial parameters exactly: the baud rate, the number of data bits, the parity, and the stop bits. If any one of these is wrong, the two ends cannot understand each other at all and you get silence or garbage, so these values are read from the device's manual and entered to match. Because RS-485 is a multi-drop bus, several devices can share the same wire, which is why the unit ID matters so much on serial.

Modbus TCP runs over an Ethernet or cellular network instead, and its connection settings are an IP address and a TCP port, conventionally port 502. This is generally easier to set up than serial because there are no baud rates or parity to match, but it brings network concerns instead, the device needs a reachable address, the network path has to allow the traffic, and firewalls can block it. Many modern devices and gateways speak Modbus TCP, and some serial devices sit behind a gateway that converts RTU to TCP, so it is common to have a mix. Knowing which transport you are on tells you which set of connection fields to fill in.

The unit ID, also called the slave ID or device address, identifies which device you are talking to, and getting it right is essential. On a serial RS-485 bus with several devices sharing one wire, the unit ID is how the master addresses one specific device and not its neighbors, so every device on the bus must have a unique ID and your configuration must use the exact ID the device is set to. On Modbus TCP, where the IP address already identifies the device, the unit ID is often a fixed value like 1 but is still required and still occasionally matters, especially for a gateway that fronts several serial devices behind one IP, where the unit ID selects which downstream device the request is routed to. A wrong unit ID typically produces no response at all, which is at least an obvious failure to diagnose.

Mapping Coils and Registers with the Right Function Code

Modbus organizes data into four separate address spaces, and picking the right one is the core of mapping. Coils are single bits that can be read and written, used for on/off outputs like a pump run command. Discrete inputs are single bits that are read-only, used for on/off statuses like a limit switch. Holding registers are 16-bit values that can be read and written, used for setpoints and most numeric process values. Input registers are 16-bit read-only values, often used for measurements. Each space is accessed by its own function codes, so when you create a tag you tell it which space and therefore which function code to use, and the same numeric address means a different thing in each space.

This four-way split is the source of one of the most common Modbus mistakes, along with the numbering offset that goes with it. A value at address 40001 in the traditional convention lives in the holding register space, and depending on the tool you may enter it as register 0, register 1, or the full 40001, because vendors disagree about whether numbering starts at zero or one and whether to include the space prefix. Reading the device's register map carefully, and noting exactly which convention it uses, is what keeps you from landing one address off and reading the neighbor's value. When a tag reads a plausible but wrong number, an off-by-one address or the wrong register space is the first thing to suspect.

The disciplined way to map is to work straight from the manufacturer's register map, the table that lists every value the device exposes with its address, its space, its data type, and its scaling. For each value you want, you create a tag, set it to the correct space and function code, enter the address using the tool's convention, and give it a name and description. Doing this methodically, one row of the register map at a time, is far more reliable than guessing from a similar device, because two devices from the same vendor can have entirely different maps. The register map is the single source of truth for a Modbus device, and mapping is essentially the act of translating that table into tags.

Word Order, Scaling, and Verifying Over the Real Link

The two things that most often make a correctly addressed Modbus tag still read wrong are word order and scaling, and both come from Modbus registers being only 16 bits wide. Any value that needs more range than a 16-bit integer, a 32-bit integer or a floating-point number, has to be spread across two consecutive registers, and there is no universal rule for which register holds the high half. Some devices put the high word first and some put it low word first, and if your tag assembles them in the wrong order the value comes out wildly wrong, often a huge or nonsensical number. Fixing word order, sometimes called byte or word swap, is usually a single setting on the tag once you recognize the symptom, and the symptom is unmistakable because the number is absurd.

Scaling is the other half, and it comes from Modbus having no way to carry units or decimal points. A device often reports a value as a plain integer that represents a scaled quantity, a pressure sent as 1250 to mean 125.0 psi, a temperature sent in tenths, a flow sent in some device-specific units. The register map tells you the scaling, and you apply it on the tag, a multiplier and offset, or a raw-to-engineering span, so the tag reads the real engineering value with the right units rather than a raw count. A tag that reads exactly ten times too big or too small is the classic sign of a missing or wrong scale factor, distinct from the absurd numbers that signal a word-order problem, so the two failure modes are usually easy to tell apart.

Nothing about a Modbus map is trustworthy until you have watched the tags read live over the real link, and this final verification catches the errors that survive the paperwork. You want to see each tag reading a sensible value in the right units with good quality, ideally while someone confirms the physical condition, a pump that is actually running shows its run bit set, a pressure that is really 90 psi reads 90. In a cloud SCADA platform such as Merobix, a Modbus RTU or flow computer at a remote site connects over cellular or a gateway, and its mapped tags appear live in the browser, so an engineer can verify the whole map from the office while a technician at the site creates known conditions. Because Modbus over a cellular link also makes scan rates and traffic matter, verifying the map is also the moment to confirm the device is responding reliably and not timing out, which would leave tags reading stale or bad-quality values regardless of how correct the mapping is.

Frequently Asked Questions