Download the PDF of the entire series of articles on Modbus

The second and last level of the Modbus protocol, known as the “Application layer”, deals with the Protocol Data Unit (PDU), that is, the useful part of the information contained in the frames exchanged between the Master and the Slave. In fact, in the previous layer (Data Link layer), only the parts of the protocol relating to the transmission of PDUs are defined without considering their significance.

The PDU contains all the information necessary for the Master to perform operations on a Slave, such as writing or reading a parameter.
For this reason, the bytes of a PDU are subdivided into the first field (1 byte length) defining the particular operation to be performed (function code) and a possible second Data field specific of the command to execute:

The function field contains a default value for each implemented command. The Modbus protocol provides that only values from 1 to 127 are used to encode the command, leaving values from 128 to 255 for encoding the same command (but with the highest bit to 1) in order to report, in the Slave response, an “exception” that is an error detected during its execution.
The Modbus protocol divides the set of numeric codes into two groups. The codes included in the 1÷64, 73÷99 and 111÷127 fields are used for “public” functions, ie officially documented and therefore unique for the protocol. The remaining codes in the fields 65÷72 and 100÷110 are free for the implementation of custom protocol functions.

The meaning and length of the Data field depend on the specific command and this part may also not be present. The maximum Data field length is 252 bytes because the total sum of bytes of a frame, according to the specification, is 256 bytes.
The protocol manages 16bit-word values using the “big-Endian” notation, which requires that the most significant byte of the word be first transmitted. Note that this is not the case for sending the CRC that is transmitted with the least significant byte first

The standard commands of the Modbus protocol, used for reading and writing the Slave resource values, refer to the concept of “Object” instead of the real memory address of the device. This allows the protocol to be free from the effective physical locations of the resources within the Slave’s internal memory.
For this reason, each device must define the objects that are accessible to the protocol by assigning it to a Modbus address and consequently have to deal with objects association with the effective internal variables in own memory.

The objects are grouped into 4 different typologies with a clear reference to the type of resources that the devices offered during the period in which the protocol had been defined:

“Discrete Inputs” resources refer to digital input (ON/OFF) values while the “Coils” resources to digital output values and therefore are writable but at the same time readable. “Input Registers” and “Holding Registers” resources are analogue versions (continuous values in range 0-65535) of the previous and used for analog inputs/outputs or any other numeric value of the device such as a work parameter.

These objects are associated with both the identification numbers and the specific addresses in order to access these resources through the protocol PDUs. Remember that the address of the resource does not necessarily coincide with the physical memory address inside the device. It is task of the latter to associate, on the fly, the Modbus address with the internal memory variable, using, for example, matching tables.
These tables define what is called “Data Model” of the specific device and constitute a sort of “programmer reference manual” as these list all possible resources available in the Slave and those that are the addresses for the protocol.

Modbus addresses of objects, defined by a word, can extend across the range from 0 to 65535, while the number of objects is numbered from 1 to 65536. However, the numbering of objects is only formal, whereas what is important for the resources access is only the address entered in the PDU.
For each of the 4 subdivision areas, the entire range 0 to 65535 can be used as the function code will define to which of the four areas the address refers.
This extended way, which allows the addressing to 65536 objects for each of the four areas, is alongsided by another convention originally defined by the protocol and still used. In this convention, resources are counted in a narrow range of values from 0001 to 9999 by adding an offset, multiple of 10000, depending on the area concerned:

It is the object number that define to which of the four areas refers and with which function code the related operations must be performed.
The standard function codes predefined by the Modbus specification are few and much of these are used to read or write bit type variables and word type variables:

The Modbus protocol also provides error handling at the “Application layer” level by checking that Master’s requests are legitimate. If a Slave receives a PDU with values that are not compatible with its resources, it will not execute the requested command and will respond to the Master with a particular PDU (Exception) containing, in the Function field, the same command required but with the most significant bit set to 1. Subsequently to the Function field, it will transmit a data field, with 1 byte length, containing the code of particular error verified:

The Modbus protocol also defines other function codes used for service functions, status readings, diagnosis and device identification, as well as other additional error codes. For more details, refer to the official document of the Modbus protocol:

http://www.modbus.org/docs/Modbus_Application_Protocol_V1_1b.pdf