Emerson Exchange 365

• Not Answered

DeltaV Diagnostics - can one suppress "bad quality" flags?

Anyone know a way to suppress or disable lingering "bad quality" (yellow "?") flags in DeltaV Diagnnostics? Since the smallest malfunction e.g. instrument air is shut off to a positioner, rolls up and flags an entire controller bad, I am looking for how one "acknowledges" such an indication and perhaps "disables" or "suppresses" it so that ensuing malfunctions are more readily indicated . . .

• diagnostics

John Rezabek

• 12 Sep 2018 1:18 PM
• Cancel

5 Replies

• doug bray

  

  • 12 Sep 2018 2:29 PM

  We would love to know how to do this as well. We asked our Emerson LBP how to do it with no success. We would also love to be able to disable the alerts on some instruments so our event log does not fill up with messages about things we know are "bad" but most likely are just not running.

  • Cancel
• Lou Heavner

  

  • 12 Sep 2018 3:42 PM

  If the bad status is being propagated from a different block (forward propagation) or BKCAL, then you might be able to intercept the status and change it in a CALC block. For BKCAL, it literally is an interception, as the BKCAL goes into the block and the revised BKCAL comes out. For something like an AI block, you can bring it into a SCALER block and use a CALC block or CND and ACT blocks to change the status leaving the SCALER block.

  • Cancel
• Andre Dicaire

  

  • 13 Sep 2018 2:47 PM

  John, I just posted on another thread about the Condition Summary. Basically, the status flags in Diagnostic are status, and as such cannot be suppressed. However, the Hardware alerts for a node are set by these conditions, and the conditions can be suppressed. The Alarm Banner uses the Hardware Alerts to report bad integrity, and the Hardware Alarm Summary shows all nodes with a hardware condition set. You can launch the Condition Summary from Diagnostics, the hardware Alarm summary or the Node Faceplate. There you can view the conditions sorted by Alert and suppress those that are of no value. This allows new conditions to set the alarm.
  
  Using the Alarms[1] parameter for the node, you can set color expressions on displays to indicate the presence of abnormal conditions, and suppressed conditions will not light these flags. The OINTEG and other status conditions are fixed and always shown in Diagnostics.
  
  The Hardware Alerts bridge the status to manageable alerts.

  Andre Dicaire

  • Cancel
• John Rezabek

  

  • 13 Sep 2018 3:45 PM

  In reply to Andre Dicaire:

  I found the Condition Summary - first time I've looked at it in 20 years of using DeltaV (did not know it was there). Although I have a number of yellow "?" - e.g. a fieldbus device that is "not attached" waiting on the technician to replace it, as well as the associated modules that are "bad" because the device is bad. I don't see any of these faults displayed in the Condition Summary. Both fields are blank for all controllers. So it would appear the scope of the condition summary does not include all conditions that roll up to node integrity - correct? What sort of problems would I see here?

  • Cancel
• Andre Dicaire

  

  • 13 Sep 2018 4:08 PM

  In reply to John Rezabek:

  John,
  
  I didn't say it was perfect.... When it comes to fieldbus devices, they have separate device alerts.
  
  My point is that the yellow status icons in Diagnostics and DeltaV Explorer are hardcoded as a crumb trail to any and all abnormal status. The Hardware and Device alerts provide managed reporting of abnormal conditions.
  
  I understand that being able to mask/suppress low level bad Status would clean up diagnostics and make new conditions visible. I think I'd like that too. But the mechanism for managed reporting of conditions is through the alerts, right or wrong. One thing I would like to see is that DeltaV Explorer should use the Hardware Alert instead of OINTEG as a flag to report issues. That would allow Explorer to show meaningful new conditions rather than an integrity fault for something that cannot be addressed, or is considered normal for the process conditions.
  
  This might be something to present to the UDEP as an enhancement.

  Andre Dicaire

  • Cancel