Understanding Modbus: History, Memory Areas, Addresses, and Function Codes

Historical Background

Modbus was introduced in 1979 to provide a simple, open protocol for communication between programmable logic controllers (PLCs). Its free and straightforward design has made it a de‑facto standard in industrial automation for more than four decades.

Protocol Foundations

Modbus operates on a master‑slave model and can be studied on two levels:

Application layer : Most developers use open‑source libraries that hide the low‑level details.

Message layer : Understanding the raw frame format gives a solid base for working with other industrial protocols.

Memory Area Classification

Modbus defines four logical memory areas based on read/write capability and data type:

Input coil (read‑only Boolean, “1区”)

Output coil (read/write Boolean, “0区”)

Input register (read‑only 16‑bit word, “3区”)

Holding register (read/write 16‑bit word, “4区”)

Coils represent on/off states; registers store numeric values.

Storage‑Area Codes

Each area is identified by a numeric code used in addresses. The codes are:

1 – Input coil

0 – Output coil

3 – Input register

4 – Holding register

There is no “2区” code; this is a historical quirk of the original specification.

Address Ranges

Every area can contain up to 65 536 items, indexed from 0. Consequently each area’s address range is 0‑65535.

Absolute vs. Relative Addresses

Modbus forms an absolute address by concatenating the storage‑area code with a five‑digit relative offset (padded with leading zeros). This fixed‑length format removes ambiguity. For example, the first holding register is addressed as 400001 (area code 4 + offset 00001).

Long and Short Address Models

Two common notations exist:

Long address model (6‑digit): area code + 5‑digit offset, e.g., 400001.

Short address model (5‑digit): only the offset, used when the area is implied, e.g., 00001 for the first holding register.

Function Codes

Function codes identify the specific read/write operation. Combining the two actions (read/write) with the four memory areas yields six permissible actions (writing to input coils/registers is prohibited). Splitting write operations into single‑item and multiple‑item variants expands the set to eight standard function codes: 0x01 – Read output coils 0x02 – Read input coils 0x03 – Read holding registers 0x04 – Read input registers 0x05 – Write single coil 0x06 – Write single register 0x0F – Write multiple coils 0x10 – Write multiple registers

Additional diagnostic function codes exist but are rarely used.

Protocol Families

Modbus is defined in three families, each with its own transport:

Modbus RTU – Serial line (RS‑485/RS‑232) with binary framing.

Modbus ASCII – Serial line with ASCII‑encoded frames.

Modbus TCP – Ethernet using TCP/IP.

Although RTU and ASCII are typical for serial links and TCP for Ethernet, the protocol itself is application‑layer only and can be carried over any physical medium.

Message Formats

Modbus RTU

Slave address (1 byte)

Function code (1 byte)

Data (N bytes)

CRC checksum (2 bytes)

Modbus ASCII

Start character ‘:’

Slave address (2 ASCII bytes)

Function code (2 ASCII bytes)

Data (N ASCII bytes)

LRC checksum (2 ASCII bytes)

End characters CR LF

Modbus TCP

Transaction identifier (2 bytes)

Protocol identifier (2 bytes, always 0)

Length (2 bytes)

Unit identifier (1 byte)

Function code (1 byte)

Data (N bytes)

Understanding the RTU frame provides a basis for interpreting the ASCII and TCP frames.

Addressing Example

To refer to the 100th holding register unambiguously, use the absolute address 40100 (area code 4 + offset 00100). The same numeric offset in another area would have a different area code, e.g., 10100 for the 100th input coil.

Absolute address = storage‑area code + 5‑digit offset. Relative offset is the same for each area; the absolute address uniquely identifies a data point.

Practical Notes

Modbus is free, well‑documented, and supported by many debugging tools, allowing thorough learning without hardware. When hardware is available, testing against real devices helps validate the concepts.