Is placing PID block in "Bypass" bumpless?

I have a PID block configured to serve as a cascade "master" of sorts - I was attempting to manipulate a flow from a vendor skid. But they in turn have a flow loop configured (anyhow). The two loops are too close in dynamics, so I want to put our DeltaV PID block in "Bypass" (which I have enabled in control_opts).

The loop has been run in MAN for some weeks now . . . when I invoke "bypass" mode, will "manual" mode work as always (operator sets output independent of PV), and then when I switch to AUTO or CAS, the setpoint will be "translated" to 0-100% of the PV scale and applied to the output (right?). Will there be a "bump" in the output, and if so how might one ensure it is minimal?

Thanks,

John

  • Hey John,
    The BYPASS feature works very well. It will transistion bumplessly in the example you describe since a manual output will create the proper setpoint which will be tracked by a master loop via BKCAL_OUT of the bypassed loop. You might take a look at SP limits to make sure they won't cause a restriction as percent of scale. Be aware that the BYPASS feature even takes into account the controller action to keep the correct action of the master loop if the slave loop is bypassed. This might mean that a SP_HI_LIMIT is the low limit on the output! You might check this out.
    Hope this helps!
    James
  • The bypass functionality is analogous to what is known as PRD (primary direct) in other spaces. One of the restrictions of the DeltaV (not elsewhere) is that you have to be OOS or MAN to allow the BYPASS to be set to true. This is a similar requirement to the FF_GAIN, and it is a pain, to be honest. It would be nice if the BYPASS function was by default available in all modes of operation. So, I have created a drop-in composite for a slave loop which allows for the BYPASS to be switched on and off in any modes (as well as a FF gain correction block). The nice part of it is that when you have 1/2/3 element concepts, there is no need for two master PID blocks as the slave is always the same route to the valve. There is a trick to getting this right to ensure initialization occurs correctly on each state change. Just putting the comment out for the DeltaV developers: some deficiencies in the system can be addressed and should be.
  • In reply to Paul Hughes:

    Excellent points by Paul! Opportunities for improvement to DeltaV!

    FYI, you can programmatically (or in Control Studio On-Line) turn FF off, change the FF_GAIN, and then turn it back on, all while in an Automatic mode.
  • In reply to James Beall:

    James - works as you describe, thanks.
    John
  • In reply to James Beall:

    Based on a direct question on the topic of "turning off" feed forward, I will clarify. This is done by changing the PID/FF_ENABLE parameter to False to turn off feed forward and True to turn it on.
  • In reply to James Beall:

    Hi James,
    the first post here is a while ago but the good of the internet is, it forget never :-)

    I think about to create a AO Composite and use a PID permanently in BYPASS similar as an AO-FB to build an AO Class module which then can be a software AO or a hardwired AO.
    I don't like libraries which become an own project after a while with hundreds of similar class modules!
    That's why generic simple class modules are my favorite.

    The PID/IO_OUT don't need to configure to a DST while an AO must have a reference to a DST to avoid module output errors.
    My question is, do all the SP_HI/LO_LIM and SP_RATE_UP/DN work also to the IO_OUT if the PID is in Bypass?
    I just try on a DV14 Simulate, but can't see any IO-Values if the module is assigned to the ProPlus.
    Also from the Ctrl-Load perspective a ready PID FB need less load than a manual frickeld AO composites with the same functions.
    Best Regards,
    Michael