Does it makes sense that the DC block can trip when already commanded to passive

I was surprised by a pump indicating shutdown/interlocked (using DC blocks) when the setpoint and output were already set to the passive states. This did not make sense to me as the interlock can't accomplish anything more than is already being accomplished except preventing the output from being set to an active state if the setpoint changed. 

The specific scenario is needing to block flow before stopping the pump to prevent backflow, but interlocking the pump off if the valve used to block flow is closed and the pump is running deadheaded for too long.

I realize the DC block has likely always worked like this, but I can't seem to understand why it should work that way. I'm just curious if there is some rationale or use case that explains why it works this way. I find knowing the history of things makes me more effective at applying.

18 Replies

  • If I understood the scenario correctly - To me at first I see ,it's for the pump- it now must not to be started if the valve is closed. Needless to say, the general sequence of operation of these two devices is to open the valve first and then the pump. Of course this condition might also be configured as permissive though. I am curious for other perspectives or reasoning :)
  • In reply to HumairaF:

    I really hoped or would know the history. Love their stories!
  • In reply to Brian Hrankowsky:

    Don't we all. And just wait until you hear their stories in person! Slight smile

    Best Regards,

    Rachelle McWright: Business Development Manager, Dynamic Simulation: U.S. Gulf Coast

  • In reply to Rachelle McWright:

    which one are you implying is which?!!!
  • In reply to Brian Hrankowsky:

    I'm the tall one...

    Will reply when back on a computer and not on a phone

  • In reply to Matt Stoner:

    I'm the good looking one....

    Brian, I set up a quick DC block with Interlock option enabled in Device Opt. When DC is at Active1, and Interlock goes to 0, FAIL shows Shutdown/Interlocked as expected. SP and OUT go to passive and MODE goes to AUTO/LocalOverride. All as expected.

    When I clear the interlock (set equal to 1), FAIL goes to CLEAR and DC stays in passive state. as expected.

    But if I set INTERLOCK_D to 0, the FAIL stays at CLEAR. It does not go to Shutdown/Interlocked.

    I see the same thing with Shutdown. If DC is active, SHUTDOWN = 1 sets FAIL = Shutdown/Interlocked and Mode.Actual to LO. But if SP_D and OUT_D are passive, FAIL remains CLEAR but Mode.Actual goes to LO.

    The FAIL value will hold the Fail cause until condition clears, but Shutdown_D and Interlock_D have no effect on FAIL state while SP_D is passive.

    Is it possible the SP_D was not Passive when the interlock occurred?

    I'm on a v14.LTS release.

    Andre Dicaire

  • In reply to Andre Dicaire:

    Hi Andre,

    The way our module is designed, the DC block is always in cascade and we use the cascade input (wired from a calc block).

    The interlock condition has a few seconds delay to allow us to command the motor to stop from a phase before the interlock trips.

    The motor has a VFD and the VFD stop was configured for a ramped stop. the deceleration rate selected was slow (on the order of 7 seconds to go from the normal speed down to 0).

    What I swear I saw was the DC block get to stopping, a few seconds later the interlock timed out, the DC block then indicated shutdown/interlocked, then the VFD finally turned off the run status feedback - but by then it was too late and we have the interlock alarm.

    I am very confident the DC block was executing the passive command (output was stop) before the interlock condition timed out and tripped.

    I am also on 14.LTS

  • In reply to Andre Dicaire:

    Trying to keep my answers shorter, so I split them in two posts.  Clever no?

    Actually, there's no history to add here as it looks like the DC works as it always did.  There are a lot of options for the DC block on how it can be configured to drive its outputs but there must be an explanation for your observation.  

    Here's a before and after shot of DC block while in passive state and Interlock goes to 0:

    The FAIL parameter is shown as an output and remains set to CLEAR.

    Your scenario states that you interlock the PUMP to the state of an OUTFLOW Block Valve, so that the PUMP stops if the valve is closed, to prevent deadheading the PUMP, but the PUMP still deadheads for too long, i.e. it takes too long for the pump to stop.  Is that still an issue?

    This sounds like a process design issue.  Is the block valve there to serve the PUMP and prevent back flow or is it used to block flow to downstream process?  If it is for the later, shouldn't you normally stop the pump first and interlock the block valve to close at the appropriate time so that back flow is prevented without deadheading the Pump?  Interlocking Pump to the block valve is still required incase it is closed inappropriately, but normal operation should sequence the two.  

    Andre Dicaire

  • In reply to Brian Hrankowsky:

    When I tested, I was not using CAS mode for SP_D manipulation. The interlock is occuring as the motor is ramping down. Does the PV_D go to Passive confirmed immediately or does it wait for the motor to stop turning?


    I'll take a look at how the FAIL behaves when the DC is transitioning to PASSIVE at the time of the INTERLOCK.

    One work around is to included the state of OUT_D in the interlock, but not the permissive.

    Andre Dicaire

  • In reply to Andre Dicaire:

    Confirmed that if the interlock_D goes to 0 while the PV_D has not reached confirmed Passive, the DC FAIL will indicate Shutdown Interlock, even if the SP_D and the OUT parameters are passive.

    I added an Off delay on my DC feedback so that I could interlock the DC before the PV_D achieved Passive confirmed. If your DC feedback remains in the "Active" state as it ramps down, that would explain the behavior.

    Andre Dicaire

  • In reply to Andre Dicaire:

    this thread is going to be interesting to keep track of ....

    I didn't mean to imply that I thought the DC got broken or changed in. really i'm just curious why it behaves the way we were seeing it.

    It might help to know that our module design and use of the DC really hasn't changed since the late '90's.

    we don't see any issues with getting shutdown/interlock statuses as interlocks come and go while we're in the passive command and state. (if we'd had that problem for the last 20 years , it would be fairly embarrassing)

    yes. the pump takes a long time to stop and it appears while it is stopping, if an interlock trips, we are seeing the shutdown/interlock status.

    Unfortunately in pharama batch processes with GIPSM design considerations, there are some chicken and egg scenarios that crop up: can't stop the pump first or get backflow and suck material back up a diptube, can't close the inlet or cavitate, can't close the outlet or deadhead.
  • In reply to Andre Dicaire:

    The VFD was not indicating stopped until it had finished its ramp down. We changed the stop type to a coast stop - which does drop the run status when the start contact is de-energized. which made the issue disappear because it indicated stopped before the interlock timeout.
  • In reply to Andre Dicaire:

    yep - that's what I see. ultimately I'm just curious why it works that way. because it doesn't seem intuitive. I'm hoping there is some insight I am just missing that i can learn from it.
  • In reply to Brian Hrankowsky:

    The Interlock and Shutdown functions are tied to the State of the field device which is determined by the PV_D and whether it is confirmed passive or not. Once it reaches confirmed Passive, we don't care about Shutdown or Interlock. But, as you ask, if the OUT_D and the SP_D are already at Passive, and the Interlock would have no additional impact, why does the PV_D state matter?

    I can't answer that. What I know is that if the Interlock was ignored before PV_D reached Confirm Passive State, someone would want the FAIL to reflect that, and we'd be stuck . In your case, you are able to address the duration of the transition time and reach Confirmed passive before the interlock. Or one could add more conditioning logic to the Interlock condition to control when the interlock is valid or not.

    It was good to understand this nuanced behavior during the transition to Passive. An like GI Joe says, knowing is half the battle.

    Andre Dicaire

  • In reply to Andre Dicaire:

    Thanks! Oh how I'd like to see under the hood of the DC block. GO JOE