A Comprehensive Guide to the Modbus Protocol: From Messages and Registers to Field Diagnosis – A Detailed Explanation

3, understand the master-slave relationship:

The fundamental logic of Modbus is straightforward.

1.the master station sends requests and the slave station responds.

2. Check the address, function code, and data at the station.
3. Receive a normal or abnormal response from the server.
4. The main station continues reading the next point.

On the RTU bus, only one master station may actively send requests at any given time. Slave stations cannot transmit data spontaneously; they must wait for a request from the master station—a critical requirement. Some mistakenly believe that "instruments automatically send data to the PLC when available," but this does not align with Modbus RTU functionality.

The PLC reads data sequentially, device by device and segment by segment, according to a predefined polling schedule.

Therefore, during field design, the following factors must be considered:

• How many devices are connected to the bus?
• How many registers does each device read?
• What is the Porter ratio?
• How fast should the polling cycle be?
• How to configure timeout and retry limits?

When multiple devices are connected to an RS-485 bus and numerous registers are frequently read, slower communication speeds are normal.

4. The Modbus data model defines four distinct object categories.

 Unlike traditional protocols that simply state "I want to read the temperature," Modbus specifies exactly which type of data should be read from a specific address. It includes four standard data fields:

• Coil: A read/writeable Boolean value, commonly used for start/stop, reset, and switching commands.
• Discrete Input: A read-only Boolean value, commonly used for switch states or fault states.
• Input Register: A 16-bit read-only register, commonly used for measurement values.
• Holding Register: A 16-bit register that is both readable and writable, commonly used for parameters, set values, and operational data. The most frequently employed registers in field applications are the holding register and input register. For example, a meter manual may specify: • Voltage: Holding Register 40001
• Current: Holding Register 40003
• Power: Input Register 30021
• Device Address: Holding Register 40010.

In such cases, one must not only examine the numerical values but also identify their respective data categories, as different data categories correspond to distinct function codes.

5. Function Code:The "Action Command"

 function code in Modbus determines what the master station should do. Common function codes include:

• 01: Read coil status.
• 02: Read discrete input.
• 03: Read the hold register.
• 04: Read the input register.
• 05: Write for a single coil.
• 06: Write to a single hold register.
• 15: Write multiple coils.
• 16: Write to multiple maintain registers.

Here are some practical examples:

• Reading the inverter's operating frequency: typically using codes 03 or 04.
• Set the frequency for the inverter: commonly set to 06 or 16.
• Read the device's operating status: may use codes 01,02,03, or 04; refer to the manual.
• Control a specific output channel of the relay module: use 05 or 15.

Function codes should not be selected based on intuition; always refer to the device's communication manual. Some devices store measurement values in the input register, which can only be read using 04; others store the same data in the hold register, readable with 03. Using the wrong function code may cause the device to return an error directly or fail to respond altogether.

     6.Register address:

 The most common pitfall in Modbus field applications lies not in wiring but in addressing. Several formats may be encountered:

• 40001
• 400001
• 0000H
• Address 0
• Address 1
• Holding Register 1

 these could refer to the same register or different ones.

The key is to distinguish between "logical numbering" and "protocol address." In many manuals, 40001 is a manually readable register number that identifies the first register in the register area.

However, the actual starting address included in a Modbus message is often 0.

In other words:

• The manual specifies 40001, but the software may require entering 0.
• The manual requires entering 40002, while the software may require entering 1.
• Some domestic equipment manuals specify address 1, and this value must also be entered in the software.
• Some tool software automatically handles the 40001 prefix, while others do not.

Therefore, when troubleshooting address issues, the most practical approach is to first use a debugging tool to read a register known to change, then test both the zero-based and one-based addresses separately to determine which yields a valid value.

Do not read large blocks at once, and avoid starting with complex floating-point numbers. Begin with simple data such as device addresses, baud rates, status words, and version numbers for easier identification.

7.Message Structure: How are the RTU and TCP messages structured?

Understanding the message isn't about calculating every frame manually, but about identifying where the issue lies during troubleshooting.

Modbus Message Structure Diagram

The Modbus RTU request example assumes the master station needs to read two hold registers starting from address 0 of slave device No.1. The message can be interpreted as: 01 03 00 00 00 02 C4 0B, where: • 01: Slave device address.

• 03: Function code; read the hold register.
• 00 00: Starting address.
• 00 02: Reads the quantity; 2 registers.
• C4 0B: CRC16 check; the low byte comes first.

If the slave station responds normally, it may return: 01,03,04,00, FA, 13,88, D7, or 54. Their meanings are: • 01: Slave address.

• 03: Function Code.
• 04: Remaining data byte count, 4 bytes.
• 00 FA: First register, decimal value 250.
• 13 88: The second register, with a decimal value of 5000.
• D7 54: CRC16 check.

The most error-prone fields in RTU packets are CRC, address, baud rate, parity bit, and byte order. The Modbus TCP request structure begins with an MBAP header followed by a PDU.

MBAP typically includes:   • Transaction Identifier: A unique identifier for matching requests and responses.

• Protocol Identifier: The protocol identifier; Modbus typically uses 0.
• Length: Length of subsequent bytes.
• Unit Identifier: A unit identifier, commonly used for gateways to forward traffic to serial slave devices.

The TCP protocol does not include the CRC field at the end of an RTU packet. Since it operates on top of TCP/IP, both the link layer and transport layer already have their own verification mechanisms; consequently, the Modbus TCP message structure no longer incorporates the CRC field used by RTUs.

8.Data type: 16-bit is just the starting point

Modbus registers are inherently 16-bit, but field data isn't always a 16-bit integer. Many devices split more complex data across multiple registers: • 16-bit unsigned integers.

• A 16-bit signed integer.
• 32-bit integer.
• 32-bit floating-point number.
• 64-bit double precision or cumulative value.
• An integer with a multiplier.

For example, if the electricity meter manual specifies a voltage of 40001 with a data type of UINT16 and a scaling factor of 0.1, then reading 2301 corresponds to an actual value of 230.1 V.

Consider a flow meter that uses two registers to represent a 32-bit floating-point number. When reading four bytes, there are several possible interpretations: • AB CD: the standard high-order bit comes first.

• CD AB: Low-case letters come first.
• BA DC: Byte exchange.
• DC BA: Both characters and bytes are exchanged.

Modbus specifies that the high byte should come first in registers; however, when multiple registers form 32-bit or 64-bit data streams, different manufacturers may handle byte order differently.

Therefore, when encountering incorrect floating-point values, do not immediately assume the protocol is faulty. First refer to the data types, scaling factors, byte order, and word order in the manual.

9. Typical Use Cases

Modbus is widely used because it excels in various scenarios involving data acquisition, configuration, and monitoring.

Power meters and energy consumption acquisition devices

including smart meters, multifunctional meters, power quality analyzers, and temperature/humidity sensors many of which support Modbus RTU or TCP protocols. Host computers, gateways, or PLCs can read data such as voltage, current, power, power factor, energy consumption, and frequency.

These applications are widely used in factory energy consumption management, power distribution monitoring, and industrial park energy systems.

The frequency converter and soft starter

PLC can read the frequency converter's status, fault codes, output frequency, and current via Modbus, as well as write start/stop commands and frequency setpoints.

However, note that frequency converter communication control typically requires proper parameter configuration. Parameters such as command source, frequency source, communication address, baud rate, parity bit, and timeout protection must all be set consistently.

Thermostats, flow meters, and pressure transmitters 

Instrumentation devices typically use Modbus to transmit measurement values and also support writing setpoints, alarm thresholds, and control parameters. Although these devices have limited monitoring points, their address tables can be configured with great detail.

During debugging, it is best to verify each item according to the manual.

PLCs, HMIs, SCADA systems, and gateway

 HMIs can read and write PLC data via Modbus. SCADA systems can collect data from multiple controllers or gateways using Modbus TCP. Serial servers and protocol gateways can convert Modbus RTUs to Modbus TCP.

However, the gateway is not a universal translator. It addresses communication transmission and forwarding issues but does not automatically understand the meaning of each device register. The point table must still be configured manually.