Applies To:
  • CitectSCADA 5.xx, 6.xx, 7.00
  • CitectHMI 5.xx, 6.xx, 7.00
Summary:
CitectSCADA’s behaviour, in allowing runtime configurable changes to the alarm delay parameter, has been discovered to have the side effect of overwriting configured alarm delays.

The effect can be seen when performing the following actions:

An alarm with delay X is defined in the system, the system is compiled, started, and an alarm is triggered. The delay time is changed to Y in the DIGALM.DBF database. A full compile is performed and the system is started up then shutdown – with or without triggering any alarms. If the DIGALM.DBF database is examined the delay has changed back to X.

Solution:
A Citect.ini parameter has been added to give the option of changing this behaviour. By default this parameter is 0 (FALSE).  To enable the configuration based limits (delay or threshold) to always be used, in the Alarm section, set:

useConfigLimits = 1

The correct behaviour now depends upon whether we are running standalone or redundant configurations and the online and offline state of the servers.

Standalone:
- By default run time generated changes override configuration changes to preserve existing behaviour.
- The above parameter can be used to force Citect to use the limits from the rdb file (compiled from the dbf file). Update times of the rdb and almsave.dat are NOT considered – the rdb is always used.

Redundant:
- If the secondary or backup is online and changes are made at runtime on the primary, to limit parameters these changes will be propagated to the secondary and saved to the secondaries rdb file and dbf file. These may potentially overwrite configuration changes being performed on this machine. Hence be aware editing the dbf file on an online machine may result in your changes being overwritten. The above parameter DOES NOT prevent this.
- If the machine is offline you can edit the dbf and rdb then the local almsave.dat, rdb or dbf is not updated by the remote machine. Setting UseConfigLimits influences whether this station, when coming online will use the rdb only or potentially use the almsave.dat. If it uses almsave.dat, as per previous behaviour it will compare the timestamp of the primary and secondary almsave.dat files. As with any deployment of the configuration files, on a partial set of the machines in a network, this can lead to the configuration for multiple machines being out of sync. This would mean runtime configured limits, via cicode or tag writes calls generated on a remote machine and not stored in the local rdb or dbf, will NOT be preserved.

This fix has been tested in both a standalone and network configuration.

Future versions of Citect will clarify the editing and deployment of configuration data and the policy on runtime changeable limit data.  This problem has been resolved in v7.00.

 
Keywords:
Alarm delay  

Attachments