Modbus serial protocol (the original version) is a master/slave protocol, e.g. one master that controls the Modbus data transactions with multiple slaves that respond to the master’s requests to read from or write data to the slaves.
In a standard Modbus serial network, there is one master and as many as 247 slaves, each with a unique slave address. Modbus TCP is typically implemented on an Ethernet network, and data transactions from a Modbus client are directed toward a Modbus server via an IP address.
There are two types of serial Modbus, RTU and ASCII. RTU and ASCII transmission modes determine the way in which the Modbus messages are encoded. In Modbus RTU, bytes are sent consecutively with no space in between them, with a 3-1/2-character space between messages as a delimiter.
This allows the Modbus interface software to know when a new message is starting. For each eight–bit byte, one start bit, eight data bits, one bit for parity, and one stop bit are sent, for a total of 11 bits per byte. Each Modbus RTU message is terminated with an error checksum called a cyclic redundancy check (CRC).
Modbus ASCII marks the start of each message with an ASCII colon character ” : ” and the end of each message is terminated with ASCII carriage return/line feed (CR/LF) characters. This allows the spacing between bytes in the message to be variable, which makes it suitable for transmission through some modems.
The data in a Modbus ASCII message uses ASCII characters. For each eight–bit byte, one start bit, seven data bits, one bit for parity, and one stop bit are sent, for a total of 10 bits. Modbus ASCII messages are terminated with an error checksum called a longitudinal redundancy check (LRC).
Modbus TCP or TCP/IP is basically Modbus RTU wrapped in an Ethernet (IEEE 802.3) package with the destination address as an IP address using the TCP/IP transaction protocol. The TCP port 502 is reserved for Modbus, while the new Modbus/TCP Security uses Port 802. For more information, see “MODBUS Messaging on TCP/IP Implementation Guide” V1.0b at Modbus.org.
Modbus Protocol Serial
Modbus serial traditionally uses RS-232 and RS-485 wiring for collecting data from Modbus slaves. The original Modbus was RS-232-based need to connect multiple slaves soon expanded Modbus to use multidrop wiring methods. RS-422 has been used but RS-485 is more capable and is more commonly used.
A Modbus master can communicate with as many as 247 Modbus slaves (limited by the RS-422/485 driver capability), which can be PLCs, smart devices, DCS and remote telemetry units (RTUs), which is where Modbus RTU got its name. “MODBUS over Serial Line Specification and Implementation Guide” at Modbus.org provides more information on wiring Modbus serial links.
To connect more than two devices and distances greater than 50 feet, a network of multidrop devices, RS-485 or RS-422 should be used. For multidrop networks, RS-485 is by far most popular and supports as many as 32 nodes without repeaters over the range as far as 4,000 ft (1,200 m).
The speed that Modbus messages are sent is known as the baud rate (or bits per second) and all devices on the network must use the same baud rate, typically 9,600-19,200 Baud, but network speeds as fast as 115 kb/s are not unknown. Generally, the higher transmission speed, the shorter the cable and the more important to have the correct network end termination resistors to minimize reflections (equal to resistance component of the cable characteristic impedance).
Modbus Communication
The Modbus RTU protocol uses a Master/Slave technique to communicate between devices. Meaning, any application that utilizes the Modbus RTU protocol will have a Modbus Master and at least one Modbus Slave. A Modbus Master is typically a host supervisory computer running software that will communicate with one or more Modbus Slave devices.
Modbus enables Master/Slave communication between devices connected through buses or networks. On the OSI model, Modbus is positioned at level 7. Modbus is intended to be a request/reply protocol and delivers services specified by function codes. The function codes of Modbus are elements of Modbus’ request/reply PDUs (Protocol Data Unit).
In order to build the Modbus application data unit, the client must initiate a Modbus transaction. It is the function which informs the server as to which type of action to perform. The format of a request initiated by a Master is established by the Modbus application protocol. The function code field is then coded into one byte. Only codes within the range of 1 through 255 are considered valid, with 128-255 being reserved for exception responses. When the Master sends a message to the Slave, it is the function code field which informs the server of what type of action to perform.
To define multiple actions, some functions will have sub-function codes added to them. For instance, the Master can read the ON/OFF states of a group of discreet outputs or inputs. It could also read/write the data contents of a group of MODBUS registers. When the Master receives the Slave response, the function code field is used by the Slave to indicate either an error-free response or an exception response. The Slave echoes to the request of the initial function code in the case of a normal response.
Modbus RTU Data Representation
Like everything else about Modbus, the data representation is simple. Data is represented more simply in Modbus than in any other industrial protocol you’ll ever find. The Bit of least importance is sent and received first. All devices within the network must interpret each transmitted byte analogously in this manner.
There are no methods for automated recognition of baud rates. The same baud rate must be utilized by the Slave(s) and Master connected to the bus. No specific baud rate is specified by the Modbus: typical baud rates are 9600 or 19200.
There are only two data types in Modbus: coils and registers. Coils are simply single bits. The bits can be ON (1) or they can be OFF (0). Some coils represent inputs, meaning they contain the status of some physical discrete input. Or they represent outputs, meaning that they hold the state of some physical discrete output signal. Registers are simply 16-bit unsigned register data. Registers can have a value from 0 to 65535 (0 to FFFF hexadecimal). There is no representation for negative values, no representation for values greater than 65535 and no representation for real data like 200.125.
Registers are grouped into Input Registers and Holding Registers. Like Input Coils, Input Registers report the state of some external input as a value between 0 and 65535. The original intent of an Input Register was to reflect the value of some analog input. It is a digital representation of an analog signal like a voltage or a current. Most Modbus devices today are not I/O devices and Input Registers simply function identically to Holding Registers.
Holding Registers were originally designed as temporary program storage for devices like Modbus controllers. Today, Holding Registers function as data storage for devices.
Modbus RTU packets are only intended to send data. They do not have the capability to send parameters such as point name, resolution, units, etc. If the ability to send such parameters is needed, one should investigate a BACnet, EtherNet/IP, or other modern protocols.
| Modbus Function Code | Type of Register |
| 1 | Reading coil |
| 2 | Reading of discrete inputs |
| 3 | Reading of holding registers |
| 4 | Reading of input registers |
| 5 | Writing of single-coil |
| 6 | Writing of single holding register |
| 15 | Writing of multiple coils |
| 16 | Writing of multiple holding registers |