search

CapnBry / HeaterMeter

HeaterMeter and LinkMeter Arduino BBQ Controller
https://tvwbb.com/forums/heatermeter-diy-bbq-controller.85/
MIT License
502 stars 83 forks source link

[hm] Integrator / Derivative Changes #9

Closed R-Burk closed 9 years ago

R-Burk commented 9 years ago

Integrator would stay stuck at a value even when the _pidOutput was outside the 0-100 range. Derivative was working against the instantaneous current temp. Put a small filter so it's across the most recent 4 values. Using a second derivative addition to bring it back close to real time. Also provides extra steerage when the derivative is changing at a high rate

CapnBry commented 9 years ago

You're right about the resetting the integrator change 744fd14, however I don't understand or agree with the rest of your changes. Derivative is calculated against the moving average, which you've duplicated with your new filter code. You can't calculate the D against such a fast moving average on a system that takes 5-10 minutes to change, which is why we calculate against a much larger time. I'm also not clear on how your control saturation logic is better.

R-Burk commented 9 years ago

Deriv - Current code is Probes[TEMP_PIT]->Temperature against a 60 second average. I'm doing a 8 second average against a 60 second average. So a slightly filtered head verse an instantaneous head value. Amplify that by higher values of Td. For Td - I've been aiming for somewhere between Ti/10 and Ti/4. So for a Ti of 250 ( or .004) that gives a range for 25 to 62. Ti/6.25 seems to be a good point. Last couple of cooks have been at 50

Int - If it's not saturated then it doesn't care which way the error is going and applies the error. Otherwise it starts recalling the integrator. I could probably just add the additional recall logic to original saturation check. At this point I'm not sure how I got there after trying a dozen different revs.

R-Burk commented 9 years ago

Correction. Original deriv calc is Current Temp against a 30 second average.

Original Integration seems to get stuck at 2 noticeable points. If error is positive and pidOutput is > 100 then the integrator accumulator is stuck with a value. Once the error went negative it would start to unwind but it could have been doing it much sooner and brought the pidOutput out of saturation quicker. Maybe it makes sense to keep the value instead of unwinding but it seems to help on startup and has no effect once steady state.

BTW - The ZN or TLC tuning rules work once I realized the deltaTime for Derivative is 30 seconds verse the 1 second for P and I. So if you divide the Kd result by 30 it works out pretty well.