• Not Answered

PVbad start heater

Hi

I have temperature transmitter response to start and stop the heater when the temperature below 25C the heater start and above heater stop, during the test we find that when the charm has PVBAD the heater also go to start because when PVBAD the value became -27 so that means as the condition it below 25C so heater go to start, could please advise how to solve this issue and prevent the heater from starting when PVbad comes.

3 Replies

  • Hi, probably is much efecttive use a extra condition like PV.ST = GOOD or PV.ST ≠ BAD so first is see if valid PV and then interrogate by temperature condition for you proccess. You can use a CALC block.
  • In reply to Luis Paredes:

    Fundamentally, Luis is correct that Status should be evaluated before taking action on a signal. You did not indicate what type of CHARM/signal you are using, but an open circuit on a TC, RTD or a 4-20 mA will all set Bad Status on the IO channel. This is reflected in the Module via the Block_Err, and on the .ST of the PV and the OUT parameters. And of course, if you have configured a BADPV alarm via the BAD_ACTIVE.

    many function blocks in DeltaV evaluate .ST before taking action. PID block will shed to MAN or suspend Integral action based on Status of PV value.

    For CND Blocks the Abort on Read Error can be enabled, which will suspend the block's logic if the referenced values are Bad Status. You then have to decide if you need to take a separate action when PV goes BAD. In your case, the Heater should stop, or not start on a bad status.

    Since a Bad Status does not tell you what the process conditions are, you might choose to delay an action on a Bad Status. When the Bad status occurred, the process was in a known state that did not warrant an action. Given the process time constants, how long could it continue to operate before it could be an issue. that is, if the heater was left running for 10 seconds or 1 minute after a bad status would that be a problem? Putting a reasonable delay on this abnormal trip condition might prevent a spurious trip from an intermittent, temporary condition.

    Anyway, Status is there to help you build a robust strategy. Error handling is always the most complicated aspect of configuring the system. All these "what if" conditions can take time to evaluate and resolve. Status helps in that your data is validated at the channel before your logic reads it. If it is BAD, you don't have to evaluate all the ways it might be bad. You just handle it as Bad.

    Andre Dicaire

  • In reply to Andre Dicaire:

    Thanks Andre for the detailed explanation about CND block. In my simulation, CND didn't trigger for bad status unless we configure to check PV status(ST) along with PV value (CV) in the CND block. Is the Abort on Read Error only for the communication errors? Thanks.

    Ravi