Yes... both... I'm probably going to do the roast logging pc first so I can visually see what's going on with the PID... then once I get that figured out, then I will probably build a self-contained unit with (hopefully) some flexibility but standard curves...
That's a good plan. I'm sure you've already given this some thought but here's my take on monitoring/control and how it relates to the profile methodology problem...
Monitoring is central to just about everything else, so it's probably a good idea to get the thermometry interface up and running before anything else. I don't know what your dev environment is but if you can use C# (mono on linux), there's an open source grapher called ZedGraph that's great for time-temp plotting duties. I don't use Java much these days so I can't give a specific recommendation for a grapher on that side but I know there's a wide selection. Whatever you use, you'll find that a real-time (or near real-time anyway) time-temp plot on screen is invaluable for troubleshooting and visualization. Also, collecting temp samples on a background thread that's independent of the UI is a good idea - it's better to have the UI's representaton of the data lag reality a bit than have artificial delays in the data stream caused by UI latency.
Control: once you have monitoring up and running, a good next step is to add manual control capability to the UI that displays your time-temp plot (the control panel, so to speak). I would start off simple and not worry about PID initially. Think in terms of power level - you could have a slider control in your UI that goes from 0% to 100% and has ticks every 10%, for instance. You already know that the sono control logic uses a 21 second duty cycle so it should be pretty easy to map proportional time to power level - a background thread could periodically wake up and cycle power on-off as appropriate according to the time mapping vs. current power setting. Of course, you could skip the manual control step altogether and go right to PID control but be prepared to spend LOTS of time getting the PID response dialed in. Personally, I prefer to hold off on that sort of fine detail work until the rest of the system is stable - but that's just me.
The nice thing here is that once you've written the code to support monitoring and translating control panel input requests into burner control commands, you basically have 90% of what you need to support automated profile control. The only thing left to do is define "profile" in the context of the automated system. The intuitive approach is to define profile as a series of control segments. There are a handful of commercial examples to draw from here, including the Ambex software and the Hottop P. Each control segment typically represents a time- and/or temperature-constrained instruction for the control system. An inherent weakness of the typical automated profile, of course, is that the segments are fixed and don't accomodate variations or overrides very well. This is mitigated somewhat if you can make simplifying assumptions about the roast environment - for example, the sono stock profile is based on a fixed load size. A more sophisticated, general purpose approach might incorporate rate-of-change instructions and event-based segment transitions (rather than time or temp) to address some of those limitations but, of course, this increases complexity.
Ok, enough rambling... hopefully there's food for thought in there somewhere.
