Emerson Exchange 365

• Not Answered

conditional alarming question

Very simple conditional alarming case regarding PCSD V12 S_AI_120 Templet -

I want to conditionally disable the Lo Amps alarm when an external pump is STOPPED,and conversely enable the alarm if the pump is RUNNING.
Also - When monitoring in Operate/runtime I prefer to see the alarm 'conditionally disabled', and not merely turned off/disabled.

Should I be targeting enable/disable at '/LO_ALM.ENAB' or at '/AI1/LO_ENAB.CV'?

IF '//HS-123/PV_D' = '_MTR2_PV:STOPPED' THEN
'/LO_ALM.ENAB' := 0
ENDIF;
IF '//HS-123/PV_D' != '_MTR2_PV:STOPPED' THEN
'/LO_ALM.ENAB' := 1
ENDIF;

And, is this leaner/preferred?

IF '//HS-123/PV_D' = '_MTR2_PV:STOPPED' THEN
'/LO_ALM.ENAB' := 0
ELSE
'/LO_ALM.ENAB' := 1
ENDIF;

Recommendations are appreciated

Regards

• alarming
• conditional

SimHogan

• 18 Jun 2018 3:14 PM
• Cancel

9 Replies

• Matt Forbis

  

  • 18 Jun 2018 3:25 PM

  Writing to AI1/LO_ENAB will allow you to see the Conditionally Disabled text and would be the preferred way. As to how to write the condition, the second is generally what I would recommend as better. It requires only one conditional compare instead of two, so less loading. If you want to make it even more efficient, you could simplify it as '/AI1/LO_ENAB.CV' := ('//HS-123/PV_D.CV' != '_MTR2_PV:STOPPED');

  • Cancel
• Matt Stoner

  

  • 18 Jun 2018 3:30 PM

  In your example you should be using the AI1/LO_ENAB.CV parameter. This is the conditional alarm Enable/Disable while the LO_ALM.ENAB is the Alarm Enable/Disable of the "LO_ALM" itself.
  
  I would suggest just using this logic for your expression:
  '/AI1/LO_ENAB.CV' := ('//HS-123/PV_D' = '_MTR2_PV:RUNNING');
  
  You may also have to add time delay to the conditional enable by setting the AI1/LO_ENAB_DELAY to a non-zero number (i.e. after the pump starts there is a "x" sec delay before the alarm is enabled)
  
  If you don't have the AI1/LO_ENAB and AI1/LO_ENAB_DELAY parameters you need to enable conditional alarming by right clicking on the AI1 block, select "Assign Alarm" and then check the box for "Conditional alarming for all alarms".

  • Cancel
• Michael Krispin

  

  • 18 Jun 2018 3:49 PM

  Hi Sim,
  first off all, you should learn about the differences between trip and alarm. Many people mix this and even in DeltaV it is not correct described.
  You generate always first a trip and depending on this signal you can also configure a link of an alarm on that trip.
  The trip will be used further for the interlocks to somewhere else. I suggest to use always this parameter instead of checking on the alarm for interlock.
  Even you may not need an alarm but only the trip for some other trigger ( HI-LO Level of a sump pump switch on / off the pump without alarm and only HIHI would maybe need to alarm too if your pump don't suck enough)
  I.e your AI-FB (or ALM-FB/PID-FB etc.) has the LO_LIM and the LO_ACT for a lo trip. If your PV is below LO_LIM then LO_ACT becomes true.
  LO_ACT is your trip point!
  An additional alarm can be configured and linked to that trip point, i.e. you get a LO_ALM alarm and link to the AI1-FB.
  You can enable conditional alarming (which is false here in DeltaV naming) but this activates the conditional trip in the AI-FB. Here is an individual LO_ENAB, LO_ON_DELAY, LO_OFF_DELAY and LO_ENAB_DELAY as extended parameters in your AI-FB.
  If you enable conditional alarming it create automatic the alarm and put the LO_ACT as link-field and LO_LIM also into this new alarm
  
  In your case you need to enable the AI1/LO_ENAB input. Connect a condition block and link out_d to the AI1/LO_ENAB.
  
  For LO current it is gut to set an ENAB_ON_DELAY for some seconds, so that the motor get time to come on the right current before the trip become active.
  Additional the LO_ON_DELAY can be used if the current can become LO for a short while (seconds i.e Motor runs free)
  
  The most lean expression for the CND-FB would be '//HS-123/PV_D' != '_MTR2_PV:STOPPED'
  or in an action/calc-expression '^/AI1/LO_ENAB' := '//HS-123/PV_D' != '_MTR2_PV:STOPPED';
  This save the extra IF condition and an internal jump (microscopic in the pseudo code of the expression) You can check also how many bytes the different approaches need.
  Best Regards
  Michael

  • Cancel
• John Rezabek

  

  • 18 Jun 2018 3:49 PM

  I haven't used the PCSD template so maybe my concern is addressed. We have gotten away from changing the ENAB bit dynamically (or manually) since it is not easy to get a listing of all disabled alarms (in our case the list would be vast). We use "disable" for rationalized "alarms" that were configured but determined to be "no alarm" or redundant. We eliminated thousands.
  
  In lieu of this perhaps the OPSUP or OOS bits would offer the operator a mechnism to review them on a prebuilt summary. (AlmSupp,grf)

  • Cancel
• SimHogan

  

  • 18 Jun 2018 4:13 PM

  Thanks everybody!
  I have my example up and testing out OK on my Simulate platform.
  
  Best Regards
  Sim

  • Cancel
• SimHogan

  

  • 18 Jun 2018 5:34 PM

  In reply to Michael Krispin:

  Hello Michael -
  Thanks for the in-depth explanation. I prefer to have Alarm enable/disable separate from (trip) interlock logic enable/disable. I use thresholds for trips for interlocks, instead of alarm limits, and configure corresponding alarms as needed. My question - if using LO_ACT as a trip, does disabling the alarm disable the LO_ACT ?
  
  Best Regards

  • Cancel
• Michael Krispin

  

  • 18 Jun 2018 5:47 PM

  In reply to SimHogan:

  Hello Sim,
  No, the alarm read only the AI1/LO_ACT parameter. LO_ALM.ENAB en/disable only the alarm itself.
  Only AI1/LO_ENAB = False disable the LO_ACT with conditional "alarming" and further the LO_ALM, because the AI1/LO_ACT can not become True if disabled and so the LO_ALM also not.
  Best Regards
  Michael

  • Cancel
• Gareld Butler

  

  • 18 Jun 2018 6:13 PM

  In reply to SimHogan:

  Hi Sim,
  Thresholds use a different block than the alarms do. You can do the same with thresholds by putting a condition on the THRESHOLDS/TH_ENAB parameter.

  Gareld Butler

  • Cancel
• johndaulton

  

  • 31 Jul 2019 1:58 PM

  In reply to John Rezabek:

  John, you mention that you have gotten away from changing the ENAB bit dynamically. Do you mean disabling the alarm altogether or conditional alarming? We are starting to apply conditional alarming, which helps with alarms, but makes alarm testing much more difficult. Any thoughts?
  If you do not apply conditional alarming, how do you handle alarms that might not apply for a specific plant state?

  • Cancel