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.
Even if you don't need to process large amounts of Modbus, remember that:
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 tel 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).
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.
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)|
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!
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?
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.
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.
At DPS, we receive many urgent quote requests after an earlier "Do Nothing" decision comes back to bite you. You have no reason not to be proactive (and maybe you'll manage to impress your boss).
Call us. Chat with an expert for 10 minutes. We'll email you a detailed quote with a custom application drawing. We'll even include a summary of business benefits you can use to justify your project budget.
Call 1-800-693-0351 now for your quote
(or send us a quick online message instead)