Introduction to Modbus

Publish Date: Nov 21, 2012

Overview
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 www.modbus.org

Table of Contents
Modbus Protocol
Introduction 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.

1/7

www.ni.com

Primary Tables Discrete Input Coils Input Registers Holding Registers

Object Type Single bit Single bit 16-bit word 16-bit word Table 1: Modbus Data Types1

Type of Read-Only Read-Write Read-Only Read-Write

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 slaves 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 Types 1 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

2/7

www.ni.com

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 modbus-ida.org 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 www.modbus.org.

Function Codes Code Sub Code (hex) Section

Physical Discrete Inputs Bit Access

Read Discrete Inputs

02

02

6.2

Read Coils Internal Bits or Physical Coils Write Single Coil Write Multiple Coils Read Input Register

01 05 15

01 05 0F

6.1 6.5 6.11

Physical Input Registers

04

04

6.4

Read Holding Registers Data Access 16 bits access Internal Registers Or Physical Output Registers Write Single Register Write Multiple Registers Read/Write Multiple Registers Write Mask Register Read FIFO Queue Read File Record File Record Access Write File Record Read Exception Status Diagnostic Get Com Event Counter Diagnostics Get Com Event Log Report Slave ID Read Device Identification Encapsulated Interface Transport

03

03

6.3

06

06

6.6

16

10

6.12

23

17

6.17

22

16

6.16

24

18

6.18

20

14

6.14

21

15

6.15

07 08 11 00-18,20

07 08 0B

6.7 6.8 6.9

12 17 43 14

0C 11 2B

6.10 6.13 6.21

43

13,14

2B

6.19

Other

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.

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

3/7

www.ni.com

Response Function Code Byte Count Input Status 1 Byte 1 Byte N* x 1 Byte *N=Quantity of Inputs / 8 if the remainder is different of 0 N = N+1 0x02 N*

Error 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 manufacturers 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 MBAP Header Transaction Identifier Hi Transaction Identifier Lo Size 1 1 Example 0x15 0x01

4/7

www.ni.com

Protocol Identifier Length Unit Identifier Figure 10: MBAP Header

1

2 2 1

0x0000 0x0006 0xFF

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

5/7

www.ni.com

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 CompactRIOs 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.

6/7

www.ni.com

Figure 15: Modbus Library Examples

1

Resources

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

Related Links
NI Developer Zone: How LabVIEW Uses I/O Servers NI Developer Zone: How to Connect Any PLC to LabVIEW Using Modbus

7/7

www.ni.com