Hi Brian - Sorry, I didn't get a notification from my RSS app that you had posted. Just saw it.

Phidgets require that the same version of their software be running on both the host and Roastmaster - in your case the host is the SBC. That is the mismatch - the SBC is newer. If you were using a laptop as a host, then the preference pane software would need to match with Roastmaster.

We need to basically downgrade the SBC itself with older software (20120912), not necessarily the preference pane. I'll poke around for a Phidgets article and post back.

Danny

Hi Baldys - thanks for the kind words. I've added this to the tentative backlog for the next update - a number of folks have asked for this. The current update I'm working on is small - adding J Type thermocouple support and a couple of minor things. In the next one though I'd like to tackle reporting features (the most popular request). If it works out, I'd like to also address this one too. I can see where it would be very beneficial.

Thanks for the input!

Hi Steve

Unfortunately, there's just not going to be an intuitive way to accomplish this because it simply is not designed to show that data. Actually, after rethinking this a bit since we've been talking, it's likely not even possible for me to provide a way represent preheat in a Behmor curve, even in a future release.

Behmor time shifts happen in two ways. Before the roast starts, time shifts scale the entire curve. After a roast is in progress, only the final leg is scaled. Injecting extraneous nodes to a curve would corrupt the time-shift functionality to where it would no long match what is happening on the roaster. To put it another way, there are no absolute values in the programmed curves in the logic board of the Behmor - they start out as scaled algorithms from a template, and are adjusted internally in the machine based on the program and weight setting, then further adjusted by the two rules above when you perform the time shifts. The time shift functionality in Roastmaster mimics this, and (like the roaster) relies on there being a predictable number of nodes. If this number of nodes changed in Roastmaster, the effect would be a curve that no longer matched what is occurring on the machine.

The customs setting types we discussed would just be a way to record your preheat times. They would not tie into the graphical representation of curves in the graph in any way. They just provide a record of an arbitrary setting for any given roast. They ARE tied into the selector strip below the graph, so you would be able to pinpoint past roasts with the same preheat setting chosen as the current roast.

To deconstruct it a little, Behmor curves in Roastmaster are designed to represent the heat settings being applied by the machine through the duration of a roast cycle. The time shift functionality lets you alter this data the same way you would on the roaster. These things together give you the ability to see this graphically, compare and contrast against past roasts, and a convenient way to match only identical roasts via the "Curve" selector button on the selector strip under the console graph to better predict the events of the current roast.

Adding the custom preheat setting we discussed would enhance this to allow you to further hone in and show only roasts with the same preheat setting applied in the graph, and of course - provide a readable reference.

Now, the workflow.... keeping in mind that adding preheating to a curve is not a supported feature, and consequently no concrete workflow exists for that, you could simply copy and paste your manually created curves into new profiles and abandon the concept of defining separate profile, program and weight settings for the roaster - relying only on the curve and the custom profiles you've created.

For instance, create a profile called "P1, D, 1lb", then paste the curve you've built for that into it. Then in future roasts, simply tag that profile instead of all three items separately. That curve would come in automatically - similar to what you're describing. One important note: you would lose the time-shift functionality for that curve.

I still think that accepting the concept of Behmor curves as a representation of a concrete roasting cycle, and relying on custom roaster settings to represent preheat times is your best bet.

Let me know if I'm not explaining this correctly.

Danny

Hi Steve

Thanks for the kind words!

Curves, for reasons of simplicity, don't support the concept of preheating. I felt it would get way too complex trying to support 'negative' values on a time scale.

I had originally toyed with the idea of adding a "Charge" field to either the roast or a curve - holding simply a numeric value to represent either time or temperature, but found most folks have a set temp they like to drop at and that doesn't vary. So, for this situation, and a few others, I added the "Custom Roaster Settings" a few updates ago.

That would be an ideal place to define your standard preheat times. Create a Custom Setting Type in the Behmor roaster within Roastmaster called "Preheat", and then within that custom setting, create individual custom roaster settings. For example: "No Preheat", "P1 - 1:30", "P1 - 2:00", etc. Once defined, you'll be able to select those in roasts that use the "Behmor" roaster. Custom Roasters Settings have a button on the graph selector strip, so you'd have the flexibility to filter by both the curve AND the custom setting type - matching only roasts with preheats that match the current preheat.

Custom Roaster Settings are pretty flexible. You can define as many as you'd like for a roaster, and they show up as choices in roasts that use that roaster.

Hope this helps - let me know if you have any other questions.

Danny

Hi Ryan

This is an older article, from before Behmor curves had the capability of being automatic.

Do you mean Behmor curves are not being created in the current roast? There is a preference setting in Utilities/Preferences called "Auto Behmor Curves". Turn that on, and curves will be created whenever you choose any combination of Roaster, Profile, Program and (Custom) Weight Settings, as long as they're named in such a way that Roastmaster can identify which Behmor setting they represent.

I've started building a library of documentation in the main part of the site - there is an article here with better instructions... http://rainfroginc.com/documentation/using-behmor-1600-curves/  It tells you what profiles, programs and custom weight settings to create in the roaster and how they need to be named so that Roastmaster can identify which Behmor control they represent. There's also a sample Behmor roaster you can import into Roastmaster as an example.

If, however, you're not seeing past roasts display in the graph as expected, please double-check the selectors you have chosen in the selector strip below the graph - particularly the "Curve" button in that strip. If you have not created a curve to the current roast, and the "curve" selector is selected, you may not see any roasts at all, because the current roast doesn't have a valid curve. The easy way to troubleshoot is to deselect all of the selectors below the graph, then turn the ones you want on one by one. This will give a clue as to which one is keeping them out.

The selector buttons are often very specific, and specialized. Once you start using Behmor curves in Roastmaster, you'll probably come to see the benefit of having a separate "Curve" button, even when the Profile, Program and Custom Settings selectors seem to suffice. It gives you a way to only focus on roasts that have extremely similar curves. This will come in very handy if you time-shift your Behmor curves.

Also, one more thing about the graph. Verify that it's set to display past curves by tapping the "i" button near or beneath the graph, and setting the Transparency value to a comfortable setting.

Hope this helps - let me know if not.

Danny

Thanks for the feedback Dave

Hi Dave

Thanks for the kind words and support - I appreciate that!!!

Ya know, it occurred to me a year or so ago, that shop roasters would probably love to be able to track batches. I tossed it around for awhile, and thought it might work similar to how blend, profile and program snapshots work. First and foremost there would need to be a shipment date field, then each batch you receive could become a "child" of the parent - with each child selectable in a roast, and counting toward the parent's inventory. That would be a nice way to track the age of beans as well - beyond just identifying the quality of a particular batch.

That's probably a larger task than I will attempt for the next update, plus I try to go by popularity of requested features. So, in the interim I may tackle the "clone bean" feature first. Someone prompted me for the clone roast feature, and once I dove in, it took about 30 minutes to implement - winning the award for quickest feature implementation.

Thanks for the suggestion - I like it!

Danny