• Not Answered

PV_BAD

What is the definition of PV_BAD for an AI module?

PV is out of range?

<4mA  or >20mA?

Hardware failure?

Why is this not defined in deltaV literature?

11 Replies

  • Where did you see this parameter? Can you please provide screen capture?
  • In reply to Lun.Raznik:

    on the analog detail display face plate
  • In reply to Petrisky:

    I'm pretty sure that is from a PCSD class. BTW, the version we had had an error where it was using the OVERRANGE_PCT parameter where the UNDERRANGE_PCT should have been used.
  • in the channel detail, you can find the OVERRANGE and UNDERRANGE which will flag the alarm but not PV_BAD in case signal is out of the range.
    You can change the range and download the channel.

    To make AI flag PV_BAD when out of the range mentioned above, you can either
    1) tick "BAD if limited" in the property of AI block and download
    or
    2) you can enable NAMUR_ENB in the channel detail and download. This option will hold the condition for 4 second before flagging PV_BAD.
  • In reply to Junggyu Yu:

       it seems like people are saying PVBAD_ALM is not a standard Alarm.  however, it is in books online and in an old emerson technical note.  I do not find any definition or trigger for that bit. WHY?

  • In reply to Petrisky:

    PVBAD is included in the standard OOB module templates as well as many other libraries like PCSD. Generally it's tied to the BAD_ACTIVE parameter on a block or the module (which is a rollup of the individual block BAD_ACTIVE's).

    If you look in Books Online, BAD_ACTIVE on a block is "The indication that a block error condition selected in BAD_MASK (at the function block level) is True (Active)...". BAD_MASK controls which bits in BLOCK_ERR trigger the BAD_ACTIVE.

    On an AI block, Out of Service, Input Failure/Bad PV, Simulate Active, and Configuration Error are the selections in BLOCK_ERR. You can search for more details in Books online of course, but the most common on an AI is the "Input Failure/BAD PV" which generally corresponds to a signal significantly outside of the normal 4-20mA range (See "Analog Input function block status handling" article in Books Online for more details. If it's a HART device, a device not communicating will also set the bad status or if the HART device is sending a bad status up from the instrument. Hopefully this helps a bit.

    Thanks,
    Matt
  • In reply to Matt Forbis:

    Yes thank you Matt. very helpful.

    now my question is: Why cant I type in PVBAD_ALM into books online and find out a description similar to yours?
  • In reply to Petrisky:

    The Alarm Name can be anything you want. It just happens to be that in the templates that are included, but many other libraries I have seen will call it something slightly different. Since all alarms behave the same, looking at the parameter it's referencing is where you can dig into the functionality of the control system and if it's a standard parameter, what it does. Since DeltaV is so flexible in it's usage, many libraries will also replace the PVBAD alarm that the out of the box templates with a custom one looking at a condition block that rolls up many pieces into a single alarm bit. In general, books online is more about how DeltaV works vs. documenting the configuration one might have because everyone can accomplish the same thing in many different ways.
  • In reply to Matt Forbis:

    I understand.  however, if there is an out of the box parameter I would like more detail in books online (such as your description above). Out of the box parameters... (especially if they are on the faceplate displays used in reference figures in "books on-line) examples) ......should be described in more detail in books on-line.  

    I really appreciate the help received through Emerson exchange365.

  • This is a good question, because signal status propagation and underlying causes may not be represented in the same way on different configurations.

    The PV_BAD alarm is a custom Alarm created in the Module.  In the OOB templates, the PVBAD_ALM is provided and linked to a specific Function Block's BAD_ACTIVE.  In an AI module it would typically be linked to the AI/BAD_ACTIVE.   In other configurations it can be linked to a different parameter.  

    The Bad_Active parameter is set based on BAD_MASK and BLOCK_ERR.  The Selected bits in the mask determine which bits in the BLOCK_ERR set the BAD ACTIVE

    For an AI, the BLOCK_ERR reports the following:

    - Out Of Service

    - Power Up

    - Readback Failed

    - Memory Failure

    - Output Failure

    - Input Failure/Bad PV

    - Device Fault State Set

    - Local Override

    - Simuate Active

    - Configuration Error

    - Other Error

    The various conditions are for all Function block types and not all conditions apply to the AI block.  The Parameter information for the AI block in BOL indicates the applicable conditions for an AI block:

    The Input Failure/Bad PV status condition is generated by the IO channel status indicates BAD.  

    The IO Channel status is determined by as follows:

    • Signal Wiring Fault -  This produces either a short circuit (> 22.25 mA )or an open circuit (< 0.75 mA)  Functioning transmitters will have their mA output within those limits
    • NAMUR Limits - Enabling NAMUR allows the channel to detect a transmitter "Fault" level signal.  > 21 mA or < 3.6 mA for 6 seconds will set the channel to BAD status.  These limits are not configurable on the channel.  The transmitter is configured to send a high or low signal on sensor fault, depending on the application.  
    • Overrange/Underrangne limits.- These limits set the Limit status of the signal and are at default set to 103 and -3 percent.  They are adjustable.  When the transmitters output signa is saturated, i.e. the process value moves outside the configured range of the transmitter, the signal becomes limited.  This limit should be set within the NAMUR Limits, which are 106.25% and -2.5 %.  A saturated output is not a BAD signal, but it is not an accurate signal.  By setting the limit status on the signal, a PID block will suspend Integral action on a limited status, but will not shed mode to MAN.  
    • HART ERRORS - When HART is enabled, the transmitter provides the HART Status byte to the channel and this can be used to set the channel status.  In SIS, these are ignored by default.  In standard BPCS AI, they are not ignored.  The Unignored status will affect the channel status.

    Signal status therefore starts with the Transmitter.  Is it configured to drive a high or low signal on sensor fault.  If so, the AI channel should have NAMUR enabled to set the status to BAD.  HART ERRORS can also be used, such as PV Fixed, where the transmitter was left in an offline state, with a fixed mA signal.  Also Device Malfunction and Loop Current disparity.  This last one is set when the transmitter is unable to achieve the correct current for the given PV Value, typically due to low supply voltage. .With the Channel set to BAD status, the AI/BLOCK_ERR will have Input Failure/Bad PV set, and this should be masked to BAD_ACTIVE to set the PVBAD alarm.

    The Overrang/Underrange limits will set the Limit Status, but does not set the channel BAD.  The AI Status Opts allow you to elevate this to Uncertain or BAD status.  From their the AI PV and OUT status will pass this to downstream blocks.  Since a limited AI signal is not necessarily a BAD condition, this should be set on a case by case basis.  The process may very well be within the operating range of the sensor, but is outside the calibrated range of the 4-20mA range.  The Limit status will suspend integral action on the PID block.  If elevated to Unscertain, the PID block can then treat Uncertain as BAD, causing the PID to Shed to MAN.  If elevated to BAD, the PID will Shed to MAN, or whatever you configure the options in the PID.

    Note that Namur low limit is 2.5% and Underrange limit is set to -3% default.  To avoid setting the Namur Bad Status, the transmitter should use a low saturation value above -2.5%.  In most cases, the saturation occurs at the upper range limit where NAMUR is set at 106.25%.  If you enable NAMUR and you wish to use the Overrange/.Underrange limits, you must also make sure the transmitter's signal is configured to stay within Namur limits for Saturation and to go beyond Namur on Upscale or Downscale fault condition.  

    Many users rely simply on the overrange limits for signal status so that they can configure the trip points on the DeltaV channel.  This is fine if you do not need to differentiate between signal saturation and signal Fault condition.  You can set the limits for one or the other and adjust the AI block Status options to use BAD on limit.  

    I am not sure if the BLOCL_ERR will have Input Failure/BAD PV based on the Limit Status of the signal if the Status Option is set to use BAD if Limited.  This may just be a signal status option and to set the PVBAD alarm, one would need to use a condition block to read PV.ST = BAD,  The Short and open circuit conditions will always set Input Failure/Bad PV and if masked to BAD ACTIVE, it will be True.  

    I believe that if you do not ignore PV Saturated in HART ERRORS, this would set the channel BAD and this would propagate through BLOCK_ERR to BAD_ACTIVE.  Using a calibration source, one would provide a process reference beyond the transmitter's calibrated range to observe the HART status for PV Saturated and the resulting Channel status, and consequently the BLOCK_ERR in the AI block of the module, with Namur disabled, and Over/under range set beyond the incoming mA signal.  Then ignore this HART Error and  observe the BLOCK ERR to confirm the status is not set.  Then configure the Over/Under range limits to indicate limited status, and there should not be an Input Failure/Bad PV set.  Then finally enable the status option to use BAD if Limited.  That will confirm if the Over/Under range settings will set BAD ACTIVE on the AI block.  

    Andre Dicaire

  • In reply to Petrisky:

    I don't know the reason but it seems that Emerson doesn't fix the way to detect device failures. So users should have clear idea about how to range the error and how to flag the alarms. Even GSC didn't have the clear answer about 4 second delay when NAMUR_ENB is enabled. Because the 4 second delay is not in line with my company's standard for condition handling, I decided to use OVERRANGE, UNDERRANGE and "BAD if limited" to flag BAD_PV.