Modbus or MODBUS is a client/server data communications protocol in

the application layer.[1] It was originally designed for use with programmable
logic controllers (PLCs),[2] but has become a de
facto standard communication protocol for communication between
industrial electronic devices in a wide range of buses and networks. [3][1]

Modbus is popular in industrial environments because it is openly published

and royalty-free. It was developed for industrial applications, is relatively
easy to deploy and maintain compared to other standards, and places few
restrictions on the format of the data to be transmitted.

The Modbus protocol uses serial communication lines, Ethernet, or

the Internet protocol suite as a transport layer.[1] Modbus supports
communication to and from multiple devices connected to the same cable or
Ethernet network. For example, there can be a device that measures
temperature and another device to measure humidity connected to the same
cable, both communicating measurements to the same computer, via
Modbus.

Modbus is often used to connect a plant/system supervisory computer with

a remote terminal unit (RTU) in supervisory control and data acquisition
(SCADA) systems. Many of the data types are named from industrial control
of factory devices, such as ladder logic because of its use in driving relays: a
single-bit physical output is called a coil, and a single-bit physical input is
called a discrete input or a contact.

It was originally published by Modicon in 1979. The company was acquired

by Schneider Electric in 1997. In 2004, they transferred the rights to the
Modbus Organization[4] which is a trade association of users and suppliers of
Modbus-compliant devices that advocates for the continued use of the
technology.[5]

Protocol description

[edit]

MODBUS communication stack

Modbus standards or buses include:[1]

  TCP/IP over Ethernet

 Asynchronous serial communication in a wide range of standards,

technologies: EIA/TIA-232-E, EIA-422, EIA/TIA-485-A, fiber, radio
frequency,...

 MODBUS PLUS, a high speed token passing network.

Architecture of a network for Modbus

communication

To support Modbus communication on a network, many modems and

gateways incorporate proprietary designs (refer to the diagram: Architecture
of a network for Modbus communication). Implementations may deploy
either wireline or wireless communication, such as in the ISM radio band, and
even Short Message Service (SMS) or General Packet Radio Service (GPRS).

PDU and ADU

[edit]

Modbus defines a client which is an entity that initiates a transaction to

request any specific task from its request receiver.[6] The client's "request
receiver", which the client has initiated the transaction with, is then called
the server.[6] For example, when a Microcontroller unit (MCU) connects to a
sensor to read its data by Modbus on a wired network, e.g RS485 bus, the
MCU in this context is the client and the sensor is the server. In former
terminology, the client was named master and the server named slave.

Modbus defines a protocol data unit (PDU) independently to its lower layer
protocols in its protocol stack. Mapping MODBUS protocol on specific buses
or networks requires some additional fields, defined as the application data
unit (ADU). The ADU is formed by a client inside a Modbus network when the
client initiates a transaction. Contents are: [7]

 PDU = Function code + data

 ADU = Additional address + PDU + error check

The ADU is officially called a Modbus frame by the Modbus Organization,
[7]
although frame is used as the data unit in the data-link layer in the OSI
and TCP/IP model (while Modbus is an application layer protocol).

PDU max size is 253 bytes. ADU max size on RS232/RS485 network is 256
bytes, and with TCP is 260 bytes.[8]

For data encoding, Modbus uses a big-endian representation for addresses

and data fields. Thus, for a 16-bit value, the most significant byte is sent
first. For example, when a 16-bit register has value 0x1234, byte 0x12 is sent
before byte 0x34.[8]

Function code is 1 byte which gives the code of the function to execute.
Function codes are integer values, ranging from 1 to 255, and the range from
128 to 255 is for exception responses.

The data field of the PDU has the address from 0 to 65535 (not to be
confused with the address of the Additional address field of ADU). [9] The data
field of the PDU can be empty, and then has a size of 0. In this case, the
server will not request any information and the function code defines the
function to be executed. If there is no error during the execution process, the
data field of the ADU response from server to client will include the data
requested, i.e. the data the client previously received. If there is any error,
the server will respond with an exception code. [6]

Modbus transaction and PDU

[edit]

A Modbus transaction between client and server includes: [6][10]

 Step 1: Client initiates a request with PDU = Function code + data

request

 Step 2: Server receives the request from client. Server will then
read/parse the function code, get the address of the data field of the
PDU, then get this data field value and finally perform the action based
on the function code. If there is no error during those steps, the server
will respond with PDU = Function code + data response. As long as
there is no error during those steps, the server's responding function
code will also be the function code sent from the client. If there is any
error during those steps, the server will respond with PDU = Exception
Function code + Exception code (Reference to PDU mb_excep_rsp_pdu
defined below).
  Step 3: Client receives the response and ends the transaction.

Based on that, Modbus defines 3 PDU types:[8]

 MODBUS Request PDU, mb_req_pdu

 MODBUS Response PDU, mb_rsp_pdu

 MODBUS Exception Response PDU, mb_excep_rsp_pdu

mb_req_pdu = Function code (1 byte) + request data (n bytes)

request data field's size depends on the function code and usually includes
values like variable values, data offset, and sub-function codes. [8]

mb_rsp_pdu = Function code (1 byte) + response data (n bytes)

As in mb_req_pdu, response data field's size depends on the function code

and usually includes values like variable values, data offset, and sub-function
codes.[8]

mb_excep_rsp_pdu = Exception Function code (1 byte) + exception code (1

byte)

Exception Function code = Function code (1 byte) + 0x80. Exception

Function code is equal to the Function code, except that its MSB is set to 1.

Exception code (1 byte) of mb_excep_rsp_pdu is defined in the MODBUS

Exception Codes table.

Modbus data model

[edit]

Modbus defines its data model based on a series of tables of four primary
types:[11]

Primary Acces
Size Features
tables s

Discrete input R 1 bit (0–1) Read on/off value

Coil (discrete Read/Write on/off

R/W 1 bit (0–1)
output)[12] value

16 bit words Read measurements

Input register R
(0–65,535) and statuses
 Holding 16 bit words Read/Write
R/W
register (0–65,535) configuration values

For each of the primary tables, the protocol allows individual selection of
65536 data items, and the operations of read or write of those items are
designed to span multiple consecutive data items up to a data size limit
which is dependent on the transaction function code. [11]

Function code

[edit]

Modbus defines three types of function codes: Public, User-Defined and

Reserved.[13]

Public function codes

[edit]

Function Functio Comme

Function type
name n code nt

Data Physical Read

Acces Discrete Discrete 2
s Inputs Inputs

Bit Read Coils 1

acces
Internal
s Write Single
Bits or 5
Coil
Physical
Coils Write
15
Multiple Coils

16-bit Physical
Read Input
acces Input 4
Registers
s Registers

Internal Read 3
Registers Multiple
or Physical Holding
Output Registers
 Write Single
Holding 6
Register

Write
Multiple
16
Holding
Registers
Registers
Read/Write
Multiple 23
Registers

Mask Write
22
Register

Read FIFO
24
Queue

Read File
20
Record
File Record Access
Write File
21
Record

Diagnostics Read
serial
Exception 7
only
Status

serial
Diagnostic 8
only

Get Com
serial
Event 11
only
Counter

Get Com serial

12
Event Log only

Report 17 serial
Server ID only
 Read Device
43
Identification

Encapsulated
Other Interface 43
Transport

Note: Some sources use terminology that differs from the standard; for
example Force Single Coil instead of Write Single Coil.[14]

Function code 01 (read coils) as an example of public function code

[edit]

Function code 01 (read coils) allows reading the state from 1 to 2000 coils of
a remote device. mb_req_pdu (request PDU) will then have 2 bytes to
indicate the address of the first coil to read (from 0x0000 to 0xFFFF), and 2
bytes to indicate the number of coils to read. mb_req_pdu defines coil
address by index 0, i.e the first coil has address 0x0. On a successful
execution, mb_rsp_pdu will return one byte to note the function code (0x01),
followed by one byte to indicate the number of data bytes it is returning (n),
which will be the number of coils requested by mb_req_pdu, divided by 8 bits
per byte, and rounded up. The remainder of the response will be the
specified number (n) of data bytes.[15] That is, the mb_req_pdu and
mb_rsp_pdu of function code 01 will take the following form: [15]

mb_req_pdu:

 Function code: 0x01 (1 byte)

 Starting Address (1st coil address to read): From 0x0000 to 0xFFFF (2

bytes)

 Quantity of coils to read: Range from 1 to 2000 (0x7D0) (2 bytes)

mb_rsp_pdu:

 Function code: 0x01 (1 byte)

 Byte count: 1 byte (n=quantity of coils/8, rounded up)

 Coil Status: n bytes

For instance, mb_req_pdu and mb_rsp_pdu to read coils status from 20-38
will be:[16]

mb_req_pdu:
  Function code: 0x01

 Starting Address High byte: 0x00

 Starting Address Low byte: 0x13

 Quantity of Outputs High byte: 0x00

 Quantity of Outputs Low byte: 0x13

Starting Address (2 bytes) is 0x0013, (or 19 in decimal) which is the 20th

coil.

Quantity of Outputs (2 bytes) is 0x0013, (or 19 in decimal) which

corresponds to 19 values of status of coils 20th to 38th.

mb_rsp_pdu:

 Function code: 0x01

 Byte Count: 0x03

 Outputs status 27-20: 0xCD

 Outputs status 35-28: 0x6B

 Outputs status 38-36: 0x05

As 19 coils (20-38) are required, 3 bytes is used to indicate the coil's state.
So that Byte Count is 0x03. States of coil from 20 to 27 is 0xCD, which is
1100 1101 in binary. So coil 27 is MSb, and coil 20 is LSb. Same for coil 28 to
35. With coil from 36 to 38, the state will be 0x05, which is 0000 0101. Coil
38 state is the 3rd bit (count from the right), i.e 1, coil 37 is 0, and coil 36
state is LSb bit, i.e. 1. 5 left bits are all 0.

User-defined function codes

[edit]

User-Defined Function Codes are function codes defined by users. Modbus

gives two range of values for user-defined function codes: 65 to 72 and 100
to 110. Obviously, user-defined function codes are not unique. [13]

Reserved function codes

[edit]

Reserved Function Codes are function codes used by some companies for
legacy product and are not available for public use. [13]
Exception responses

[edit]

When a client sends a request to a server, there can be four possible events
for that request:[17]

 If server receives the request and execute successfully, server will

return a normal response.

 If server cannot receive the request as having communication channel

error, server will not respond anything to the client. Client will then
have the timeout request error.

 If server receives the request and detect an error on the

communication channel (e.g parity, LRC, CRC), server will not response
anything to the client. Client will then have the timeout request error.

 If server receives the request and is unable to execute it (e.g client

requests to read a non-existent register), server will return
an exception response to client to indicate the nature of the error.

Exception response message includes two other fields when compared to a

normal response message:[17]

 Function Code: Function code's MSB bit of Exception is 1. This will make
this function code 0x80 higher than then request message function
code.

 Data: Server returns the exception code inside the Data field. This field
defines the nature of the error.

All Modbus exception code:[18]

Cod
Text Details
e

Function code received in the

Illegal
1 query is not recognized or
Function
allowed by server

Data address of some or all

Illegal Data the required entities are not
2
Address allowed or do not exist in
server
 Illegal Data Value is not accepted by
3
Value server

Server Unrecoverable error occurred

4 Device while server was attempting
Failure to perform requested action

Server has accepted request

and is processing it, but a
long duration of time is
required. This response is
returned to prevent a
Acknowledg
5 timeout error from occurring
e
in the client. client can next
issue a Poll Program
Complete message to
determine whether
processing is completed

Server is engaged in
Server processing a long-duration
6
Device Busy command; client should retry
later

Server cannot perform the

Negative programming functions;
7 Acknowledg client should request
e diagnostic or error
information from server

Server detected a parity

Memory
8 error in memory; client can
Parity Error
retry the request

Gateway Specialized for Modbus

10 Path gateways: indicates a
Unavailable misconfigured gateway

11 Gateway Specialized for Modbus

Target gateways: sent when server
Device
 Failed to
fails to respond
Respond

Modbus over Serial Line protocol

[edit]

Modbus standard also defines Modbus over Serial Line, a protocol over
the data link layer of the OSI model for the Modbus application layer protocol
to be communicated over a serial bus.[19] Modbus Serial Line protocol is
a master-slave protocol which supports one master and multiple slaves in the
serial bus.[20] With Modbus protocol on the application layer, client/server
model is used for the devices on the communication channel. With Modbus
over Serial Line, client's role is implemented by master, and the server's role
is implemented by slave.[20][21]

The organization's naming convention inverts the common usage of having

multiple clients and only one server. To avoid this confusion, the RS-485
transport layer uses the terms "node" or "device" instead of "server", and the
"client" is not a "node".[21]

The (Modbus Organization) is using "client-server" to describe Modbus

communications, characterized by communication between [client device (s),
which initiates communication and makes requests of server device(s), which
process requests and return an appropriate response (or error message).

A serial bus for Modbus over Serial Line can have a maximum of 247 slaves
communicating with one master. Those slaves have a unique address
ranging from 1 to 247 (decimal value).[22] The master doesn't need to have
an address.[22] The communication process is initiated by the master, as only
it can initiate a Modbus transaction. A slave will never transmit any data or
perform any action without a request from the master, and slaves cannot
communicate with each other.[23]

In Modbus over Serial Line, the master initiates requests to the slaves
in unicast or broadcast modes. In unicast mode, the master will initiate a
request to a single slave with a specific address. Upon receiving and finishing
the request, the slave will respond with a message to the master. [22] In this
mode, a Modbus transaction includes two messages: one request from the
master and one reply from the slave. Each slave must have a unique address
(from 1 to 247) to be addressed independently for the communication.
[22]
In broadcast mode, the master can send a request to all the slaves, using
the broadcast address 0,[22] which is the address reserved for broadcast
exchanges (and not the master address). Slaves must accept broadcast
exchanges but must not respond.[23] The mapping of PDU of Modbus to the
serial bus of Modbus over Serial Line protocol results in Modbus Serial Line
PDU.[22]

Modbus Serial Line PDU = Address + PDU + CRC (or LRC)

With PDU = Function code + data

 Address is slave address

 PDU is defined identically to the PDU of Modbus Application protocol

 The Error check field with CRC/LRC: The error check methods depend
on the protocol versions of the MODBUS over Serial Line, whether it
is Modbus RTU or Modbus ASCII.

On the physical layer, MODBUS over Serial Line performs its communication
on bit by RS485 or RS232, with TIA/EIA-485 Two-Wire interface as the most
popular way. RS485 Four-Wire interface is also used. TIA/EIA-232-E (RS232)
can also be used but is limited to point-to-point short-range communication.
[20]
MODBUS over Serial Line has two transmission
modes RTU and ASCII which are corresponded to two versions of the
protocol, known as Modbus RTU and Modbus ASCII.[24]