Using the Arduino PID library, would adjusting the setpoint after every cycle be a bad idea?
Here's some context:
I'm building a bbq controller very similar to the bbq guru. I'm using a blower to control the amount of oxygen fed to a charcoal fire which in turn controls the temperature of the barbecue. I'm using the Arduino PID library for the brains.Arduino Playground - PIDLibrary
The web page linked above explains it far better than I can. The idea is that as the food's internal temp approaches a certain point the barbecue temperature will "ramp down" so that eventually the barbecue pit and food temps will converge at a predefined temperature so you don't overcook your meat.
My first thought was to use a second PID object that takes food temp as input, blower's setpoint as output, and food target as it's setpoint. This however, would seem to require a lot of time and $$ to tune, the idea of tuning a second pid to control the first pid makes my head hurt (after fumbling through tuning the first one for the last week). Instead, I'm just simply adjusting the setpoint linearly/proportionately to the error. (error being "food target temp" - "actual food temp"). A second PID just seems like overkill.
MY QUESTIONS: How would you approach incorporating this feature? Would changing the barbecue temp controller's setpoint ,every cycle, cause havoc to the PID algorithm? Maybe, rather than changing the setpoint after every little change in food temp, the setpoint should be changed after every 5 to 10 degrees difference in error?
PID algoritms need to establish the Differential and Integral components, it you keep changing the set point these will not reflect correctly the control stimulus, hence determining if your control is over / under damped would be nearl impossible ...
It's not unusual in industrial process control having one PID controller's output 'wired' to the setpoint input of a second controller. When used as such it is said to be a cascade controller. The issue is not if sending the new output every cycle is bad on not, but rather how much the setpoint will or can change with each cycle. Temperature processes tends to change slowly compared to typical PID computation cycle time, but having the first controller's output change too quickly and used as the setpoint for the second controller could certainly make 'loop tuning' difficult. I would suggest you first get each controller tuned correctly first as standalone controllers before trying to operate them as a cascade pair, where you may only require minor tuning changes to make it stable and effective.
Having one control loop to control the fire temperature and another one controlling the food temperature seems like a good approach to be. Trying to do everything in a single loop would IMO give the risk that you end up making the fire excessively hot trying to make the food heat up quicker - you need to manage the fire temperature in its own right.
It may be that the control loop for the food temperature doesn't need to be a full PID and could be a simple proportional control - in other words, just calls to map() and constrain(). That would be one less thing to have to tune and would naturally lead to your desired behaviour of the fire temperature converging with the food temperature.
PeterH:
It may be that the control loop for the food temperature doesn't need to be a full PID and could be a simple proportional control - in other words, just calls to map() and constrain(). That would be one less thing to have to tune and would naturally lead to your desired behaviour of the fire temperature converging with the food temperature.
'P' only controller was my thought as well. But how much would constantly changing the setpoint screw with the PID algorithm controlling the fire?
PID algoritms need to establish the Differential and Integral components, it you keep changing the set point these will not reflect correctly the control stimulus, hence determining if your control is over / under damped would be nearl impossible
^-- this is what I was afraid of.
Maybe the best thing to do is just try it out and see what happens, but I won't be able to do a real cook for a little while.
theboozler:
But how much would constantly changing the setpoint screw with the PID algorithm controlling the fire?
I wouldn't expect any particular problems. The I term will give it some inertia, but it's not as if you're going to be making frequent and large changes to the set point - more a matter of the set point drifting slowly (relative to the PID feedback loop response time).