Polling Groups and Scan Intervals are separate concepts. In some configurations, there can be a logical relationship between them, but membership in a Polling Group has no effect on the driver's Scan Interval or Delay After Scan. These are separate things.
Background
Polling Driver Tags were created when the most common link between the VTScada workstation and the remote device was through a serial port. In that configuration, it was typical to create a Polling Group for each serial communication link. This continues to be true for the case of stations connected via a radio link. While the Scan Interval is typically configured to be the same for every driver in the group, there are situations where it might vary, as described later in this topic under Scan Intervals.
There are three use cases for Polling Groups:
Use Case #1
The main purpose of the Polling Driver is to try to poll all the IO in a remote RTU closely in time rather than letting the driver poll individual blocks of data from any remote station based upon the oldest data (the default behavior). This is helpful when there is a slow polling update to get to all of the data, as is typical in radio telemetry systems where it can take several minutes to poll all of the remote stations. If various parts of the data from a station were each polled a few minutes apart, it can create unexpected results, such as the pump showing as running but the motor's amperage being 0. The scan interval of each driver should be configured to be the same in this case.
Use Case #2
The second major reason for the Poll Driver is to force the sequence of polling through a set of RTUs. This is seldom necessary for any reason other than the reassurance of seeing stations being polled in an expected order. Scan intervals and delays must be the same for all drivers in the group.
Note that delays due to the time it takes to scan can affect the order, with variations increasing over time.
Use Case #3
A third feature of the Polling Driver is that it will immediately force a poll of all the inputs at a station whenever something is written to a station. This lets the operator see the effect of a control action immediately rather than waiting for the next poll cycle.
Scan Intervals and Delays
Each Polling Driver specifies its own poll (scan) interval. When the specified time since the last poll is reached, that driver goes on the "to-be-polled" list. In most cases, drivers with the same scan interval all go on the list at the same time and they all get polled in order according to their sequence number in a group.
If the scan interval is longer than the time it takes to poll the last group, then that station will wait until its next scan interval is reached. Others with shorter scan intervals may continue to poll in the meantime.
(In the following example, the 10 seconds required to poll a station is unusually long. The number was chosen for the sake of clarity in the sample rather than to approximate actual hardware.)
For example, suppose that you have a system that requires 10 seconds to poll each station, and you have 4 stations, each set with a 1-second scan interval. Each station would go back on the list 1 second after it is polled but must wait for the remaining stations to be polled, so all stations would be polled once every 4 x 10 = 40 seconds. (Example continues...)
Suppose further that one station is more important than the others. You might back off the timing on the other 3 by setting their poll interval to 60 seconds. The result is the high-priority station (still set to poll at 1 second) would poll every 10 seconds (the time required by the hardware), while all of them would poll every minute. This is not ideal, because at the minute mark, the high priority station would have to wait 3 x 10 = 30 seconds longer to get its data. The scan delay parameter can help here. For the three lower priority stations, the delays might be set to 0, 20 and 40 respectively. What this will do is poll the high priority station consistently every 20 seconds, and each of the others once per minute (at 0 second mark the first low priority station would go on the poll list with the high priority station, next at the 20 second mark the next low priority station would go on the list, and so on).
High and Low Priority Groups
Another use case for the poll groups would be to put high priority stations in one group and low priority stations in another. The stations in each group could be set up with different polling intervals, with the high priority ones set to a very short interval, say 1 second, even though the com channel may not support that low of a polling rate.
The low priority stations would have a poll interval set significantly higher than the time it takes to poll all of the high priority stations. As in the previous example, the low priority stations might have a 60 second interval. The benefit of this method is that it avoids any need to calculate and maintain scanning delays. All could be set to 0 and the same result as the previous example would be achieved.
