Introduction
This guide explains the Modbus communications protocol features and functions.
The standard
Modbus is a serial communications protocol originally published by Schneider Electric in 1979 for use with their programmable logic controllers (PLCs). Modbus is located in the level 2 of the OSI model, and uses a master/slave (or client-server) architecture. Simple and robust, it has since become a de facto standard communication protocol, and it is now a commonly available means of connecting industrial electronic devices. Modbus communication protocol presents the follow features:
It has been developed with industrial applications in mind
Openly published and royalty-free
Easy development and maintenance
Modbus allows communication between many devices connected to the same network, for example a system that measures temperature and humidity and communicates the results to a computer. Many of the data types are named from its use in driving relays: a single-bit physical output is called a coil, and a single-bit physical input is called a discrete input or a contact.
This list includes some of the most common uses of the standard:
Multiple master-slave applications
Sensors and instruments
Industrial networking
Building and infrastructure
Transportation and energy applications
Master/Slave principle
The master / slave principle has the following characteristics:
Only one master can be connected in a network.
One or more slaves can be connected at the same time in a network.
Only the master can initiate communication, i.e., sending requests to the slaves.
In Modbus communications, the master can only initiate one transaction simultaneously.
The slaves can only respond to requests from the master.
Slaves are not allowed to initiate communication with or the master or with any other slave. In Modbus communications, slaves generate an error message and send it as a response to the master if an error has occurred in the reception of a message or the slave can not perform the requested action.
Modbus data transmission
Modbus for Waspmote uses RTU mode of transmission. This mode is used in serial communication and makes use of a compact, binary representation of the data for protocol communication. The RTU format follows the commands/data with a cyclic redundancy check checksum as an error check mechanism to ensure the reliability of data. Modbus RTU is the most common implementation available for Modbus. A Modbus RTU message must be transmitted continuously without inter-character hesitations. Modbus messages are framed by idle periods.
The Modbus RTU transmission mode usually includes a parity bit to detect transmission errors. You can choose to transmit data with or without parity checking, but always make sure that all equipment connected to Modbus has the same configuration mode, otherwise communication will not be possible.
Modbus RTU frame
An RTU frame includes the following information:
Address: Valid slave device addresses are in the range of 0 ... 247 (decimal). The individual slave devices are assigned addresses in the range of 1... 247. Value 0 is reserved for broadcast messages (no response). When the slave sends its response, it places its own address in this address field of the response frame to let the master know which slave is responding.
Code Function: Valid codes are in the range of 1... 255 (decimal). The function code field tells the slave what kind of action to perform. For a normal response, the slave simply echoes the original function code. For an exception response, the slave returns a code that is equivalent to the original function code with its most significant bit set to a logic 1. All Modbus devices recognize the same set of function codes
Data: The data field contains additional information which the slave must use to take the action defined by the function code. This can include items like register addresses, quantity of items to be handled, etc. If no error occurs, the data field contains the data requested. If an error occurs, the field contains an exception code that the master application can use to determine the next action to be taken.
CRC: The checksum is calculated by the master and sent to the slave. The checksum is re-calculated by the slave and compared to the value sent by the master. If a difference is detected, the slave will not construct a response to the master.
Last updated
