MODBUS in a Nutshell

by Grid Connect Team

MODBUS may seem complicated and confusing to some, but it is a very simple protocol when you understand how it works. MODBUS is a request and response protocol. A MODBUS master will initiate a request and a slave will respond with either an error or the data requested. This is the simple concept of MODBUS.

You can implement MODBUS over several different types of busses and networks, but there is one core component of MODBUS protocol that is used in all of them. This piece is referred to as the Protocol Data Unit (PDU). When speaking of MODBUS in general, the PDU is the entirety of the protocol. The PDU consist of a function code and data.

MODBUS can be used over nearly all busses and networks, however the most common two are Ethernet (TCP/IP) and Serial (RS232, RS485, RS422, etc.). There are specifications for both MODBUS/TCP and MODBUS serial. MODBUS/RTU is the most commonly used serial MODBUS protocol. There is also a less common ASCII version. The difference between MODBUS/TCP and MODBUS/RTU is mostly in the transport frames or the wrapper around the PDU. In both forms of MODBUS, application specific addressing and error checking are attached to the PDU to make the Application Data Unit (ADU). In MODBUS/TCP the ADU is encapsulated in a TCP packet. The TCP protocol handles the error checking, which is why it is omitted from the MODBUS/TCP ADU.

MODBUS/RTU Serial – Slave ID and CRC

Slave ID - 1 byte. Identifies which slave device receives the request.

CRC – 2 bytes. Insures that the correct amount of bytes were sent and received.

MODBUS/TCP – MODBUS Application Protocol (MBAP)
Transaction Identifier - 2 bytes. Helps identify each request/response pair when several responses are expected.

Protocol Identifier - 2 bytes. For regular MODBUS protocol, it is set to 00 00. Incorporated for protocol expansion in the future.

Length - 2 bytes. Identifies the number of bytes in the message to follow.

Unit ID – 1 byte. If a MODBUS/TCP gateway is used, there may be several slaves that use the same IP address. The Unit ID is used to differentiate which slave the request is for.

There are four supported data tables for MODBUS devices. These are Discrete Inputs, Discrete Outputs (Coils), Input Registers, and Holding Registers. Each table can support up to 65536 data addresses. They are addressed 0000 to FFFF hexadecimal (0 to 65535 decimal). The data table is selected by the function code. The data addresses on that table, for reading or writing, are specified by a start address (2 bytes) and a size (2 bytes) at the beginning of the data portion of the PDU. Discrete Inputs are 1-bit and read-only. Discrete Outputs (Coils) are 1-bit and read-write. Input Registers are 16-bit and read-only. Holding Registers are 16-bit and read-write. The following illustrates the data model and addressing for MODBUS protocol.

Most GUIs try to make the adressing more user friendly. They do this with 1 based addressing (starting at 1 rather than 0) and appending a number at the front of the address correlating to the data type. Discrete Inputs append a 1, Discrete Outputs (Coils) append a 0, Input Registers append a 3, and Holding Registers append a 4. The following illustrates addressing structure commonly used in MODBUS software.

In conclusion, MODBUS is simply a request and response protocol. Requests consist of an ID to determine which unit to address, function codes to specify what is being requested, and data. Responses use these same 3 fields to respond to the requests. Different networks add different variations to the protocol, but they all address the same MODBUS data structure which has Discrete Inputs, Discrete Outputs (Coils), Input Registers, and Holding Registers.