Homeroasters - Home Roasting Coffee Community » DATALOGGERS - CONTROLLERS - RATE OF RISE METERS » Dataloggers/Controllers/Rate of Rise Meters
Who is here? 1 guest(s)
Page 3 of 5: 12345
 Print Thread
TC4 - Bourbon application software
Daisy
Top  #61 Print Post
Posted on 09/18/2011 6:34 PM
Hi folks first post,
Ive been following the development recently of the tc4 and id like to say well done for all the work you have put in. I have a quest m3 that i would like to add the tc4/ arduino to for monitoring only with the lcd and i have a few questions. The tc4 seems to have grown to include extra outputs etc to control fans and heaters but if i only want to monitor i dont think i need to use these functions so when i by the kit do i need to solder all the headers and pins to these areas or can you leave them just blank? Sorry for the the basic level questions i have built a few things but my level of knowledge is low in the dc area. Also what is the jeenode for and will i need to use this for my application with abourbon. Last question is the gndpt on the tc4, does this need to be connected to the arduino or is this an extra gnd for adding extra things to the shield? If any one has some photos of completed boards connected that would help my quest dramatically.
Cheers
Daisy
 
JimG
Top  #62 Print Post
Posted on 09/19/2011 1:36 PM

Quote

Daisy wrote:
The tc4 seems to have grown to include extra outputs etc to control fans and heaters but if i only want to monitor i dont think i need to use these functions so when i by the kit do i need to solder all the headers and pins to these areas or can you leave them just blank?

If you only wish to monitor temperatures and view an LCD, then you need only solder these: the 4 stackable headers for connecting to the Uno, the green screw terminals (one terminal for each thermocouple you plan to read), and the 4-pin I2C header.

If you don't need the LCD, and wish to watch the roast on your PC instead, then skip the I2C header also.

Quote

Daisy wrote:Also what is the jeenode for and will i need to use this for my application with abourbon.

Jee3 port was added just for fun smile There was no particular purpose for the header other than to provide support for some of Jee's widgets. Recently, an HRO-er successfully connected a Jee LCD adapter and got it to work.

Quote

Daisy wrote:Last question is the gndpt on the tc4, does this need to be connected to the arduino or is this an extra gnd for adding extra things to the shield?

The grounding pins generally are only needed if you are using grounded thermocouples and also powering your Arduino from a non-grounded power supply. Wall warts and some computer chargers fit into this category. If you run from batteries, or from a power supply whose negative lead is at the same potential as the frame of the Hottop, then no external ground wire will be needed.

Jim
 
Web
Daisy
Top  #63 Print Post
Posted on 09/19/2011 8:04 PM
Thanks Jim,
Its what I thought and I'm alot clearer in my head of what I'm doing. Cant wait to start soldering.

Daisy
 
petershek
Top  #64 Print Post
Posted on 09/30/2011 1:32 PM

Quote

JimG wrote:

The grounding pins generally are only needed if you are using grounded thermocouples and also powering your Arduino from a non-grounded power supply. Wall warts and some computer chargers fit into this category. If you run from batteries, or from a power supply whose negative lead is at the same potential as the frame of the Hottop, then no external ground wire will be needed.

Jim


Hi Jim,

How should I connect the ground pin if I recorded such a shift in temperature readings as shown in pic when I do the following: using battery power-> connected laptop's power supply -> connected TC4's external power supply -> disconnect TC4's external power supply -> disconnect laptop's power supply

farm7.static.flickr.com/6026/6198690106_d3f84717dd_b.jpg

Thanks!

Peter
Edited by petershek on 09/30/2011 1:40 PM
 
JimG
Top  #65 Print Post
Posted on 09/30/2011 4:07 PM
Connect the TC4/arduino GND pins to the frame of the coffee roaster. This should put the grounded thermocouple sheath at the same potential as the arduino system GND.

Alternatively, connect the TC4/arduino GND pins to the earth ground of the outlet powering the laptop or the PSU.

I have not had this problem when using grounded PSU's, or grounded chargers for my laptops.

I would advise having only one power source connected to the arduino at any one time, too.

Jim
 
Web
petershek
Top  #66 Print Post
Posted on 09/30/2011 11:49 PM

Quote

petershek wrote:

Quote

JimG wrote:

The grounding pins generally are only needed if you are using grounded thermocouples and also powering your Arduino from a non-grounded power supply. Wall warts and some computer chargers fit into this category. If you run from batteries, or from a power supply whose negative lead is at the same potential as the frame of the Hottop, then no external ground wire will be needed.

Jim


Hi Jim,

How should I connect the ground pin if I recorded such a shift in temperature readings as shown in pic when I do the following: using battery power-> connected laptop's power supply -> connected TC4's external power supply -> disconnect TC4's external power supply -> disconnect laptop's power supply

farm7.static.flickr.com/6026/6198690106_d3f84717dd_b.jpg

Thanks!

Peter


Thanks for the advice Jim. If I connect power adapter to the arduino board, the power would be automatically shifted to the power adapter from USB power, right?
 
JimG
Top  #67 Print Post
Posted on 10/01/2011 10:20 AM
Hi, Peter -

Yes, the Arduino boards have some circuitry to automatically select external power when both USB power and external power are detected. So as long as everything works like it is designed, there shouldn't be a problem on that end.

When I suggest using only one power source at a time, I am mostly concerned about the possibility of creating more ground loops.

Is your laptop charger grounded, BTW?

Jim
 
Web
petershek
Top  #68 Print Post
Posted on 10/01/2011 12:43 PM

Quote

JimG wrote:
Hi, Peter -

Yes, the Arduino boards have some circuitry to automatically select external power when both USB power and external power are detected. So as long as everything works like it is designed, there shouldn't be a problem on that end.

When I suggest using only one power source at a time, I am mostly concerned about the possibility of creating more ground loops.

Is your laptop charger grounded, BTW?

Jim


I'm using a Macbook and the power adapter seems to be ungrounded. However, my Quest M3 roaster is grounded. So, I think it's better to ground the TC4 or just to use laptop's battery as power supply. I had several occasions that the battery ran out right before 1C and I lost BT readings (then I would drop the beans at about 3 minutes after start of 1C). However, if I plugged in the power supply, either the laptop one and/or a separate power supply for the TC4, the reading of the unconnected TC socket (#4), which was supposed to show room temperature, went up while the other 3 sockets (#1, #2, #3) went down.

This raised another question, why there's a temperature reading when the thermocouples were disconnected from the TC4? And am I right on the assumption that when thermocouple is not connected, the reading shown on that port would be room temperature?

Thanks.
 
JimG
Top  #69 Print Post
Posted on 10/01/2011 4:05 PM

Quote

petershek wrote:
This raised another question, why there's a temperature reading when the thermocouples were disconnected from the TC4? And am I right on the assumption that when thermocouple is not connected, the reading shown on that port would be room temperature?

When a thermocouple isn't connected, the reading from that channel on the ADC is undefined. Most of the time, it reads zero, or something pretty close. And when the ADC reads zero, then the TC4 will report room temperature.

But there's no way to really predict what kind of reading you'll get from an open input to the ADC, so I hesitate to draw any conclusions. If you short TC+ to TC- on any input, however, (e.g. using a short piece of wire) then you definitely should get a reading near room temperature.

Jim
 
Web
UNM
Top  #70 Print Post
Posted on 10/09/2011 3:13 AM
Well, have done a few roasts with the arduino/TC4/aBourbon. Mostly OK, though last time it hung several times during the roast (LCD still displayed, but no updates). reset brought it back.

Could be dodgy connection, something on the workbench shorting something, poor quality Arduino clone or ??? Anyroad, will monitor and see if it happens again.

Just tried to get pBourbon working - no luck yet. I'm using an ancient laptop with ubuntu 10.04.1. processing 1.5.1.

Set correct serial port in pBourbon.cfg - at least when I ran pBourbon the arduino reset correctly.

The log in the sketch window showed an RXTX mismatch betwen jar version RXTX-2.2pre1 and native lib version RXTX-2.2pre2. first error was a java.lang.NullPointerException
at processing.serial.Serial.write!UnknownSource!
and various other errors relating to resetRemote, keyPressed etc.

Will troubleshoot further and no doubt solve what I mis-configured, but if someone knows most likely cause, I'm happy to be put on right track.

At least I got it to open the serial port and reset the device first time.
Might have to borrow the kids netbook and try with windoze as I know I can talk to the arduino from processing under windoze.
 
Bhante
Top  #71 Print Post
Posted on 10/09/2011 5:58 AM

Quote

UNM wrote:
Well, have done a few roasts with the arduino/TC4/aBourbon. Mostly OK, though last time it hung several times during the roast (LCD still displayed, but no updates). reset brought it back.

I've also been struggling with a similar problem with aCatuai ever since version 1.1 was released. However I made a number of changes of my own, and I haven't had the time to check rigorously the exact source. I also went back to version 1.0 of aCatuai since I was also having a number of other problems with 1.1, but unfortunately I borrowed a few lines of code (the new PWM and thermocouple libraries) from 1.1 before realising that it still had the serial port error. Here is some typical output from Processing when the Arduino hangs (LOOPTIME 750, NCHAN 1, MIN_DELAY 300):

thumbs.picr.de/8437001xpx.jpg

Here is another one with LOOPTIME reduced (probably with the above variables 300, 1, 300 or something similar):

thumbs.picr.de/8436999yay.jpg

I was reducing NCHAN to 1 and reducing LOOPTIME accordingly. I also tried reducing MIN_DELAY to 270-280, but that was not the cause (whether it was a contributory factor I cannot yet rule out, but I think not). Crucial was LOOPTIME - if this was less than 1000 (even 750 with NCHAN 1 and MIN_DELAY 300) it would crash (eventually - after around 7-10 minutes, sooner with other values) with a serial port error as shown. Without the new libraries I think I reduced LOOPTIME successfully, but I need to go back and double check because the serial error sometimes only hits in after a lengthy delay and I didn't do any roasts with this setting at that time. However in any case whether or not it has anything to do with the new libraries, I am surprised that it does not allow LOOPTIME to be reduced when NCHAN is 1 - it looks like it is expecting a 1000ms loop somewhere - in the temperature measurement cyle perhaps? I haven't found anything so far.

I got it to display the "idle" time at the end of the loop and there is no problem there; even if I trimmed the idle time quite fine it still seemed to work OK under version 1.0, but maybe I didn't test it for long enough. As long as the loop time is 1000 I haven't had any problems.

I disabled the new button code in 1.1, eventually I found the best way to do so is simply change the default value of standAlone to false.

I had the error on two computers, one a Core2Duo running XP, the other a netbook running Windows 7.

Bhante
Edited by Bhante on 10/09/2011 6:07 AM
 
Bhante
Top  #72 Print Post
Posted on 10/09/2011 6:16 AM
By the way I found that when NCHAN is reduced to 1 in aCatuai, pBourbon does not correctly parse the serial data, although the column headings are given correctly at the start of the serial output received by Processing. Does pBourbon not check the number of columns output? A workaround is to put an extra if statement in Logger to add dummy values to the serial stream:

Quote

if( NCHAN == 1 ) { // dummy values for T2 and RoR2 to avoid confusing pBourbon
Serial.print(", ");
Serial.print( 0.0, 1 );
Serial.print(", ");
Serial.print( 0.0 , 1 );
};

(Note the space after the comma in Serial.print(", "); - it makes the output a lot easier to read!)
Edited by Bhante on 10/09/2011 6:21 AM
 
JimG
Top  #73 Print Post
Posted on 10/09/2011 8:37 AM

Quote

UNM wrote:
Well, have done a few roasts with the arduino/TC4/aBourbon. Mostly OK, though last time it hung several times during the roast (LCD still displayed, but no updates). reset brought it back.

Does this happen on battery power?

On rare occasions, I have seen the LCD either get locked up, or start to display gibberish. For me, it only happens when the arduino is running from AC power and when there is some sort of "event." For instance, the TC4 system on my Silvia espresso machine sporadically had this problem when the brew switch was turned off.

I added a filtering diode across the plug prongs on my wall wart (this point is safely buried inside the machine) and that solved it on the Silvia.

But it seems like the LCD is kinda sensitive to small power fluctuations and spikes?

Quote

UNM wrote:
Just tried to get pBourbon working - no luck yet. I'm using an ancient laptop with ubuntu 10.04.1. processing 1.5.1.

I had all kinds of problems with processing 1.5.1. I would recommend using processing 1.2.1. For me, 1.2.1 works across all my computers (XP, Ubuntu, OSX).

If needed, I think I can release a compiled (under 1.2.1) version of pBourbon. Would this be helpful?

Jim
 
Web
JimG
Top  #74 Print Post
Posted on 10/09/2011 8:59 AM

Quote

Bhante wrote:
I've also been struggling with a similar problem with aCatuai ever since version 1.1 was released. However I made a number of changes of my own, and I haven't had the time to check rigorously the exact source. I also went back to version 1.0 of aCatuai since I was also having a number of other problems with 1.1, but unfortunately I borrowed a few lines of code (the new PWM and thermocouple libraries) from 1.1 before realising that it still had the serial port error. Here is some typical output from Processing when the Arduino hangs (LOOPTIME 750, NCHAN 1, MIN_DELAY 300):

The output window suggests it might have had a looptime of 450? Best guess here is that you exceeded the array limits inside processing since the shorter looptime will generate more than 2X the number of data points.

Quote

Bhante wrote:
I was reducing NCHAN to 1 and reducing LOOPTIME accordingly. I also tried reducing MIN_DELAY to 270-280, but that was not the cause (whether it was a contributory factor I cannot yet rule out, but I think not). Crucial was LOOPTIME - if this was less than 1000 (even 750 with NCHAN 1 and MIN_DELAY 300) it would crash (eventually - after around 7-10 minutes, sooner with other values) with a serial port error as shown. Without the new libraries I think I reduced LOOPTIME successfully, but I need to go back and double check because the serial error sometimes only hits in after a lengthy delay and I didn't do any roasts with this setting at that time. However in any case whether or not it has anything to do with the new libraries, I am surprised that it does not allow LOOPTIME to be reduced when NCHAN is 1 - it looks like it is expecting a 1000ms loop somewhere - in the temperature measurement cyle perhaps? I haven't found anything so far.

Bourbon and Catuai were both written with a 1s cycle time in mind. In principal, I agree that it should be possible to shorten this. But at some point I suppose the array limits in the processing sketch are going to blow up since so much more data is transmitted.

Jim
 
Web
JimG
Top  #75 Print Post
Posted on 10/09/2011 9:06 AM

Quote

Bhante wrote:
By the way I found that when NCHAN is reduced to 1 in aCatuai, pBourbon does not correctly parse the serial data, although the column headings are given correctly at the start of the serial output received by Processing. Does pBourbon not check the number of columns output? A workaround is to put an extra if statement in Logger to add dummy values to the serial stream:

Quote

if( NCHAN == 1 ) { // dummy values for T2 and RoR2 to avoid confusing pBourbon
Serial.print(", ");
Serial.print( 0.0, 1 );
Serial.print(", ");
Serial.print( 0.0 , 1 );
};

(Note the space after the comma in Serial.print(", "); - it makes the output a lot easier to read!)

As you figured out, pBourbon doesn't have too many smarts when it comes to parsing the input stream. It does only a limited amount of checking. It ignores the columns header, BTW, that the arduino sends.

It expects to receive input from 2 channels. So if you change the number of input channels, then you'll have to make a compensating change in the processing source code for pBourbon, or send dummy values as you did.

Jim
Edited by JimG on 10/09/2011 9:07 AM
 
Web
Bhante
Top  #76 Print Post
Posted on 10/09/2011 11:33 AM

Quote

JimG wrote:
The output window suggests it might have had a looptime of 450? Best guess here is that you exceeded the array limits inside processing since the shorter looptime will generate more than 2X the number of data points.

Evidently it was 450 in this case, but I tried 750 also with the same result.

Hmmm, I'm rather confused. If the root cause of the error is in processing rather than on the Arduino, why does the Arduino hang - does it have to wait for a response from Processing on the serial port, or does it churn out the data continuously? Why does a shorter looptime generate more data? Each line of serial data is the same. Why would Processing fill up arrays with several lines of serial data? Or do you mean it is storing the data while plotting the graph? In that case it is partly a computer-speed issue. Maybe it hangs when there is a momentary surge in demands on resources on the computer.

Judging from his description of the error message, UNM's error sounds like the same as mine.
 
JimG
Top  #77 Print Post
Posted on 10/09/2011 12:34 PM

Quote

Bhante wrote:
Hmmm, I'm rather confused. If the root cause of the error is in processing rather than on the Arduino, why does the Arduino hang - does it have to wait for a response from Processing on the serial port, or does it churn out the data continuously?

Without more information, I can't explain why the arduino would hang. I don't think the arduino cares whether or not processing is successfully reading the data. It just spits out data to the serial port without waiting for an ACK.

But I suppose it is possible that processing is resetting the COM port when it hiccups? This would cause the arduino to reset as well.

The only issues I've personally seen on the arduino side have been caused by (I think) power glitches that mess up the communication with the LCD. And I have only seen this occur on my espresso machine -- never on the roaster.

Quote

Bhante wrote:
Why does a shorter looptime generate more data? Each line of serial data is the same. Why would Processing fill up arrays with several lines of serial data? Or do you mean it is storing the data while plotting the graph? In that case it is partly a computer-speed issue. Maybe it hangs when there is a momentary surge in demands on resources on the computer.

The processing sketches use large arrays to store all incoming data. Processing redraws the screen constantly "from scratch", so it needs all of the past data for every redraw.

Jim
 
Web
Bhante
Top  #78 Print Post
Posted on 10/09/2011 1:12 PM

Quote

JimG wrote:
But I suppose it is possible that processing is resetting the COM port when it hiccups? This would cause the arduino to reset as well.

The only issues I've personally seen on the arduino side have been caused by (I think) power glitches

If processing is causing the arduino to reset then the arduino will reset not hang. Unless the arduino is waiting for a handshake it appears to me the problem ought to be on the arduino side. I've seen the power glitches you refer to (with a poor quality USB cable with a rather poor connector), but that has totally different effects.

Quote

JimG wrote:
The processing sketches use large arrays to store all incoming data. Processing redraws the screen constantly "from scratch", so it needs all of the past data for every redraw.

If that is the issue, the amount of data involved is very tiny compared with the amount of data Processing is able to handle - I've had it hang after less than 1 minute with a loop time of about 300 ms, and on the other hand I've left it running for a couple of hours with a loop time of 1s, and it continued merrily plotting away without complaint. There is something else going on here.

Bhante
Edited by Bhante on 10/09/2011 1:14 PM
 
UNM
Top  #79 Print Post
Posted on 10/09/2011 6:33 PM

Quote

JimG wrote:

Does this happen on battery power?

Quote

UNM wrote:
Just tried to get pBourbon working - no luck yet. I'm using an ancient laptop with ubuntu 10.04.1. processing 1.5.1.

I had all kinds of problems with processing 1.5.1. I would recommend using processing 1.2.1. For me, 1.2.1 works across all my computers (XP, Ubuntu, OSX).

If needed, I think I can release a compiled (under 1.2.1) version of pBourbon. Would this be helpful?

Jim


Not tried battery power, but the wall wart was on the same strip as my triac power control, so interference could well be an issue. Will make up a 9v battery connector and use that, or laptop power in future.

I THINK it was processing 1.2.1 on windoze I initially tested with. Will grab a copy for linux and try that next. I know it is not pBourbon as such, but something in my environment that is the problem.

Many thanks.

No need for a compiled version, but appreciate the offer.
Edited by UNM on 10/09/2011 6:36 PM
 
UNM
Top  #80 Print Post
Posted on 10/16/2011 4:57 AM
No joy with processing 1.2.1, same problems. I've just been using the java environment included with the processing .tgz file, so will install a full java package separately and retest.

The arduino hangs I saw - better news there. Hangs seemed related to power going to the heater - full heat OK, partial heat caused hangs. Heater off, OK.
Tried off battery power and same thing, then realised that in among the mess of cables on the workbench, the power cable between the triac heat controller and the hottop went right under the power connectors of the Arduino/TC4 and the LCD interface cable.
D'oh!

All seems good since rerouting cables. Almost certainly interference.
 
JimG
Top  #81 Print Post
Posted on 10/16/2011 11:33 AM
Sounds like you've figured out the problem. Glad to hear it.

The only other thing I will mention is that I have found the LCDapter (I2C interface to an LCD panel) seems to be a little sensitive to noise (fluctuations in Vcc, I think). If your system acts up again, you might temporarily disable the LCD and see if that makes a difference?

The LCD display I am using on my espresso machine was flaking out once in a while when I switched the pump off. I put a suppressor diode across mains right at the connection to my Arduino's 9V switching power supply, and that has fixed it so far.

Jim
 
Web
UNM
Top  #82 Print Post
Posted on 10/23/2011 3:19 AM
Tried with a Windoze XP netbook and processing 1.2.1. All good and did a dummy test roast (more hangs as the cable from Arduino -> LCD passed under the netbook case. It seems really prone to interference.
Rerouted cable and managed a roast of Harrar with no problems and saved log/graphs.

Will sort out the Ubuntu problems separately.
Next step is to fit plugs/sockets for the thermocouples (so I can easily move the arduino for testing/programming) and add in arduino control of roaster heat/fan.

Bourbon all seems to work fine for now, much easier than pencil and notepad.
 
JimG
Top  #83 Print Post
Posted on 02/02/2012 8:13 AM
Thanks to LoftyNotions, a new installation/user guide for the Bourbon application is available. I uploaded Larry's file to the project googlecode site today. You may view and download it here:
http://code.googl...bon%2Fdocs

Thanks, Larry!

Jim
 
Web
greencardigan
Top  #84 Print Post
Posted on 07/11/2012 5:23 AM
Hi Jim,
I've just downloaded the latest version of Bourbon (2.3a) and it doesn't seem to have any info regarding the changes made since version 2.2.

I'm thinking of adding some PIC algorithms to pBourbon. Do you think that's a worthwhile endeavor?

Brad
 
JimG
Top  #85 Print Post
Posted on 07/11/2012 6:38 AM
Hi, Brad -

Version 2.2 is the latest version of pBourbon. Following are the release notes for that version:

Code Download source  

Version 2.20

------------

The program will look for files with these names, and 

if found, open them:



"profile.csv":  A guide profile in default F units

"logfile.csv":  A saved log file in default F units



If the config file has put the program in C units, then it will

look for, and open if found, these files:



"profile_c.csv"

"logfile_c.csv"



The guide profile and saved log files are optional.



pBourbon will log up to two output levels (e.g. for a heater or for a fan).  

It will plot only the first output level, however. If pBourbon finds values in 

the serial stream following the temperature data, then it will process them.  

If there is no additional data following the temperature data, then no errors will be

generated and no output trace will show up.


What kind of PIC features do you have in mind?

Jim
 
Web
Page 3 of 5: 12345
Jump to Forum: