Understanding Modbus

Client and Server (or Master and Slave?)

One of the biggest sources of confusion on-site is the terminology. Older Modbus documentation and many devices still use master and slave. Newer standards use client and server. They mean the same thing:

You'll see both naming conventions used interchangeably in datasheets, PLC manuals, and configuration software. A "Modbus master" is the same as a "Modbus client". If a colleague says "the slave isn't responding", they mean the server.

TCP or RTU

Modbus comes in two variants that determine how messages are transmitted:

Modbus TCP works over a regular network (Ethernet/Wi-Fi). You need an IP address and port. No special hardware required. This is the most common variant in modern installations.

Modbus RTU works over a serial connection (RS-485). RTU is common in older installations and industrial environments where devices are directly connected by cable.

Unit ID

The Unit ID identifies which server should respond to a request. How it works depends on the variant:

With RTU the Unit ID is always required. Multiple devices share the same serial bus, and the Unit ID is the only way to address a specific one. Each device on the bus has its own unique Unit ID.

With TCP the Unit ID is often optional. Each device typically has its own IP address, so the Unit ID is redundant. You can usually leave it at 0.

RTU-to-TCP converters are where it gets interesting. These converters bridge a TCP network to a serial RTU bus. You connect via TCP (IP address and port), but behind the converter there may be multiple RTU devices. In that case the Unit ID is required to route your request to the correct device on the bus.

Register types

Modbus organizes data into four types of registers. Each type has its own purpose, described here from the client's perspective:

Holding Registers: read and write

The workhorses of Modbus. The client can both read and write these. Used for setpoints, configuration parameters, alarm thresholds.

Input Registers: read only

Sensor data and measurements. The server populates these with values (e.g. a temperature reading) and the client reads them out. The client can't write to them.

Coils: read and write (on/off)

Digital outputs. The client can turn them on or off, for example a pump or a valve. Each coil is one bit: 0 (off) or 1 (on).

Discrete Inputs: read only (on/off)

Digital inputs. The server sets these based on physical state (a switch, a sensor). The client can only read them. Like coils they're binary, but read only.

Addressing

The address problem

The wire carries one number, from 0 to 65535. Manuals print something else, and rarely the same something. These are all the first holding register, the one Modbux reads at address 0:

Two independent choices produce that list: whether the number carries a type prefix, and whether counting starts at 0 or 1. Rows three and four make both choices differently and land one apart, which is the argument people keep having about "register 40001".

Modicon, in case you were wondering, is the company that invented Modbus in 1979. The 4xxxx numbering comes from how their PLCs laid out memory.

When 40001 really is 40001

There is a seventh reading: 40001 is also an ordinary address. SunSpec solar inverters put their register map at 40000 and upward, and those are real addresses on the wire.

The decisive test is the ceiling. A manual listing anything above 49999 cannot be using the 5-digit prefix scheme, because that scheme has no room past 4x9999. If it also prints a separate 3xxxx table for input registers, it is using prefixes.

Working it out

Strip the prefix, then fix the base:

• 40001 → drop the 4 → 0001 → counting from 1, subtract 1 → 0
• 30011 → an input register → 0011 → 10

To find the base, look at the manual's lowest address. 40001 counts from 1, 40000 from 0, and a table starting at 0 is already protocol addresses.

Or ask the device

When the documentation is the problem, stop reading it.

Scan both candidate ranges, 0 to 200 and 39900 to 40100. Whichever comes back full settles it. Then read the values rather than the addresses: a grid voltage sits near 230 and a frequency near 50, so the row with a plausible number is your register. Compare its address with the manual's and that offset holds for the whole device.

The prefix, when there is one

Siemens TIA Portal's MB_CLIENT block works this way. MB_MODE says read or write, and MB_DATA_ADDR carries the type and the address together:

On the write rows MB_DATA_LEN picks between the single and multiple function codes. Past 9999 registers the block takes 400001 to 465535, where 400001 is address 0, so 465535 is 65534: the last register a device can have is the one address this notation cannot write down.

Function codes

Under the hood, Modbus uses numbered commands (function codes) for each operation. You don't need to memorize them, but they help when debugging:

Big-Endian vs Little-Endian

When a value needs more than 16 bits (like a 32-bit integer or float), it gets split across multiple 16-bit registers. The question is: which register gets the "high" part and which gets the "low" part? That's what endianness determines.

Take the 32-bit integer 305419896 (hex 0x12345678) split across two registers. Switch between the tabs to see what changes:

Register 0:  0x1234  (W1 - high word)
Register 1:  0x5678  (W0 - low word)

registers[0] := W1;   // most significant word first
registers[1] := W0;

Register 0:  0x5678  (W0 - low word)
Register 1:  0x1234  (W1 - high word)

registers[0] := W0;   // least significant word first
registers[1] := W1;