So off we go!
In Section 5 of the “Mastering Modbus RS485 Network Communication” course, we looked at the messaging method that a Modbus master would use to communicate with a Modbus slave. Specifically in Lecture 16, we looked at 6 commands that are used most frequently in this type of Modbus communication. To refresh your memory, I will list the commands here again as follows:
– Read Coil Status
– Read Input Status
– Read Input Registers
– Read Holding Registers
– Force Single Coil
– Present Single Register
To become very proficient in solving Modbus communication issues, you will have to understand the inner workings of each of these commands. So let’s see what these commands are really about.
What exactly happens when a Modbus master device executes any command? Well two things really. They are:
1. The Modbus master sends a request to the Modbus slave. This transaction is known as the Query.
2. The Modbus slave will then send a response back to the Modbus master. This transaction is known as the Response.
The great thing about the Modbus protocol is that every single communication transaction follows the two steps above. Together, these two steps are known as the Query/Response cycle. If you forget everything else in this post, don’t forget this concept of the Query/Response cycle. It is the foundation on which ALL Modbus transactions are built.
So we know that a master will send a Query to a slave and that a slave will send back a Response to the master. But what exactly is a Query and what exactly is a Response? Well both a Query and a Response are simply data, in the form of bytes, that is sent across the Modbus network. For purposes of this discussion, we will call data sent across a Modbus network a “byte stream”, regardless of whether it is a Query or a Response.
Let’s have a look at the guts of a typical Query/Response cycle using the diagram below.
– Device Address
– Function Code
– Eight-Bit Data Bytes
– Error Check
Let’s look more deeply at these four sections, first from the standpoint of the Query part of the Query/Response cycle.
In the Query cycle of the transaction, the master device is sending a command to a particular slave device. It therefore must have some way of telling that slave device that the command is for it and no other slave device. It does this by placing the address of the slave device in the “Device Address” section of the byte stream. The address of a slave device is the Unit ID of that device. We learned about Unit ID in the course. The Unit ID is simply a number which uniquely identifies a slave. The “Device Address” part of the byte stream is just one byte long.
The master must also tell the slave what it would like it to do, or rather what function it would like it to perform. Each of the 6 commands mentioned previously is represented by it’s own unique code, which is a number. Hence the master must place the appropriate code of the command in the “Function Code” section of the byte stream it is sending to the slave. This is the only way that the slave will know what to do. The “Function Code” section of the byte stream is just one byte long, just like the “Device Address” section.
The “Eight-Bit Data Bytes” section in a Query is used by the master to specify a data block address range that the slave is to consider when it is performing it’s function. This section expresses the data block address range by specifying the start address and number of data blocks. Remember from the course we saw that, in Modbus, a master specifies a data block address range by specifying the start address and the number of data blocks that follow from that start address. In a subsequent email, we will look at the “Eight-Bit Data Bytes” section in much more detail to see how exactly the bytes are arranged to specify the data block address range. The “Eight-Bit Data Bytes” section is typically 4 bytes in length.
Finally we are at the “Error Check” section of the Query byte stream. Every communications medium that Modbus uses will have some form of disturbance. It may be electrical disturbance, or physical disturbance or other. Disturbances to a communications medium can cause data errors to occur when a byte stream is being transferred from master to slave and back again. The “Error Check” section of the byte stream is used to detect and deal with these possible disturbances to ensure reliable master-slave communication. We will delve into the “Error Check” section in a subsequent email, but for now know that it is 2 bytes in length and is called a Cyclical Redundancy Check or CRC.
Now let’s take a look at the four sections from the standpoint of the Response part of the Query/Response cycle.
In the Response part of the cycle, the byte stream is also composed of the four sections we dealt with in the Query part above. In the case of the Response, the slave sends back the “Device Address” and “Function Code” it would have originally received in the Query byte stream it received from the master. So we say that the “Device Address” and “Function Code” are reflected.
The “Eight-Bit Data Bytes” section for the Response varies significantly from that in the Query. In the Query, this section of the byte stream specifies the data block address range that the slave considers when it is performing it’s function. In the case of the Response, however, the “Eight-Bit Data Bytes” section contains the data values that are stored in the data block that was originally addressed in the Query byte stream. In this way, the slave is able to return the data values that the master requested in the first place. We will look at this in much more detail in a subsequent email lesson.
The “Error Check” serves the same purpose in the response byte stream as it does in the query stream.