• Not Answered

Locking in an alarm on a graphic (DV 11.3)

I have a customer that has a solar installation and an associated operator graphic of "alarm conditions" for each major process area in the solar farm.  Each condition for an alarm has it's own individual block on an operator graphic and there are many conditions (some come in very quickly and clear) that can cause the module to alarm. 

When a module senses an alarm condition, it displays properly on the alarm banner but if the operator isn't viewing the "alarm graphic" for that module and the condition clears he does not know what particular point caused the alarm.  I would like to be able to lock in the condition that caused the alarm on the operator graphic until seen by the operator and then allow them to reset the condition. 

Is there a simple way to accomplish this?

3 Replies

  • Can you clarify what you mean by alarm condition v.s. an alarm? DeltaV alarms are assigned a priority. There are two properties of a priority that relate to auto-acknowledgement. The first is Auto Acknowledge New Alarms and the other is Auto Acknowledge when Inactive. If either of these properties are enabled, alarms of that priority will clear on their own when the condition clears. Conversely, if neither is enabled, alarms of that priority will persist in alarm lists until acknowledged by the operator.

    Are you working with PlantWeb hardware and device alarms (FAILED, MAIN, ADVISORY, etc.)? These can have multiple contributing conditions, so perhaps it is these contributing conditions you are hoping to latch? The contributing conditions are presented in the alarm message.
  • Are you bringing multiple conditions into a single alarm block so that multiple items can cause a single alarm to be set instead of each condition setting an individual alarm? If this is the case, you could use the Boolean Fan Input block to aggregate the alarm conditions, as a First Out parameter is built into the block, (this block is commonly used for aggregating interlock/permissive information and supplying first out information to the operator). The first out information can be used to let the operator know what caused the alarm. You would probably want to add some code to reset the first out once the alarm goes to acknowledged or inactive-acknowledged, so that the operator doesn’t have to remember to reset the first out after every alarm.

    Although, I would be inclined to have each condition set its own alarm - if for no other reason that being able to track how often a single condition goes into alarm. And if you are having issues with alarms setting and clearing before the operator can even look at the display, tracking of alarm frequency would help identify these nuisance alarms.
  • The following thread discusses displaying the first-out condition as an alarm with the condition description in the alarm message.

    http://community.emerson.com/process/emerson-exchange/operateandmanage/deltav/f/50/p/4358/9546#9546

    It is very similar to what is being requested.