Trouble autotuning a system with significant process lag

[Kurt]

Hi AzeoTech and forum users,

We have a number of heating elements supplied with controllable DC power supplies whose current output is set by a DAQFactory PID loop. This system has worked well for us, including autotuning. However, we recently increased the size of the system being heated, resulting in a larger current needed to achieve similar temperatures. For these larger systems, autotuning no longer works well.

When we try to autotune using the larger systems, the autotuning appears to work, but post-tuning control (including at the same setpoint used for tuning) is poor. We see large oscillations (sometimes undamped). We tried increasing the relay height to ca. 80% of steady-state output (i.e., if the steady-state output at the setpoint is 100, the relay tuning sweeps from an output of 20 to an output of 180), but the resulting autotuned parameters still result in oscillation. As a result, we've had to manually tune by trial and error.

We suspect the autotuning problem is because of increased process lag with our larger system. As one example, once power is cut, the larger system takes 30-45 s for its temperature to decrease by half.

Is there another autotuning method, or a way to adjust the methods used by the relay tuning method, that we could try to improve our results? We were wondering if there might be a way to fit our data to a "first order plus deadtime" model (whether in real space or Laplace space). Or if there might be other known tuning correlations we could use.

Thanks for your help!

[AzeoTech]

The autotune shouldn't care about the lag by itself, but it can cause impatience in the user :).  There are several key points when using the auto-tune:

1)  The system has to be stable at the current setpoint when you start the autotune and not oscillating much.  You can achieve this with some simple manual tuning, usually just with P, or just do it manually, perhaps changing the setpoint in the PID to match whatever stable temperature you achieve by manually controlling the output.  I believe the PID has to be running, but you can set P to 0 to basically disable it until the autotune is finished.  The autotune doesn't care what the existing parameters are.  When it activates, it shuts off the existing PID control and is just looking for the time it takes to reach the setpoint with the output tweaked

2) you want it to run through 3 or 4 oscillations.  

3) if you need to use an 80% output sweep (20->180) then you probably aren't being patient enough.  Set it to something like 10 or 20% (80->120 say) and just wait it out.  If you rush it on these slow systems you introduce noise into the result resulting in a poor result (sorry, 3 uses of "result" in one sentence!)

On a side note, if you are getting big oscillations your P is too big.  If there isn't damping, then I is probably too big (note that I is inverted, so non-zero small numbers have a bigger effect than larger numbers, 0 causes I to be ignored).  But I is multiplied by P typically, so you really need to get the oscillations down before messing with P.

[AzeoTech]

In reference to your actual question: are there alternatives, the answer is yes, kind of.  A PID loop is not a particularly complex algorithm.  Although probably not for a beginner, someone with a little scripting experience could script their own PID controller and make it what they want.  Likewise, a different auto-tune algorithm could be pretty easily scripted in.  In fact, we are slowly moving towards trying to implement many of the built in DAQFactory features in script so that a beginner can use it as is, but someone who needs to tweak it could delve into the script and make those tweaks.

[Kurt]

Thanks for your reply. We generally let the autotune run for 30 s and this is enough time for 15-20 or so oscillations. As I recall, the autotuned PID parameters have fully stabilized by the time the tuning is shut off, but the values are just bad. I'll try running it longer and see if I get better results, then report back.

[AzeoTech]

30 seconds with 15-20 oscillations sounds way too fast.  You should lower your output delta so that you get an oscillation every 20-30 seconds and run for 3-4 oscillations.  If you run it fast like you are doing there are significant noise problems due to sampling intervals and other things.  You only have to autotune rarely, so don't rush it!

[Kurt]

In our case, we need to autotune every cell, every run, because the heated system changes slightly. But spending 2-3 minutes is no problem if we get better results. What you said about the noise also makes sense; with each successive oscillation the tune seems to get no closer to a fit - the P parameter, for example, keeps bouncing around over a 5-fold range. Will test your advice and report back. Thanks!

As a side note, it would be helpful for your advice of targeting an oscillation every 20-30 s and a minimum of 3-4 oscillations to be included in the user guide.

[AzeoTech]

Thanks, and we have added that to the docs for the next release.  The 20-30s is really dependent on the acquisition speed/pid loop speed and how fast your system responds.  I assumed you were sampling at like 1/sec or 2/sec and not 100/sec for that number.  If you had a fast moving system and were sampling at say, 100 hz, then you certainly could target a faster cycle time if you had the PID loop also running at 100hz.  The 3-4 oscillations is to give the autotune a chance to stabilize.  

[Kurt]

Hi again. Since your last message I've tested some more using smaller relay heights. I should note that our PID loop runs at 10 Hz, so it may be that a shorter oscillation time than the 20-30s is appropriate for us, as you mentioned in your last message. I observed the following:

> Starting from a low relay height of ca. 1% of steady-state output and increasing gradually, I started to get decent results with a relay height of around 5-10% of SS output.

> Control is still not great, with the autotuned parameters frequently making the integral contribution too large (numerically small), causing (sometimes undamped) oscillations in post-tuning control. Control is also quite slow, taking 30 s or more to reach setpoint.

> Most concerning - no matter what I select for the relay height and how long I wait during tuning (usually 120 s), the "settling in" you hint at above never seems to happen. It's hard to be sure, but it seems more like the autotune is recalculating the parameters afresh after each oscillation, rather than adding to an average or fine-tuning, etc. Can you share the code for the autotune procedure?

Thanks again for your help.

[Kurt]

@AzeoTech Can you share the code for the autotune procedure and/or comment on my last bullet above? Thanks!

[AzeoTech]

The output of the autotune is calced as:

Out = U + (-2 * (up < 0) + 1) * H

where U is the output value the instant you start the autotune, H is the specified height, and UP is the effect from the P part of the PID.  In this case it really is just telling us which direction we need to go and just makes H positive or negative.  The Out is then inverted if the PID is reverse acting and constrained by the out min/max.  

The result is calculated based on the period of oscillation and the actual deviation from the set point, and is recalced with every oscillation:

K = (autoTuneHeight / (maxPVinLastOscillation - SetPoint))
P_Result = K * x2
D_Result = periodOfOscillation; * x3
I_Result = periodOfOscillation; * x4

K is just a temp variable.  x1-x4 are various constants