Hi,
My company has Delta V 10.3 since a couple of years. Right now we have a major interest in taking advantage of system flexibilty on alarm management. I'm trying to create a tag that will allow me to monitor the current number of active alarms in my system and go back in time to see the value of this number at any moment in the past. This will allow me to identify alarm flooding / alarm banner saturation since my current Delta V Analize version is no capable of this.
The problem is that I don't know how to create a reference to this number so I can link it to a control module and from there to data historization. One of the default operating pictures shows this number using the following reference: DVSYS.THISUSER/ALMCNT.F_CV, but I've tried this and doesn't work. I know from Books On-Line that THISUSER is acknowledged by DV as a control module in the default AREA_A, so I've tried to change the reference to: DVSYS.THISUSER/ALMCNT.CV , but it seems like ALMCNT is not a valid module parameter.
I'm also trying to the same with current suppressed alarms number, but I guess the logic is just the same.
Thanks a lot in advance for any help.
Regardless of you particular usage, the alarm framework is such that it is reliant on the DeltaV application user scope, and is thus not available via OPC or by persistent reference in the controller.
You have a couple of options:
1. Write scripting within Operate VBA to read the THISUSER values periodically, and write them to a control module parameter via the frsreadvalue and frswritevalue functions. This scripting would need to be placed in a persistent graphic object such as a schedule, toolbar, alarm banner, user.fxg, or SIglobals.fxg. The scripting would only run when Operate is running, however.
2. Write SQL queries against the chronicle database to determine, for a single point in time, to find latest *distinct* instance of all alarms becoming active before that point, then subquery each instance to find if a complimentary inactive or disabled event occured before the point in time. This will likely be a very expensive query, and dependant on the size and retention of you chronicle, may not yeild alarms which have been active for very long durations.