Introduction:
MODBUS RTU is a widely used communication protocol in industrial automation, enabling seamless data exchange between master and slave devices. One essential aspect of MODBUS RTU is the addressing scheme, involving both the Protocol Data Unit (PDU) and logical addresses. In this post, we will explore how the negotiated presentation of the PDU streamlines communication and the conversion process between PDU addresses and logical addresses for different types of registers.
It is important to clarify early that MODBUS addressing is often misunderstood because device documentation, SCADA software, and the protocol itself use different representations of the same data. This article focuses on how addressing works at the protocol level and how logical (human-friendly) addresses are derived from it.
Protocol Data Unit (PDU) presentation:
In MODBUS RTU, the PDU (Protocol Data Unit) is a crucial part of the communication frame used to exchange data between the master and slave devices. The PDU is structured to include the following components:
Function Code (1 byte)
The function code serves as a command that instructs the slave device on the type of action the master device wants to perform. It is a single-byte value that indicates operations such as reading data, writing data, or requesting diagnostic information.
From an addressing perspective, the Function Code implicitly defines the register type (coils, discrete inputs, input registers, or holding registers). This means that the same register address value can refer to completely different data depending on the Function Code used.
Register address (2 bytes)
The register address field specifies the starting point of the register in the slave device’s memory. It is a two-byte value that helps the master device identify the location of the data to be accessed or manipulated. Within the definition of the PDU, Modbus defines the address of each data element as ranging from 0 to 65535.
This address is always zero-based and is the only address that is actually transmitted on the wire.
Additional data fields (up to 250 bytes)
Depending on the specific function code, the PDU may include additional fields with varying lengths, extending up to 250 bytes. These additional fields carry the necessary data to execute the requested operation. For example, when reading data, the additional fields might include the number of registers to read, while writing data would require the values to be written to the registers.
By including the function code, register address, and additional fields in the PDU, MODBUS RTU ensures efficient and reliable data exchange between the master and slave devices.
Understanding the four types of registers
MODBUS RTU defines four types of registers, each serving distinct purposes in industrial automation:
Coils (Discrete outputs)
Coils represent binary outputs that can be controlled by the master device. They have two states: ON (1) and OFF (0). Coils are read and written by the master, allowing it to control various industrial processes.
Discrete inputs
Discrete inputs provide binary input data to the master device. These registers are read-only for the master and typically represent the status of sensors or switches.
Input registers
Input registers store analog data or data received from sensors. These registers are read-only for the master and provide valuable information about the external environment.
Holding registers
Holding registers serve as a two-way communication channel, allowing both read and write operations. They are commonly used to control slave devices and store temporary data.
A critical but often overlooked detail is that these four register types represent four independent address spaces.
As a result, it is perfectly valid for the same register number (for example, address 13) to exist simultaneously as a coil, a discrete input, an input register, and a holding register.
The register type is not determined by the address itself, but by the Function Code used in the MODBUS request.
Calculating Logical Addresses from PDU Addresses
The MODBUS application protocol defines precisely PDU addressing rules. In a MODBUS PDU, each data is addressed from 0 to 65535.
It also defines clearly a MODBUS data model composed of 4 blocks that comprise several elements numbered from 1 to n.
To convert the PDU addresses to logical addresses for Coils, Discrete inputs, Input registers, and Holding registers, an offset is applied. The conversion formula is as follows:
Logical Address = PDU Register Address + Offset
or
PDU Register Address = Logical Address – Offset
According to modbus.org:
“The offsets (pre-mapping) between the MODBUS data model and the device application is totally vendor device specific.”
In practice, however, widely accepted “conventional” offsets are often used across the industry purely for human readability, even though they are not part of the MODBUS protocol itself.
Typical examples include:
- 1 or 0 for coils
- 10001 for discrete inputs
- 30001 for input registers
- 40001 for holding registers
Logical address representations and offsets
For example, instead of referring to an item as holding register 14 at address 13, a device manual would use the following representations:
- 4014 (offset = 4001)
- 40014 (offset = 40001)
- 400014 (offset = 400001).
In each case, the first number, 4, indicates holding registers. The choice between 4XXX, 4XXXX, and 4XXXXX depends on the device’s address space. For instance, if all 65536 registers are in use, 4XXXXX notation is utilized, allowing a range from 400001 to 465536. Conversely, if only a few registers are used, the common practice is to use the range 4001 through 4999.
In various manufacturers’ documentation, the address of a holding register can be represented in multiple ways, which can lead to confusion:
- PDU address 13
- Logical address 4014
- Logical address 40014
- Logical address 400014
Regardless of the logical address representation used, the actual MODBUS RTU communication always relies exclusively on the PDU address combined with the Function Code.
Here are some examples:
- For logical address 4014 and offset 4001 -> PDU address = 4014 – 4001 = 13
- For logical address 40014 and offset 40001 -> PDU address = 40014 – 40001 = 13
- For logical address 400014 and offset 400001 -> PDU address = 400014 – 400001 = 13
Reverse case: from PDU to logical address
The opposite situation can also occur. In the manufacturer’s documentation for an input register, a PDU address of 33 may be used. However, the SCADA software works with the 3XXXX or 3XXXXX logical format for input registers.
In this case, the offset is 30001 or 300001, depending on the addressing convention.
For example, with an offset of 300001:
Logical address = PDU address + Offset = 33 + 300001 = 300034
Examples from real devices
In the documentation for the iEM3250 energy meter, Schneider Electric uses holding register addresses such as 30, 50, 70, etc. It is obvious that the offset is 0, meaning that the addresses presented are PDU addresses.
To read the “Serial number” using SCADA software that works with logical addresses in the 4XXXXX format:
Logical address = PDU address + Offset = 130 + 400001 = 400131
In the documentation for the PR720 power and energy meter, Yokogawa uses the 4XXXX format for holding registers.
It is obvious that the offset here is 40001.
The PDU address for “Demand current Upper limit value” is:
PDU address = 40106 – 40001 = 105
Conclusion
Understanding the conversion process between PDU addresses and logical addresses is crucial for effective communication in MODBUS RTU-based industrial automation systems.
Equally important is understanding that MODBUS uses multiple independent register spaces and that the Function Code implicitly selects which register space is being addressed.
Logical address formats and offsets are human conventions layered on top of the protocol and do not affect the actual data transmitted on the wire.
By applying the correct offsets and interpreting addresses in the context of the appropriate Function Code, engineers and operators can streamline data exchange and ensure seamless industrial operations.