Emerson Exchange 365

In Scenario 2, were Steps 2 and 3 performed while the loop was in Manual or Auto? The sequence for Scenario 2 isn't quite making sense for me. It would also help to know the PV_SCALE of the PID block. For now, I'll assume that both the PV and the OUT are 0-100%.
In Scenario 1, you start out with the PID block in MAN. When you flip the block into AUTO and drive the setpoint change, the PID algorithm goes to work. The proportional "kick" you saw makes sense based on the high Gain in your PID tuning (and assuming 0-100% scaling on PV and OUT). If you are using PI on Error, D on PV (the default and most common form in DeltaV), then your PID algorithm is working with an error of (SP - PV = 9 - 18.6 = -9.6). Your PID is Reverse Acting on the error term, so the proportional action will immediately open the valve by (Error * Gain = -9.6 * -10 = 96%). You can see that this aggressive value in your PID Gain will likely cause large overshoot in both directions of error.
In Scenario 2, you start out with the PID block in MAN. When you flip the block into AUTO with the SP = PV in Step 1, then your error term is zero and you wouldn't expect the PID output to change (it was already 0% and remained so). Steps 2 and 3 don't follow what I would expect unless the PID was in MAN or IMAN and not AUTO. Can you confirm the sequence of events and PID actual mode? I would be interested in seeing a Process History View chart of PV, SP, OUT, Target Mode, and Actual Mode for both Scenario 1 and Scenario 2. If the sequence above is correct for Scenario 2, the PID loop was almost behaving as if the Target Mode was AUTO but the Actual Mode was IMAN. This can be caused if a downstream block isn't ready to accept a setpoint from an upstream block. Is this PID block part of a Cascade control strategy? Is the PID block alone in the control module or does an AI->PID->AO? What was the PV doing as the PID output was moving?

In reply to GeloCortez:

Gelo,
All the previous comments are valid. However, there is one additional fact about the DeltaV PID block that will explain the response to scenario 2, step 3. The DeltaV PID block is implemented as a "positional" (vs. an velocity or incremental) algorithm. There are pros and cons to each type but if you know which type is being used, it is not an issue. Suffice to say, DeltaV developers felt there were more "pros" to the positional implementation.

A positional algorithm keeps track of the INTERNALLY calculated OUT of the PID even if it is outside the actual OUT_LIMITS. Note that integral is turned off when the internal OUT is outside of the OUT_LIMITS unless the Integral action is bringing the internal OUT back towards the OUT_LIMIT.

So, in scenario 2, step 2, when the SP was changed from 18.6 bar to 0 bar (46.5% to 0%), the internally calculated OUT went to (0% + 10*(-46.5%)=-465% which is below the OUT_LO_LIMIT of 0% so the external OUT stayed at 0%.
In in scenario 2, step 3, when the SP was changed to 9 bar (22.5%), the internal OUT to (-465% + 10*(+22.5%)=240% which is still below the OUT_LO_LIMIT of 0% so the external OUT stayed at 0%.

FYI, if the SP had been changed to 18.6 or above, the OUT would have come up above 0%

At first glance, this may appear to be incorrect. However, consider this loop being lined out at SP=18.6 bar (46.5%), PV=18.6 bar (46.5%), OUT=50%. Suppose the operator (or engineer) incorrectly changed the SP to 9 which would step the OUT to 0% and the internal OUT would be (50% + 10*(-24%) ) = -190%. However, when the operator (or engineer) set the SP back to 18.6, the OUT would go back to 50% (-190% + (10*(+24%)) as desired! With a velocity or incremental type PID, the OUT would haven ended up at 100% [(0% + 10(24%)) = 240% but limited to 100%].

Hope this answers your question! If not, feel free to let me know!