Introduction to Modbus

Publish Date: Nov 21, 2012 | 57 Ratings | 3.89 out of 5 |  PDF


Modbus is an application-layer protocol based on a master/slave or request/reply architecture. It was published by Modicon in 1979 and is primarily used in industrial applications. The following tutorial outlines the high level functionality of the Modbus application layer with emphasis on the specifications for a serial implementation and TCP/IP specification.

For more details, please see the complete MODBUS specifications on

Table of Contents

Modbus Protocol


The Modbus protocol follows a master/slave architecture where a master will request data from the slave. The master can also ask the slave to perform some action. The master initiates a process by sending a function code that represents the type of transaction to perform. The transaction performed by the Modbus protocol defines the process a controller uses to request access to another device, how it will respond to requests from other devices, and how errors will be detected and reported. The Modbus protocol establishes a common format for the layout and contents of message fields.

During communications on a Modbus network, the protocol determines how each controller will know its device address, recognize a message addressed to it, determine the kind of action to be taken, and extract any data or other information contained in the message.

Controllers communicate using a master/slave technique where only one device, the master, can initiate transactions or queries. The other devices, slaves, respond by supplying the requested data to the master or by taking the action requested in the query. Typical master devices include host processors and programming panels. Typical slaves include programmable controllers.



Figure 1: Basic Modbus Network1

Figure 2: Basic Modbus Transaction1 

The messages exchanged between the master and the slave are called frames. There are two types of Modbus frames: Protocol Data Unit (PDU) and Application Data Unit (ADU). The PDU frames contain a function code followed by data. The function code represents the action to perform and the data represents the information to be used for this action. ADU frames add a little more complexity with an additional address part. ADU frames also provide some error checking. Both the ADU and PDU frames follow Big-Endian encoding.


Figure 3: Modbus Frame1 

Modbus transactions always perform a set of actions by reading or writing to a set of four data types. Table 1 describes the four data formats used by the Modbus application layer.


Primary Tables Object Type Type of
Discrete Input Single bit Read-Only
Coils Single bit Read-Write
Input Registers 16-bit word Read-Only
Holding Registers 16-bit word Read-Write

Table 1: Modbus Data Types1 

The Discrete Inputs represent a single bit (Boolean) which can only be read.  In other words, the master can only perform a read action on the discrete inputs.  The same holds for the Input Registers.  The master can only read the slave’s Input Registers.  The difference between the Discrete Inputs and the Input Registers is that the Input Registers represent 16 bits while the Discrete Inputs are only a single bit.  The Coils also represent a Boolean data type which can be read and written to by the master.  The Holding Registers represent a 16 bit word that can be read and written to.


Figure 5: Modbus Transaction with Data Types1 

The Complete Modbus Transaction

As mentioned before, the type of action that the slave performs is defined by a function code.  For example, if the master wants to read a certain Discrete Input, it will send a function code of 0x02 followed by the address of the desired Discrete Input.  The slave will read the 0x02 and will know that the master wants a Discrete Input.  The slave will retrieve the Discrete Input from the given address and reply back to the master.  


Figure 6: Complete Modbus Transaction1

More Function Codes

There are three main types of function codes: Public, User Defined, and Reserved.  Since the public function codes are validated, publicly documented, and have available conformance tests by the community, most Modbus devices implement them.  Each of the public function codes are associated with a well defined function.  A brief overview of the public function codes is presented in Table 2.  More information on public function codes can be found at



Function Codes



Sub Code






Bit Access

Physical Discrete Inputs

Read Discrete Inputs





Internal Bits or Physical Coils

Read Coils





Write Single Coil





Write Multiple Coils





16 bits


Physical Input Registers

Read Input Register





Internal Registers Or Physical Output Registers

Read Holding Registers





Write Single Register





Write Multiple Registers





Read/Write Multiple Registers





Write Mask Register





Read FIFO Queue





File Record Access

Read File Record





Write File Record






Read Exception Status










Get Com Event Counter





Get Com Event Log





Report Slave ID





Read Device Identification






Encapsulated Interface Transport





Table 2: Public Function Codes1


In the previous example, we used function code 0x02 to read the Discrete Inputs.  We can look at this function code in more detail, since it is a public function code.


Function Code 1 Byte 0x02
Starting Address 2 Bytes 0x0000 to 0xFFFF
Quantity of Inputs 2 Bytes 1 to 2000 (0x7D0)


Function Code 1 Byte 0x02
Byte Count 1 Byte N*
Input Status N* x 1 Byte  

*N=Quantity of Inputs / 8 if the remainder is different of 0 ۠N = N+1


Error Code 1 Byte 0x82

Table 3: Detailed Function Code Example1 


As seen in Table 3, the function code must be followed by 2 bytes for the starting address and 2 bytes for the number of inputs the master requires.   The slave must respond with the function code, followed by the 1 byte representing the number of bytes sent and then the Discrete Input values.  The complete transaction is shown in Figure 6. 


In contrast, the user defined codes are unique for each Modbus device.  They are usually tied with a special set of functions which are only available for the specific device. These will be detailed in the device manufacturer’s manual.  

Hardware Implementations

Serial Implementation

There are two serial modes that the Modbus application layer can follow: RTU and ASCII.  In RTU, the data is represented in Binary format, whereas the ASCII mode represents the data such that it is human readable.  Figure 7 and 8 demonstrate the difference between these two modes.



Figure 7: Modbus RTU Serial Frame1 


Figure 8: Modbus ASCII Serial Frame1 

The most common serial protocols used with Modbus are RS-232 and RS-485.  For more details on these protocols, please see this link.

TCP Implementation

As in many TCP applications, the first requirement is to establish a connection between the master and the slave.  When connection has been established, the master can build a request for the slave.  The request contains a PDU (Modbus frame described above) followed by a MPAB header, as shown in Figure 9.  Figure 10 represents a template for the MPAB header.      


Figure 9: Modbus TCP Frame1 

  Description Size Example
MBAP Header Transaction Identifier Hi 1 0x15
Transaction Identifier Lo 1 0x01
Protocol Identifier 2 0x0000
Length 2 0x0006
Unit Identifier 1 0xFF

Figure 10: MBAP Header1 

The Transaction Identifier can be like a “TCP Sequence Number” used to keep track of which Modbus transaction the packet is associated with.  This is important because, in Modbus TCP, the slave can handle many requests at the same time.  This is not possible in Modbus Serial.

The Unit Identifier is typically used to address the Modbus slave.  When using Modbus TCP, the address of the slave is its IP address and the Unit Identifier in the MBAP header is not used.  Figure 11 demonstrates a complete Modbus TCP transaction.



Figure 11: Complete Modbus TCP Transaction1

Using LabVIEW With Modbus

Modbus I/O Servers

The LabVIEW Datalogging and Supervisory Control (DSC) Module is the preferred way to have LabVIEW communicate with a Modbus device. The DSC module uses I/O Servers to handle all protocol between a master and slave. The I/O servers are used in the Shared Variable Engine(SVE) and allow the SVE to become both a Modbus master and slave. Modbus I/O servers are also included in the Real-Time module, so CompactRIOs can be used to communicate with other Modbus devices.

Modbus Master I/O Servers

The SVE can create Modbus Master I/O Servers to communicate with Modbus Slaves. A typical application is to have a computer running a LabVIEW application and the SVE be configured as a Modbus Master that then communicates with PLC that is configured as a Modbus Slave. Figure 12 shows how the I/O Servers and the SVE work together to allow LabVIEW access to Modbus coils and registers on a PLC.

Figure 12: LabVIEW and Modbus Network

The SVE uses the Modbus Master I/O server to communicate with the PLC using the Modbus Standard through either serial or Ethernet. The I/O Server handles low level communication protocol to provide faster development times. The SVE uses NI Publish-Subscribe Protocol (NI-PSP) to provide a PSP URL for each Modbus address. With a PSP URL, Shared Variables can be bound to the Modbus addresses by enabling aliasing. Once the Shared Variables are deployed to the SVE and communicating with Modbus addresses, then LabVIEW can easily read and write to the Shared Variables like in Figure 13.

Figure 13: Reading from Bound Shared Variables in LabVIEW

When the Shared Variable Engine binds the Shared Variables to Modbus addresses, reading and writing is simplified to directly reading from and writing to the Shared Variables on the block diagram. No extra code is required to initialize and close the connections. The bound Shared Variables can be published to the network, so any computer with LabVIEW can read from and write to the bound Shared Variables. For more specific steps on how to set up a Modbus I/O Server for the Shared Variable Engine see the Developer Zone: Connect to any PLC using Modbus.

Modbus Slave I/O Servers

The SVE can use Modbus Slave I/O Servers to allow for communication with Modbus Master devices. When designing an application that will run a LabVIEW application on a normal desktop computer, it is not typical to use Modbus Slave I/O Servers. A more common application is to have Real-Time targets such as the CompactRIO configured as slaves with Modbus Slave I/O Servers set up on a CompactRIO’s SVE, as seen in Figure 14.

Figure 14: Using Modbus Slave I/O Servers with a CompactRIO

CompactRIO targets can be deployed remotely in place of PLCs and allow for integration into Modbus applications. The SVE and Modbus I/O servers support must be installed on the CompactRIO Real-Time controller. LabVIEW Real-Time can be used to access the physical I/O from the C Series modules then write values to Shared Variables. The Shared Variables are then bound to Modbus addresses using NI-PSP and Modbus Slave I/O Servers. LabVIEW Real-Time interacts with Modbus addresses through Shared Variables in the same way as used in Figure 16. This way many CompactRIO targets can be deployed as Modbus Slaves that all communicate with a single Modbus master over serial or Ethernet.

NI Modbus Library

You can download free Modbus libraries for LabVIEW.  It is recommended by NI to use Modbus I/O Servers provided in the LabVIEW Datalogging and Supervisory Control (DSC) Module or Real-Time Module. The modules provide easy to use Shared Variables for both Modbus TCP and serial. If you do decide to use the NI Modbus library a great point to start for your application is to look at the examples supplied with the libraries.  There are examples for master and slaves for both the serial and TCP implementation of the Modbus protocol. 


Figure 15: Modbus Library Examples


Please note that the main resource used for this document comes from the Modbus Organization located at     

Related Links


Back to Top

Bookmark & Share


Rate this document

Answered Your Question?
Yes No