Customer wants to change the alarm limits at runtime to account for changes in the process. I find the dpe+:_alert_hdl.2._l_limit and dpe+:_alert_hdl.2._l_limit data point elements and can read them using dpGet(). Using dpSet() does not seem to work with either (but the manual hints that it should for the _l_limit). I tried to use the alertSet() command but find it very complex and odd that we need time for such changes?
Can someone share an example of setting new alarm limits at runtime (without redefining the entire alarm configuration)?
Version: WinCC OA 3.10 OpenSUSE
Thanks,
Todd Malone
script for changing the limits of an alarm
- mweber
- Posts:42
- Joined: Mon Aug 02, 2010 11:23 am
Re: script for changing the limits of an alarm
Hello Todd,
when an alert handler is active you can not just write to the alert handler attributes - you have to switch it of first.
But you could only switch it of if it is acknowledged.
(remember that the alert handler is a state machine worked inside the event manager and that it could lead to inconsitant states if it is not done in that way)
the solution is now the following (the example uses an alert handler with 3 ranges - range 1 is good, 2 is warning, 3 is alert):
dpSetTimedWait(0, $DPE+":_alert_hdl.._ack", 2); // we have to acknowledge the alarm first before we could deactivate (2 is a single acknowledge)
dpSetTimedWait(0, $DPE+":_alert_hdl.._active", 0); // deactivate the alert handler
dpSetTimedWait(0, $DPE+":_alert_hdl.._ack", 2); // acknowledge again - just in case... afterwards we could set the new parameters
dpSetTimedWait(0,
$DPE+":_alert_hdl.1._u_limit", minAlert,
$DPE+":_alert_hdl.2._l_limit", minAlert,
$DPE+":_alert_hdl.2._u_limit", maxAlert,
$DPE+":_alert_hdl.3._l_limit", maxAlert,
$DPE+":_alert_hdl.2._text", warningText,
$DPE+":_alert_hdl.3._text", alertText);
err = getLastError(); if (dynlen(err) > 0){ throwError(err);}
dpSetTimedWait(0, $DPE+":_alert_hdl.._active", 1); // activate the alert handler again
In this example "minAlert" is the warning range limit and m"maxAlert" is the alert range limit.
Note that there is an upper limit of one range that is equal to the lower limit of the next range - if you use hysteresis this is not the case, then the both limits are slightly different (what makes the hyteresis...).
The dpSetTimed is used for a special reason - when changing attributes of configs with normal dpSet this is stored in the configuration history of the RAIMA database, but the history is limited in size.
When this changes are done very frequently it might lead to the situation, that the history table is getting full and no changes can be done any more.
When setting it eith the "0"-time of the database (01.01.1970) this is not stored in the history (it is a workaround we have implemented).
The alertSet() is dealing with the instances of the alert handler that is the individual alerts created by the alert handler.
You will see those alert instances on the alert screen - if you want to interface with them (for instance force filter some or doing individual acknowledge) you need alertSet().
I hope this will help you.
when an alert handler is active you can not just write to the alert handler attributes - you have to switch it of first.
But you could only switch it of if it is acknowledged.
(remember that the alert handler is a state machine worked inside the event manager and that it could lead to inconsitant states if it is not done in that way)
the solution is now the following (the example uses an alert handler with 3 ranges - range 1 is good, 2 is warning, 3 is alert):
dpSetTimedWait(0, $DPE+":_alert_hdl.._ack", 2); // we have to acknowledge the alarm first before we could deactivate (2 is a single acknowledge)
dpSetTimedWait(0, $DPE+":_alert_hdl.._active", 0); // deactivate the alert handler
dpSetTimedWait(0, $DPE+":_alert_hdl.._ack", 2); // acknowledge again - just in case... afterwards we could set the new parameters
dpSetTimedWait(0,
$DPE+":_alert_hdl.1._u_limit", minAlert,
$DPE+":_alert_hdl.2._l_limit", minAlert,
$DPE+":_alert_hdl.2._u_limit", maxAlert,
$DPE+":_alert_hdl.3._l_limit", maxAlert,
$DPE+":_alert_hdl.2._text", warningText,
$DPE+":_alert_hdl.3._text", alertText);
err = getLastError(); if (dynlen(err) > 0){ throwError(err);}
dpSetTimedWait(0, $DPE+":_alert_hdl.._active", 1); // activate the alert handler again
In this example "minAlert" is the warning range limit and m"maxAlert" is the alert range limit.
Note that there is an upper limit of one range that is equal to the lower limit of the next range - if you use hysteresis this is not the case, then the both limits are slightly different (what makes the hyteresis...).
The dpSetTimed is used for a special reason - when changing attributes of configs with normal dpSet this is stored in the configuration history of the RAIMA database, but the history is limited in size.
When this changes are done very frequently it might lead to the situation, that the history table is getting full and no changes can be done any more.
When setting it eith the "0"-time of the database (01.01.1970) this is not stored in the history (it is a workaround we have implemented).
The alertSet() is dealing with the instances of the alert handler that is the individual alerts created by the alert handler.
You will see those alert instances on the alert screen - if you want to interface with them (for instance force filter some or doing individual acknowledge) you need alertSet().
I hope this will help you.
- leoknipp
- Posts:2928
- Joined: Tue Aug 24, 2010 7:28 pm
Re: script for changing the limits of an alarm
Hello,
please notice that this procedure will acknowledge the original alert. When activating the _alert_hdl-config again new alerts will be generated for this dp-element if one or several alert-limits are exceeded.
Therefore you'll get new entries at the alert-history (if the alerts are saved according to the settings at the alert-class.
Best Regards
Leopold Knipp
Seniour Support Specialist
please notice that this procedure will acknowledge the original alert. When activating the _alert_hdl-config again new alerts will be generated for this dp-element if one or several alert-limits are exceeded.
Therefore you'll get new entries at the alert-history (if the alerts are saved according to the settings at the alert-class.
Best Regards
Leopold Knipp
Seniour Support Specialist
- tmalone
- Posts:192
- Joined: Mon Nov 22, 2010 11:21 pm
Re: script for changing the limits of an alarm
The script is great, but it is important for everyone to know that you must change
$DPE+":_alert_hdl.2._u_limit", maxAlert,
$DPE+":_alert_hdl.3._l_limit", maxAlert,
Notice that this really the same value on the alert handler panel if you are not using hysteresis. The system call to change the tags must use ALL the tags that could be used. So even if you are not using Hysteresis, you still have to set the limits as if it existed.
Here is my objects for changing a Lo-Hi and a Lo-Hi-HiHi alarm limits for a data point element at runtime.
Enjoy:
Todd Malone https://www.winccoa.com/fileadmin/image ... panels.zip
$DPE+":_alert_hdl.2._u_limit", maxAlert,
$DPE+":_alert_hdl.3._l_limit", maxAlert,
Notice that this really the same value on the alert handler panel if you are not using hysteresis. The system call to change the tags must use ALL the tags that could be used. So even if you are not using Hysteresis, you still have to set the limits as if it existed.
Here is my objects for changing a Lo-Hi and a Lo-Hi-HiHi alarm limits for a data point element at runtime.
Enjoy:
Todd Malone https://www.winccoa.com/fileadmin/image ... panels.zip
- Attachments
-
- AlarmLimit_panels.zip
- (3.37 KiB) Downloaded 286 times
- leoknipp
- Posts:2928
- Joined: Tue Aug 24, 2010 7:28 pm
Re: script for changing the limits of an alarm
Hello,
I had a look at the example.
If you want to read information which can be read in one dpGet()-call you should use one call instead of several dpGet()-calls.
Best Regards
Leopold Knipp
Senior Support Specialist
I had a look at the example.
If you want to read information which can be read in one dpGet()-call you should use one call instead of several dpGet()-calls.
Best Regards
Leopold Knipp
Senior Support Specialist