Temperature control enhancement #62
Comments
|
Wouldn't the calibration table need to change depending upon how much coffee is being roasted? (Thermal load?) and perhaps even depend a little upon the size of the individual coffee beans if that can change airflow dynamics?) It would be nifty to incorporate a little control systems math to auto-correct for these variables. Here's a tip-of-the-iceberg: Ah, and here's a deeper intro, leading into modern state-space methods: for accurate roasting profiles... ;) |
|
David,
I understand the use of feedback (+ or -) to control various functions. That is one way to accomplish control.
This idea is to calibrate the heating system accurately (using feedback) to establish one (PWM) power setting that produces a particular temp, literally define how much power is needed to generate X degrees.
The idea is you can now eliminate the real-time feedback control during roasting. Instead its run from the pre-calculated stable feedback table and you are sending the SR700 a signals known to generate a specific heat.
The SR700 is lacking a real bean temp probe. We have to guess at what the bean temps will be. The temperatures reported by the sensor are off by over a 100 degrees. The sensor will still record whatever temperature are generated and a owner will build a roast profile based upon that.
For a controlled roast you wish to keep the heater at steady temps and eliminate swings. I believe a sophisticated high speed feedback control will work but to do that would employ higher mathematics averaging functions and filters. That is either pretty serious engineering or lots of trial and error. If you can do that, go for it.
Using the calculation table when roasting your sensor will still show real time temps while your profile shows calibrated temps. You could create an offset control to adjust for the differences between actual and profile temps. Lets say you observe the actual is about 5 degrees less than your profile temp, then an offset could add 5 degrees to every table temp requested.
Now the roast profile that deals with bean size thermal load, humidity, ambient temp... and those parameters are up to the person to set in their roast profiles. The SR700 now has stable settings to generate specific heat points your profile may use.
I hope this makes sense and thanks for your work and interest,Richard
On Thursday, June 29, 2017 11:20 PM, David Holl <[email protected]> wrote:
Wouldn't the calibration table need to change depending upon how much coffee is being roasted? (Thermal load?) and perhaps even depend a little upon the size of the individual coffee beans if that can change airflow dynamics?)It would be nifty to incorporate a little control systems math to auto-correct for these variables. Here's a tip-of-the-iceberg:
https://www.av8n.com/physics/feedback-controller.htm—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or mute the thread.
|
|
Looks like someone is tackling the serious engineering (a la state-space modeling) at least for brewing: |
|
David,
Cool stuff. That is what I mentioned or meant when I said if you can implement a well modeled PID control (a sophisticated high speed feedback control) "then go for it". Accurate control will rely upon an adequate feedback loop response time with the SR700. I believe the processor in the SR700 is fast enough to handle sub second feedback and input. Adapting Openroast software to that is another story and an area of your expertise.
I was simply saying if that kind of PID control was problematic perhaps a simple brute force method, aka the table, would work.
To me either is OK. The desired result is and accurate and smooth control of temperature. Even though the built in sensor does not accurately indicate bean temp, it is always an offset temp. My roast profile tells the machine to target 485 degrees but the actual bean temp is closer to 285 (backed up by published drum roaster bean temps and my own experiments).
Commercial machines have roast capacities and adequate bean probe contact to record more accurate BT. The only method I see able to do that for a SR700 roaster is an IR sensor. IR will ignore the air temp and if mounted correctly will report only the bean surface temp. Then real feedback based on BT can happen. I am trying to get created such a IR temp sensor. There are several physical obstacles which I believe can be overcome that will make this a reliable and preferred measurement.
I think we can agree, no matter what method is used, temp control is the key around which good roasting occurs. My hope is to encourage those with the talent and knowledge to keep up the good work already started. I used to design and build computer business systems. I may have some designs skills left but programming is no longer one of them.
Having experienced the progress through several versions now up to 1.2.1 has been very encouraging. Thanks for helping all of us out who love home roasting. It is making it easier for others to also enjoy the satisfaction one gets from a good cup o' java. Thanks,
Richard
On Friday, June 30, 2017 4:02 PM, David Holl <[email protected]> wrote:
Looks like someone is tackling the serious engineering (a la state-space modeling) at least for brewing:
http://people.kth.se/%7Emandreas/post/espresso/
https://github.com/martinandreasson/espresso-mpc
http://www.home-barista.com/espresso-machines/model-predictive-control-with-raspberry-pi-zero-t46351.html—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or mute the thread.
|
|
This is an interesting conversation. What I'll say is that the goal of the 'thermostat' mode of the freshroastsr700 driver was to do closed-loop PID control using the chamber temperature sensor as input. What is implemented in v0.2.3+ is as good as it's going to get without upgrading sr700 firmware itself, which is beyond the scope of this project (Openroast and freshroastsr700). Currently, the freshroastsr700 communications rate is 4 packets/sec (250 ms), and this is due to previous authors' empricial observations of roaster behavior - to them, communicating at rates faster than this caused issues of some sort. I do not have the details of this, nor have I personally tested the comm rate limits of the SR700. It's possible that we could run at 10 Hz or more for the comm rate, and thereby do a better job in PID, as well as with the software heater. But I'll leave that experimentation to someone else. So I don't beleive that an empirical approach of open-loop control of the heater can be more effective than the current PID controller in freshroastsr700. Also, just FYI, my understanding is that the SR700 firmware has some form of PID control for its Lo/Mid/Hi hardware heater - it seems to target 3 specific temperatures, and bit-bangs the heater element at a 10-20 Hz rate once it hits its particular target (I run my SR700 won a circuit with a fluorescent light bulb that changes intensity based on the heater being on or off at any given moment...). I implemented the heater_level feature to control the heater element from the PC side and give me better control over heat inputs. A faster USB update rate would do wonders for this heater_level software heater. |
Regarding controlling the heater to achieve consistent (non-wandering) temperatures.
Using PWM (pulse width modulation) is a practical and known method for controlling analog devices to vary outputs. Pulsing the heat (probably high only) on and off at varying rates (typically multiple time a second) can achieve stable heater output.
Setting up a calibration program to record stabilized PWM rates in a table for each temperature (ideally 1 degree increments ~150 to 550 or about 400 entries - a small table) would without needing a temperature sensor feedback loop create reliable and stable heater performance.
An added benefit is every SR700 would then have a calibrated table of PWM specs generated for that unique machine.
In use when a created profile indicates 373 degrees for 1 minute with a fan speed of 7, the software looks in its calibrated table and uses the PWM spec to create 373 degrees.
It appears that the processor speed and electronics of the SR700 would support PWM heater control.
Hopefully the principle is clear.
• Use PWM to control the heat output instead of temperature sensor feedback.
• Create table calibration values using the temperature sensor.
• Vary the PWM until a stable temperature is reached.
• Record the PWM data in the calibrations table and repeat for the next degree.
• Once calibrated, use the PWM table plus .json data to execute a profile’s requirements.
The result is an ability to dynamically control the SR700 heat without relying upon the temperature sensor. The sensor is then only used to read and display actual temperatures.
If with age or other reasons the requested temperature does not match the sensor reading, simply recalibrate and update the PWM table. It should be suggested that periodic cleaning, blowing out accumulated debris, and general inspection of the SR700 creates more consistent performance.
If I can answer any questions I am happy to do that.
Regards,
Richard
The text was updated successfully, but these errors were encountered: