New Custom Firmware Feature: Prioritized Modbus Polling

This new interpolated method of polling Modbus registers optimizes data retrieval of important values (ex. low fuel, high temperature) according to YOUR prioritization.

DPS recently developed a new way to prioritize the polling of thousands of Modbus registers. This helped one of our clients monitor hundreds of registers spread out over several devices while focusing primarily on the few that matter the most.

You may not need to process large amounts of Modbus. But what DO you need? Remember that we can customize a solution that will directly meet your unique needs.

Treat DPS Like Your Engineering Department

Even if you don't need to process large amounts of Modbus, remember that:

1. DPS can develop custom firmware to meet your very specific technical requirements.
2. Your new firmware functions will run on our proven hardware and benefit from our remote-monitoring expertise.
3. For best results treat us like your engineering department. Just tell us what you want.

What is Modbus Polling?

Modbus masters and Modbus-processing RTUs monitor alarms by means of a process called polling. In essence, the RTU requests a value (a "register") on one of your remote devices. If the register indicates a problem (low fuel, high temperature, etc.), then an alarm is set on the RTU to tell you that something is wrong. After a register has been polled, your device repeats the process for the next register in the polling queue.

Once your RTU has polled all registers it is monitoring, it has completed what we call its polling loop. Depending on how many registers your RTU is polling, the amount of time it takes for your RTU to complete its polling loop will vary.

For example: say your RTU is monitoring a total of 1200 registers across several remote devices. It takes your RTU approximately 1 second to poll each register. The amount of time it will take for your RTU to complete its polling loop is 20 minutes (1 second x 1200 registers = 1200 seconds / 60 seconds = 20 minutes).

Large Register Counts = Long Polling Loops

In the example above, each of the registers is polled once approximately every 20 minutes. You may be satisfied with this. It's likely, however, that you are more concerned with some alarms than others. After all, every device has a number of conditions upon which the proper functioning of the device depends. A generator will cease to run if it overheats, for example. Knowing the running temperature of your generator is thus more important to you than knowing an obscure device statistic.

Prioritized Polling Gives You the Most Important Modbus Information First

One of our clients was concerned about this, so we developed an Modbus-polling RTU with a prioritized polling function. With prioritized polling, you can group your registers into different priority categories. Your highest priority registers will be polled most often by your RTU, while the registers with a lower priority are polled less often. This ensures that issues which could potentially be catastrophic for your devices are detected before its too late.

Example: You've grouped all 1,200 registers into four separate categories, each with a different priority ranking. In Group 1 you have 20 registers. These are your highest priority registers, so you want them polled at least once every 5 minutes. Group 2 has 280 registers that you want polled at least once every 30 minutes. Group 3 has 400 registers which you want polled once every hour. Finally, Group 4 has 500 registers which you want polled once every 2 hours. These are your lowest priority registers.

The settings for your RTU's polling loop might look like this:

Priority Group	# of Registers	Polling Timer (secs)
Group 1	20	300
Group 2	280	1800
Group 3	400	3600
Group 4	500	7200

In the above example, your RTU would begin its polling loop by polling the 20 registers in Group 1. At a rate of 1 register / second, it would take your RTU approximately 20 seconds to poll all of the registers in Group 1. Because your timer for Group 2, set to 1800 seconds (30 minutes), has not expired, your RTU will return to Group 1 and begin the polling process over again. The RTU will poll Group 1 roughly 6 times before the timer for Group 2 expires and the RTU turns to polling the 280 registers in this lower priority group. To poll each register in Group 2 would take roughly 280 seconds (about 4 minutes and 40 seconds). The RTU then would return to Group 1 and poll those 20 registers just before the 5 minute timer for that group expires. Phew!

DPS Anticipated - and Solved - a Potential Polling Delay Caused by Large Groups

Again, a problem emerges. Once Group 3's polling timer expires and your RTU turns to polling the registers in this group, it will take roughly 6 minutes and 40 seconds to complete its process. In the meantime, Group 1's timer has expired and your most urgent alarms are left further down the queue than they should be.

The problem is worsened once 2 hours have elapsed and your RTU turns to polling the registers in Group 4 which would take approximately 8 minutes and 20 seconds.Your polling timer for Group 1 has been expired for 3 minutes and 20 seconds at this point. This may not seem like a lot of time, but consider that the registers being monitored in Group 1 are your most important variables. You begin to assume more and more risk the longer these registers remain unmonitored.

Group 1 registers are polled several times before Group 2 's polling timer expires. Once Group 2 's polling timer expires, the RTU stops polling Group 1 and polls Group 2 before returning again to Group 1. Depending on how many registers are in Group 2, the amount of time before the two red sequences could be longer than your specified polling settings.

All of these delays stem from a simplistic polling algorithm, where a large group is started and completed without considering higher-priority registers.Do you really want to risk having your generator damage and site downtime because your RTU was not smart enough?

The Modbox Smartly Manages Polling Priorities in Real Time

With a DPS Modbox, you need not assume this risk. Theengineers at DPS have developed an algorithm that ensures that each of the registers being monitored by your RTU will be polled before each of your group polling timers expire.

Here's how DPS' prioritized polling function outperforms its competitor's RTUs:

Rather than repeatedly polling Group 1 registers until Group 2's polling timer expires, theModbox will spread out the polling of each Group 1 register across the time period that you've allotted for that group.

Returning to the example above, with 20 registers in Group 1 that need to be polled once every 300 seconds, the Modbox determines that it will poll one register in Group 1 every 15 seconds (300 seconds / 20 registers = 15 seconds / register. The Modbox then uses the intervening time to poll registers from the lower priority groups. After 5 minutes, the Modbox will restart its Group 1 polling loop and, once again using the intervening time, continue its polling of your lower priority registers. Should the Modbox have enough time to get "ahead of schedule" in all 4 groups, it will cycle through each group, polling a single register from each in turn. When a Group next needs a poll to stay "on schedule", the normal prioritizaion logic will resume.

The Modbox's smart prioritized polling process spreads the polling of Group 1 registers out over the entirety of the time slot allotted to the group. In the intervening time, lower priority registers are polled. Rather than wasting time unnecessarily repeating Group 1's polling loop (and subjecting it to long waits while polling the other groups), the Modbox maximizes efficiency by only polling Group 1 registers once during the group's allotted time period. It uses the time freed up by this process to poll lower level registers.

After the Modbox completes its entire polling loop, you can access the "Stats" pagein the web interface. IThis will tell you how long it took for each group to be polled. This allows you to reorganize your register groupings to optimize the Modbox's polling process.

Allow DPS To Customize a Solution to Your Unique Modbus Problems

The firmware solution described above was customized for one of our clients. Allow DPS to do the same for you - no matter what you need. Call DPS today at 1-800-693-0351 and tell us what to build next.