Download the PDF of the entire series of articles on Modbus

The “Data Link layer” is the first of the software type levels of the Modbus protocol and defines how the bytes are exchanged between one device and the other, however, regardless of their specific meaning. This level provides two different methods for transmitting information.

Transmission of RTU Modbus type involves the exchange of binary frames where the bytes can assume all the possible values 0÷255. Since the start and end of each communication frame can not identified by specific bytes values (synchronization characters), timers that control the exact timing of the transmission must be used. In some systems, managing these timings, which can be very short at the highest communication speeds, can be heavy for processing and problematic.

The ASCII transmission is obtained by encoding the value of each byte of the information with the sequence of two hexadecimal characters (digits 0÷9, A÷F). The ASCII protocol is less efficient than the RTU protocol since each byte of information is encoded by two characters. However, this coding allows the reservation of special characters for the purpose of being used as start and end frame indicators (sync characters). This greatly simplifies transmission management especially in slower systems or not equipped with particular hardware devices to implement the timing control needed instead to the RTU protocol.
In this series of articles, only the Modbus RTU serial protocol will be described.

RS485 serial network communication is half duplex, meaning that only one device at a time can transmit bus information. This requires the transmission of the various network nodes to be coordinated in such a way that there are no overlapping of the driving of differential line by more than one device at a time.
Communication coordination is obtained by assigning the Master role to one of the nodes, while the other ones have the Slave role. Typically, the Master function is assumed by the system logic controller, such as the PLC, while all peripheral and I/O expansion devices work as Slave.

The Master controls communication in the sense that it is the only one authorized to initiate an exchange of information. Periodically or by necessity, the Master starts communication with one of the Slave by sending a bytes packet on the bus containing the address of the Slave concerned, the function to be executed, any data associated with the function and the checksum for packet control:

The Address field consists of a single byte containing the address of the selected Slave. The values allowed by the protocol are in the range 0÷247.
Also, for the Function field, only one byte is used and this contains the command code of the specific request to the Slave. Some command-specific Data bytes, up to a maximum of 252 bytes, can be associated with the function code. The function code values and the meaning of
the data associated to the command will be defined in the next protocol layer (Application layer). The set of function field and data field is called Protocol Data Unit (PDU) and represents the useful part of communication.
Two bytes containing the lower and upper part of the checksum word (CRC), calculated on all previous bytes, are added at the end of the frame. This word is a signature about the content of the frame in order to identify any errors in the transmission of the bytes.

All Slaves, usually in “listen mode” on the bus, will receive the frame transmitted by the Master but only the addressed one will continue the communication while the others will ignore the request.
The selected Slave will respond to the Master by sending a frame with the same structure as the one described above.
After completing the exchange of frames with a Slave, the Master will be able to start a new communication sequence with the same Slave or with one of the others in the same manner:

The addressed Slave must reply within the shortest possible time, even in order not to slow down the communication operations with all the others Slave. Additionally, it is important to manage in the Master a predetermined time (Timeout) within which the Slave must reply to avoid blocking the communication in the case of missing or faulty Slave.
The Modbus protocol does not specify how to update the information of the Slave so that the Master may execute requests arbitrarily, as needed, or periodically (polling) to keep the status of the Slave resources constantly updated.

Each byte of the frame is transmitted on the RS485 fieldbus by serialization of a total of 11 bits, including the start bit, parity bit, and stop bit:

The start bit always applies one 0 level and constitutes a synchronization reference to initialize the reception of all character bits. After the start bit, the 8 bits of the byte are sent starting with
the least significant bit. Subsequently, a parity bit is transmitted for error control over one data bit and finally a stop bit (fixed value to 1).
The Modbus protocol allows one of the following modes to be used for the parity bit:

The Modbus specification, even though it gives full freedom, to the device’s user, in choosing the parity, forces the manufacturer to implement at least Even parity in the device, while recommends the availability of the “No parity” configuration.

Note that in the case of “No parity” the parity bit is still in tenth position and fixed at logic 1 value. Also considering the stop bit in eleventh position, the transmitted character then always has a total of 11 bits, even in the absence of parity, as if the “No parity” configuration corresponds to the presence of two stop bits:

It is quite common, in various implementations of the Modbus protocol, to find a character bits configuration outside the official specification. In fact, in the case of “No parity”, some devices consider the total absence of the parity bit, bringing to 10 the total number of character bits. This configuration corresponds, for example, to the classic “9600,N,8,1” (in case of 9600b/s communication speeds) that is particularly used on systems that do not allow parity management or on PC systems.

In the Modbus RTU protocol, all bytes of the same frame must be sent under strict temporal specifications, because they do not have special characters to use as synchronism and the packets are recognized and isolated from each other based solely on their timings:

Each frame must necessarily have all its bytes close to each other with a maximum time between the end of a byte transmission and the start of the next, equal to 1.5 times the duration of the character itself.
In addition, to distinguish a frame from the adjacent one, after the transmission of a frame, there is a pause of 3.5 times the duration of a character. This end frame pause, combined with the “compactness” of the frame bytes, guarantees the ability to distinguish and separate all the frames between them.

A transmitting device must then ensure that the frame bytes are contiguous, for example by preparing all the bytes up to the checksum in a transmission buffer and subsequently activating the entire buffer trasmission on the serial line.
Receiving devices will “capture” immediately all the bytes of a frame, continuosly reactivating a timer (1.5 character) on each byte received to control bytes contiguity and a timer (3.5 characters) to verify the effective end of a frame. After receipt of the entire frame, checksum value and match of Slave address will be checked.
Only the next level of the protocol (Application layer) will analyze the correctness of the received PDU and in case of success it will process it.

Regarding the address field of the communication frame, the Modbus protocol uses values in the range 1÷247 to communicate with only one specific Slave at a time (Unicast mode) while the special address 0 is used for Broadcast mode. A Master request with address 0 is processed by all Slaves but none of them will respond to the Master to avoid transmission conflicts on the bus. This mode is used to send the same command at the same time to all Slaves without receiving a response and then without any confirmation of the command execution by the Slave.
Finally, the addresses from 248 to 255 are “reserved” and allow the manufacturer to implement specific features.

The terminal field of frame consists of two bytes corresponding to the lower and upper part of the checksum word (CRC). This value allows the verification of the integrity of the packet bytes as it is a signature for the bytes values that precede the CRC field. In transmission, the checksum is calculated on all the bytes from the first (address) to the last of the Data field and added at the end of the frame. In receiving, the checksum is calculated on all bytes of the received frame (CRC field included). In this case, only a zero result indicates the correctness of the received frame.
Two different approaches can be used to calculate the CRC. The first is a complete algorithm that processes the values of all bytes considered and determines the 16 bit value of the CRC. The second is simpler and faster from the calculation point of view but requires the use of a table of 256 bytes pre-calculated constants and this, on microprocessors with little memory program, can be more onerous. For more details on these algorithms, refer to the official document of the serial Modbus protocol:

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

Abnormal situations may occur during frame communication such as the receiving an incomplete frame or incorrect checksum. In this cases, Slave devices must discard these frames and not reply, while the Master, if it founds errors in a Slave response, may decide to retry the frame exchanging.