What Is Modbus? A Field Guide

Modbus is one of the oldest protocols still in daily use, and if you work anywhere near factory floors, building automation, or energy metering, you will run into it. It is refreshingly simple once the vocabulary clicks. This is a practical tour of what Modbus is and how to read a device that speaks it.

A protocol from 1979 that never left

Modbus was created by Modicon in 1979 for their programmable logic controllers. Decades later it is a de-facto standard: PLCs, remote terminal units, power meters, and countless sensors expose their data over Modbus, which is why it remains the common language of industrial equipment.

The model is deliberately plain. Modbus is a request/response protocol built around one asker and many responders. A master asks, a slave answers, and that is the entire conversation. (The 2020 revision of the specification renamed those roles to client and server; newer documentation uses those terms, but master/slave is still what you will hear on most factory floors.) There is no streaming and no push. If you want data continuously, the master has to poll continuously.

The memory map: registers and coils

Every Modbus device exposes a flat memory map divided into four tables:

• Coils. Single read/write bits, typically outputs like a relay or a pump-on flag.
• Discrete inputs. Single read-only bits, typically digital inputs like a limit switch.
• Input registers. Read-only 16-bit values, typically live measurements like a temperature.
• Holding registers. Read/write 16-bit values, used for setpoints, counters, and configuration.

A request names a function code (what to do, such as "read holding registers"), a starting address, and a count. The slave replies with the values or an error. To read ten measurements starting at address 100, the master sends one request and gets ten registers back.

RTU or TCP: same data, different pipe

Modbus comes in two common transports. Modbus RTU runs over a serial line, usually RS-485, and packs the request into a compact binary frame with a CRC. Modbus TCP wraps the same request in a TCP/IP packet over Ethernet. The data model, the register tables, and the function codes are identical. Only the delivery changes. If you understand one, you understand both.

The gotcha everyone hits: register numbering

Two conventions collide here, and they cause more confusion than anything else in Modbus. Documentation often lists a holding register as 40001, but the address that actually travels on the wire for that register is 0. The leading 4 denotes the holding-register table, and the numbering is one-based, so 40001 maps to protocol address 0, 40002 to 1, and so on. When your values come back shifted by one, this is almost always why.

The second half of the gotcha is scaling. A register is only 16 bits, so a device usually stores a decimal value as an integer. A temperature of 25.1 °C might arrive as 251, meaning tenths of a degree. Larger or fractional values are often split across two registers and reassembled into a 32-bit number. The raw register is never the whole story; you always need the device's register map to know the scale.

Reading a Modbus device

Serial Studio Pro can act as the Modbus master. You choose the transport (a serial port for RTU, or a host and port for TCP), the unit ID, and for each block the function code, starting address, count, and poll interval. Each register then becomes a value you map onto a widget, with any scaling handled in a short parser. If your vendor provides a register map as a CSV, XML, or JSON file, Serial Studio's importer can turn it straight into a project.

As with the other buses, you can practice without hardware. Serial Studio's Modbus example includes a PLC simulator, so you can poll registers, watch them update, and lay out a dashboard before you ever connect to a real device.

Modbus does not try to be clever, and that is its strength. Learn the four tables, remember the register-numbering offset, and keep the scale factors handy, and you can read almost any industrial device you meet.