Modbus

[Anonymous user]

📖 Home  Back  

How Fast can I Scan Modbus?

Problem

• I’d love to use a modern protocol like DNP3 with its intelligent report on change, but I’m stuck with Modbus which I must scan quickly to make sure I catch changes.
• How fast can I scan the devices – what are the limitations?
• I read that there are limits to data rates caused by the size of historic files, such as 15 second data, but I need to read data quicker than that.

Response

We are careful to state limits because there are so many variables. It’s useful to review our Software Performance Guidelines document to help understand the process. Please see the Geo SCADA Expert Performance Guidelines document for details. Link.

Driver Scan Rate

An important point is that the driver itself has few limitations on how fast the scanning is set up for. You can set it fast, and it becomes self-limiting because it can’t start a new scan until the old one has completed. The scan interval is the time between the end of the last scan and the start of the next. Therefore, the scan times of 1 second or shorter are possible.

For Advanced Modbus, the scan times are defined with the term 'Retrieval Interval' and are defined on the outstation object, with the selection of interval on the points:

For fast scanning to be useful, what we want to do is limit the data coming out of the driver process and into the server’s database. This is where the database gets potentially overloaded with non-useful data, and by the same reason the users are overwhelmed with it too. Note also that the Promoted scan rates may need to be changed, depending on whether you wish to enable 'Promote when displaying points', a feature which can accelerate scanning for devices on displayed mimics. This feature is enabled on the outstation object's 'Direct' tab.

Point and Device Configuration

To stop the driver from reporting no-change or little-change of analogues to the server, which then gets to the historian for processing, you can use the Advanced driver’s Deadband setting:

This will filter noise from the signal. You can also use the Hysteresis setting (and Persistence below it) to reduce the affect of noise causing alarm transitions which are load-intensive for value and event history:

Confidence Polling

The other area for consideration is the Confidence Poll. These are timed polls which ALWAYS cause data processing and storage. These MUST be configured for their real purpose, which is to provide a value to the database when not much change is happening to give operators confidence that the values are OK. However, you have device alarms and point quality (colour) to tell operators that devices are not healthy, so a good time interval for confidence polling is no more than HOURLY – which may also then be useful for report queries. Configure this on the Channel and the points. The default options for this shown here are very likely to be too fast for good system performance when a large system is set up. In this example use Group 8 which is set up for hourly updates.

The screenshot above also shows how the channel configuration has communication statistics update timing, which you may wish to increase for large numbers of devices.

Historian Compression

While it’s possible to use the historian’s compression feature to reduce the number of historic values stored, that does not stop data from being processed into the database as current values. Doing a lot of that will load up the database with noise. But historian compression may still be needed.

The above configuration will help to reduce the amount of noise stored by the historian and affecting historic query and trend display times.

Go: Home Back

More Links:

   Modbus RTU via Terminal Server

   Modbus Dual Ethernet Communications