The Modbus Guide | Know How To Use It Correctly

Modbus is a term that frequently appears when searching for industrial control modules and how to set them up. Many sensors use Modbus, but the various registers and communication with a Modbus device can be a struggle. Luckily, the experts here at Automation Products Group, Inc. (APG) have put together a comprehensive Modbus guide.

What Is Modbus?

Modbus is a communication protocol that enables industrial controllers or programmable logic controllers (PLCs) to communicate with sensors, actuators, HMIs, and other modules used in instrumentation and control. Almost every integrable industrial device supports Modbus.

Modbus is a half-duplex, serial digital communication protocol. It works with RS485, the communication medium for industrial controllers. RS485 enables Modbus communication over long distances. Modbus is also compatible with other serial communication interfaces, such as RS232 and RS422.

Why Is Modbus Popular?

For over 40 years, Modbus has remained the most common protocol used by modern industrial systems. Modbus is successful with industrial engineers, equipment manufacturers, and PC programmers for three reasons:

1. Cost-Effective: Modbus is an open-source protocol, meaning that manufacturers can incorporate it into their industrial products without paying royalty fees. Incorporating Modbus into a controller is done by adding the Modbus driver into the controller’s firmware. Modbus has an advantage over the direct connection of switches (input) and solenoids (output) in terms of wiring. Modbus only takes a pair of twisted cables for an RS485 connection, while a direct link will require as many wiring connections for the individual I/O. Given that cabling costs are always on the rise, it makes sense to opt for Modbus.
2. Simplicity: Modbus is straightforward. It provides read/write operation on an industrial device’s coil, status, input registers, and holding registers, mapped to a range of addresses. Writing and reading from coils and registers is easy to understand. With visual interface, users can set up and control Modbus-operated devices without any programming skills.
3. A Mature Ecosystem: Over the decades, Modbus has matured into a large ecosystem of industrial control products. Many engineers and programmers are familiar with it and there isn’t a growing need for a different protocol form. Existing Modbus infrastructures are unlikely to undergo drastic changes even with technology upgrades.

How Does Modbus Work?

Modbus simplifies data acquisition and output control for an industrial controller. A Modbus connection requires a client controller and at least one server device. The client controller sends Modbus commands, and server devices respond with data or acknowledgment.

Modbus can’t have more than one client controller. Doing so will result in corrupted data packets when multiple controllers try to send commands simultaneously on the Modbus network.

Modbus replaces individual connections to input/output modules. As such, it retains familiar terms like coils and inputs in its data representation. All Modbus protocols share the same data types, which are allocated to specific addresses.

Modbus Data Types

Here’s how Modbus data types are represented:

Modbus Data Type	Read/Write	Format	Address Range (Dec)
Coil	R/W	1 bit	00001-09999
Discrete Input	Read-only	1 bit	10001-19999
Input Register	Read-only	16 bit	30001-39999
Holding Register	R/W	16 bit	40001-49999

Fig 1 – Modbus Data Type

The coil data type is associated with a solenoid output or solid-state relays. Discrete inputs are often flow switches, limit switches, or other single-bit digital inputs. Input registers are similar to discrete inputs, except that it returns a 16-bit data.

The holding register is a read/write storage is used for various purposes, such as writing and reading parameter configuration on a Modbus actuator. In addition, the holding register can be used to set parameters like maximum torque, alarms, relay contact, and fail-safe measures by writing the appropriate 16-bit data variable.

Modbus Message Frame

This describes how a Modbus data packet is transferred between client and server devices. The following diagram of a typical Modbus message frame gives a clearer picture.

Modbus message frame

Start

Device ID

Function Code

Register Address

Register Count

Data

Checksum

End

Fig 2 – Modbus Message Frame

The above message frame is valid for Modbus RTU and Modbus ASCII. In Modbus TCP, the Checksum and End fields are removed, and the Start field is replaced with a 6- byte overhead. Each Modbus message frame is wrapped by a start and end field, allowing the receiving unit to segregate different data packets.

The Device ID indicates the recipient of the Modbus message. The device ID ranges from 1 to 247, but the limit differs based on the transmission medium. Most industrial systems run on RS485, which allows up to 32 connected devices. For RS232, there’s a maximum of 2 devices. Running Modbus on TCP will expand the device count, subjected to the network switches and gateways.

Modbus Function Code

The core of Modbus lies in Protocol Data Unit (PDU), which is the Function Code, Register Address, and Data. These fields provide specific instruction to Modbus servers on what information needs to be retrieved, written, and where they’re located.

These are standard function codes supported by industrial Modbus devices:

Function Code (Dec)	Function
1	Read Coil
2	Read Discrete Input
3	Read Holding Registers
4	Read Input Registers
5	Write Single Coil
6	Write Single Holding Register
15	Write Multiple Coils
16	Write Multiple Holding Registers

Fig 3 – Modbus Function Codes

Modbus Communication Flow

Modbus communication always starts with a client controller sending a request to a server device. It can be a write or read request. The controller specifies the register address, register count, and data written on the Modbus PDU for a written request. A read request has a similar format, without the data field.

When a server device successfully processes a request, it’ll return an acknowledgment Modbus frame to the client controller. The acknowledgment frame contains the functioned code that was executed and data if it’s a read request. If a server device fails to process the request, it’ll respond with an exception code.

Modbus Exception Code

Sometimes, a client controller sends a request that isn’t supported by a server device, or the latter experiences technical issues. In such cases, the server device will respond with a Modbus exception code.

Exception Code	Name
1	Illegal Function
2	Illegal Data Address
3	Illegal Data Value
4	Server Device Failure

Modbus Data Integrity

It’s disastrous for the data to be corrupted during transmission and processing by the devices. The Checksum in the Modbus frame is vital to ensure the data integrity of Modbus transmission.

The 2-bytes Checksum is calculated from each byte of the Device ID and PDU. It’s then appended on the Modbus message. Upon receiving a Modbus frame, the recipient will compare the Checksum value against the calculated Checksum based on the received packet. If there’s a mismatch between the Checksum values, the device discards the Modbus data packet.

Modbus Distance and Speed

Modbus can run over RS232, RS485, or an ethernet cable. Each transmission medium allows different distances and speed limits. Most installations are on RS485, which works up to 4,000 feet and a speed limit of 115,200 baud. Ethernet cable provides a distance of 100 meters and the speed of the network switches.

Common Modbus Protocols

When setting up a Modbus system, ensure that all devices can communicate on the same protocol. Modbus RTU is the most popular protocol, but if there’s a Modbus ASCII or Modbus TCP sensor, ensure that the client controller supports both protocols.

The protocols differ in formatting and size. So let’s take a deeper look at each protocol.

What Is Modbus RTU?

Modbus RTU Frame	Length (bits)
Start (silence)	28
Device ID	8
Function Code	8
Data	n x 8
Checksum	16
End (silence)	28

Fig 5- Modbus RTU Frame

The Modbus RTU protocol transmits data in 8-bits (byte) binary format. For example, the function code of 16 is represented by a single byte 0x10 hexadecimal value. Using the Modbus RTU format allows users to send or receive data with the smallest bandwidth.

Modbus RTU uses a silence period to indicate the start and end of a message. Timing is crucial for a Modbus RTU device, as it needs to time the silence interval to mark the end of a message frame.

What Is Modbus ASCII?

Modbus ASCII Frame	Length (byte)
Start	1
Device ID	2
Function Code	2
Data	n x 2
Checksum (LRC)	2
End	2

Fig 6- Modbus ASCII Frame

Modbus ASCII shares the same field types with Modbus RTU, but that’s where the similarity ends. Instead of binary formatting, Modbus ASCII uses ASCII characters to encode the data into the message frame. For example, function code 16 is represented by two characters of 0x31, 0x36.

ASCII formatting limits the device limit to 247 (0xF7). Thus, the most significant device ID on a Modbus ASCII frame is 0x46, 0x37, the ASCII values for ‘F’ and ‘7’. The same applies to the register address and data passed in the message body. A 2-byte LRC Checksum is calculated for error-checking and appended to the message.

Modbus ASCII uses characters to indicate the starting and ending of a message. It uses 0x3A (:) as a start character and CRLF (0x0D, 0x0A) to terminate the transmission.

The payload uses only alphanumeric characters, producing intelligible text string when monitored on a Modbus sniffer software. It’s less sensitive to timing requirements as the message starts and ends with characters.

The downside of Modbus ASCII is that it takes at least twice the size of Modbus RTU. For example, it takes 2 bytes to transfer 0x5469 in Modbus RTU, but it’ll take 4 bytes to convert the value to ASCII representations of 0x35, 0x34, 0x36, 0x39.

What Is Modbus TCP?

Modbus TCP Frame	Length (byte)
Transaction Identifier	2
Protocol Identifier	2
Length Field	2
Unit Identifier	1
Function Code	1
Data Bytes	n

Fig 7- Modbus TCP Frame

Modbus TCP leverages ethernet connectivity. TCP is a connection-based transport layer protocol on the OSI stack. It automates connection synchronization, handshaking, error checking, and packet handling. With TCP taking care of the data transfer mechanism, the Start, End, and Checksum fields were redundant and removed. They’re now replaced by a 6-bytes header.

The new Transaction Identifier determines that a request is followed by a matching response. The Protocol Identifier is set to 0, indicating TCP protocol, while the Length Field indicates the remaining byte in the data packet.

What about Modbus Plus?

Despite sounding similar, Modbus Plus is not Modbus. Instead, it’s a high-speed peer-to-peer communication protocol that allows data transfer at 1 Mbps.

Modbus Plus specification includes protocol and hardware layers such as cabling and terminating connector. It involves token-passing in a flat network hierarchy, which differs from Modbus’s client-server configuration.

Understanding Modbus Addressing And Messaging

Understanding how Modbus addressing and messaging works helps when configuring and troubleshooting a Modbus network.

Device ID

A single byte can hold up to 255 possible Device IDs. However, Modbus specifications limit the valid IDs from 1 to 247. So, if you’re sending address 0x00 or 0xF8-0xFF on a Modbus RTU frame, the data frame will be ignored.

Relative Addressing

The standard Modbus specification allocates 9,999 memory points for different data types (coil, discrete input, input register, holding register). On a Modbus device, these data are stored in volatile and non-volatile memories.

Configuration values for a Modbus transducer are stored on a non-volatile memory like an EEPROM. Meanwhile, sensor values are stored and updated on an SRAM. Physical storage is abstracted for a PLC programmer. A programmer needs to know how to access the data with the address allocation of each data type.

Modbus data frame takes in relative addresses and not absolute addresses. The absolute and relative address for the data types are as follow:

Modbus Data Type	Absolute Address (Dec)	Relative Address	Data Frame (Hex)
Coil	00001-09999	0001-9999	0x0000-0x270E
Discrete Input	10001-19999	0001-9999	0x0000-0x270E
Input Register	30001-39999	0001-9999	0x0000-0x270E
Holding Register	40001-49999	0001-9999	0x0000-0x270E

Fig 8- Modbus Addressing

The relative address is the result of discarding the tenth-thousandth decimal from the address. An input register at an absolute address at 35,468 has a relative address of 5,468.

A device receiving the Modbus frame determines the data type from the relative address by inspecting the function code. A Read Holding Register request has a function code of 04, and the device automatically translates the relative address to 35,468.

The register address sent in a Modbus frame is deducted by one from the corresponding relative address. To read a coil at an absolute address at 00100, a command request is sent with an address of 0x63 (00099) in the data frame.

Extended Addressing

Each of the data types is allocated 9,999 memory spaces. They’re often sufficient for most applications. However, some devices require registries exceeding the standard allocation, and that’s where extended addressing comes in.

Extended addressing stretches the address limits to 65,535 (0xFFFF), which is the maximum address possible with 2-byte addressing. The Modbus protocol remains the same in fields and syntax with extended addressing. Devices that don’t support extended addressing respond with an exception when responding to a request with a vast address range.

How To Interpret Modbus Values

This isn’t a Modbus guide without showing what Modbus data packets look like when observed on a protocol sniffer software.

Modbus Transmission Example 1: Read Input Register

Let’s consider an example where a PLC reads 1 input register 30100 from a device (ID 2)

The PLC will transmit the following sequence in Modbus RTU (Hex).

02 04 00 63 00 01 C1 E7

Request frame breakdown:

• • • 02 – Device ID
    • 04 – Function Code for Read Input Register
    • 00 63 – the relative data address for 30100 deducted by 1
    • 00 01 – the number of registers to be read.
    • C1 E7 – the CRC checksum for the PDU.

The server device responds with the next data frame.

02 04 01 5F 27 74 DA

Response frame breakdown:

• • • 02 – Device ID copied from the received data frame.
    • 04 – Function code copied from the data frame.
    • 01 – the number of data bytes returned
    • 5F 27 – the register value.
    • 74 DA – the CRC checksum for the PDU.

The above protocol sequence is similar when performing a Read Holding Register request.

Modbus Transmission Example 2: Write Holding Register

Write holding register is usually used for setting configuration parameters on a Modbus device.

For example, a PLC writing 0x782A and 0xB7C3 into register 40078 and 40079 on a device (ID 3)

The request sequence will be as follow:

03 10 00 4C 00 02 78 2A B7 C3 B7 05

Request frame breakdown:

• • • 03 – Device ID
    • 10 – Function code 16 for writing multiple holding registers.
    • 00 4C – starting address of the holding register.
    • 00 02 – the number of registers to be written
    • 78 2A B7 C3 – values to be written
    • B7 05 – CRC checksum

When successfully executed, the device will respond with:

03 10 00 4C 00 02 81 FD

Response frame breakdown:

• • • 03 – Device ID copied from the received frame.
    • 10 – Function copied from the received frame.
    • 00 4C – starting address of the written registers.
    • 00 02 – number of registers written.
    • 81 FD – CRC checksum

Modbus Transmission Example 3: Read Multiple Coil

Understanding the data frame for reading coils (and discrete inputs) is more challenging, as each of the addresses holds only 1 bit. When retrieving multiple coil values, interpreting the value requires bit-wise identification.

A PLC reading 10 coils from an address 00500 from a Device ID 4 has the following request sequence.

04 01 01 F3 00 0A 4F 97

Request frame breakdown:

• • • 04 – Device ID
    • 01 – Function code
    • 01 F3 – Starting address of the coil.
    • 00 0A – number of coils to be read.
    • 4F 97 – CRC checksum.

Assuming that coils 501 and 508 are set, the response will be as follow:

04 01 02 01 02 F5 AD

Response frame breakdown:

• • • 04 – Device ID copied from the received frame.
    • 01 – Function code copied from the received frame.
    • 02 – number of bytes returned.
    • 01 02 – binary representation of coil values.
    • F5 AD – CRC checksum

The value of the coils returns as 0x01, 0x02. How does this correspond to the 10 coil addresses? Modbus is a “Big Endian” communication protocol, with the most significant bytes are transmitted first. Within a byte, the value starts with the most significant bit from left to right.

If you would like to learn more about Modbus or which APG products connect with it, please feel free to contact us!