1) Structure
All bytes from Modbus RTU/TCP protocol are in hexadecimal format, except if the driver has been set up to communicate with Modbus ASCII protocol.
In case of (TX) commands for reading via Modbus protocol’s “03” Function, the byte structure is the following:
Modbus RTU command (with CRC):
Modbus TCP command (without CRC):
These are the bytes to be interpreted:
SS Corresponds to Slave ID byte, that is, the device’s address on the network (N1/B1 parameter)
03 “03” byte indicates Modbus’ write “03 Function”
MM MM This 2-byte set represents the initial memory address (N4/B4 parameter)
QQ QQ Refers to the amount of records to be read from the initial memory address
In case of (RX) responses for Modbus protocol’s “03” Function, the byte structure is the following:
Modbus RTU response (with CRC):
Modbus TCP response (without CRC):
These are the bytes to be interpreted:
SS Corresponds to Slave ID byte, that is, the device’s address on the network (N1/B1 parameter)
03 “03” byte indicates Modbus’ write “03 Function”
CC Counter indicating the amount of bytes from all received values
DD DD 16-bit value (2 bytes) returned by the device
To identify correctly the value received via bytes, you must know the amount of records requested by TX command. Example:
1. One single record: the value must be within the last 2 bytes of the RX (DD DD) before CRC, when it exists.
2. Two records: the values must be within the last 4 bytes of the RX (DD1 DD1 DD2 DD2) before CRC, when they exist.
3. Three records: the values must be within the last 6 bytes of the RX (DD1 DD1 DD2 DD2 DD3 DD3) before CRC, when they exist.
4. And so on and so forth, where each of the device’s memory record will return a 16-bit value (2 bytes).
2) Read example for a PLC Tag:
Modbus RTU (with CRC):
Modbus TCP (without CRC):
With the example above, we can analyze the bytes and check both the parameters inserted into each tag’s settings and the value returned by the driver.
From “TX”, you will notice that:
1. The device’s ID (address) on the network is 1.
2. It is using Modbus’ “03” read function.
3. The 2 bytes of the initial memory address correspond to “00 66” values. Since these values are hexadecimal, just convert them to obtain the Modbus memory address, which in this case is 102 (equal to 0066h).
4. The amount of required records is 1.
Modbus RTU (with CRC):
Modbus TCP (without CRC):
Based on the information from TX, we can identify the value received by the driver via RX response:
Modbus RTU (with CRC):
Modbus TCP (without CRC):
The last 2 bytes (due to the amount of requested records) correspond to “1BD0” values (memory 0066h).
When converting hexadecimals to decimals, we get 7120 for the PLC tag.
3) Read example for a 2-element Block Tag:
Modbus RTU (with CRC):
Modbus TCP (without CRC):
From “TX”, you will notice that:
1. The device’s ID (address) on the network is 1.
2. It is using Modbus’ “03” read function.
3. The 2 bytes of the initial memory address correspond to “00 66” values. Since these values are hexadecimal, just convert them to obtain the Modbus memory address, which in this case is 102 (equal to 0066h).
4. The amount of required records is 2 (one for each element in the Block Tag).
Modbus RTU (with CRC):
Modbus TCP (without CRC):
Based on the information from TX, we can identify the value received by the driver via RX response:
Modbus RTU (with CRC):
Modbus TCP (without CRC):
The last 4 bytes (due to the amount of requested records) correspond to values “1BD0” (memory 0066h) and “1AC6” (memory 0067h).
When converting hexadecimals to decimals, we get 7120 (blockTag.Element1) and 6854 (blockTag.Element2).
