Recent Control & Safety Systems Discussions
Similar Posts
Evaluating Valve/Actuator Performance
Safety Valve and Actuator Proof Test Coverage
Operator Control Moves—Too Many or Too Few?
safety functionality to detect if a manual valve is open or closed
block valve going into hold when in cas
Share

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

18 Replies

  • AdrianOffield
    Do you have limit switches on the valve?

    Depending on what inputs you have coming back from the valve, you could use the difference between crack_timer and crack time (active when DC change of state), if the difference is big then they valve is moving quickly.

    Hope that helps
  • Michael H Burton

    In reply to AdrianOffield:

    Forgot to to include that I do have open and closed limit switches on the valve.
  • Jonas Berge

    In reply to AdrianOffield:

    Is this for control valve?

    An alarm would only tell you the valve is (already) moving too fast, but it is already moving, so it is reactive. Right?

    The DCS controller usually has a rate-of-change limiter on the analog output you can use to limit how fast it tells the control valve to move.
  • AdrianOffield

    In reply to Jonas Berge:

    I believe it is a discrete valve operated via a DC block. However, the op is a little light on details!
  • Andre Dicaire

    In reply to AdrianOffield:

    The red flag I see is that we are wanting to create an alarm because a valve closed too fast. As Jonas points out, the deed is done, so that leaves no time for an operator to do anything about the valve closure speed. But Michael indicates that the fast closing valve can or will result in a "water hammer" effect. There are several things that need to be considered before this is an Alarm:

    Is there an action that the operator must take when this condition occurs?
    Is there time for the Operator to take this action?
    What is the consequence if the action is not taken?

    If we can say yes to the first two, then there needs to be an alarm. If we build the Alarm condition in the DeltaV control Module hosting this valve, will that be the right place to take the Operator when this happens? Or would that distract him from the action he needs to take. maybe this condition should be an interlock to another module that might mitigate the "hammer". Can we automatically take action in seconds rather than create an alarm that does not leave time for action?

    I'm curious to know how this new Alarm will help the Operator. What Priority would you assign this.

    Andre Dicaire

  • Virginijus Vaiciulis

    In reply to Andre Dicaire:

    I might be out of line here, but are we trying to solve instrumentation issue with control system. Like others pointed out, even if you get alarm. It is too late at that point. The valve should be calibrated to close at the designed rate.
  • Michael H Burton

    In reply to Andre Dicaire:

    Andre, I am thinking of using this alarm as a diagnostic tool to flag a valve that might be deviating from the original closing time that it was set at, since there isn’t much the operator can do about it once it is closed.
    For example we currently have these valves set up to close at about 30 seconds. We don’t want it to close any faster than 15 seconds. I was think about a timer to flag it if it closes sooner than say 20-25 seconds, so we can check it out for the cause of the change and correct it before it gets to a point that is could cause a problem.
  • Andre Dicaire

    In reply to Andre Dicaire:

    A quick look at the EDC block and it indicates that the Travel time is initiated on an SP Change.  If the Valve failed without a command to close (Fail closed due to loss of power) then the indication of a fast close time might not be generate.  Then again, may this is only needed on a command to close.  Anyway, using the two limit switches my solution is to use to RET time that is started when the Valve Open switch goes to 0, indicating the valve is closing.  In a CND block, evaluate the elapsed time when the Close confirm switch goes true, and that will set the CND True.  The ResetSet flipflop goes to false when the Close switch is confirmed, stopping the RET timer and holding the CND output to True.  You could also use an NDET instead of the NOT so that the transition of Open Switch to 0 will set the Flip flop and it will remain true until the Close Switch goes true and resets the Flip flop, halting the timer.  The timer is reset to 0 when the Valve is reopened, at which time the Flip flop will remain false until the next closure.

    In this logic, I've used the RET/Time_Duration as my minimum time.  The RET will stop at or beyond the Time Duration value, but we are interested if whether it stops before.  If you want to track the actual travel time the valve normally takes, the EDC block does that already. So we don't need to create a separate limit value parameter for the expression.

    The CND expression looks at the F_IN_D1 which is the confirmed close. 

    '^/EDC1/F_IN_D1.CV' AND ('^/RET1/ELAPSED_TIMER.CV' < 'TIME_DURATION')

    Simplifying this a bit.  If we hold the RET timer reset when the valve is confirmed Open, the RET1/IN_D is also true, but does not increment.  When Open switch goes to 0, RET increments immediately until Closed Switch goes TRUE, and RET holds time. CND block is the same.

    If the IO are defined in the EDC/DC block, you can expose F_IN D as outputs and wire to NOT and RET blocks.  Make sure execution order is correct so CND sees RET timer value in current scan.  

    Sometimes fewer blocks is not as obvious as to how the logic is working.  There are many ways to accomplish this.  

    Andre Dicaire

  • Andre Dicaire

    In reply to Michael H Burton:

    In that case, you could simply use the TRAVEL_TIME in the EDC block, and with the CND expression, set the output true when the close switch goes true but Travel time is less than 25 or 20 seconds. This is not an alarm and more of a device alert. You could log this to the event chronicle, or set a low priority alarm that is auto acknowledged and below the process alarm Threshold so it only shows up on your maintenance Alarm list.

    Even simpler.

    Andre Dicaire

  • Michael H Burton

    In reply to Andre Dicaire:

    Thank you Andre! I will try this when I get back on shift later this week.
  • Andre Dicaire

    In reply to Michael H Burton:

    Michael. I did not Test this, so proceed with caution. You can't trust everything you get from the internet.

    Andre Dicaire

  • John Rezabek

    In reply to Andre Dicaire:

    Andre - the built-in timers in the DC block (looks like you have one there) wouldn't be doing the same?
    It might be worth the investment to get an analog positioner. That way you can more precisely control the closing time. We chose to do this for a big piston actuator that was getting banged up by its solenoid switching on / off.
  • SBPosey

    In reply to Andre Dicaire:

    If tracking valve closure time is not as important during a fail-close event, this is an alternate way (as Andre says, there are many ways to solve this):
    Wire DC1/F_IN_D1 (or the DI that feeds it -- the CLOSED confirm) to a PDE.
    Wire DC1/TRAVEL_TIMER to the DISC_VAL of a CMP block. Configure COMP_VAL1 to 25 (whatever your alarm limit is).
    Wire the PDE and the CMP/LT to an AND gate. The AND gate is the source of the alarm -- will only be active for one scan, but that is enough to alarm.

    Thought process: When the valve BECOMES closed, how long did it take to get there? If less than the limit, then alarm.
    This will not work on a fail-close situation, or in a situation where the valve starts closing from other than the fully open position, but is fairly light on controller resources (execution time/memory) and is fairly easy to understand.

    Like Andre's, this solution has not been tested.
  • Jeffrey Mach
    Andre Dicaire is clearly a much better expert in programming for DeltaV than I am. (Haven't used it, actually.) But, it seems the best solution is to watch the limit switches, as opposed to timing it off of a command. The closer you measure to the actual problem, the better the data.

    Then, you have two options: 1) Create a timer that counts up from when the Open switch indicates the valve is no longer Open to when it positively indicates that it is closed, and alarm if the incremented time is greater than your set limit. 2) Create a delay timer set for the minimum opening time that starts when the valve is no longer Open, and its output will trigger an alarm unless the output is stopped by the Closed switch indication.

    I am not sure which would be easiest in DeltaV. Option 2 shows my Ladder-logic roots.
  • SBPosey

    In reply to Jeffrey Mach:

    Ok, if it is better to base the alarm purely off the confirms, but you still want to avoid the expressions of a CND block:
    Wire OPEN confirm to a NOT gate
    Wire OPEN confirm to OFFD with time duration of 25 sec
    Wire CLOSED confirm, NOT gate, and OFFD to an AND gate
    Alarm based on the AND gate

    Thought process: To get the alarm:
    The valve has to be closed
    The valve can't be open
    The alarm is only good for the first 25 sec of not being open

    If the valve closes in 20 sec, the alarm will come in when the valve closes and stay in alarm for 5 sec (until 25 sec threshold is met). In my thought experiments, this seems to capture a valve closing too fast, is easy to understand, works on failure action, does not activate when closing from a less than fully open position, and is still fairly light on controller resources (3 blocks, the most "expensive" of which is the OFFD). Other than in my head, this is still untested.

This is the official online community site of the Emerson Global Users Exchange, a forum for the free exchange of non-proprietary information among the global user community of all Emerson Automation Solution's products and services. Our goal is to improve the efficiency and use of automation systems and solutions employed at members’ facilities by sharing our knowledge, experiences, and application information.

User Groups | World Areas | Community Guidelines | Legal Information | Privacy Policy | Contact Community Manager

Website translation provided by Website Translator

© 2015-2022 Emerson Global Users Exchange. All rights reserved.