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