• Not Answered

Area Alarms

I am trying to access alarms associated with an area to drive an output and i am having trouble. I would like to identify if there is an unacknowledged alarm of a certain priority to drive an area horn. I would preferably like to monitor this in a controller to control the module. I have found in books online that there are area alarm parameter fields but have not had success accessing them in the controller or in graphics. 

Daniel Moyers

• 20 May 2025 6:17 PM
• Cancel

7 Replies

• KeithStThomas

  

  • 20 May 2025 10:47 PM

  Hey Daniel,
  We have done this using the HORN parameter of a specific workstation, WORKSTATION/HORN, where WORKSTATION is replaced with your operator station node name. HORN is normally 0 when there are no alarms but will change to the highest priority alarm value requesting the workstation alarm horn to sound. Externally reference this parameter into a module (type it manually though as it cannot be browsed to), compare if it matches or exceeds the alarm priority of your choosing, and drive an output for an external horn.
  
  This will only work if only the area of interest is assigned to the workstation. If more areas are assigned, then alarm(s) from any area that meets the test threshold will trigger the output.

  • Cancel
• Andre Dicaire

  

  • 21 May 2025 2:34 PM

  As Keith points out each console has the Horn parameter that you can reference from a controller module. It follows the horn settings of the workstation, which is driven by the Alarm system on that workstation, which depend on the assigned Plant Areas and current Logged on User. The intent of this parameter is to allow an external horn for each console.
  
  Consider monitoring the HORN parameter of several consoles in a given Control room. Since these consoles would participate in global horn acknowledge, and serve the same process area, you would have greater robustness in your solution and not dependent on a single workstation/logon. Also consider if a delay is warranted so that when an operator is at the console, and acknowledges the horn, the external horn need not sound. A Condition block with its delay timer will accomplish this, with flexibility to tune the delay as desired.
  
  Understand that each console has an alarm system that receives and sorts alarms into the various alarm lists based on assigned areas. The overall list drives the Alarm Banner as well. The Horn is set whenever there is a new alarm and is not directly associated with a given alarm. Controllers do not have access to this sorted alarm list and can only view alarms directly in the modules. That is because the alarm system is a workstation tool for the operator.
  
  Note that the Horn parameter does not generate any Event records and is meant to be read from modules. Using a script in the console to push alarm information to a module will result in a User Change event in the Ejournal. If you wanted to drive a value based on Units, be sure this is on an exception basis so you are not generating these change events except on demand. If /HORN works, use that.

  Andre Dicaire

  • Cancel
• Daniel Moyers

  

  • 21 May 2025 3:51 PM

  In reply to Andre Dicaire:

  Does the filter of the alarm list have an effect on this horn parameter?

  • Cancel
• KeithStThomas

  

  • 21 May 2025 6:41 PM

  In reply to Daniel Moyers:

  Yes. Basically, if an alarm is going to sound the station speaker horn, the HORN parameter will be something other than 0. If the station has rights to the area, and the user has rights to the area, and alarm area filtering is check marked to allow alarming, then the HORN will work.

  • Cancel
• Matt Stoner

  

  • 27 May 2025 7:47 PM

  In reply to KeithStThomas:

  Another method in Live is to just check individual areas un-acknowledged alarm count using DLSYS['THISUSER/AREAUNACKCNTSEQ[' + # + '].CV'] where # is the area number (AREA_A is 0 by default). This all depends on what is wanted or needed for the external Horn. In the latest case I've had there was multiple workstations that had all kinds of different areas assigned and it couldn't just be done off the HORN of a workstation so we had to check if areas had unacknowledged alarms in that area to trigger them.
  
  You just need to ensure the priorities are set properly as you could have a priority you don't want to fire the HORN active and un-acknowledged while one you do want and it's lower and it won't fire your output properly using the HORN. All your priorities that will fire the output should be highest priorities and no priority in between that you don't want to fire the area horn.

  • Cancel
• chrisslattery

  

  • 21 Jul 2025 5:43 AM

  Related to this, is there a way to silence the horn from module logic rather than a workstation. e.g. pressing a field button to silence the horn. I know you can write to specific alarms to acknowledge them, but this doesn't seem to be possible for all alarms in a specific area or workstation. Writing to the horn parameter is also not permitted.

  • Cancel
• Andre Dicaire

  

  • 21 Jul 2025 2:53 PM

  In reply to chrisslattery:

  See Keith's first post. Horn =0 normally. Try writing to Workstation/Horn.cv = 0. Set up an External Reference parameter to a Workstation HORN that is participating in global horn acknowledge. That either works or doesn't.
  
  If that does not work set up a Boolean variable in your alarm banner with OnWrite and animate this to a module Boolean parameter. In the OnWrite script, write Horn = 0 and reset the module parameter to false. This will record a change event in the Ejournal showing the remote field button was used to acknowledge the horn. If you don't want that message, then set the Boolean in the module to be a pulse (on off timer) and have the OnWrite script set the HORN to false and the Display variable to match the module. When the pulse goes to false, have the script simply return that to the Variable. No write to the module and therefore no message in the event chronicle.
  
  OnWrite enabled variables will execute the script as long as the variable is not equal to the source. The script must return the value to pass to the variable, which is usually the value of the source.

  Andre Dicaire

  • Cancel