Emerson Exchange 365

Hooter_ACK_FB

Dear Expert

As per client requirement DV Exp. control modules generated alarm are only registered in the alarm list and make the Horn disable in alarm banner.We have created one control module in DV Exp. exclusively for alarm purposes.We are making logic in control studio with 50 nos. alarm HH PV and we also generate DO block output high . An external hooter is connected with DeltaV control panel.Hooter is working fine as per logic but we can not acknowledge this hooter from DV operate.We need a hooter Ack. function block in control studio for making high bit low in DO block and making this hooter ack. FB link with DV operate .How we can execute this requirement please suggest.

krishna sen

• 23 Aug 2020 3:45 AM
• Cancel

4 Replies

• Lun.Raznik

  

  • 24 Aug 2020 4:51 AM

  Is there a 1:1 relationship between Hooter and the alarm? Or can you use the speaker as the hooter?

  • Cancel
• krishna sen

  

  • 24 Aug 2020 1:14 PM

  Very sorry for late response.yes, there is a 1: 1 relationship between hooter and the alarm.we disable the speaker/horn in DV operate and only required parameters alarm will be generated through control module logic( though DO out bit make high) and acknowledge it through DV operate.

  
  

  • Cancel
• krishna sen

  

  • 26 Aug 2020 2:48 PM

  Please suggest how can I acknowledge hooter from deltaV operate.

  
  

  • Cancel
• Andre Dicaire

  

  • 26 Aug 2020 3:20 PM

  In reply to krishna sen:

  The Console horn is independent of individual alarms. The Horn is triggered by any alarm configured to do so. When the user acknowledges the Horn, the state of the alarm does not change and typically would remain in its Active/Unacknowledged state.
  
  If you've created a dedicated Horn Output signal that is tied to a specific alarm, and the logic is entirely based on the information in the controller, i.e. the alarm state, then you will be triggering the horn when the alarm activates, but there is no Horn Acknowledge to work with.
  
  Each Workstation has a /HORN parameter, which is set to a number corresponding to the priority of the Alarm that triggers the horn. When the Operator Acknowledges the Horn, this value is reset to 0. Any alarm that occurs on the console that triggers the Horn, sets this parameter. An External Horn can be controlled by reading this parameter from one or more consoles and this gives you the ability to drive a Horn and acknowledge it from the consoles in normal fashion. Your logic in the external Horn module can use timers to drive different Horn sequences to reflect the priority of the alarm. Or you can set the threshold so the external Horn only sounds for alarms of certain priority.
  
  In the case of your specific Horn for this one alarm, you need to decide how your want this acknowledged. You can add an Horn acknowledge parameter in you module and modify the Alarm Banner Horn Acknowledge button to write to this parameter when the Horn button is pressed. This will be independent of the /HORN parameter of the console. Then, in your module make sure that you use oneshot logic to set and reset the Horn state.
  
  That is, to set the Horn On, monitor the Alarm NALM parameter which is set true and remains true until the alarm is acknowledged. Use this to drive a PDET that sets the state of the alarm ON. separately monitor your Acknowledge bit and when it is turned on, use a PDET to reset the Horn state to OFF. Also reset the Acknowledge Bit to 0 so that the next time the horn acknowledge is set to one, it forces a positive change. A Flip Flop block works well with PDET blocks to set and reset the output based on these two events.

  Andre Dicaire

  • Cancel