Homeroasters - Home Roasting Coffee Community » DATALOGGERS - CONTROLLERS - RATE OF RISE METERS » Dataloggers/Controllers/Rate of Rise Meters
Who is here? 1 guest(s)
Page 7 of 13: 1...45678910...13
 Print Thread
TC4 - Coding and tech issues
allenb
Top  #151 Print Post
Posted on 09/16/2011 5:45 PM
Jim, Bill and Randy

I would like to personally thank you for all the hours of hard work you guys have poured into the TC4 hardware and software and especially for being willing to dig into issues to answer the questions that come up which allows our members to get through the debugging stages.

I would like to encourage everyone out there who's finding uses for the TC4 and it's various softwares who have not taken the time to comment in this forum to please jump in so all can benefit.

Happy building and modding!ThumbsUp

Allen
1/2 lb and 1 lb drum, Siemens Sirocco fluidbed, presspot, chemex, cajun biggin brewer from the backwoods of Louisiana
 
JimG
Top  #152 Print Post
Posted on 09/19/2011 1:47 PM
For my contributions to the project, Allen, I say thanks for the kind words! The project has really been a lot of fun, and along the way I have developed some hardware and software that soon (I hope) will become part of a snazzy espresso machine temperature control system.:)

Jim
 
Web
JimG
Top  #153 Print Post
Posted on 10/01/2011 11:00 AM
Been working the last couple of weeks on adding some fancier AC control options to the TC4 system. Expected benefits are AC motor control and "pulseless" electric heater control.

The first step was bringing the INT0 line out to the new I/O2 header on the version 5.20 board.

Since then, I've built and tested a zero crossing detection circuit that I think might be the one. This detector operates directly on mains, but should provide adequate isolation (through an optocoupler) to protect the TC4.

On the software side....

Using a link that Bill sent me a year or more ago, I've successfully implemented some "period-skipping" code that creates fairly smooth power output using a garden variety zero-cross SSR. It works by turning the SSR on and off for predetermined numbers of half-waves, depending on the output level needed. It operates on groups of 256 half-waves, and has a unique pattern of on's and off's for each of 255 different output levels.

This works great on heaters, but I haven't tested it yet on AC motors. I could use a volunteer who'd like to give it a try on an AC fan motor.

Currently, I am working on code for phase angle control, i.e., like a lamp dimmer or router speed controller, only digital. This requires special "random-fire" SSR's, but these are reasonably priced and I had a few of them lying around. A homespun TRIAC is an option, too.

This would be a great time for folks who have an interest in this aspect of the TC4 project to guide me in the right direction (or at least try) B)

Jim
 
Web
Bhante
Top  #154 Print Post
Posted on 10/31/2011 10:48 AM
@Jim

I've just come across an interesting signal conditioner IC that can zoom in on the most relevant part of the sensor data to get very high resolution and very accurate ADC output:

http://www.semtec...x8724c.pdf

It would be nice to put one of these on the next generation TC4! Not sure how easy or difficult it would be to set up, although a quick glimpse at the hefty datasheet might suggest that it would not be so easy! Have a look anyway. It is supposed to work with any ADC and any microprocessor.

Bhante
 
JimG
Top  #155 Print Post
Posted on 11/01/2011 11:24 AM
@Bhante

That looks like a nice device, with a lot of flexibility. I didn't dig too deep into the data sheet, but I thought it looked like a replacement for the MCP3424, not necessarily an add-on?

Jim
 
Web
Bhante
Top  #156 Print Post
Posted on 11/01/2011 12:00 PM

Quote

JimG wrote:
I thought it looked like a replacement for the MCP3424, not necessarily an add-on?

SNAP, I also didn't dig too deeply into the datasheet, but from the blurb I understand that it is intended as an interface between the ADC and the micro. I imagine you could get high res (i.e. quantisation below signal noise level) data very fast (small fraction of a second) because of the way it makes better use of the data. That should translate into better and more stable RoR values. You could probably get an average of several readings in a fraction of a second at optimal resolution. As the temperature changes you just shift the zoom window accordingly. If you look on the website you'll find more general info including an article on the approach used. They say it works with any ADC.
 
Bhante
Top  #157 Print Post
Posted on 11/23/2011 3:03 PM
@Jim:

Is there any (not too complicated) way of getting pBourbon to plot a graph from a CSV data file instead of the serial port? I suppose I could use it a a "template", and then click as soon as it starts. I'd have to change the colours and timescale of course.

I had a roast in which the Arduino crashed several times. I combined the data in excel (with the unavoidable discontinuities of course), and want to plot them. Configuring a meaningful graph of overlapping variables in excel is a harassment I'd rather avoid if possible.

Sometimes it would also be nice to be able to easily replot a graph after the event (to correct anomalies in start and finish times for example, or after correcting wrong button presses, or to remove an irrelevant template, etc).
 
JimG
Top  #158 Print Post
Posted on 11/23/2011 3:27 PM

Quote

Bhante wrote:
Is there any (not too complicated) way of getting pBourbon to plot a graph from a CSV data file instead of the serial port?

Nothing comes to mind. Had I stopped reading here, I would have suggested Excel :|

I think it might be easier (not easy, just less difficult) to manipulate the data in Excel than to try to combine several partial CSV files as in input to pBourbon.

Quote

Bhante wrote:
I had a roast in which the Arduino crashed several times.

I have not experienced this, so I am quite concerned. Can you tell me more about the circumstances? What did the crashes look like?

Any chance that serial port resets were generated by the host computer?

Which Arduino board?

Jim
 
Web
Bhante
Top  #159 Print Post
Posted on 11/24/2011 11:37 AM

Quote

JimG wrote:I have not experienced this, so I am quite concerned. Can you tell me more about the circumstances? What did the crashes look like?

Any chance that serial port resets were generated by the host computer?

Which Arduino board?

Same old crash as before,
http://forum.home...post_31241
I found the main problem was that when the timescale is increased the arrays are not extended sufficiently - easily resolved by multiplying the extension to the arrays by 4 - the crashes have been largely eliminated since then, although they still occur from time to time, for reasons which I have not isolated. It does not seem that a reset was sent on the serial port, as the arduino hangs, it does not reset. It is the 2009 arduino.
 
JackH
Top  #160 Print Post
Posted on 11/28/2011 6:32 AM

Quote

Bhante wrote:

Quote

JimG wrote:I have not experienced this, so I am quite concerned. Can you tell me more about the circumstances? What did the crashes look like?

Any chance that serial port resets were generated by the host computer?

Which Arduino board?

Same old crash as before,
http://forum.home...post_31241
I found the main problem was that when the timescale is increased the arrays are not extended sufficiently - easily resolved by multiplying the extension to the arrays by 4 - the crashes have been largely eliminated since then, although they still occur from time to time, for reasons which I have not isolated. It does not seem that a reset was sent on the serial port, as the arduino hangs, it does not reset. It is the 2009 arduino.


I am assuming that it is aCatuai crashing. (The Arduino stops sending serial data when viewed with the serial monitor).

From what I have been reading --- two different Arduino boards and two different computers do this? I guess it rules out component failure (thermal) or USB port/operating system issues. It might be something to do with aCatuai's added features. I am guessing is that if you ran aBourbon as a test, you would probably never see these failures.

I hope I am not interfering, sometimes it helps to review symptoms and have others take a look.

I hope you are able to solve this problem, it is interesting.
Jack
---Jack

KKTO Roaster.
 
Bhante
Top  #161 Print Post
Posted on 11/28/2011 7:03 AM

Quote

JHan816 wrote: From what I have been reading --- two different Arduino boards and two different computers do this? I guess it rules out component failure (thermal) or USB port/operating system issues. It might be something to do with aCatuai's added features. I am guessing is that if you ran aBourbon as a test, you would probably never see these failures.

Thanks for your ideas Jack, it was indeed aCatuai. I'm not getting many crashes while roasting at present, mostly on my espresso machine, so I'll try substituting the aBourbon on the espresso machine as you suggest.

Talking of added features, the start of the problem coincided with the release of aCatuai 1.10 - not long after I started getting full control over the roaster, I hastily add - but then I tried comparisons of versions 1.0 and 1.1 and never managed to unambiguously pin it down. What I should really do is de-install the new library versions installed with version 1.1 and try running the comparisons again, but I never got round to that.
 
JimG
Top  #162 Print Post
Posted on 11/28/2011 9:05 AM

Quote

Bhante wrote:
Same old crash as before,
http://forum.home...post_31241
I found the main problem was that when the timescale is increased the arrays are not extended sufficiently - easily resolved by multiplying the extension to the arrays by 4 - the crashes have been largely eliminated since then, although they still occur from time to time, for reasons which I have not isolated. It does not seem that a reset was sent on the serial port, as the arduino hangs, it does not reset. It is the 2009 arduino.


I understood that problem to be on the PC side of the wire. The screen captures in that thread showed that the error was caused by one or more array limits going out of bounds in Processing. Sounds like you fixed that?

Do you always use aCatuai with a PC connected running pBourbon? When in standalone operation, i.e. no PC connected, do you experience lockups? I would like to work on fixing this, but am struggling to know which side of the USB connection, PC or TC4/Arduino, is crashing things.

Jim
 
Web
JimG
Top  #163 Print Post
Posted on 11/28/2011 9:10 AM

Quote

iBeans wrote:
I wonder if I could use a tablet, like iPad or the driod Vizio for this project.

hmmmm,

toni:BowDown:


Yes, sort of. It would require a serial to WiFi adapter connected to the arduino, and a PC to gather the data stream. From there, the data can be rebroadcast by the PC to an IOS app.

Look for posts by RandyT to describe how he made this work for the Kona application.

Jim
 
Web
Bhante
Top  #164 Print Post
Posted on 11/28/2011 11:39 AM

Quote

JimG wrote: I understood that problem to be on the PC side of the wire. The screen captures in that thread showed that the error was caused by one or more array limits going out of bounds in Processing. Sounds like you fixed that?

Do you always use aCatuai with a PC connected running pBourbon? When in standalone operation, i.e. no PC connected, do you experience lockups?

Earlier I was having crashes associated with the extension of the timescale on pBourbon, which seem to have been resolved by increasing all the arrays by 500 instead of 120, every time the timescale is extended. However that was only one portion of the crashes.

A few times it crashed quite early (within the first ten minutes), which cannot be explained by the above. I have also had a small number of other crashes since extending the arrays.

In addition I get regular crashes on my espresso machine, so much so that I now regularly reset before pulling a shot. In this case the Arduino is running in independent mode, with aCatuai loaded (currently aCatuai 1.10, with various customisations to display, buttons, PWM, 3-digit accuracy on the serial port, etc). I wonder if part of the problem could be the display of the time, overflowing/leaking? The time goes up from 0:0 to 59:59, and then seems to stop there, but later it is then a very large number ...

I did see a simpler way of displaying the time somewhere using a library - I suspect it was probably here:

http://forum.home...post_30601

I was planning to try and modify the time display in aCatuai accordingly, but never managed to find the time to struggle with it.

However it is NOT the case that it crashes after a fixed period - the crash can occur at any time.

Can you think of anything useful that one could write to the EEPROM to track what is going on? Otherwise the crashes have to be reproduced with the PC attached.
 
Bhante
Top  #165 Print Post
Posted on 11/28/2011 11:44 AM

Quote

JimG wrote: I understood that problem to be on the PC side of the wire.

In any case, I don't think it is valid to say the problem is entirely on the PC side, because even if the problem (some of the time only) originates there, it causes the arduino display to freeze.

Maybe a good place to start is to look at what happens if there is a problem on the PC side, and try to understand what effect that has on the arduino.
 
Bhante
Top  #166 Print Post
Posted on 11/28/2011 11:56 AM

Quote

Bhante wrote: I did see a simpler way of displaying the time somewhere using a library - I suspect it was probably here:

http://forum.home...post_30601

Hmmm ... I think it was probably some other espresso project actually. Whatever it was, it was displaying time on the LCD in a simple way.
 
JimG
Top  #167 Print Post
Posted on 11/28/2011 12:00 PM
Thanks for the clarification. Let's try and focus on problems that arise in standalone mode first since that cuts way down on the variables.

Here are the likely suspects, IMO:

- Running out of RAM. The total runtime memory available for global variables, current local variables, and other stack stuff is 2K. If you exceed that then the processor will crash. If this is the problem, then the solution is normally to move static variables into PROGMEM, or use local variables instead of global variables. Arrays are particularly problematic in using up RAM.

- Do you have potentiometers connected to ANLG1 and ANGL2? If not, I would suggest adding jumper shunts to tie the input values to either 0V or 5V. This will eliminate the rapidly fluctuating input values you will get from floating pins.

- Some kind of a glitch on the I2C bus caused by noise on the cable between LCDapter and TC4. As I've said previously, this is sometimes a problem with my installation of a TC4-based PID controller for my Silvia. But it is a rare occurence and does not depend at all on how long the machine has been up and running. When it happens it is always associated with turning the vibe pump on or off.

- aCataui was written with the assumption that it would run for 15 to 20 minutes at a time during a roast. So there may be demons lurking in the code that do not show up until much later. It stops updating the displayed time at 59:59 by design, but should keep running, IIRC.

If you would like to send me your modified aCatuai code, I will diff it with the original 1.10 release and see if I see anything else to suggest.

There is around 63K available on the EEPROM, which will hold a lot of data. EEPROM writes, however, are fairly slow so be selective about what you write and when you write it. There are also some limits to the number of write cycles on the chip. But, hey, chips are cheap ;)

Jim
 
Web
Bhante
Top  #168 Print Post
Posted on 11/28/2011 1:17 PM

Quote

JimG wrote: - Do you have potentiometers connected to ANLG1 and ANGL2?

Quote

Reply: Yes

- Some kind of a glitch on the I2C bus caused by noise on the cable between LCDapter and TC4. As I've said previously, this is sometimes a problem with my installation of a TC4-based PID controller for my Silvia. But it is a rare occurence and does not depend at all on how long the machine has been up and running. When it happens it is always associated with turning the vibe pump on or off.

Quote

Reply: As far as I know, I've never had it associated with the pump. I've always assumed it is most likely associated with the switching of the heater. Do you know for a fact that what you observe is a problem with the I2C, or is that your assumption? Does it garble the LCD display or just freeze it? My LCD just freezes (I have seen the garbled display, but only under unusual circumstances such as loose connections while testing, display connected after reset, etc).

- aCataui was written with the assumption that it would run for 15 to 20 minutes at a time during a roast. So there may be demons lurking in the code that do not show up until much later.

Quote

Reply: Often it can run for many hours without freezing, even though the 59:59 is replaced by a large number

It stops updating the displayed time at 59:59 by design, but should keep running, IIRC.

Quote

Reply: What is behind the display of the large number? Have you seen that?

If you would like to send me your modified aCatuai code, I will diff it with the original 1.10 release and see if I see anything else to suggest.

Quote

Reply: I'll send you a copy of what I use on the espresso machine.


But, hey, chips are cheap ;)

Quote

Reply: Yes, except when they are already soldered in!
 
JimG
Top  #169 Print Post
Posted on 11/28/2011 2:11 PM
The glitches I see once in a while on the LCD take the form of garbled characters. The program actually continues to run. Sometimes it restores itself, but other times I need to reset to fix the display.

Switching the heater, especially with a zero cross SSR, should be fairly innocuous -- at least compared to inductive loads (pump, solenoid, motor).

The timestamp (in seconds) is stored as a float, so can become very large without overflowing. To display it on the LCD, however, the value is stored in a local integer variable. After 9 hours, the timestamp will have grown too large to fit in an integer variable. That might cause it to go a little crazy. But I think we can rule this out, too, since you seem to experience the problems well before 9 hours, right?

The display of a large number on the LCD screen suggests to me that memory has somehow become corrupted. When I receive your code, I will load it into a 2009 Arduino and track memory consumption. I will also let it run for a long period to see if I can replicate the problem here.

Jim
 
Web
Bhante
Top  #170 Print Post
Posted on 11/28/2011 3:48 PM

Quote

JimG wrote:Switching the heater, especially with a zero cross SSR, should be fairly innocuous -- at least compared to inductive loads (pump, solenoid, motor).

I still haven't installed PID, so the switching is from the pressurestat, which is likely to be very noisy.

Quote

JimG wrote:you seem to experience the problems well before 9 hours, right?

I would quite often have an espresso around 4-5 hours after turning on, and by that time it will almost invariably be displaying a large number, and quite often also hung.

Wait a minute though ... I have the arduino on a separate power supply, so it has nothing to do with the espresso machine being switched on, so that would increase the proportion of times that it is over the 9 hours. There are certainly times when it happens in under 9 hours, but I can't say how often. I'll have to make a point of watching that in future.
 
JimG
Top  #171 Print Post
Posted on 11/28/2011 4:02 PM
I have posted your version in a TRY branch on the project googlecode site. You can view a diff for aCatuai.pde here:
http://code.googl...mp;old=774

First thing I noticed is that you are using print() for both integers and for string/character data. I had some trouble (can't remember the specifics) when I tried using print() for integers and floats. So I used sprintf() to create strings from the numerical values, and then printed the strings. Either way should work, though.

I did not see any smoking guns in your revisions (nor in the original). i will keep looking.

Jim
 
Web
Bhante
Top  #172 Print Post
Posted on 11/29/2011 5:36 PM

Quote

Bhante wrote: There are certainly times when it happens in under 9 hours, but I can't say how often. I'll have to make a point of watching that in future.


Arduino has been fairly generous with me in this respect today (observation wise).

1) This morning I noticed it had hung, but with the boiler showing it hung before I switched it off the night before - indicating with fairly high probability that it failed within less than 9 hours (probably about 7 hours or less), displayed time large number.

2) By lunchtime it had failed again - about 4 hours later, displayed time 59:59.

3) When I switched it off in the evening it was still running, after about 8 hours, displayed number 59:59.

- pretty much the full range of possibilities!
 
Bhante
Top  #173 Print Post
Posted on 11/29/2011 6:02 PM

Quote

JimG wrote:First thing I noticed is that you are using print() for both integers and for string/character data. I had some trouble (can't remember the specifics) when I tried using print() for integers and floats. So I used sprintf() to create strings from the numerical values, and then printed the strings. Either way should work, though.

I'm actually printing floats, which is why I changed it. That change went in right from the beginning with aBourbon, and never caused any problems. I think you converted to integers to cramp it into the 16 char screen.

If anyone is interested in trying it, it is optimised for a 20x4 LCD (VERY much worthwhile, in my view), with decimal output of temperatures and RoR. The display can be quite simply cramped back into a 16x2 for those who don't have the 20x4. If using only one sensor (I use 1 on my roaster, 2 on my espresso) the NCHAN can be changed to 1 and LOOP can safely be reduced to 500, maybe less.

You'll notice I also put spaces in the serial output - makes it a LOT easier to read!
Edited by Bhante on 11/29/2011 6:03 PM
 
JimG
Top  #174 Print Post
Posted on 11/30/2011 12:48 PM
I soldered a 20x4 LCD to a spare LCDapter, flashed your unmodified aCatuai code into an Uno/TC4 version 5.20 shield, fired up the serial monitor in the Arduino IDE, then set everything on the desk and let it run on USB. So far (almost 4 hours), I cannot get it to do anything bad. The timer display stops at 59:59, as expected. But the data stream from the TC4 to the PC is continuing per normal behavior.

I will start it up again later and let it run overnight to see what happens.

I have also checked available RAM. Looks like there is over 900 bytes unused, so I do not think this is the problem.

I am beginning to suspect that perhaps transients from switching the heater with mechanical contacts may be the culprit as you suggested. Perhaps a snubber could be added, or maybe use the pressuretat to switch a smaller load (e.g. SSR).

Until I can reproduce the problem, I am running out of other ideas.

Jim
 
Web
JimG
Top  #175 Print Post
Posted on 12/01/2011 7:34 AM
Bhante -

The large number you are seeing on the LCD in place of the elapsed time is indeed due to overflowing the integer variable after 9 hours. I made a simple change to the code to trap this error.
http://code.googl...tail?r=777

The overflow did not cause my setup to lock up, however. So that part of the problem remains.

Jim
 
Web
Page 7 of 13: 1...45678910...13
Jump to Forum: