How does Modbus Communication Protocol work?In this video and article, you are going to learn about how Modbus communication protocol works between devices.
In the previous video, you learned about what Modbus communication protocol is and the types of Modbus communication used in the industry. Now, as promised, in this video you are going to learn about How Modbus communication protocol works between devices.
1. Modbus Protocol Message Structure
Each Modbus message has the same structure. Four basic elements are present in each message. The sequence and order of these elements are the same for all messages. This allows for easy parsing of the content of the Modbus message.
A conversation is always started by a master in the Modbus network. A Modbus master sends a message, and depending on the contents of the message, the slave interprets the message and responds to it.
Physical slave addressing in the message header is used to define which slave device should respond to a message. All other nodes on the Modbus network ignore the message if the address field doesn’t match their own address.
Modbus functions perform read and write instructions to the slave’s internal memory registers to configure, monitor, and control the slave’s inputs and outputs.
1.1. Modbus Protocol Devices
Modbus protocol devices will typically include a register map outlining where the configuration, input and output data can be written and read from. You should always refer to the slave’s register map of your device to gain a better understanding of its overall operation.
The Modbus data model has a simple structure described in four basic data types:
1. Discrete Inputs
2. Coils Outputs
3. Input Registers (Input Data)
4. Holding Registers (Output Data)
1.2. Modbus Protocol Data Unit (PDU)
The service request area of the message or Modbus Protocol Data Unit or PDU is comprised of
– Function code.
– A number of “data” bytes requested by the master.
The Modbus memory registers of a device are organized around the four basic data reference types and this data type is further identified by the leading number used in the devices memory address, such as:
– Zero (0) based register referencing a message to Read or Write “discrete outputs or coils”.
– One (1) based register referencing Reading “discrete inputs”.
– Three (3) based register referencing Reading “input registers”.
– Four (4) based register referencing Reading or Writing to “output or holding registers”.
1.2.1. Modbus Message “Function Code Field”
The “function code field” specifies which register data group it reads or writes to and from the slave.
For example, a Function code 03, read Holding Registers 40001-40002 is addressed as data register 0000 in the data address field of the message sent to the slave.
The function code 03 works on Holding Register type (4xxxx) in the slave’s data map because the request specifies using a holding register data type operation and the 4xxxx addressing in the request is implied.
The fields in the PDU are broken down into bytes and grouped by the field name.
The request message contains:
– The “Slave address” of 01.
– The “Function code” of 03 (Read from Holding Registers 4xxxx).
– The “starting address” HI and LO bytes (0000) which specifies the “starting register”.
– The “count number of addresses” to read from the slave, register HI and LO bytes of the count value (0002) which specifies the “quantity of registers” to be read from the slave.
Example of a request to “read” the “first two registers” in the “Holding Register” area 0 to 1 (register 40001 to 40002) from slave device 1 is shown below.
It is revealed in the above picture that the holding register 40108 is actually addressed as register 107 in the message data area of the PDU.
Many of the data types are named from its use; for example, a single-bit physical output is called a coil, and a single-bit physical input is called a discrete input or a contact.
The function code field of the message will contain one byte that tells the slave what kind of action to take.
Valid function codes are range from 1 to 255, but not all codes will apply to a particular slave.
The table shown in the below picture highlights a subset of standard Modbus protocol functions.
1.2.2. Modbus Message “Data” Field
In addition, the master request “data” field, provides the slave with any additional information required by the slave to complete the action specified by the “function code” in the master’s request.
The master’s request typically includes:
– The slave map register address.
– The number of registers to provide in the request.
– Any write data from the master.
2. Modbus Message Error Handling
The slave’s normal response simply echoes the original function code of the request, but the slave’s error response returns a code that is equivalent to the original function code with the most significant bit set to logic 1.
For example, the “Read Holding Registers” command (Function Code 03) has the function code with 1 byte containing 8 bits is binary 0000 0011 (03 Hex). If the slave device accepts the request without error it will return the same code in its response.
However, if an error occurs, the slave will return 1 byte containing 8 binary bits 1000 0011 (the most significant bit set to logic 1) in the “function code” field and appends a unique code (Exception Code) in the “data” field of the response message that tells the master device what kind of error occurred, or the reason for the error.
3. Modbus RTU Most Common Function Codes
This function code 01, “Read
The function code 02, “Read Discrete Input” code, is used to read from 1 to 2000 contiguous status of discrete outputs in a remote slave. The Request PDU specifies the first input address of the slave’s memory registers, and the number of inputs to read from the slave device.
The function code 03, “Read Holding Registers” code, is used to read the contents of a contiguous block of holding registers in a remote slave. The Request PDU specifies the starting register address and the number of registers to read from the slave device.
The function code 04, “Read Input Registers” code, is used to read from 1 to 125 contiguous input registers in a remote device. The Request PDU specifies the starting register address and the number of registers.
The function code 05, “Write Single Coil” code, is used to write a single output to either ON or OFF in a remote slave device.
The function code 06, “Write Single Register” code, is used to write a single holding register in a remote slave device. The Request PDU specifies the address of the slave memory register address to be written to.
The function code 15, “Write Multiple Coils” code, is used to force each coil in a sequence of coils to either ON or OFF in a remote slave device. The Request PDU specifies the coils memory address to be forced ON or OFF.
And the function code 16, “Write Multiple Registers” is used to write a block of contiguous registers from 1 to 123 registers in a remote slave device.
While these Modbus function codes represent the most common read and write functions, it would be helpful for you to review the Modbus protocol specification for additional information.
And for more information about different protocols used with automation, refer to this web page.
4. Modbus Protocol Simulator Software
Communication with slave devices or master PLCs or computers can be accomplished with Modbus simulator software to run on your personal computer.
The connection can be either serial or Ethernet and in the form of a master or slave. The software will allow you to perform all of the Modbus Protocol Communication function code to simply read or write to an existing slave.
You can set up one computer to run the slave simulation software and another to run the Master simulation software.
Connecting to a slave is first performed by setting the communication parameters for your serial COM port.
Then by entering the slave’s address in the Device ID field, for
In addition, there are several companies providing products and support to help you with protocol communication. ProSoft Technologies, HMS Industrial Communication, and MOXA are to name just a few.
This concludes the article, How Modbus communication protocol works. I hope you have learned what’s required to move forward in creating your own motion control project.
Thanks again for reading. Leave your questions and comments and we’ll chat with you soon!
The RealPars Team
By Wally Gastreich
Posted on Des 17, 2018
By Wally Gastreich
Posted on Dec 17, 2018
5 ACTIONABLE TIPS FOR GETTING A PLC PROGRAMMING JOB WITH NO EXPERIENCE The mindset that helped me find my ideal job as a PLC programmer with NO experience. Working as a PLC Programmer is one of the most attractive and highest paying jobs in the engineering industry....
In previous articles, we have talked about variable frequency drives (VFD) and soft starters. If you need a refresher on the detailed working of either a VFD or Soft Starter be sure to look back at those articles by clicking the links below. What is a VFD? What is a...
In this video and article, we are going to do a deep dive into the DCS and discuss some of the why’s and how’s associated with the DCS. Let’s first clarify for the purpose of this lesson, what we mean by DCS. Over the years, the term DCS has evolved from the original...
RealPars is the world's largest online learning platform for automation engineers.
+31 10 316 6400
Mon - Fri 8:30 am to 5:30 pm (CET)
Rotterdam Science Tower, Marconistraat 16,
3029 AK Rotterdam, The Netherlands
© 2019 RealPras B.V. All rights reserved.
This project is approved and supported by The Netherlands Enterprise Agency