Shaun Shue

My favorite PID mods

My introduction to PID came from building a sous vide controller, before Anova made it easy. PID controllers are good proven tools. But after eating raw eggs and other under/overdone foods, I became very aware of its limitations. A simple system (no knowledge beyond process variable and setpoint) doesn’t deal with large disruptions well. Standard P on error overshoots to reach target temperature. And of course, poorly tuned coefficients make for an under-responsive or wildly inaccurate system.

I have hopes for tinyML taking a chunk of PID applications, given the computing power that even low end devices now have. But in the meanwhile, and for those who can’t entrust their system to a black box, here are the better modifications I’ve used.

Integrating Bang-Bang

Below a specified threshold: Maximize output (and don’t let the system integrate).

On hitting that threshold: Switch to PID control.

Above a specified threshold: Zero the output.

This reached setpoint faster and avoided excessive I windup—which in turn avoided excessive overshooting. It requires knowledge of when zero or full output makes 100% sense. For my second sous vide setup, the hotplate’s wattage made a low-Bang of 30F < setpoint, and a high-Bang of 0F > setpoint comfortable.

P on Measurement

For cases where overshoot is unacceptable (e.g. sous vide), P on measurement changes P’s effect from driving to moderating. Brett Beauregard’s writeup illustrates this beautifully, and the PID formula becomes:

P on Measurement PID formula

A.B.T. Always Be Tuning

For revision 3 of my grill controller, I made it start with a Ziegler–Nichols [auto tuning] state before moving to a [hold] state—the idea being to learn the characteristics of the grill/smoker it was attached to. I graphed the log data from multiple tests to find optimal PID parameters for my smoker, and found that there were no consistently optimal PID parameters.

This makes sense. At the start of a cook, more air is needed to catch fuel and get to setpoint. When fuel has caught, less air is needed to hold temp. When the fuel is almost out, more air is needed again. When the fuel is out, bringing in air is the opposite thing needed to (try and) maintain temperature.

This presents a problem because PID relies on a relatively consistent relationship between input and output. So I treated it like a tuning problem. I added logic to track peaks, valleys, and when the process variable crossed the setpoint/in which direction. I set it to tune the coefficients and stored-up integration accordingly, to reduce the amplitude of errors, increase responsiveness when needed, and minimize oscillation. In short, Always Be Tuning.