Emerson Exchange 365

• Not Answered

Alarm variable behavior while not enabled

DeltaV 13.3.1.

PCSD ver 13

I have a fan with a DCC expression using the HI_ACT.CV=1 as an interlock. If I disable this alarm in the block driving the HI_ACT will the CV change when it is greater than SP?  Maybe another way to ask the same thing would be: Are the alarm_ACT.CV variables processed regardless if the particular alarm is enabled or not?

Thanks

s_brwn

• 30 Dec 2020 9:16 PM
• Cancel

4 Replies

• Andre Dicaire

  

  • 31 Dec 2020 5:22 PM

  That is a good question. There are several different scenarios possible here, so I did some testing (V14.3.1)
  
  For an Alarm, you can Enable it in configuration, Conditionally Enable it at run time, Shelve it, or Remove from service.
  
  Turns out, the only thing that affects the x_ACT parameter is the Conditional Enable. The _ACT parameter follows the _LIM threshold and goes active when ever the PV exceeds the _LIM. The Alarm can be Enabled or Disabled, suppressed, shelved, removed from service and the _ACT will still transition to 1 when the Alarm condition is present.
  
  However, if you set _ENAB to 0, the corresponding _ACT will remain at 0. For instance, if I use HI_ACT as an interlock and I don't "assign" this alarm in the module, the HI_ACT will still change state according to the HI_LIM and ALARM_HYS values.
  
  The HI_ENAB parameter is only present if you've enabled Conditional Alarming on the source AI or ALM block (or other). When you enable Conditional Alarming, you add additional logic to the alarm processing, including the conditional Enable, Enable Delay, On Delay, Off Delay and Hysteresis for each alarm. The HI_ACT parameter will go to 0 if HI_ENAB is = 0. It will also delay going to 1 as set in HI_ENAB_DELAY.
  
  When you enable Conditional Alarming on a function block, you see these additional alarm related parameters appear in the parameter list. Based on my observations, I would say that conditional alarming inserts itself into the logic that sets the HI_ACT parameter. The Alarm configuration itself occurs based on the state of HI_ACT. The Alarm configuration and behavior is therefor the same with or without conditional alarming, as far as its response to the _ACT parameter. Conditional Alarming conditions the behavior of the _ACT parameter.
  
  So don't confuse Conditional Enable (Module/ALM1/HI_ENAB.CV) with Alarm Enabled (Module/ALARM.ENAB). The HI_ACT parameter will transition to 1 whether or not you create the associated alarm on the module or whether the alarm is enabled or not.

  Andre Dicaire

  • Cancel
• s_brwn

  

  • 31 Dec 2020 5:52 PM

  In reply to Andre Dicaire:

  Makes sense. Thanks a lot for the detailed explanation.

  • Cancel
• Matt Stoner

  

  • 4 Jan 2021 9:37 PM

  In reply to s_brwn:

  One caution of using alarms for control (which ISA 18.2 recommends avoid doing) is that "someone" could do some "tuning" for an alarm limit, hysteresis, delay on/off time, etc. thinking that it will only affect the alarm and change interlock(s) functions not knowing the full effects of the alarm change.

  • Cancel
• Andre Dicaire

  

  • 4 Jan 2021 10:56 PM

  In reply to Matt Stoner:

  Valid point Matt. It is convenient to use the _ACT values as trip initiators for interlocks, and even if the alarm has not been assigned in the module, the related _LIMIT value might still be adjusted as a matter of course, and there is no way to restrict the write locks differently as this same parameter name is used on all alarm enabled blocks. One might want to manage this limit via a CALC block that forces the LIMIT at runtime to the interlock trip value, and use a different Parameter name for Interlock trip values.
  
  I think in this case, the _ACT value appears to be used without the Alarm being present, so it is not "breaking" the ISA 18.2 recommendation.

  Andre Dicaire

  • Cancel