Chief Delphi - Integral Window for PID Control

Chief Delphi (http://www.chiefdelphi.com/forums/index.php)

- Programming (http://www.chiefdelphi.com/forums/forumdisplay.php?f=51)

- - Integral Window for PID Control (http://www.chiefdelphi.com/forums/showthread.php?t=41087)

Integral Window for PID Control

How do you determine how many error samples to include in your PID model? For the derivative portion you presumably just use the last sample (or is it common to do the average difference over a few samples?). There are well defined methods for tuning the constants in a PID algorithm, but how do you choose how far back the algorithm should look?

Re: Integral Window for PID Control

Quote:

Originally Posted by phrontist

If you want the result to be zero error, you don't use a sliding finite
time window for the integral feedback. You start with zero integral
when you activate the control system and let the time integral of the
error be a running sum. The question is when to start the integral
feedback. If the proportional and derivative signals are arranged
to produce a critically damped system the system will not overshoot
at all (as a PD system). Delaying the start of the integral signal will
limit any overshoot that the integral signal injects into the system.

With regard to averaging the time derivative signal, you have to be
careful about the time delay when you do this. If you use an average
from too far back in time you could produce a sizable delay.
If you delay the signal too much you will get growing oscillations
instead of the damping that you want.

Have fun,
Eugene

Re: Integral Window for PID Control

I used a running sum for my error, but with the current sum cut down by a % each loop, so that the more recent error has more "weight". You also get the advantage of not having to keep and manage an error array for a time window.

Code:

// Integral control

Integral_Sum = (Integral_Sum *995) / 1000 + Err;

Integral_Counter = (Integral_Counter *995) / 1000 + 1;



Iout = Ki * (Integral_Sum / Integral_Counter);

Using this, every loop the current sum and number of sums is multiplied by 0.995, or cut down a half a percent, then the current sum is added. The average error of the old sum stays the same since the count is reduced too. The current sum gets added while all the old sums get repeatedly reduced.

Sums from 38 loops (1 second) ago to now make up 17% of the running sum.
0.995^38 = 0.827

Sums from 114 loops (3 seconds) ago to now make up 43% of the running sum.
0.995^114 = 0.565

Sums from 191 loops (5 seconds) ago to now make up 62% of the running sum.
0.995^191 = 0.384

Sums from 382 loops (10 seconds) ago make up 85% of the running sum.
0.995^382 = 0.147

Sums from 763 loops (20 seconds) ago make up 98% of the running sum.
0.995^763 = 0.022

You can change the 0.995 to make your running sum more recent or keep older sums more important.

I haven't seen this online anywhere, I don't know what it's called or if it even works yet, but it made sense to me. If anyone sees anything wrong with it let me know.