Hi,
I need to generate DO on any alarm in DeltaV System. Checking all alarms will be difficult. Is there any simpler way. Is there any method by which I can read is there any alarm active in the whole system on FRS by vb and if there is then write a tag in DVSYS.
or there is any other way
Anyone done this before?
In reply to amitwani:
Can you please elaborate? Energizing a DO on any alarm with any priority (advisory, warning, critical) system-wide would seem to create a situation that would energize the DO very frequently. Perhaps a DO with a condition block as input would suffice. Program the condition block with the critical alarms that would energize the DO as required. What are you trying to accomplish? Perhaps we can find a more elegant solution.
I've seen it done using VB code in the workstation. DeltaV Operate already keeps track of alarms by user and by area. You can let DeltaV operate keep track of the alarms and just look at the alarm count under THISUSER using a VB script but you will need a user account that has read access to all areas of the plant and write access to the area in which you locate the DO module. You would also need a workstation that has all areas assigned to it so it would keep a complete list of all active alarms. Beyond that, there are a few complications. For example, if the user is automatically logged out after a certain time of inactivity, the script trying to write to the DO would get an error.
In reply to carllemp:
It's been a long while since I did this, but it was along the lines of what Carl suggested. Each console has a HORN parameter that is exposed and can be read by any control module. Since you are driving an external horn, this would be in a control module where the Horn is wired to a DO.
The horn parameter is written to with the number of the highest priority alarm currently active on the console. Initinally the value is biased by 100 so an unacknowledged, Active Critical alarm would be "115", when acknowledged, the value would be 15. I think if it goes inactive/unacknowledged, it goes to "-15". You can monitor the HORN value and confirm these values. So you can write some evaluation code in the module to only respond to active alarms of a certain priority.
You can read the HORN parameter from a collection of workstations, but as Carl points out, if the console all logout, you would not have any console driving the HORN parameter. The HORN parameter is intended to reflect the local horn of the conole. You could monitor the logged on user and if this goes to <none> on all the stations involved, you could set a horn sound indicating there is no alarm coveraged anywhere. Seems inappropriate to have alarms generated if its normal for there to be noone there to hear them....
So you'd be interested in any horn value above say 112, indicating an unacknowledged, active high priority alarm. Once acknowledged, the HORN value(s) drop to 12. The Global Horn acknoledge feature will reset the horn on all consoles.
I'd buil the module to have an External reference parameter to the HORN.CV of a console, and a string parameter to hold the current logged on user. The console ToolBar would have a variable pointing to the current user and on a change, would execute a script to write that value to the control module. Default this value to be empty, so that you ignore it if it is empty (don't set an alarm when you download this module because the logon parameters are empty)
Then you can build a CND block to look at both the HORN value and for USER to be <none>. You can also add a time delay on the CND output so you don't chatter the HORN. If a console operator silences the horn in a couple of seconds, is there a need to drive the external horn? If so, set the delay to 0 seconds.
Repeat this for each console and combine the CND block outputs appropriately to drive the DO channel.
You could also look at the Priority of the alarm and change the HORN pattern based on priority. That would require a bit more logic, and so you might use a CALC block. Anyway, once you have the HORN values in the module you can drive whatever logic you need to set the DO state.
You likely don't need this to run quickly (2 or 5 second executuion rate, since your primary response is from the Console (WS) Operator. So if the horn is to advise the operator when he is away from the console, a 5 second delay will not likely matter. If you think it does, your alarm strategy is likely not compliant with EEMUA or ISA18.2, where a time to respond is required for the condition to be an alarm...
, so really, you'd be looking to create a condition block for each workstation and read the HORN parameter, and have a Logged on User parameter (String)
Andre Dicaire