In reply to JDWheelis:

I suspected as much.

I appreciate Douglas' advice about a discrete valve or a solenoid in the air line. I had thought of it and the discrete valve would definitely be preferred, but is a costly modification. I will offer some possible solutions and see what our Process Engineer thinks about it. Thank you

In reply to JDWheelis:

What we have done when we need this functionality is to have the OUT_LO_LIM wired from a Transfer (XFR) block. IN_1 is the normal OUT_LO_LIM. IN_2 is "0". Wire the same signal that you have wired to TRK_IN_D to the Transfer Block's SELECTOR parameter. In normal operation, the normal OUT_LO_LIM applies. When TRK_IN_D becomes true, OUT_LO_LIM is set to 0. When TRK_IN_D_ becomes false again, OUT_LO_LIM returns to the normal value.

In reply to SBPosey:

Great idea! Like the screenshot above?

In reply to SBPosey:

Looks good. clean solution

In reply to vitthalrathod:

There are many ways to solve this issue, each introduce other possible unintended consequences. Wiring to the OUT_LO_LIM means you can no longer tune the parameter normally.

Some other thoughts would be to add the transfer block after the PID on the Out connection to the AO/CAS_IN. The PID would track to 10%, but the AO would be forced to 0% directly. This would leave the OUT_LO_LIM unchanged and tunable to desired low limit.

Note that the PID can be set to not be limited in MAN. Shedding the PID Target mode to MAN would allow the Track IN to drive to 0% out. Again, this allows the OUT_LO_LIM to remain tunable as always. But an operator would then be able to close the valve in manual. Changing mode could impact the current SP if SP tracks PV in MAN is enabled. You have to think about what the Mode and SP should do when you come out of the track condition.

A CALC expression could capture the current Lim value, set value to 0 and restore the previous value coming out of track. This would allow normal tuning of OUT_LO_LIM when not in Track. But the code is a bit more complicated.

(Note: If you store a value in a calc block using an internal variable, that value is not transferred to the standby, and if a switchover occurs, the internal variable will be initialized in the new active. You must store such a value in a module parameter so that the stored value is transferred and available to the expression when it is recalled.)

I'm leaning to having the XFER block on the PID/OUT wire to force value to 0% to the AO block when TRACK IN is active. That leaves the OUT_LO_LIM free to be tuned as needed. The PID goes to AUTO/LO on track in true to indicate interlock is present. Field signal goes to 0%. The OUT Bar graph will show 10% due to limit. You could point the OUT bargraph and value to the AO/OUT parameter when in LO through visibility. You need the PID/OUT bargraph and value to allow operator control in MAN.

Each has its pros and cons.

Andre Dicaire

In reply to Andre Dicaire:

Good idea Andre - Putting XFR1 between PID1 and AO1 is like software mimicking a solenoid on the air line. I usually don't worry about OUT_LO_LIM being adjusted as this is rarely done, and done by engineers in Control Studio when it is. But your suggestion leaves that functionality.

Assuming that the PID output is connected to an AO block (in same module as the PID block or another module via reference), an option is to interpose a BIAS GAIN block in between the PID and the AO block. Then that 5 % can be set as Bias Gain SP regardless if PID out is 0.

Also note that the Bias Gain block provides it's own TRACK_VAL and TRACK_IN_D so it is possible to add tracking conditions outside the PID for very specific cases. For example,In this case that 5 % can be set as BIAS GAIN TRACKING value. So far, adding the Bias Gain provides to different ways to address this.
Finally, becasue the Bias Gain provides the BKCAL parameters, wiring the BKCAL_IN and BKCAL_OUT parameters between involved function blocks can be done This mightbe specially important to avoid unexpected behavior due to the internal function blocks logic (for example unexpected recovery behavior after module download).