In the last lesson we saw an example of a Modbus master (PLC A) reading two pieces of data from a Modbus slave (PLC B). This took place using the “Read Input Registers” command. We had a very close look at what the byte streams would be for both the Query and Response parts of the cycle. Specifically, the byte streams were as follows:
Response : [W][Z]
In this lesson, I want to you about two topics as follows:
1. The numbering systems that are most frequently used by Modbus Testing applications to represent the Query and Response byte streams.
2. How to interpret 16-bit data values sent in the Eight-Bit Data Bytes section of the Query and Response byte streams.
So let’s get into it.
1. Numbering system used in Modbus
A byte consists of 8 bits. But in the Query and Response byte streams above, you would notice that I represent the bytes using decimal numbers. For example, the Device Address is . But really, to a Modbus device it looks like binary i.e. 00000101. I use decimal simply because it saves a heck of a lot space and decimal is what most people are accustomed to using.
However, in much of the Modbus documentation that exists on the Internet, the representation of the bytes in a byte stream is not in decimal form, but rather in hexadecimal form. Hexadecimal is useful in representing the byte streams due to the ease of transformation into binary and back again.
Let me illustrate this using an example. The Device Address in binary is 00000101. The first 4 bits are 0000 and the last 4 bits are 0101. To convert this to hexadecimal, I would convert the first 4 bits to hexadecimal separately and do the same with the last 4 bits and then just put together. So, using this method:
0000 in binary = 0 in hex
0101 in binary = 5 in hex
So the Device Address in hexadecimal would be . Not too bad right? Looks pretty much the same. But things start to differ as the byte stream values increase in size.
For instance, look at the Eight-Bit Data Bytes section for the Response. It is  in decimal. But in hexadecimal it would look like [2E].
Now I know that hexadecimal looks like a pain in the butt, but you need to know it for the following really good reasons:
(a) It is heavily used in the Modbus documentation of Modbus compliant devices. And you need to understand this type of documentation to create and troubleshoot Modbus networks.
(b) It is heavily used in Modbus software diagnostic tools to display byte streams to the user. If you can’t interpret what the software shows you then you can’t solve Modbus network problems.
2. Interpretation of 16-bit Modbus values
In the Response byte stream above, the value of the pressure returned by the Modbus slave is , which is really the 46 psi reading from the pressure sensor. But what if the pressure was 500 psi, what would these two bytes look like then. Well they would look like .
How the heck did I get that? Well it’s time to jog your math memory a bit.
Let’s look at what decimal really is. Take for instance the number 35. We take it for granted, but to what a computer would do to calculate the absolute value of 35 is do this (3 X 10) + 5 = 35. The 3 is not really a 3 but (3 X 10).
But when you are using bytes, each byte is 8 bits. And 8 bits can only count up to 11111111 which is 256 in decimal. So if we have the , to get the absolute value, what we do is (1 X 256) + 244 = 500. Isn’t 500 psi our pressure value?
Don’t worry, we will do more examples like this and you will get used to how Modbus expresses these 16-bit data values. Finally, for completeness sake, how our 500 psi value would look if we were to express it in hexadecimal would be [F4].
In the example here with the 500 psi, I want you to understand that the absolute value remains the same. We are just looking at it from the perspective of binary, decimal and hexadecimal.