Please ensure Javascript is enabled for purposes of website accessibility
Powered by Zoomin Software. For more details please contactZoomin

AVEVA™ Plant SCADA

[Alarm]UseConfigLimits

  • Last UpdatedSep 11, 2025
  • 4 minute read

Certain alarm properties that are configured in Plant SCADA Studio can also be modified at runtime, either by writing to an alarm property tag or by calling Cicode functions such AlarmSetThreshold or AlarmSetDelay. These properties include the alarm limits, delays and others (see Write to Alarm Properties for the complete list).

The values for these properties are stored in the alarm database located in the [DATA] folder. They are initialized from the configuration values for a particular alarm (stored in the RDB files produced by the compiler). This occurs the first time the alarm server is started after an alarm is added. By default, subsequent changes to the configuration values in Plant SCADA Studio are not reflected in runtime. This parameter allows that behavior to be changed.

If [Alarm]UseConfigLimits is set to 1, when the alarm server starts the values for all the writable properties in the alarm database are updated with the configuration values from the RDB files. When a property is modified at runtime, the modified value is written to the appropriate RDB file to avoid losing the change the next time the server is started. The modified value is also written to the appropriate DBF value to avoid losing the change if the project is recompiled.

Note:
• Modified values are only written to the DBF files on the local alarm server machine. If your development environment is not on the same machine as your runtime alarm server (for example, you are using deployment or [CtEdit]Run and [CtEdit]Copy), then you need to ensure changes made at runtime to the writable alarm properties are propagated back to the development environment manually. Otherwise, the values will be lost when the project is recompiled and redeployed.
• The DBF files on client machines are never modified in response to runtime changes. For this reason, make sure you do not use the project files from a client machine for developing a project.

When using a redundant pair of alarm servers, changes made on one server will be automatically propagated to the paired server and written to both servers' RDB and DBF files (as long as both servers are running). If one server is not running, the changes will not be written to the files on that server. However, if the server that is not running is then started, the changes made while it was not running will be synchronised from the paired server (assuming it is still running) and will be written to the RDB and DBF files.

Note: Take care if runtime changes are made while one server is offline, then the server with the changes is stopped before restarting its paired redundant server. If the server without the changes is started first, the changed values will be lost when the server with the changes synchronizes to the server without the changes. This applies regardless of the value of [Alarm]UseConfigLimits.

When starting a pair of redundant servers from cold (both servers are stopped), the first server to be started will always take the configuration values from the RDB files (when [Alarm]UseConfigLimits = 1). A server that starts while its paired server is already running will check if the runtime values are newer than the time the project was compiled.

For example, the server will check if changes were made on the paired server while it was offline. If so, the runtime values will be written to the RDB and DBF files, otherwise the runtime properties on both servers will be updated with the configuration values from the RDB file. Note that this check is a comparison of the last update time for all writable properties on all alarms, it is not done on a per-alarm basis.

Details on the actions taken on startup will be logged to syslog.dat file for the alarm server process.

Allowable Values:

0 or 1.

When set to zero (0):

  • Configuration values for writable alarm properties are only used to initialize the alarm database the first time the alarm server is started (or when a new alarm is added)

  • Changes made to the writable alarm properties at runtime are only stored in the alarm database, the RDB and DBF files are not modified.

When set to 1:

  • Configuration values for writable alarm properties will be used to update the alarm database each time the alarm server is started, unless starting as a redundant server and the partner server is already running with newer runtime values

  • Changes made to the writable alarm properties at runtime are stored in the alarm database and also written to the RDB and DBF files.

Default Value:

0

Note: This parameter can also be applied to a specific cluster or alarm server process. For more information, see Configure Alarm Parameters for a Specific Cluster or Process.

See Also

Alarm Parameters

[CtEdit]Copy

[CtEdit]Run

In This Topic
Related Links
TitleResults for “How to create a CRG?”Also Available in