Emerson Exchange 365

Valve Timers to detect when a valve is actuating too quickly

I am looking for a way to set an alarm condition for when a valve is operating too quickly (closing) to avoid a water hammer type condition in a crude oil line. I am familiar with the timing & alarming for a slow acting valve, but not a way to detect a quick acting valve. We are using DeltaV ver 13.3.1

This is for an solenoid operated SDV valve Full Open or closed only using a DC block. We adjust closing speed with restrictor valves on the actuator line. We do have open and closed limit switches on the valve to determine status.

Thanks

Michael H Burton

• 2 Feb 2021 1:56 PM
• Cancel

18 Replies

• Andre Dicaire

  

  • 3 Feb 2021 5:19 PM

  In reply to Jeffrey Mach:

  Jeffery. I agree. You can read the raw input of the EDC/DC blocks via their F_IN_D parameters. Whether you wire the inputs to the block from DI blocks or reference the IO switches directly in the DC Block, you can still read the raw discrete signal states. The internal Travel Timer of the EDC/DC blocks locks in once the state is achieved, so it makes for minimal code to simply confirm the Travel Time when Close switch goes true.
  
  This is not for alarm, detection of a failed actuator is not the point. The EDC/DC blocks would alarm on Loss of Confirm, and the abnormal condition is already reported. No need to be adding additional alarms that might result. So with normal activity being monitored for change in valve closing time, we can use the built in feature so the EDC/DC blocks.
  
  I would consider storing the Travel time value when there is a normal Closing of the valve. You could historize the Travel Timer and use that to evaluate performance. Or you could Log the Travel time upon a Close Confirm. It would then be easy to view all the travel times with a simple filtered view of the EJournal. Use a Log priority on the Alarm and reference the Travel Time value when the valve closes. This would allow you to see change over time and you don't need a trip value. You get all the data and you don't have to use a History Tag license.
  
  In fact, you could create a custom alarm with Log Priority. Link it to the Close Switch. Make sure the Alarm message is linked to show the Travel Time value as %P1 and I think you get all the data in the Ejournal so you can go back and view this performance. No new function block code. If you leave the Alarm message blank with just %P1, the Description2 field would just have the Travel time value. You only need the CND block if you want to add some criteria like value less than x. The alarm would be configured of the CND/OUT_D and only record closing times shorter than x.

  Andre Dicaire

  • Cancel
• Andre Dicaire

  

  • 3 Feb 2021 5:58 PM

  In reply to SBPosey:

  SBPosey brings up a very good point. We need to consider the full behavior of the logic so we don't create unwanted conditions. If we plot the various states of the Inputs and not just the normal values, we can then clearly see when we want to trigger our condition, and when we don't. Like when the valve is partially opened and is commanded to close. And what conditions should clear the value, based on how the system behaves.
  
  Since abnormal closure due to failure is not the end game, we know we can use the EDC Travel timer. To eliminate the "Partial" open scenario, we would want to "Arm" our logic when the Open confirm is reached. Since the travel time stops when Close is confirmed, the value would remain below our trip value. Since we only care about the Travel Time on a normal closure, we can latch the condition until the next normal Open state of the valve. I often add a deadband to CND block logic that latches the condition when the OUT_D goes True, combined with the condition that clears it. So if we say (OPEN_SWITCH <> 1) AND '^/OUT_D') to latch the CND and then OR (Close_switche AND (Travel_Time < Limit)
  
  Once the condition is met on close, the OUT_D goes TRUE. Since the OPEN_Switch is 0, the Latch side of the expression is true. This CND will hold OUT_D True until the valve confirms Open again. So we end up with a TRUE condition only if the valve was open, and closed faster than our threshold, and the value latches. A single CND block gives you the trip condition with "hysteresis".

  Andre Dicaire

  • Cancel
• SBPosey

  

  • 4 Feb 2021 3:00 PM

  In reply to Andre Dicaire:

  A cautionary note. You'll need to make sure not to activate if the valve closes normally, then is commanded to open and it takes a second to lose the CLOSED confirm (you'll meet the [CLOSED switch and (Travel_Time < Limit)] condition, but it is not a valve closed too quickly situation, since the Travel_Time is actually time-to-open at that point).

  • Cancel