Modbus RS-485 is like the reliable messenger of the industrial world, making sure different machines can talk to each other smoothly.
It’s the language they use to share important information, like how fast they’re running or if they need maintenance.
Imagine a bustling factory where robots, sensors, and controllers need to communicate constantly to keep operations running smoothly.
That’s where Modbus RS-485 steps in, providing a standardized way for these devices to exchange data. It’s been around for decades, evolving to meet the needs of modern industrial environments.
Modbus Data Register Type: Holding Register
Holding registers are one of the four primary types of data registers used in Modbus communication, alongside input registers, coil registers, and discrete input registers.
Holding registers are used to store and provide access to data that can be both read from and written to by the Modbus master device.
Holding registers are essential data storage points in Modbus communication, allowing devices to store and exchange information crucial for industrial processes.
Unlike input registers, which are read-only, holding registers enable both reading and writing operations by the Modbus master device.
Typically addressed numerically, holding registers are assigned specific ranges, such as 40001 to 49999, each capable of storing 16-bit or 32-bit data values. These registers commonly store parameters, settings, and control values, serving as a hub for critical data related to process control and automation tasks.

Typical registers address range: 40001 to 49999. What if, non-typical registers address are being used?
When encountering non-typical register addresses for example we have encountered an instrument hardware with Modbus holding register address ranges of 400418 to 400498, it indicates a deviation from the common range but does not inherently imply any functional difference.
The holding registers within this range serve the same purpose as those within the typical range – they store data used for communication and control between Modbus devices.
These non-typical holding register address, indirectly discover the limitation of Modbus Master software application that had been widely used like Modscan32 application.
These limitations can stem from the application’s predefined settings and scanning capabilities, which may not accommodate register addresses outside of commonly encountered ranges.
As a result, users may experience difficulties in accessing and manipulating data stored within these non-typical holding registers using ModScan32.

One potential explanation for this limitation could be that ModScan32 is designed to adhere to industry standards and conventions, focusing on typical register address ranges commonly found in Modbus systems.
As a result, register addresses falling outside of these ranges may not be supported or recognized by the application, leading to challenges in effectively scanning and interacting with non-typical holding registers.

This was the message we got via Modscan32 application when trying to retrieve signals from register addresses 400418 to 400498: “Exception response: 0x02 – Illegal Data Address.
The data address sent in the query is not an allowable address for the server (or slave).”

It appears that the combination of reference numbers and transfer length within this range is considered invalid by the server or slave device.
This error is commonly encountered when attempting to access registers beyond the allowable range specified by the Modbus protocol, leading to the application’s inability to retrieve data successfully.
Manage to Read Modbus Holding Registers by using Rapid Scada Application Software

It was finally manage to find the breakthrough, by using Rapid Scada application software.
One possible explanation for this success could be that Rapid Scada is more flexible or adaptable in its handling of Modbus communication, allowing it to accommodate a wider range of register addresses and data configurations.

Additionally, Rapid Scada may have built-in error handling mechanisms or protocol interpretation algorithms that enable it to effectively communicate with Modbus devices even in scenarios where other applications encounter difficulties.
This experience underlines the significance of exploring diverse software solutions and meticulously evaluating their unique features and capabilities when engaging with Modbus communication protocols.


