• Not Answered

Is there a way of grouping multiple alarms into one trigger for a horn?

Hello everyone,

I hope this is the right thread for the question. I´ll detail the problem in the post and relevant pictures are attached in the .zip file.

We are using the DeltaV version v14.3.1 build 7288.

We have several unit modules in an area which contain many control modules inside them. The task we have in front of us is that we want to connect each of the critical alarms from the modules to also trigger the horn activation present in one of the modules. (picture 1, Overview of the area and units where alarms are needed on the horn)

As attaching all the alarms individually would be impractical, we would like to connect the signal to a unit alarm or an area alarm. Since it seems the area alarms aren’t present in the controllers we have opted for unit alarms.

The method for reading the alarms by utilizing the ALARMS[1].NALM parameter seems to not return an error as the script finds the parameter which isn´t shown on the unit itself within DeltaV explorer. The problem is that the unit alarm doesn´t seem to be connected to the alarms of the modules within the unit. When using the same method of reading the alarm from a module (in the example //MAA131-P103/ALARMS[1].NALM) the output is working as intended. The same script for area alarms of course doesn´t work within an action block in a control module. The area and module ALARM[1] parameters work and change value dynamicly within the watchit application when an alarm is triggered or acknowledged. (picture 2, Test control module for reading ALARMS[1] parameter from unit MAA131-B101, and also from module MAA131-P103 within the unit)

When testing the response of the DVSYS tags withing DeltaV Operate, they seem to access all 3 ALARMS[] parameters, on all levels, but we need to execute the solution using a module in DeltaV Control Studio. (picture 3, Area, unit and module ALARM[1] parameter while relevant alarm is active) (picture 4,  Area, unit and module ALARM[1] parameter while relevant alarm is inactive)

 

Thank you in advance for the help,

Kind regards, 

Marino Martinelli

Pictures of DeltaV issue.zip

Marino Martinelli

• 16 Dec 2024 10:23 AM
• Cancel

2 Replies

• Andre Dicaire

  

  • 16 Dec 2024 8:45 PM

  I think I tried this once and found that the controller level UNIT/ALARMS[1] reference only returns the alarm explicitly created on the UNIT module. The Workstations have a U$ unit scope, similar to the AREA scope or THISUSER Scope that builds an array of up to 250 alarms for use in the alarm summaries, Alarm Banner and such.
  
  A workstation would be able to read all alarms from all modules assigned to a Unit, showing you the Highest priority alarm in the ALARMS[1] position of the array, based on the confiration of the assigned Areas of the workstation and logged on user. A workstation script could write to a module to trigger an external horn per Unit when ever the ALARMS 1 parameter changes to an active unacknowledged state. You'd have to think through the acknowledgement of all active alarms or maybe delay reactivation of the horn so that following an initial alarm, operator response and acknowledgement of alarms stabilizes before a new Horn is needed. Devil is in the details.
  
  Since the U$ unit based alarm collection is not exposed in the communication layer, I don't think this is available even by a module assigned to a workstation. You might try this, but I don't think UNIT/ALARMS[1] will show an alarm from a module assigned to the Unit, just the UNIT's local alarms.
  
  I'm not 100% sure on this, but hope this helps explain what you are seeing in your tests.

  Andre Dicaire

  • Cancel
• Marino Martinelli

  

  • 17 Dec 2024 7:25 AM

  In reply to Andre Dicaire:

  Hi, thank you for the reply. You are absolutely right, the module can read unit/ALARMS[1].XYZ parameters but they only seem to apply to the alarms of the unit and not the contained modules. I believe the the delay in horn activation is implemented already after the triggering of the horn activation bit. Our biggest problem is how to trigger it. I tried, as you said, making a solution on a workstation and it does seem quite responsive to triggers of alarms within an area. If we go the workstation route it doesn´t seem to want to send the gotten values in the DeltaV operate (.F_NALM and .F_PRI) to the tags in a control module.

  • Cancel