MODBUS APPLICATION PROTOCOL SPECIFICATION
V1.1b3
CONTENTS
1
Introduction ...................................................................................................................... 2
1.1 Scope of this document ........................................................................................... 2
2 Abbreviations ................................................................................................................... 2
3 Context ............................................................................................................................. 3
4 General description .......................................................................................................... 3
4.1 Protocol description ................................................................................................. 3
4.2 Data Encoding ......................................................................................................... 5
4.3 MODBUS Data model .............................................................................................. 6
4.4 MODBUS Addressing model .................................................................................... 7
4.5 Define MODBUS Transaction .................................................................................. 8
5 Function Code Categories .............................................................................................. 10
5.1 Public Function Code Definition ............................................................................. 11
6 Function codes descriptions ........................................................................................... 11
6.1 01 (0x01) Read Coils ............................................................................................. 11
6.2 02 (0x02) Read Discrete Inputs ............................................................................. 12
6.3 03 (0x03) Read Holding Registers ......................................................................... 15
6.4 04 (0x04) Read Input Registers ............................................................................. 16
6.5 05 (0x05) Write Single Coil .................................................................................... 17
6.6 06 (0x06) Write Single Register ............................................................................. 19
6.7 07 (0x07) Read Exception Status (Serial Line only) ............................................... 20
6.8 08 (0x08) Diagnostics (Serial Line only) ................................................................ 21
6.8.1 Sub-function codes supported by the serial line devices ............................ 22
6.8.2 Example and state diagram ....................................................................... 24
6.9 11 (0x0B) Get Comm Event Counter (Serial Line only) .......................................... 25
6.10 12 (0x0C) Get Comm Event Log (Serial Line only) ................................................. 26
6.11 15 (0x0F) Write Multiple Coils ................................................................................ 29
6.12 16 (0x10) Write Multiple registers .......................................................................... 30
6.13 17 (0x11) Report Server ID (Serial Line only) ........................................................ 31
6.14 20 (0x14) Read File Record ................................................................................... 32
6.15 21 (0x15) Write File Record ................................................................................... 34
6.16 22 (0x16) Mask Write Register .............................................................................. 36
6.17 23 (0x17) Read/Write Multiple registers ................................................................. 38
6.18 24 (0x18) Read FIFO Queue ................................................................................. 40
6.19 43 ( 0x2B) Encapsulated Interface Transport ......................................................... 41
6.20 43 / 13 (0x2B / 0x0D) CANopen General Reference Request and Response
PDU ...................................................................................................................... 42
6.21 43 / 14 (0x2B / 0x0E) Read Device Identification ................................................... 43
7 MODBUS Exception Responses ..................................................................................... 47
Annex A (Informative): MODBUS RESERVED FUNCTION CODES, SUBCODES AND
MEI TYPES .................................................................................................................... 50
Annex B (Informative): CANOPEN GENERAL REFERENCE COMMAND .............................. 50
April 26, 2012
http://www.modbus.org
1/50
MODBUS Application Protocol Specification V1.1b3
Modbus
1
Introduction
1.1
Scope of this document
MODBUS is an application layer messaging protocol, positioned at level 7 of the OSI model,
which provides client/server communication between devices connected on different types of
buses or networks.
The industry’s serial de facto standard since 1979, MOD BUS continues to enable millions of
automation devices to communicate. Today, support for the simple and elegant structure of
MODBUS continues to grow. The Internet community can access MODBUS at a reserved
system port 502 on the TCP/IP stack.
MODBUS is a request/reply protocol and offers services specified by function codes.
MODBUS function codes are elements of MODBUS request/reply PDUs. The objective of this
document is to describe the function codes used within the framework of MODBUS
transactions.
MODBUS is an application layer messaging protocol for client/server communication between
devices connected on different types of buses or networks.
It is currently implemented using:
TCP/IP over Ethernet. See MODBUS Messaging Implementation Guide V1.0a.
Asynchronous serial transmission over a variety of media (wire : EIA/TIA -232-E, EIA-422,
EIA/TIA-485-A; fiber, radio, etc.)
MODBUS PLUS, a high speed token passing network.
Figure 1:
MODBUS communication stack
References
1. RFC 791, Internet Protocol, Sep81 DARPA
2 Abbreviations
ADU Application Data Unit
HDLC High level Data Link Control
HMI Human Machine Interface
IETF
I/O
IP
MAC Media Access Control
MB MODBUS Protocol
Internet Engineering Task Force
Input/Output
Internet Protocol
April 26, 2012
http://www.modbus.org
2/50
TCPModbus on TCPMODBUS APPLICATION LAYERIPEthernetPhysical layerEthernet II /802.3EIA/TIA-232 orEIA/TIA-485Master / SlavePhysical layerMODBUS+ / HDLCOtherOther
MODBUS Application Protocol Specification V1.1b3
Modbus
MBAP MODBUS Application Protocol
PDU Protocol Data Unit
PLC Programmable Logic Controller
TCP Transmission Control Protocol
3 Context
The MODBUS protocol allows an easy communication within all
architectures.
types of network
Figure 2:
Example of MODBUS Network Architecture
Every type of devices (PLC, HMI, Control Panel, Driver, Motion control, I/O Device…) can use
MODBUS protocol to initiate a remote operation.
The same communication can be done as well on serial line as on an Ethernet TCP/IP
networks. Gateways allow a communication between several types of buses or network using
the MODBUS protocol.
4 General description
4.1
Protocol description
The MODBUS protocol defines a simple protoc ol data unit (PDU) independent of the
underlying communication layers. The mapping of MODBUS protocol on specific buses or
network can introduce some additional fields on the application data unit (ADU).
April 26, 2012
http://www.modbus.org
3/50
Figure 3:
General MODBUS frame
Additional addressFunction codeDataError checkADUPDUPLCPLCHMII/OI/OI/ODriveMODBUS ON TCP/IPGatewayGatewayGatewayMODBUS ON MB+MODBUS ON RS232MODBUS ON RS485DeviceHMIPLCPLCDriveI/OI/OI/OI/ODeviceMODBUS COMMUNICATION
MODBUS Application Protocol Specification V1.1b3
Modbus
The MODBUS application data unit is built by the client that initiates a MODBUS transaction.
The function indicates to the server what kind of action to perform. The MODBUS application
protocol establishes the format of a request initiated by a client.
The function code field of a MODBUS data unit is coded in one byte. Valid codes are in the
range of 1 ... 255 decimal (the range 128 – 255 is reserved and used for exception
responses). When a message is sent from a Client to a Server device the function code field
tells the server what kind of action to perform. Function code "0" is not valid.
Sub-function codes are added to some function codes to define multiple actions.
The data field of messages sent from a client to server devices contains additional information
that the server uses to take the action defined by the function code. This can include items
like discrete and register addresses, the quantity of items to be handled, and the count of
actual data bytes in the field.
The data field may be nonexistent (of zero length) in certain kinds of requests, in this case the
server does not require any additional information. The function code alone specifies the
action.
If no error occurs related to the MODBUS function requested in a properly received MODBUS
ADU the data field of a response from a server to a client contains the data requested. If an
error related to the MODBUS function requested occurs, the field contains an exception code
that the server application can use to determine the next action to be taken.
For example a client can read the ON / OFF states of a group of discrete outputs or inputs or
it can read/write the data contents of a group of registers.
When the server responds to the client, it uses the function code field to indicate either a
normal (error-free) response or that some kind of error occurred (called an exception
response). For a normal response, the server simply echoes to the request the original
function code.
Figure 4:
MODBUS transaction (error free)
For an exception response, the server returns a code that is equivalent to the original function
code from the request PDU with its most significant bit set to logic 1.
Figure 5:
MODBUS transaction (exception response)
April 26, 2012
http://www.modbus.org
4/50
Function code Data Request Client Server Initiate request Perform the action Initiate the response Receive the response Function code Data Response ClientServerInitiate requestError detected in the actionInitiate an errorException Function code Receive the responseException codeFunction codeData Request
MODBUS Application Protocol Specification V1.1b3
Modbus
Note: It is desirable to manage a time out in order not to indefinitely wait for an answer which will perhaps
never arrive.
The size of the MODBUS PDU is limited by the size constraint inherited from the first
MODBUS implementation on Serial Line network (max. RS485 ADU = 256 bytes).
Therefore:
MODBUS PDU for serial line communication = 256 - Server address (1 byte) - CRC (2
bytes) = 253 bytes.
Consequently:
RS232 / RS485 ADU = 253 bytes + Server address (1 byte) + CRC (2 bytes) = 256 bytes.
TCP MODBUS ADU = 253 bytes + MBAP (7 bytes) = 260 bytes.
The MODBUS protocol defines three PDUs. They are :
MODBUS Request PDU, mb_req_pdu
MODBUS Response PDU, mb_rsp_pdu
MODBUS Exception Response PDU, mb_excep_rsp_pdu
The mb_req_pdu is defined as:
mb_req_pdu = {function_code, request_data}, where
function_code = [1 byte] MODBUS function code,
request_data = [n bytes] This field is function code dependent and usually
contains information such as variable references,
variable counts, data offsets, sub-function codes etc.
The mb_rsp_pdu is defined as:
mb_rsp_pdu = {function_code, response_data}, where
function_code = [1 byte] MODBUS function code
response_data = [n bytes] This field is function code dependent and usually
contains information such as variable references,
variable counts, data offsets, sub-function codes, etc.
The mb_excep_rsp_pdu is defined as:
mb_excep_rsp_pdu = {exception-function_code, request_data}, where
exception-function_code = [1 byte] MODBUS function code + 0x80
exception_code = [1 byte] MODBUS Exception Code Defined in table
"MODBUS Exception Codes" (see section 7 ).
4.2 Data Encoding
MODBUS uses a ‘big-Endian’ representation for addresses and data items. This means
that when a numerical quantity larger than a single byte is transmitted, the most significant
byte is sent first. So for example
Register size
16 - bits
value
0x1234
the first byte sent is 0x12
then 0x34
Note: For more details, see [1] .
April 26, 2012
http://www.modbus.org
5/50
MODBUS Application Protocol Specification V1.1b3
Modbus
4.3 MODBUS Data model
MODBUS bases its data model on a series of tables that have distinguishing characteristics.
The four primary tables are:
Primary tables
Object type
Discretes Input
Single bit
Type of
access
Read-Only
This type of data can be provided by an I/O system.
Comments
Coils
Single bit
Read-Write
Input Registers
16-bit word
Read-Only
This type of data can be alterable by an application
program.
This type of data can be provided by an I/O system
Holding Registers
16-bit word
Read-Write
This type of data can be alterable by an application
program.
The distinctions between inputs and outputs, and between bit -addressable and word-
addressable data items, do not imply any application behavior. It is perfectly acceptable, and
very common, to regard all four tables as overlaying one another, if this is the most natural
interpretation on the target machine in question.
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.
It’s obvious that all the data handled via MODBUS (bits, registers) must be located in device
application memory. But physical address in memory should not be confused with data
reference. The only requirement is to link data reference with physical address.
MODBUS logical reference numbers, which are used in MODBUS funct ions, are unsigned
integer indices starting at zero.
The examples below show two ways of organizing the data in device. There are different
organizations possible, but not all are described in this document. Each de vice can have its
own organization of the data according to its application
Example 1 : Device having 4 separate blocks
The example below shows data organization in a device having digital and analog, inputs and
outputs. Each block is separate because dat a from different blocks have no correlation. Each
block is thus accessible with different MODBUS functions.
Implementation examples of MODBUS model
Figure 6
MODBUS Data Model with separate block
April 26, 2012
http://www.modbus.org
6/50
Input DiscreteMODBUS accessDevice application memoryMODBUS SERVER DEVICEMODBUS RequestCoilsInput RegistersHoldingRegisters
MODBUS Application Protocol Specification V1.1b3
Modbus
Example 2: Device having only 1 block
In this example, the device has only 1 data block. The same data can be reached via several
MODBUS functions, either via a 16 bit access or via an access bit.
Figure 7
MODBUS Data Model with only 1 block
4.4 MODBUS Addressing model
The MODBUS application protocol defines precisely PDU addressing rules.
In a MODBUS PDU each data is addressed from 0 to 65535.
It also defines clearly a MODBUS data model composed of 4 blocks that comprises several
elements numbered from 1 to n.
In the MODBUS data Model each element within a data block is numbered from 1 to n.
Afterwards the MODBUS data model has to be bound to the device application ( IEC -61131
object, or other application model).
The pre-mapping between the MODBUS data model and the device application is totally
vendor device specific.
April 26, 2012
http://www.modbus.org
7/50
Device application memoryMODBUS SERVER DEVICEMODBUS RequestInput DiscreteMODBUS accessCoilsInput RegistersHoldingRegistersRWRW
MODBUS Application Protocol Specification V1.1b3
Modbus
Figure 8
MODBUS Addressing model
The previous figure shows that a MODBUS data numbered X is addressed in the MODBUS
PDU X-1.
4.5 Define MODBUS Transaction
The following state diagram describes the generic processing of a MODBUS transaction in
server side.
April 26, 2012
http://www.modbus.org
8/50
Discrete InputCoilsInput RegistersHolding RegistersMODBUS data modelDevice application1...1.5.12. MODBUS PDU addresses1..55Read Registers 54Read Registers 1Read coils 4Read input 0MODBUS StandardApplication specificMapping