PID Manual to Auto bumpless transfer

[vt92]

I'm using the PID-Advanced VI to implement a so-called bumpless transfer from manual to auto.

This is a heating/temperature application where I am manually heating the DUT for a few seconds.  During that time, the process is close to the target.  When I switch to auto, I want to PID to take the process where it is and "fine tune" the process to hit the target.

In reality, when I switch to "Auto", the PID acts like it is resetting because the controller output goes to zero and then starts to ramp up.

Is anyone familiar with implementing the bumpless transfer? 

Attached s a picture of the process and part of my diagram.   You can see the large drop in the process variable when I switch to auto.

[nathand]

I always found that in order to make this work, you need to set the "reset" input to the negation of the "auto" input. The reset input sets the value of the integrator to the manual input. In your case, the only reset is on the first call, setting the integrator to 0, so when you switch back to Auto, the integrator is at 0, resulting in the bump that you see.

[Oligarlicky]

Your controller output isn't going to 0. Your PV is going to 0. Your output is actually increasing. The fact that you are in control later at 85% output tells me that you weren't close at the beginning when you were outputting 20%.

Also, you have "setpoint" labeled where the manual input is. You have "target" wired into the setpoint and you have no indication of what "Target" is set to.

[vt92]

Oligarlicky - During the manual mode, the output is not 20%.  The output = the setpoint.  I have the PID output range set to 20 - 100%

[nathand]

No, your terminology is off, as Oligarky pointed out, but I'm pretty sure that's not the issue with your code. The wire you marked as "target" in your diagram is the Setpoint. PID acts to drive the process variable to the setpoint. It would help to see more of your block diagram to understand how the lines on the chart match to your wired. That said, try forking the Auto wire, adding a Not to the branch, and connecting that to the Reset input.

[Barp]

In addition to what the people said, the 'manual' input defines the value that will be 'placed' in the output of the controller. So, if your 'open-loop' response require you to apply 0.5 V to obtain 200 degC, then you have to use 0.5 and not the 200 as input for manual of PID. This 

Another comment is that, if you want to be bumpless when switching from automatic to manual, you also have to update the manual value to start with the same value as it had in automatic. To do that, need to 'get' the output value to manual. A easy way to do this is using local variables. Please see http://www.ni.com/pdf/manuals/372192d.pdf in page 3.9 or below for more information:

[vt92]

Barp,  thanks for the reply. 

I am using the "manual" input as you describe.  I am also feeding "live" data to the "setpoint" and "process input" terminals, though I'm not sure it matters during the manual mode.

I'm not transitioning from auto back to manual.

[Barp]

OK... then to be better diagnostic what you are saying, it would be nice to see more of your code. Is this a simulation or just a real system? Did you modify the nomenclature used above as described by the other people? For example, setpoint is not the right term for manual input. Also, It would be nice to see what 'treatment' you are doing to the manual signal.

One thing to keep in mind is that if your system is very nonlinear and very sensitive and your tuning is not quite right, then those big jumps could happen, specially if you have a derivative action.

Basically, the algorithm used by PID does 'bumpless' transfer only at the moment you 'switch' from manual to automatic. If your controller afterwards is very aggressive and your system responds very fast, then you will see that kind of spikes. A way to test this is to use a PI controller and 'detune' a bit and see if that 'big spike' would go away.

The bumpless algorithm helps to avoid a jump in the transition, but a aggressive tuning won't make a smooth change. Here is an example of a change using a more aggressive controller:

and then, detuned (demoved Derivative and making the I slower (higher value, in the PID tuning):

And here is what happen if we have a very aggressive controller:

And all those behavior were obtained by just changing PID gains.

So, try to see if modifying the gains would help your performance.

[Barp]

One more thing that I just noticed: your 'limits' are 'unbalanced', which means that going one 'direction' is different than going to another direction. You don't have 0 on your limits either. This is a bit unusual. I think it would benefit if you describe what your are trying to control.

In general, if you limits are so far away, it is common to have a feedforward path that helps the controller to work better. For example, if have the mapping between input and output relationship, you could just add the 'static' path to the controller and, then, the PID, will just correct for the error between the feedforward and process variable. Here is an example:

\

Although PID is an excellent algorithm, it still is a linear algorithm and the bias has to be taken into account when creating a real-world controller (or at least considerably improve performance).

[vt92]

For everyone's edification, I changed the labels:

This is a real temperature control system, though the temperature is measured by the power consumption.  The setpoint and the process variable are both in watts.  The output is scaled (just by a multiplier) to control the voltage applied.  

Barp - Your feedforward idea is interesting if I can map the input vs output.  Thanks.

I can't share any more code because 1.) is is part of a state machine which is one part of a large, class-based producer-consumer application and 2.) the process is proprietary.