Each communications transaction is initiated by the Modbus master, with a message known as a Query. To any specifically addressed query, the master expects a Response back from the slave. A slave never initiates a transaction (sends an unsolicited message). This query-response cycle is the basis for all communications on a Modbus network. It is always the master that initiates the query, and the slave that responds.
A “broadcast” message can also be sent by the Modbus master. In this one case, the master does not require a response from any slave. A slave identifies a received broadcast message by the target address of “device 0”. See the following subsections for more details:
Each Modbus message has a defined structure, referencing device address, function code, and the data address (or requested data). Message structures in a serial (async) network are as follows:
The master-generated query message contains, in order:
-
A device address of target slave (or “broadcast address”, for all slaves), as first byte.
-
A function code defining the requested action, as second byte.
-
A data field describing particulars for the function code. This may be a register address (and a range) to read, or a coil address to write, for example.
-
An error-check field to confirm integrity of the message, as it will be received from the master. If the slave detects an error in a query, it is ignored. The slave then waits for the next query addressed to it.
The slave-generated response message contains, in order:
-
Its device address, confirming to the master that it is replying to the query, as first byte.
-
The function code, as second byte—normally an exact copy, unless the slave is unable to perform the requested function. In this case, the function code returned is a modified form, indicating that the slave was unable to perform. See Exception responses for more details.
-
The data, containing the data requested in the query.
-
An error-check field to confirm integrity of the message, as it will be received from the slave. If the master detects an error in the response, it is ignored.
The error-checking method depends on the Modbus transmission mode—in Modbus RTU (the most prevalent), a CRC (cyclical redundancy checksum) method is used.[3]
The following is an example query and response message pair from a ModbusAsyncNetwork to a Modbus RTU (serial) device:
-
Query
020300030004B43AFor device
02, function code03, starting address0003, number of registers04, error checksumB43A -
Response
02030800510052003C003CA387From device
02, function code03, number bytes returned08, data (00510052003C003C), error checksumA387
By enabling “Trace” logging on a Modbus network, you can see this query/response message cycle in the station’s Standard Output, for example resulting from normal data polling. The sent query is “broken out” to show fields on separate lines, and the received (response) is shown in a single line (in hex format).
Note that in the case of the ModbusTCPNetwork, trace-level output shows a similar query/response message cycle from data polling,
but with a slightly different format. There, a 6-byte leading TCP header “000000000006” is seen in sent queries, and the checksum byte is omitted in both sent and response messages.
[3] The Modbus TCP protocol has a similar message format for query and response messages. However, Modbus TCP is freed from error check routines. Instead, the error-checking mechanisms built into the lower-level TCP/IP and link layers (that is, Ethernet) are used.