Polling Regime Parameters
- Last UpdatedAug 04, 2025
- 5 minute read
|
|
|
UNINTENDED EQUIPMENT OPERATION Do not change these protocol parameters, except on the advice of Technical Support for this product. Failure to follow these instructions can result in death, serious injury, or equipment damage. |
These parameters are used to manipulate polling.
|
Parameter |
Allowable values |
Default value |
Description |
|---|---|---|---|
|
[<unit>]EventPollPeriod |
0 to 4,000,000 (seconds) |
The current value for [DNPR] |
Period to poll device for event class data. Integrity poll will poll for all classes (event and static data) after every EventPollRatio event polls. If the value is set to zero then the polling mode in the Citect.ini parameter [DNPR]ResponseModeDefault will be disabled. The device will stay offline until an integrity poll is forced out or an unsolicited message from the device is coming in. See Device Polling Regime for an example. Note: This Citect.ini parameter can be overwritten if the "Minimum Update Time" field for the I/O Device is greater than 0. (This option is only available with Plant SCADA from version 7.20.) |
|
[<unit>]PollPeriodOffset |
0 to 2,000,000,000 (seconds) |
0 |
The amount of time in seconds before the first periodic poll occurs for this unit. A common start time is used for all units for this calculation. Subsequent polls occur every EventPollPeriod after the first poll, thus the offset is maintained between units for all subsequent polls. |
|
[DNPR] [<unit>] |
0 to 65,535 |
1 |
How many class 1 event polls to be issued. A value of 2 would mean that this event class happens every n second poll period. 0 will turn class 1 polls off See Device Polling Regime for an example. |
|
[DNPR] [<unit>] |
0 to 65,535 |
1 |
How many class 2 event polls to be issued. A value of 2 would mean that this event class happens every n second poll period. 0 will turn class 2 polls off. See Device Polling Regime for an example. |
|
[DNPR] [<unit>] |
0 to 65,535 |
1 |
How many Class3 event polls to be issued. A value of 2 would mean that this event class happens every n second poll period. 0 will turn Class3 polls off. See Device Polling Regime for an example. |
|
[DNPR]EventPollRatioDefault [<unit>]EventPollRatio |
0 to 65,535 |
10 |
Default number of event class polls for every integrity poll. Integrity poll will poll for all classes (event and static data). Be reminded that a value of zero implies that only integrity polls are conducted. See Device Polling Regime for an example. |
|
[DNPR] [<unit>] |
0 – Unit recovery carried out with a static poll 1 – unit recovered using integrity poll |
0 |
Enable this setting if the driver should recover a device by issuing integrity (static class and event class) poll. static (static class) polls are issued to recover a device if this setting is disabled (default) |
|
[DNPR] [<unit>]AutoUnsolicitedEnable |
1 for class 1 2 for class 2 4 for class 3 (or any combination thereof) A value of zero (0) will result in NO classes being enabled for unsolicited responses. The default value of 7 enables all classes. |
7 |
This provides the ability to explicitly specify the classes to be enabled for unsolicited responses at start-up. Currently when a device is brought on-line, the driver will send a command to enable unsolicited responses for all classes. This command is only sent if the "Restart" bit is set in the IIN flags. This parameter will only take effect if the parameter "[DNPR]ResponseModeDefault" has "unsolicited msg" enabled. Be reminded that the driver also has a ‘virtual’ data type for enabling/disabling unsolicited responses in a unit. The classes enabled will be as specified by this parameter. |
|
[DNPR] [<unit>] |
0 – No integrity polls are issued when receiving unsolicited data from an offline device 1 – Unsolicited data from the device causes an integrity poll when the device is offline, in order to bring the device online if possible. |
0 |
Send an integrity poll when receiving an unsolicited message for an offline device. |
|
[DNPR] [<unit>]IPonECPMode |
0 – For any response, immediately send an Event Poll 1 – For any response, immediately send an integrity poll 2 – For an integrity poll response, immediately send another integrity poll, for any other response immediately issue an Event Poll 3 – Disables any polls being sent on IIN bits set except the Overflow bit 4 – Disables any polls being sent on IIN bits including the overflow bit. |
2 |
Defines the follow-up action to be taken when a response is received with any of the class 1, 2, or 3 IIN bits set. |
|
[DNPR] [<unit>]EnableRestartIIN |
0 – Unit restart sequence is not carried out when restart IIN flag is detected 1 – Unit restart sequence is carried out when restart IIN flag is detected |
1 |
Only disable if all devices are not able to clear their restart IIN flag (as required for DNP compliance). When disabled, the driver will not perform a unit restart sequence (clear restart flag, integrity poll and Enable Unsolicited messages) when a restart IIN flag is detected in a response. |
|
[DNPR] [<unit>] |
0 – Disable 1 – Enable |
0 |
Enable the adjustment of the device’s poll period via writing to a tag of address ‘PollPeriod’. This is a security feature to help ensure that an operator is not inadvertently given access to adjust the poll period. |
|
[DNPR] [<unit>] |
0 – Unit will recover based on the INI parameter "IssueIntegrity 1 – Unit recovered using Class 1 poll 2 – Unit recovered using Class 2 poll 3 – Unit recovered using Class 3 poll |
0 |
Enable this setting if the driver should recover a device by issuing Class 1, Class 2, or Class 3 poll. Note: The driver will not issue any polls if we configure this parameter along with the INI parameter "EventPollPeriodDefault" with the value Zero. |
|
[DNPR] [<unit>]MaxOperateDelay |
1000 to 60000 ms |
5000 ms |
The RTU configured max delay between a SELECT to OPERATE command in ms. This is used in the driver to freeze any polling for up to this period to allow the OPERATE command to work. |
|
[DNPR] |
0 to 20 |
0 |
During each polltime, the waiting messages are sent to each RTU. The default behavior is to send these messages out in the order they exist in the driver (when set to 0). However, some RTUs prefer the messages to go out on one COMs channel, then the next etc. Setting this value allows this behavior to happen, e.g. if set to 2 (and data was waiting for Ports 0,1,2,3), then the first polltime scan would send data out on Port 0, then Port 1, then wait until the next polltime scan, and send data out to Port 2, then Port 3. |
