How the Poll Scheduler Works in Niagara 4 Drivers
The Niagara poll scheduler polls only subscribed points, in Fast, Normal and Slow buckets. Its statistics tell you whether a network can keep up.
When engineers complain that "Niagara is slow" on a Modbus or serial network, the poll scheduler is almost always where the answer lies. It decides which points are read, in what order and how often. It also keeps statistics that tell you, in numbers, whether the network is coping. This guide explains how it works, what each setting and statistic means, and a method for tuning busy networks.
Where the poll scheduler is
Polled drivers have a Poll Scheduler component under the driver network, for example ModbusAsyncNetwork > Poll Scheduler. BACnet networks also have one for points that are polled rather than updated by COV. Each network has its own scheduler, so two RS-485 ports with separate networks are scheduled independently.
Key idea 1: only subscribed points are polled
Niagara does not poll every proxy point all the time. It polls points that are subscribed, meaning something currently needs their value:
- a graphic, property sheet or wire sheet open in Workbench or a browser
- a link from the point to logic or another component
- an alarm extension or history extension on the point
- an export, Niagara network subscription from a supervisor, or a program that reads it
Points with history or alarm extensions, or linked into logic, are effectively subscribed all the time. Points that nothing uses are not polled until someone opens a view showing them.
This is why a network can be fast when nobody is looking and slow when an operator opens a large graphic: suddenly many more points are subscribed.
Key idea 2: Fast, Normal and Slow buckets
Each point's tuning policy assigns it a poll frequency: Fast, Normal or Slow. The scheduler has a target rate for each:
| Bucket | Typical default | Use for |
|---|---|---|
| Fast | 1 second | Values on live graphics, critical statuses |
| Normal | 5 seconds | Most points |
| Slow | 30 seconds | Slowly changing values, energy totals, configuration |
These are targets, not guarantees. If the network cannot complete all polls in the time available, actual cycle times stretch.
Key idea 3: dibs polling
When a point becomes subscribed (for example, an operator opens a graphic), the scheduler gives it dibs: it is polled straight away, ahead of the normal cycle, so the user sees a value quickly instead of waiting for its bucket to come round. After that first poll it joins its normal bucket.
A high proportion of dibs polls means subscriptions are changing constantly, often because users open and close large graphics, or because something subscribes and unsubscribes repeatedly.
Poll scheduler properties
| Property | Meaning |
|---|---|
| Poll Enabled | Turns polling on or off for the network |
| Fast Rate | Target cycle time for Fast points |
| Normal Rate | Target cycle time for Normal points |
| Slow Rate | Target cycle time for Slow points |
| Statistics | Read-only figures describing actual performance |
Poll scheduler statistics
The statistics are the most useful part of the scheduler. Typical values include:
| Statistic | What it tells you |
|---|---|
| Statistics Start | When the figures were last reset |
| Total Polls | Number of polls since the reset |
| Average Poll | Average time each poll takes |
| Busy Time | Percentage of time the scheduler is busy polling |
| Dibs Polls | Share of polls that were dibs polls |
| Fast / Normal / Slow Polls | Share of polls in each bucket |
| Fast / Normal / Slow Cycle Time | How long a full cycle of each bucket actually takes |
| Fast / Normal / Slow Points | How many subscribed points are in each bucket |
Use the Reset Statistics action before measuring, let the station run under normal conditions (with typical graphics open), then read the figures.
Reading the statistics
- Busy Time near 100%: the network is saturated. It is polling flat out and cannot do more.
- Cycle times longer than the configured rates: points are being polled less often than intended. A Fast rate of 1 s with a Fast cycle time of 12 s means "fast" points actually update every 12 s.
- Average poll time high: each request takes long. Typical causes: slow devices, timeouts on offline devices, low baud rate, or reading one register per request.
- Lots of points in Fast: the most common self-inflicted problem.
How to tune a slow network
Work through these steps in order and re-measure after each.
1. Fix offline devices and timeouts
A device that does not answer makes the scheduler wait for the full response timeout on every attempt, sometimes with retries. One dead device can halve a serial network's throughput. Disable devices that are offline or removed, and fix the ones that should be online.
2. Move points out of Fast
Keep Fast for values that genuinely need it. Put meter totals and configuration in Slow. Most points belong in Normal.
3. Reduce what is subscribed
Remove history extensions and alarm extensions that nobody uses, and delete proxy points that are not needed. Break huge graphics into smaller pages.
4. Read registers in blocks
On Modbus, configure points so consecutive registers are read in one request rather than one request per point. See What is Modbus? for block reads.
5. Use COV where available
On BACnet, use change-of-value subscriptions for points on live graphics instead of fast polling.
6. Increase the baud rate
If every device on an RS-485 trunk supports it, raising the baud rate (for example from 9,600 to 38,400) increases throughput substantially. Change all devices together.
7. Split the network
Move devices onto another RS-485 port (a separate network with its own scheduler) or onto Modbus TCP. See Modbus networks per JACE.
8. Set realistic rates
Finally, set Fast, Normal and Slow rates the network can actually achieve, and stale times in the tuning policies that match.
Worked example
A Modbus RTU network at 9,600 baud has 30 devices and 900 subscribed points, 600 of them in Fast with a 1 s rate. Statistics show Busy Time 100%, Fast Cycle Time 38 s and Average Poll 60 ms, with frequent timeouts.
Actions taken:
- two removed devices are disabled, eliminating timeouts
- 500 points move from Fast to Normal and 150 energy values to Slow
- points are grouped for block reads
- the baud rate is raised to 19,200 on all devices
After the changes, Busy Time falls to about 60%, Fast Cycle Time is 3 s for the 100 points that remain Fast, and graphics update promptly. No hardware was added.
Why subscriptions matter for design
Because only subscribed points are polled, decisions elsewhere in the station change network load:
- History extensions keep points permanently subscribed. Adding a 1-minute history to every point on a slow trunk effectively forces constant polling of all of them.
- Alarm extensions do the same. Alarm only on points where an alarm leads to action.
- Links into logic subscribe the source points. Large calculation chains spread across many devices can subscribe hundreds of points.
- Graphics subscribe everything they display while open. A summary page showing every point on a floor can momentarily swamp a serial network.
- Supervisor subscriptions through the Niagara network subscribe the JACE's points when supervisor graphics or exports use them.
When designing a station, think about which of these each point really needs. A point with no history, no alarm and no links costs nothing until someone looks at it.
Poll scheduler and BACnet
On BACnet networks, points can be updated in two ways:
- COV (change of value): the device sends updates when the value changes. No polling is needed for those points, and network load stays low.
- Polling: the poll scheduler reads points that do not use COV, or whose devices do not support it.
Where devices support COV, use it for points shown on live graphics and points that change often. Use polling for the rest. Check device COV support in the BACnet PICS, and watch for devices with limits on the number of COV subscriptions they can hold. See What is BACnet?.
A maintenance routine for busy networks
At each service visit:
- Reset the poll scheduler statistics on each network and let the station run while you work.
- Before leaving, note Busy Time, cycle times and average poll for each network.
- Compare them with the previous visit. Rising busy time or cycle times usually means points, histories or devices have been added, or a device is failing.
- Check device statuses for any that are down or timing out.
- Record the figures in the site log.
This takes minutes and catches performance problems before operators notice them.
Quick reference: symptoms and causes
| Symptom | Most likely cause | First thing to try |
|---|---|---|
| Graphics slow to populate | Many points subscribed at once on a saturated network | Move non-critical points to Normal or Slow |
| Busy Time 100% | Network saturated | Remove timeouts, reduce Fast points, block reads |
| High average poll time | Offline devices, slow devices, low baud rate | Disable dead devices, raise baud rate |
| Many dibs polls | Graphics or subscriptions constantly changing | Split large graphics, check flapping subscriptions |
| Points stale intermittently | Stale time shorter than real cycle time | Increase stale time or fix the cycle time |
| Network fine until a user logs in | Large graphics subscribe hundreds of points | Smaller pages, Slow polling for display-only values |
Frequently asked questions
What does the poll scheduler do in Niagara?
It decides which subscribed proxy points a polled driver reads, in which order and how often, using Fast, Normal and Slow buckets, and it records statistics about network performance.
Why are some points not updating in Niagara?
They may not be subscribed (nothing is using them), the network may be saturated with long cycle times, or the device may be offline. Check the poll scheduler statistics and the device status.
What are dibs polls?
Immediate polls given to newly subscribed points so users see values quickly before the point joins its normal polling cycle.
What does Busy Time mean?
The percentage of time the scheduler is busy polling. Near 100% means the network is saturated and cannot poll faster.
How do I make a Modbus network faster in Niagara?
Remove timeouts from offline devices, move points out of Fast, read registers in blocks, raise the baud rate if all devices support it, and split large networks across more ports.
What are good Fast, Normal and Slow rates?
Common starting points are 1, 5 and 30 seconds, but set rates the network can actually achieve, based on the measured cycle times.
Why do points update quickly when I open a graphic, then slow down?
Newly subscribed points get dibs polls straight away, then join their normal bucket, whose cycle time may be much longer on a busy network.
Does each network have its own poll scheduler?
Yes. Each driver network has its own scheduler, so networks on different ports are polled independently and in parallel.
Does BACnet use the poll scheduler?
For points that are polled, yes. Points updated by COV subscriptions are not polled in the same way, which is why COV reduces network load.
Does polling faster improve control?
Only up to the speed the process changes. Room temperatures change over minutes, so polling them every second wastes capacity. Poll fast only where it matters, such as pressures or values used in fast loops.
How do I reset the poll scheduler statistics?
Invoke the Reset Statistics action on the poll scheduler, then let the station run under normal load before reading the figures.
Will disabling a device stop it slowing the network?
Yes. Disabled devices are not polled, so they no longer cause timeouts. Re-enable them once they are back online.
Need help from a Niagara engineer?
If this guide has not solved the problem, contact the Tyrrell Products technical team on 01942 732819 or [email protected]. Tell us the controller or host type, its Niagara version and what you have already tried, and we will help you get the system running.