Who is here? 1 guest(s)
 Print Thread
4-channel TC meter and datalogger project
JimG
The intended behavior is captured in this line from aBourbon.pde:

// #define EEPROM_BRBN

This is supposed to control whether or not aBourbon looks for calibration information written into the EEPROM.

If this line is commented out (the default), then some standard values for the calibration factors get hardcoded in, and the EEPROM is not read by aBourbon.

OTOH, if EEPROM_BRBN is #define'd, then the EEPROM must be initialized exactly as Bill indicated.

Jim
 
greencardigan
I assume I can use pBourbon with my TC4/picaxe combination if I format my serial output data the same as you do?

Is pBourbon a stand alone program? Or will I need some arduino software too?
 
randytsuch

Quote

greencardigan wrote:
I assume I can use pBourbon with my TC4/picaxe combination if I format my serial output data the same as you do?

Is pBourbon a stand alone program? Or will I need some arduino software too?


pBourbon is a processing program, so you need to set up that environment.
http://www.proces...

I modified pBourbon for my program, and send/display more information for a PID application.

BTW, why are you using a picaxe instead of an Arduino?
Seems like a lot of work.

Randy
 
greencardigan

Quote

randytsuch wrote:
BTW, why are you using a picaxe instead of an Arduino?
Seems like a lot of work.

Randy

A few reasons. I already have the picaxe hardware and software. And I'm not too keen at the moment to learn relearn c++.

I don't think using a picaxe it is any more work though. Sure, I have to write my own code, but I have have some old code from a previous PID/data logger that I can reuse.
 
randytsuch

Quote

greencardigan wrote:

Quote

randytsuch wrote:
BTW, why are you using a picaxe instead of an Arduino?
Seems like a lot of work.

Randy

A few reasons. I already have the picaxe hardware and software. And I'm not too keen at the moment to learn relearn c++.

I don't think using a picaxe it is any more work though. Sure, I have to write my own code, but I have have some old code from a previous PID/data logger that I can reuse.


I was kind of expecting that answer.
I did all my code in C, I never figured out C++. It did take me a while to remember how to code in C, had not coded in many years, but it slowly came back. Coding is way easier now, if you have any questions, you can find most things in an internet seach.

If you did use the Arduino, there is a lot of code now, on both the Arduino and PC ends, so it might be easier then you think.

Randy
 
bvwelch

Quote

greencardigan wrote:
I assume I can use pBourbon with my TC4/picaxe combination if I format my serial output data the same as you do?


Yes, the Arduino 'aBourbon' just sends a line of ASCII text over the UART periodically (once a second generally), and pBourbon reads the line. Processing is a Java-based IDE and language.

You may also want to try out Artisan, which is Python-based and likewise you could emulate the TC4 ASCII lines. Instead of streaming, Artisan requests each line separately.
 
greencardigan
I gave processing and pBourbon a go. I'm wish I'd come across this software earlier!

No problems getting some thermocouple graphs happening with the TC4 and picaxe.

www.greencardigan.com/misc/air_roaster_build/data_logger_controller/pBourbon_test.jpg

pBourbon won't strart if I already have the TC4 logger running. Some serial error. Is that normal?

Also a few changes I'd like to see. Maybe I'll try changing them myself. :eye-popping:

- A setting in config file to set up the temp axis for celcius.
- Change the single click for screenshot to something else. I get too many accidental screenshots.
- Ability to zoom in on parts of the graph with auto scrolling.
- Buttons to create crack markers.

Also, I thought it could load in and graph a roast profile from a csv file so you have a profile to follow??
Edited by greencardigan on 03/31/2011 8:29 AM
 
bvwelch

Quote

greencardigan wrote:
pBourbon won't strart if I already have the TC4 logger running. Some serial error. Is that normal?

Also a few changes I'd like to see. Maybe I'll try changing them myself. :eye-popping:

- A setting in config file to set up the temp axis for celcius.
- Change the single click for screenshot to something else. I get too many accidental screenshots.
- Ability to zoom in on parts of the graph with auto scrolling.
- Buttons to create crack markers.

Also, I thought it could load in and graph a roast profile from a csv file so you have a profile to follow??


Your serial port error seems odd. With the Arduino, there is a reset feature that is triggered by one of the modem control leads when processing opens the serial port.

Your new features sound great! You're welcome to cut/paste and enhance as you see fit, and then if you'd like to add it to the web site that would be great. Think up a new name for your version.

Yes there is a compile-time option for a profile guide which is read from a csv.
Edited by bvwelch on 03/31/2011 8:50 AM
 
Bhante

Quote

greencardigan wrote:
- A setting in config file to set up the temp axis for celcius.

Great, I'll second that. Better, a config setting to switch between Fahrenheit and Celsius, and linked config settings for Temp and RoR axes. The RoR multiple has to be reduced for Celsius, otherwise it goes way off axis and is a mess.

Quote

greencardigan wrote:
- Buttons to create crack markers.

I'll second that too. Recently when I looked at the software there seemed to be something for receiving keypresses and writing its timestamp in the output stream, but I tried it and couldn't get any output. There was also a string being tested to see if it was set, but setting it to something didn't seem to make it work. Is that part of the program started and not quite finished (cf the fix-me)? It looked to me as though it ought to do something, but it only printed whatever character I typed in the middle of the graph, unrelated to the current plotting location.

Quote

bvwelch wrote:
Your new features sound great! You're welcome to cut/paste and enhance as you see fit, and then if you'd like to add it to the web site that would be great.

Yes, but ...

Quote

bvwelch wrote:
Think up a new name for your version.

I'd vote against a new split in the tree. I personally think it is better - as far as possible - to collaborate in improving one (or a few) versions, and indeed those versions which started off in separate directions should ideally converge, at least as far as common code is concerned, so that improvements on one branch of the tree can be used easily on another branch. The more the tree gets split the less cooperative development will be possible.

The ideal, I think, would be to modularise the program as much as possible into modules that do specific tasks, which can simply be called with an include statements in each branch of the tree. So for example if a new feature is added to Bourbon as an include statement, then it could be added to Kona with a similar include statement as long as the program structures and variable names are broadly similar. Inevitably there will be cases where the new Bourbon feature will be incompatible with Kona, or only compatible with some Bourbon-incompatible modifications - in the latter case we modify the feature and save it as KFeature, and include Kfeature where Borbon inludes Feature. I think that would help keep the different branches in support of each other, instead of simply dissipating all energies proportionate to the number of branches. I know, it requires an additional investment of time, but I wanted to suggest it all the same.

Bhante
 
bvwelch

Quote

Bhante wrote:
I'd vote against a new split in the tree ... The ideal, I think, would be to modularise the program as much as possible into modules that do specific tasks...
Bhante


Thank you for your inputs and critiques.

Speaking for myself, it seems like we're already doing much of what you describe -- we've got lots of libraries/modules for reading the devices, converting voltages to temperatures, reading buttons, writing to the various types of LCD, UART, etc.

What's left are are few 'sketches', each one just a few hundred lines of code, that implement a few routines like setup(), loop(), etc. That seems about right to me. I like the idea that someone can just open up a single file and tweak it a bit as they see fit.

How about this-- you go ahead and start a new sketch, and use whatever approach you like. I'm not really from Missouri, but 'show me'. :-)
 
greencardigan

Quote

bvwelch wrote:
Yes there is a compile-time option for a profile guide which is read from a csv.

Can you elaborate on this. I'm not understanding.

I have modified pBourbon so it has a celsius mode which is activated by the third line in the config file. Can I post it somewhere so you guys can have a play?
 
Bhante

Quote

greencardigan wrote:

Quote

bvwelch wrote:
Yes there is a compile-time option for a profile guide which is read from a csv.

Can you elaborate on this. I'm not understanding.

In pBourbon 20101008:

Quote

String cfgfilename = "pBourbon.cfg"; // whichport, baudrate

// boolean enable_guideprofile = false; // set true to enable
 
greencardigan
Ah rats! I must have downloaded an old version.

I'm not familiar with this open source idea. Do I create a RC version for my modifications?
 
randytsuch

Quote

greencardigan wrote:
Ah rats! I must have downloaded an old version.

I'm not familiar with this open source idea. Do I create a RC version for my modifications?


I just looked in the latest version of pKona availabe for download, and I don't see this feature either.

Randy
 
greencardigan
Hello again.

I downloaded pBourbon version 20101023 and added my celsius code.

I also added a feature to mark 1st and 2nd crack on the graph (just type F or S then hit enter while the graph is running. See screen grab of celsius mode.

www.greencardigan.com/misc/air_roaster_build/data_logger_controller/celsius_mode_crack_markers.jpg

Here is my modified code and config file. Have a play and let me know if it's worth incorporating into the official version.

pBourbon_brad.zip

I like the language processor uses. Java?
Edited by greencardigan on 04/02/2011 5:07 AM
 
JimG

Quote

greencardigan wrote:
I'm not familiar with this open source idea. Do I create a RC version for my modifications?

I am just back in town after a couple of weeks off. Give Bill and me a few days to organize the googlecode site so that valuable contributions (like your improvements to pBourbon) can be more easily incorporated.

Jim
Edited by JimG on 04/02/2011 4:20 PM
 
Bhante

Quote

greencardigan wrote:
I downloaded pBourbon version 20101023 and added my celsius code.

I also added a feature to mark 1st and 2nd crack on the graph (just type F or S then hit enter while the graph is running. See screen grab of celsius mode.

I tried your software cold; I should be doing a roast next week, then I can try it with coffee.

The crack markers are very nicely done, although at first I couldn't get it to work because I didn't realise it was waiting for me to press return! It would be nice if it could respond to simply "f" or "s" without carriage return.

It is nice that if you press f then return once, and then again later, the marker moves accordingly, but both markers are recorded in the log. Thus if you think you hear a crack and then realise you were premature, you can correct it on the graph later, but it is good that all the key presses remain in the log for reference. It would sometimes be useful to have markers for the end of the roast (e) and perhaps also beans inserted (b).

Regarding the temperature scale, it seems to go pretty high to me on Centigrade at 350. I think 280 is more than enough, and that is already allowing extra space at the top for the text (perhaps not even necessary). Did you use 350 because of the 10x scaling for RoR? I think 10x is far too much on Centigrade. I think 5x is much better. Last roast I even tried 2x, which seemed OK, but I do not have enough experience to give an opinion on what is optimal. It would also be worth offsetting the zero of the RoR upwards, so that it appears somewhat more in the middle of the graph area. I'd prefer to use a temperature scale from +20 degrees C to about 260 degrees to give a larger graph (since I always roast indoors), but I would think RoR needs some space to go negative ... then again, negative RoR shouldn't be happening during the roast ...

[Edit]
If we wanted to put an offset on the the RoR graph, it might be better to use a separate variable to hold the exaggerated RoR + offset, so that we don't have to inverse the exaggeration when displaying RoR at the top of the screen; if sample size were to be > 1 the inverse exaggeration would get a little more cumbersome when we want to experiment with different multiples.

Bhante
Edited by Bhante on 04/03/2011 5:25 PM
 
greencardigan
I could make it place the crack markers without having to press enter. But then I'm not sure how to handle longer text notes starting with 'f', or 's' etc. I'll have a think about this. Any ideas?

I believe the ET can reach 330 C (630 F). That's what Chad was getting on his CoffeeAirII roaster. 350C give a little bit of room up the top of the graph so the traces dont go over the text. Anyway I have modified the code so the max temp for celsius mode is easily adjustable (just by changing the value c_MAX_TEMP in the code). The axis will then scale to fit.

Regarding the ROR, I'm not real sure what a maximum value would be in reality. So I'm unsure what scale factor to use. But leaving it at x10 should give you the same graph as using Fahrenheit mode. I think??

I'm also thinking that the temp axis on the right side could be used for ROR. So the left side could range from 0 to 280C while the right side could range from -? to +? degrees per minute.

These changes might take me a while. I'm learning this coding language as I go. I dont even know what language i'm learning. Roflmao

EDIT
Some updated code pBourbon_4_Brad.zip

// added code for Celsius mode
// added 'First Crack' and 'Second Crack' markers. 'F' and 'S'
// added code to scale temp axis in celsius mode if c_MAX_TEMP is changed
// added code to scale temp axis in fahrenheit mode if MAX_TEMP is changed
// added code to scale time axis if MAX_TIME is changed
// added 'Beans added' and 'End of roast' markers. 'B' and 'E'
Edited by greencardigan on 04/03/2011 11:42 PM
 
JimG
Brad -

I've done a reorganization of the googlecode SVN repository. I have created a branch for your revisions to pBourbon:

https://tc4-shiel...nches/Brad

The "4_Brad" source files are in the repository, as I extracted them from your latest zip file.

At some point I will need to figure out how to merge things with the trunk, but for now I would like to keep your revisions in the branch folder.

Jim
 
greencardigan
Thanks Jim,

I'm keen to continue helping with the coding if it can eventually be merged into the trunk. ie. I only want to code somerthing that others want included and is compatible with the trunk.

Also, I dont want to go too far before any merges with the trunk happen.
 
Bhante

Quote

greencardigan wrote:
I could make it place the crack markers without having to press enter. But then I'm not sure how to handle longer text notes starting with 'f', or 's' etc. I'll have a think about this. Any ideas?

I had the impression that any longer texts are already eliminated by the software anyway, on the grounds that they are longer than one character - am I mistaken in this belief? Is it necessary to have longer texts? If so, then they could perhaps be marked by one specific first character (itself not a part of the text) to indicate that what follows is a text string terminated by return.

Quote

greencardigan wrote:
But leaving it at x10 should give you the same graph as using Fahrenheit mode. I think??

What I can say is that the first time I tried using it on a Hottop I simply converted the upper scale limit to Centigrade without changing RoR, and the RoR graph went violently off the top. Whilst this might have been for purely obscure reasons, I interpreted it as being because the RoR was expressed in Fahrenheit numbers multiplied by 10, while the temperature scale had been converted (by me, conceivably not entirely correctly) to centigrade, therefore with smaller numbers. I have to say though that my understanding of this program is somewhat hazy, partly because I cannot find enough time to properly get to grips with it and have to work somewhat in fits and starts; also more substantially because of inexpertise in programming. I am planning for my next roast to try 4x RoR + 50.

Quote

greencardigan wrote:
I'm also thinking that the temp axis on the right side could be used for ROR. So the left side could range from 0 to 280C while the right side could range from -? to +? degrees per minute.

Sounds like a good idea to me.

Quote

greencardigan wrote:
Some updated code ...

Looks nice - I'll give it a try on my next roast. Just a thought (not sure if this is a good idea or not) - what about the user putting a list of key codes in the config file, which are then taken as a list of valid marker commands. Different people have different ideas and/or constraints of what to record.

Bhante
 
JimG

Quote

greencardigan wrote:
Thanks Jim,

I'm keen to continue helping with the coding if it can eventually be merged into the trunk. ie. I only want to code somerthing that others want included and is compatible with the trunk.

Also, I dont want to go too far before any merges with the trunk happen.

My suggestion would be to work towards a stable release of pBourbon with a limited number of new features:

1. Selectable Celsius or Fahrenheit graphs according to runtime config file.
2. Single keystroke markers for specific roast events.
3. Recognize LCDapter button press roast markers coming from aBourbon (see below).
4. There is a timing issue related to the lag in opening serial communications with the Arduino. It would be nice to fix this, too.

I suggest keeping this line of pBourbon code in the "Brad" branch:
https://tc4-shiel...nches/Brad

I would also like to propose that aBourbon be revised for compatibility:

1. Selectable (at compile time) C or F units through the user.h file.
2. Add support to read LCDapter button presses that do the same thing as pBourbon's single character keystroke inputs. The LCDapter supports 4 buttons, so that would be aBourbon's limit.

I will take care of the aBourbon side of things, and have already started a branch for release 2.00 in the repository.
https://tc4-shiel...hes/RB-200

Jim
 
randytsuch
At some point, I made a change to pKona (based on pBourbon) because it would lock up when you reached the end time limit of the graph, I think it was around 16 mins.

Do you guys see that problem?

I think it just takes a few changes to fix it.

Randy
 
Bhante

Quote

JimG wrote:
I would also like to propose that aBourbon be revised for compatibility

Very nice!
 
greencardigan

Quote

JimG wrote:
2. Single keystroke markers for specific roast events.
3. Recognize LCDapter button press roast markers coming from aBourbon (see below).

2. So we want single key strokes for markers? Just 'F' rather than 'F' then 'Enter'?

3. Does aBourbon send this data yet? I cant see it in any of the versions. What format will it be? Something like "# First Crack" ?


Quote

JimG wrote:
I suggest keeping this line of pBourbon code in the "Brad" branch:

Am I able to edit my code there?


Quote

randytsuch wrote:
At some point, I made a change to pKona (based on pBourbon) because it would lock up when you reached the end time limit of the graph, I think it was around 16 mins.

Do you guys see that problem?

I think it just takes a few changes to fix it.

Randy

I've never tried running it that long. But my code allows you to change the end time limit. I think it would be good if it automatically extended the graph if you were approaching the end time limit.
 
Jump to Forum: