Automated Roaster

[johnr]

Thanks, it's really just a learning lab more than anything though. The first 15 or so roasts under computer control were basically undrinkable while I figured out the pid tune and what kind of heat curve was appropriate, given the method of heat application and location of the probe. After trying a half dozen or so approaches, my general 'profile' currently is 100% to 375, hold there until browning starts, crank it 410 and leave it there until C1 is starting to roll. Then drop it down quickly to ~360 and then make incremental increases through C2 (assuming a FC-FC+ roast, that is). The roast that I was doing here actually deviated from that a bit and C1 stretched out a little longer than usual (I shoot for ~4 mins and have been achieving it).

I welcome comments, questions and advice, especially considering I really don't have a clue as to what I'm doing roast-wise... I'm very much employing a brute force and ignorance approach. In my defense, though, I typically have about 3-4 different projects going on at once and the current status of the roaster project is 'good enough for now, I'll revisit it again when x,y and z projects are in a stable state'.

[rasqual]

Well, here's a question/comment/discussion item.

I've often wondered whether, in the neighborhood of exotherming after C1, it might be worth PID'ing the differential between a bean and an air probe for controlling the ramp.

That lead and retardation factor (negative delta after C1) says so much about what's going on with the bean itself -- if the absolute bean temp is rising as the delta is going further negative, that seems to be something that a PID should really like to regulate, perhaps more accurately than just an absolute temp. Dunno.

[johnr]

Interesting. It would be easy enough to do (assuming you had bean temp)... what would the pid be regulating though? A minimum delta?

[rasqual]

I dunno. An absolute needs to be in there somewhere, obviously. I just wonder whether the delta might be useful somewhere in some processing because to a PID, the process behind the actual read temperature is a black box. If there were some way of opening the black box a bit for the PID, that'd be cool.

But I'm plumbing mysteries beyond my ken.   ;-)

[ButtWhiskers]

I was handed a nifty little device at work today:  http://www.futurlec.com/ATDevBoard_Accessories.shtml

The fellow was using his for a BBQ modification, and turned me on to the following article: http://www.circuitcellar.com/library/print/0503/moyer154/index.htm

I am really looking forward to playing with this bad boy - I might use this as the controller for the 3-bay 'hose bubbler' sample roaster.

[rpn]

For a straight programmable i/o board you might also have a look at Arduino, http://www.arduino.cc/

Folks already working in C or Basic have many options, but anyone new to low-level code or control systems should check this out.  They are trying to develop a control system framework accessible to artists and non-eng system design types (like stage designers).

-Rich

[johnr]

Wow, that's a pretty sweet little package for the price: http://www.robotshop.ca/ProductInfo.aspx?pc=RB-Ard-03&cf=334072a1 ... about half of what I paid for the phidget i/o board.

[rpn]

The Arduino base board is cheap because the design is open sourced and several people are manufacturing them.  It's also nice packaged with the high-level languages and non-coder friendly IDE.  However, for industrial controls it's probably going to demand a lot of integration hacking.

On the other hand, Phidgets looks like a ready to go control system framework with plug & play sensors, relay boards, etc.  Can you tell me what of their stuff you are using?  Maybe a quicky BOM of your rig?

I've just recently started roasting with an air popper and part of my interest in all of this is doing some control system hacking.  I understand everyone's attraction to the preprogrammed furnace PIDs that seem popular, but I see a lot more fun in doing a 100% software controlled system with this sort of I/O kit and a small form factor PC.

-Rich

[rpn]

Great article on PID loop design which might suggest a solution to Monito's settling rate problem:
http://www.embedded.com/2000/0010/0010feat3.htm

Monito, it would be great to know which components you used too.  The WAGO product line is broad enough that it's tough for me to suss out which i/o system and modules you used.  Also, did you already have access to software libraries?  Do you have time to look at the Phidgets stuff JohnR used and give a sense of cost comparison with what you were seeing on eBay for WAGO?  Phidgets i/o board is about US$80.  Thermocouple interface is about US$50 (TC not included).  2-relay board is about US$18.

-Rich

[johnr]

rpn, I'm using the phidgets i/o board and the dual relay board. Temp data is coming from an Omega HH306 w/K-type through rs232. The PID is a very simple implementation that I found on some web site (which I can no longer find) and converted to C#. The software model is pretty straightforward:

Roaster
^
|
Controller <----> RoastUI ---> RoastLog


'Roaster' encapsulates a simple roaster device/environment, which consists off a heat on/off switch and two readable temperature probes. 'Controller' models the roast process (roast lifetime, profile application, heat settings, things like that). The RoastUI interacts with the Controller to visualize/control the roast process and uses the RoastLog to persist roast info.

I just recently added support for automated profiles. A profile consists of a collection of segments, each of which has a heat setting and a limit. The heat setting can be either a temp-based setting (pid control) or a percent-based setting, controlling how long heat is applied during each 10 second cycle (for example, 70% means: on for 7 seconds, off for 3 seconds). The segment limit can be time-based or temp-based. A time-based segment expires when the segment has been active for the specified amount of time. A temp-based segment expires when the specified temperature is reached. When a segment expires, the next segment in the profile becomes active. I'm still working out the UI interface to an executing profile but, for the moment, there are two ways to interact with an executing profile - a segment can be suspended when a manual heat setting is chosen (which allows you to effectively extend a segment); and the remainder of a segment can be skipped (which allows you to shorten a segment). This interface is about to get reworked this weekend though, after a little 'double click mishap' caused me to accidently stop a roast of Joe's Harrah 1:13 into C1 last night... doh!

[johnr]

Woohoo, first successful test with the automated profile system... this roast was hands-free (with the exception of the manual stop):


Now whether or not it's a good profile is a seperate issue.

[bwilson]

What sort of temp probe set-up are you using Johnr.  What you are doing looks veeeeery interesting. 

[UpStateMike]

I always wondered how robots roasted coffee.

I'm impressed.

[Monito]

Johnr,

Here is mine...not finished yet...ways togo...

-pat

[johnr]

Looking good Monito! How's the profile stuff coming? I had a grand dream of a generic 'soft bean' profile and a generic 'hard bean' profile that I could use as starting points but that's not working out so well... for example, the soft bean profile works extremely well for Stubbie's Formosa but burns the crap out of milowbailey's Fazenda. Ah well, such is the trial and error approach.

bwilson, it's a K-type probe attached to a handheld. The PC talks to the handheld through a serial port. I could've used a phidgets add-on for temp sensing but I wanted the versatility/convenience of a handheld because I'll almost certaintly recruit it for duties in other projects.