Hi,
I was curious whether or not there is a datapoint that stores the total count of active alarms. We wanted to display alarm counts on our screens but weren't sure how to do this easily.
Thanks!
Total Alarm Count
- Gertjan van Schijndel
- Posts:634
- Joined: Mon Aug 02, 2010 10:37 am
Re: Total Alarm Count
What do you mean with 'total count of active alarms'?
[ol][*]Number of active '_alert_hdl' configs[*][*]Current alarm count/Number of alarms in alarm list[*][/ol]
Only the number of '_alert_hdl' config can be found in the dpe '_Stat_Configs_event_0._alert_hdl'. Other information regarding the alarms can only be obtained with a query.
[ol][*]Number of active '_alert_hdl' configs[*][*]Current alarm count/Number of alarms in alarm list[*][/ol]
Only the number of '_alert_hdl' config can be found in the dpe '_Stat_Configs_event_0._alert_hdl'. Other information regarding the alarms can only be obtained with a query.
- TBURKE2
- Posts:15
- Joined: Tue Jun 02, 2015 6:08 pm
Re: Total Alarm Count
Sorry for the confusion,
I was basically trying to figure out how to get the count of warnings/alarms that had actually triggered and would display on the alarm screen. Our current system has a small grid that displays alarm type and the count of how many of each type are activated at any point in time.
Thanks!
I was basically trying to figure out how to get the count of warnings/alarms that had actually triggered and would display on the alarm screen. Our current system has a small grid that displays alarm type and the count of how many of each type are activated at any point in time.
Thanks!
- leoknipp
- Posts:2928
- Joined: Tue Aug 24, 2010 7:28 pm
Re: Total Alarm Count
Hello,
if you want to count the pending alerts you have to use a dpQuery()-command with the keywords "SELECT ALERT".
Which _alert_hdsl-attributes need to be read depends on the information which shall be displayed.
The number of pending alerts is the dynlen of the query result minus 1, as the result also contains header information in the first line.
For detailed information concerning SQL statements in WinCC OA please have a look at the online help: System management --> Reporting --> SQL.
Best Regards
Leopold Knipp
Senior Support Specialist
if you want to count the pending alerts you have to use a dpQuery()-command with the keywords "SELECT ALERT".
Which _alert_hdsl-attributes need to be read depends on the information which shall be displayed.
The number of pending alerts is the dynlen of the query result minus 1, as the result also contains header information in the first line.
For detailed information concerning SQL statements in WinCC OA please have a look at the online help: System management --> Reporting --> SQL.
Best Regards
Leopold Knipp
Senior Support Specialist
- TBURKE2
- Posts:15
- Joined: Tue Jun 02, 2015 6:08 pm
Re: Total Alarm Count
Ah okay, thanks for the help! I'll give it a shot and see what happens.
- tmalone
- Posts:192
- Joined: Mon Nov 22, 2010 11:21 pm
Re: Total Alarm Count
I was successful in writing this code (my customer wanted to know how many alarms of each priority were active). Here is my code:
dpQuery("SELECT ALERT '_alert_hdl.._prior, _alert_hdl.._act_state, _alert_hdl.._sum' FROM '*' WHERE ('_alert_hdl.._sum' == 0)", ret);
My question to the collective smart people... when should I run this?
What event can I key off of to know when some alarm activity has occurred? (I hope it is not "every 10 seconds")
NOTE: This code does not run on the alarm panel, but in a CONTROL on the server and fills other tags with counts.
Todd Malone
HMI CoC USA
dpQuery("SELECT ALERT '_alert_hdl.._prior, _alert_hdl.._act_state, _alert_hdl.._sum' FROM '*' WHERE ('_alert_hdl.._sum' == 0)", ret);
My question to the collective smart people... when should I run this?
What event can I key off of to know when some alarm activity has occurred? (I hope it is not "every 10 seconds")
NOTE: This code does not run on the alarm panel, but in a CONTROL on the server and fills other tags with counts.
Todd Malone
HMI CoC USA
- fmulder
- Posts:330
- Joined: Wed Feb 03, 2010 9:46 am
Re: Total Alarm Count
I'd consider to make a sumalarm. The sumalarm has an attribute that will tell you what dp elements triggered it.
Look at '_summed_alerts'
Your next best option would be to implement a dpQueryConnect() and then maintain your own list of alarms. But this is not very simple.
Good luck
Frenk Mulder
Look at '_summed_alerts'
Your next best option would be to implement a dpQueryConnect() and then maintain your own list of alarms. But this is not very simple.
Good luck
Frenk Mulder
- tmalone
- Posts:192
- Joined: Mon Nov 22, 2010 11:21 pm
Re: Total Alarm Count
I think that I have found a solution. The help is very clear about NOT creating dpConnect calls to alarms, (SELECT ALERT...) but there is a specialized alertConnect() call for just alarm stuff. It seems that this alertConnect is specialized to look for ALL DPEs, so for example, you can ask the system to tell you whenever any DPE changes CAMEWENT. Using this concept and the original request need to count all alarms that are active (came), returned to normal but unack (went) and came+acked... I think this call works as an event:
ret = alertConnect("AlertActivity", TRUE, ":_alert_hdl.._ackable", ":_alert_hdl.._direction");
So, after this event, then I can make the dpQuery to get the totals for display on the Topology.
For those who might be interested, here is my complete code:
ret = alertConnect("AlertActivity", TRUE, ":_alert_hdl.._ackable", ":_alert_hdl.._direction");
So, after this event, then I can make the dpQuery to get the totals for display on the Topology.
For those who might be interested, here is my complete code:
Code: Select all
void AlertActivity(time t, int count, string alert1, int ackable, string alert2, bool dir)
{
dyn_dyn_anytype ret;
int i;
int Prio1, Prio2, Prio3, Prio4;
int P1State = 5, P2State = 5, P3State = 5, P4State = 5;
dpQuery("SELECT ALERT '_alert_hdl.._prior, _alert_hdl.._act_state, _alert_hdl.._sum' FROM '*' WHERE ('_alert_hdl.._sum' == 0)", ret);
DebugN(ret);
for(i=2; i- tmalone
- Posts:192
- Joined: Mon Nov 22, 2010 11:21 pm
Re: Total Alarm Count
I think that I have found a solution. The help is very clear about NOT creating dpConnect calls to alarms, (SELECT ALERT...) but there is a specialized alertConnect() call for just alarm stuff. It seems that this alertConnect is specialized to look for ALL DPEs, so for example, you can ask the system to tell you whenever any DPE changes CAMEWENT. Using this concept and the original request need to count all alarms that are active (came), returned to normal but unack (went) and came+acked... I think this call works as an event:
ret = alertConnect("AlertActivity", TRUE, ":_alert_hdl.._ackable", ":_alert_hdl.._direction");
So, after this event, then I can make the dpQuery to get the totals for display on the Topology.
For those who might be interested, here is my complete code:
ret = alertConnect("AlertActivity", TRUE, ":_alert_hdl.._ackable", ":_alert_hdl.._direction");
So, after this event, then I can make the dpQuery to get the totals for display on the Topology.
For those who might be interested, here is my complete code:
Code: Select all
void AlertActivity(time t, int count, string alert1, int ackable, string alert2, bool dir)
{
dyn_dyn_anytype ret;
int i;
int Prio1, Prio2, Prio3, Prio4;
int P1State = 5, P2State = 5, P3State = 5, P4State = 5;
dpQuery("SELECT ALERT '_alert_hdl.._prior, _alert_hdl.._act_state, _alert_hdl.._sum' FROM '*' WHERE ('_alert_hdl.._sum' == 0)", ret);
DebugN(ret);
for(i=2; i- leoknipp
- Posts:2928
- Joined: Tue Aug 24, 2010 7:28 pm
Re: Total Alarm Count
Hello,
the solution using alertConnect() in combination with a dpQuery() whenever the work functions is called is not a suitable approach.
You will create extra load on the system which is not necessary to get the number of alerts.
Maybe the script will work in small projects with a low number of value/alert changes.
In big projects, especially when a lot of alerts are generated in a short time, the script and the event manager will need a lot of CPU time to handle to query calls.
Normally alertConnect() is not used as you get a hotlink every time an alert changes. To get hotlinks when an alert is changed you have to use dpQueryConnectSingle() with a SELECT ALERT statement.
At the query function you can filter for alerts which shall be taken into account or not (e.g. summary ale
rts). The calculation for the number of alerts is then made within the script without calling a dpQuery() again.
Concerning the mentioned solution with a summary alerts please also have a look at the following forum thread
https://portal.etm.at/index.php?option= ... =3930#3930
Best Regards
Leopold Knipp
Senior Support Specialist
the solution using alertConnect() in combination with a dpQuery() whenever the work functions is called is not a suitable approach.
You will create extra load on the system which is not necessary to get the number of alerts.
Maybe the script will work in small projects with a low number of value/alert changes.
In big projects, especially when a lot of alerts are generated in a short time, the script and the event manager will need a lot of CPU time to handle to query calls.
Normally alertConnect() is not used as you get a hotlink every time an alert changes. To get hotlinks when an alert is changed you have to use dpQueryConnectSingle() with a SELECT ALERT statement.
At the query function you can filter for alerts which shall be taken into account or not (e.g. summary ale
rts). The calculation for the number of alerts is then made within the script without calling a dpQuery() again.
Concerning the mentioned solution with a summary alerts please also have a look at the following forum thread
https://portal.etm.at/index.php?option= ... =3930#3930
Best Regards
Leopold Knipp
Senior Support Specialist