Homeroasters - Home Roasting Coffee Community » DATALOGGERS - CONTROLLERS - RATE OF RISE METERS » Dataloggers/Controllers/Rate of Rise Meters
Who is here? 1 guest(s)
Page 6 of 13: 1...3456789...13
 Print Thread
TC4 - Coding and tech issues
Bhante
Top  #126 Print Post
Posted on 07/22/2011 1:26 PM

Quote

JimG wrote:
You might want to consider this instead (using 4N25 optoisolator)

Hmm. My first reaction was one of overkill! I was looking for a transistor to replace a hex inverter, then I have to add an optoisolator even though it is only logic signals between two 5V systems ...

On the other hand it does make sense to separate the two circuits when you consider that the Hottop circuit is more on the war front, so to speak. But it doesn't make so much sense to put an optoisolator on one signal and leave the two circuits connected for the fan ... and then in the future I want to control Eject from the Arduino, and later maybe also bean entry with a solenoid ... and ultimately get rid of the Hottop controller altogether! Even the Hottop's own heat sensor also comes into the picture at the back of my mind - not because I imagine it is good for controling roast profiles but because it is a central part of the Hottop's safety features, and I have no intention of trying to repeat the manufacturer's safety investigations!

I think the best bet at this stage is to keep the interface as simple as possible. If I go for two optos for OT1 and IO3 - something like HCPL817 which is a low cost 4-pin device - the right side of the circuit should be identical for the OT1 and IO3 lines shouldn't it? On your 4N25 circuit the base is just left unconnected is it?

Bhante
 
JimG
Top  #127 Print Post
Posted on 07/22/2011 1:59 PM

Quote

Bhante wrote:I think the best bet at this stage is to keep the interface as simple as possible. If I go for two optos for OT1 and IO3 - something like HCPL817 which is a low cost 4-pin device - the right side of the circuit should be identical for the OT1 and IO3 lines shouldn't it? On your 4N25 circuit the base is just left unconnected is it?

Yes, I think the right (Hottop) side would be the same.

The base connection to the 4N25 transistor, I believe, is to adjust sensitivity. I can imagine that adding a small bias voltage to the base of the transistor might cause it to turn on with a smaller current through the LED. This is just some speculation on my part, however, since I've not ever played around with the base connection.

Something to keep in mind: the optoisolator transistor (at least in the 4N25) will not pass much current. I think in my simulation it maxed out at around 5mA emitter current. I'm not sure what components on the Hottop PCB you will be driving with the PWM signal, but that is something to keep in mind.

You could squeeze a little more out of it by using a smaller resistor on the TC4 side (shown as 470 ohm in my sketch).

Jim
 
Web
Bhante
Top  #128 Print Post
Posted on 07/22/2011 2:55 PM

Quote

JimG wrote:
the optoisolator transistor (at least in the 4N25) will not pass much current.

All I'm driving is a logic signal between the PIC* on the controller and the ULN2003 on the mainboard. Nothing else. The Hottop mainboard does all the rest.

* actually I am simulating the signals from the PIC
Edited by Bhante on 07/22/2011 2:56 PM
 
lmclaren
Top  #129 Print Post
Posted on 07/24/2011 2:52 AM
Both using a single transistor (NPN) or an opto coupler will work, It never hurts to have more isolation but as you say, you are not isolated until all the connections are.

best regards.

Lee
 
Bhante
Top  #130 Print Post
Posted on 08/30/2011 9:48 AM
@Jim

I have an issue concerning the 16bit PWM. I have been experimenting with it to regulate my espresso pump pressure, and am getting some odd results. I've tried several different frequencies, but whichever one I use I get a periodic variation with a period somewhat less than a second (maybe a third of a second or so, but I cannot say how much with any confidence). Without an oscilloscope I can also not say with any certainty whether the observed ?1/3s? periodicity is superimposed on a properly formed PWM with the expected frequency, or whether the ?1/3s? periodicity is the only output variation I get at all. However what I can say with certainty is that the quality and feel of the result varies according to the frequency used.

What I observe is that the pump output stops altogether a few times per second. For the rest of the time the pump pumps either more regularly or splutters more, according to the frequency used. The length of the pauses depends directly on the duty cycle.

The PWM output on OT1 goes to an SSR (240D25 made by opto22, with zero crossing), which switches the pump. I can modulate the amount of water pumped, as a result of which the pressure is reduced, although actual pressure obtained depends on the resistance of the puck.

Is is possible that the PWM output gets interrupted during part or parts of the 1 second loop in the Arduino program? At first I suspected something going on in the main loop which takes temperature samples and sends data to the serial port that might be interfering with the PWM generation, but the period is well under a second so it should not be that. Perhaps another loop?

Or have I lost something in the generation of the PWM frequency? All I did in aCatuai was to change the value of TIME_BASE. In PWM16.h I defined two extra frequencies 10Hz and 20Hz (constants 1637 and 818), and that is all I changed. I tried 10Hz, 20Hz, 4Hz and 1Hz. I saw a variable named pwmN1 in PWM16.cpp, but as far as I could see that will be set by whatever value is passed to it from aCatuai. Is there something I have missed?

I am also wondering if this could explain the relatively feeble power in my hottop heater? (Most likely not, however, because with the above experiments the pump ran continuously after it was set on 100%).

Bhante
Edited by Bhante on 08/30/2011 9:58 AM
 
Bhante
Top  #131 Print Post
Posted on 08/30/2011 10:13 AM
@Jim - Sorry, another question.

What is the current status of OT2 in aCatuai? What do I need to change in order to use it? Can I get a separate duty cycle in OT1 and OT2? The PWM frequency has to be the same for both, I think.

On my espresso machine I want to use OT1 for the heater and OT2 for the pump, probably with a frequency of about 10Hz. The heater should be controlled by PID, while the pump pressure should be controlled by a potentiometer.

I also noticed that if either one of the two potentiometers is installed while the other is not, both duty cycles are set from the one potentiometer. Is this property determined by the hardware or the software? Can I override it in the software (i.e. so that if only one pot is installed the duty cycle of the other channel is unaffected by the pot setting)?

Bhante
 
Bhante
Top  #132 Print Post
Posted on 08/30/2011 10:31 AM
On roasting templates.

The facility to display a previous roast profile as template for subsequent roast profiles is really useful. For example, if I am roasting a new bean and get a reasonably good result, and want to almost replicate it but with a specific difference, this is easiest by getting the target profile superimposed on the template profile.

The problem is that sometimes the timescales do not correspond. For example if the template profile started with a warm roaster (i.e. not the first roast) then the starting time will be almost impossible to reproduce.

What would be really nice would be if the template curve could be shifted to the left or right with the cursor keys, so that the template corresponds more usefully to the current curve. Would this be difficult to implement?

Another possible strategy would be to look at the temperature at the start of the template and shift it automatically so that it crosses the current profile at the same temperature - thus if the template roast started warm it will be shifted to the right. If the template started cold and the current roast started warm, the template will be shifted to the left. Still better - since the roast starting warm will still have a nearly flat gradient at the start - would be to take a point a fixed time after start of the preheat where the gradient is expected to be roughly constant, or a comparison temperature located in the steep part of the preheat. Then as long as the drop-in temperature is the same the start of the roast curves will correspond.

Bhante
 
JimG
Top  #133 Print Post
Posted on 08/31/2011 5:46 AM

Quote

Bhante wrote:
@Jim

I have an issue concerning the 16bit PWM. I have been experimenting with it to regulate my espresso pump pressure, and am getting some odd results. I've tried several different frequencies, but whichever one I use I get a periodic variation with a period somewhat less than a second (maybe a third of a second or so, but I cannot say how much with any confidence). Without an oscilloscope I can also not say with any certainty whether the observed ?1/3s? periodicity is superimposed on a properly formed PWM with the expected frequency, or whether the ?1/3s? periodicity is the only output variation I get at all. However what I can say with certainty is that the quality and feel of the result varies according to the frequency used.

What I observe is that the pump output stops altogether a few times per second. For the rest of the time the pump pumps either more regularly or splutters more, according to the frequency used. The length of the pauses depends directly on the duty cycle.

The PWM output on OT1 goes to an SSR (240D25 made by opto22, with zero crossing), which switches the pump. I can modulate the amount of water pumped, as a result of which the pressure is reduced, although actual pressure obtained depends on the resistance of the puck.

Maybe what you are seeing are the "beats" from superimposing the PWM frequency on the pump frequency (60Hz). If it is an Ulka vibe pump, it runs on a half-wave rectified AC voltage source. The SSR can only turn one of the 60Hz AC pulses completely on or completely off, depending on whether the PWM signal happens to be high or low at the start of each half wave.

I have never tried PWM to regulate an AC device, so I'm not sure how you go about fixing this issue.

Quote

Bhante wrote:
Is is possible that the PWM output gets interrupted during part or parts of the 1 second loop in the Arduino program? At first I suspected something going on in the main loop which takes temperature samples and sends data to the serial port that might be interfering with the PWM generation, but the period is well under a second so it should not be that. Perhaps another loop?

Shouldn't happen because the PWM signal is generated directly by the hardware of the ATmega chip.

Quote

Bhante wrote:
Or have I lost something in the generation of the PWM frequency? All I did in aCatuai was to change the value of TIME_BASE. In PWM16.h I defined two extra frequencies 10Hz and 20Hz (constants 1637 and 818), and that is all I changed. I tried 10Hz, 20Hz, 4Hz and 1Hz. I saw a variable named pwmN1 in PWM16.cpp, but as far as I could see that will be set by whatever value is passed to it from aCatuai. Is there something I have missed?

That should work.

Jim
 
Web
JimG
Top  #134 Print Post
Posted on 08/31/2011 5:56 AM

Quote

Bhante wrote:
@Jim - Sorry, another question.

What is the current status of OT2 in aCatuai? What do I need to change in order to use it? Can I get a separate duty cycle in OT1 and OT2? The PWM frequency has to be the same for both, I think.

OT2 is not used by aCatuai. There is not a quick and simple answer to what you would have to change to use OT2, but the source code should be fairly easy to follow.

Yes, OT1 and OT2 are both controlled by the same timer, so they must run at the same frequency. The duty cycles can be different, but the base frequency must be the same.

Quote

Bhante wrote:
On my espresso machine I want to use OT1 for the heater and OT2 for the pump, probably with a frequency of about 10Hz. The heater should be controlled by PID, while the pump pressure should be controlled by a potentiometer.

If you wish to try and control your pump output digitally, I would suggest instead using IO3 (aCatuai is already set up for this). Run the 490Hz PWM output from IO3 through a low pass filter so that you get a 0 - 5V analog signal that corresponds to 0 - 100% duty cycle. Then use the 0 - 5V signal to drive a phase control SSR (or build your own triac circuit).

Quote

Bhante wrote:
I also noticed that if either one of the two potentiometers is installed while the other is not, both duty cycles are set from the one potentiometer. Is this property determined by the hardware or the software? Can I override it in the software (i.e. so that if only one pot is installed the duty cycle of the other channel is unaffected by the pot setting)?

This is because the second analog input pin (ANALG2) has been left floating. Its value is undefined, actually. It just usually happens to follow the value on ANLG1. But you can/should not depend on this.

Jim

(EDIT)
If you have a need to vary the PWM frequency on IO3, this capability has been added to a pending revision in the PWM16 library:
http://tc4-shield...-IO3/PWM16
Edited by JimG on 08/31/2011 6:01 AM
 
Web
Bhante
Top  #135 Print Post
Posted on 08/31/2011 8:16 AM

Quote

JimG wrote:
If you wish to try and control your pump output digitally, I would suggest instead using IO3 (aCatuai is already set up for this). Run the 490Hz PWM output from IO3 through a low pass filter so that you get a 0 - 5V analog signal that corresponds to 0 - 100% duty cycle. Then use the 0 - 5V signal to drive a phase control SSR (or build your own triac circuit).

At present I am using OT1. 10Hz works OK (apart from the periodic glitch, which occurs at all frequencies). I have tried IO3 but the lowest frequency I can set is 30.5 Hz, which is too fast - I can get some variation in pump output, but only maybe 80-100%. I have "read" (actually on a Korean web page in Korean - a comparison table partly in English appears to say this) that the Ulka can only be well regulated using PWM not phase control. Therefore I'd be reluctant to invest time and expense on developing a phase control circuit without knowing whether it will work. The company on whose website the above table appears (seems to be an Ulka distributor) manufactures a PWM control circuit for the Ulka. I tried sending them an email in English, but didn't get any reply.

Quote

JimG wrote:
If you have a need to vary the PWM frequency on IO3, this capability has been added to a pending revision in the PWM16 library:
http://tc4-shield...-IO3/PWM16

This looks similar to what I have been using, but it is nice to be put in the library. I'll try experimenting with it. If your developments to the library are ongoing I'd like to make a few suggestions: (1) for 50 Hz mains frequencies like 10 Hz, 5 Hz, 20 Hz on OT1 are very useful; for example with 10 Hz you can get 5% steps from 0 to 100%. (2) Have you worked out how to do 0 to TOP on Timer 2? If so, it would be nice to have it implemented in the library; when I tried it I couldn't get it to work - not sure if I was setting the OCRA and OCRB registers correctly.

Bhante
 
JimG
Top  #136 Print Post
Posted on 08/31/2011 12:28 PM

Quote

Bhante wrote:
I have "read" (actually on a Korean web page in Korean - a comparison table partly in English appears to say this) that the Ulka can only be well regulated using PWM not phase control. Therefore I'd be reluctant to invest time and expense on developing a phase control circuit without knowing whether it will work. The company on whose website the above table appears (seems to be an Ulka distributor) manufactures a PWM control circuit for the Ulka. I tried sending them an email in English, but didn't get any reply.

I have seen this web page also. But I was unable to tell if they were using frequency modulation, or the type of PWM that you are describing.

The language barrier is difficult!

Jim
 
Web
arriflex
Top  #137 Print Post
Posted on 08/31/2011 1:14 PM

Quote

JimG wrote:
BTW, this system will work VERY WELL without doing any calibration.

Jim


I thought that I remembered when I first loaded up aCatuai the ambient sensor reported a valid ambient temperature without having "calibrated" the system. I am assuming that was because it read the eeprom numbers properly but don't recall whether or not the eeprom read succeeded or failed.

However, after playing/hacking with the program, and uploading modifications, it now reads all 0's out of the eeprom for calibration (after telling me it successfully read the eeprom) which multiplies my ambient sensor to 0. As you can imagine, this makes the thermocouple information useless!

Anyway, by just forcing the program to load the default program values, it works close enough for government work (not having checked calibration for accuracy yet).

Does anybody have any idea what I might have done to wipe out the calibration information in the eeprom? I don't believe I have run the writeCal.pde unless it was called from inside one of the other programs. Or am I just crazy and it wasn't there to begin with.

As an aside, we should probably add a very minor sanity check to the eeprom library so that it doesn't return 0's or maybe other extreme values to the program and instead "fails" to the default values.

I can take a whack at it, but I warn that I'm an extreme noob here.

Thanks for your impressive work!

arri
 
JimG
Top  #138 Print Post
Posted on 08/31/2011 3:08 PM
Hi, arri -

Depending on what applications you may have loaded, it is possible that the calibration space in the EEPROM was corrupted. Both Bourbon and Catuai will try and read calibration information, but will not overwrite that spot. Hopefully, other TC4 applications also will leave that spot in the EEPROM alone.

You have reminded me that I really do need to get around to making the error checking more robust for reading calibration data. Currently, I think Catuai just checks to see if it successfully read "N" bytes, but doesn't sanity check the values.

This weekend I will put something in the mcEEPROM library that does a better job of error checking.

For now, though, you should be able to download and run writeCal.pde to restore your EEPROM to default values. (If I calibrated your board for you, then the gain and offset values will be scrawled on the back of the board in black Sharpie.)

http://tc4-shield...iteCal.pde

Jim
 
Web
arriflex
Top  #139 Print Post
Posted on 08/31/2011 11:02 PM
Thanks, good to know. I actually did the soldering so I'd be surprised to find your calibration on my board! Calibration is not going to be to important for me as I am going to be pushing the thermocouples to 800 deg F or so where plus or minus twenty will not be that big a deal for me.

I haven't actually checked the type-K library to see how it handles the higher temps, but it should be fine.

I'm using a beautiful Simpson 0-10 amp model 29 meter (clipped the shunt and added a 1k resistor to use as a 0-5vdc voltmeter) to display the temps and just discovered the Arduino's map function.
 
JimG
Top  #140 Print Post
Posted on 09/01/2011 6:48 AM

Quote

arriflex wrote:
... I am going to be pushing the thermocouples to 800 deg F or so where plus or minus twenty will not be that big a deal for me.

I wouldn't expect the error to be more than 1 or 2 degrees if you simply use writeCal to populate the EEPROM with default values of 1.000 gain adjustment, and 0.0 offset values.

Jim
 
Web
bvwelch
Top  #141 Print Post
Posted on 09/01/2011 8:05 AM
You may want to check the specs on the TC wire itself -- my guess is the TC4 and the libraries are more accurate than the wire I am buying. :-)
 
JimG
Top  #142 Print Post
Posted on 09/02/2011 3:16 PM

Quote

Bhante wrote:
... and OT2 for the pump, probably with a frequency of about 10Hz.

Bhante -

I have been thinking about this problem, and have an idea (untested, of course) that you might want to consider.

Instead of using an SCR to switch the pump, why not try a power MOSFET instead? This would get away from the problem of having to switch in sync with the zero cross point.

My thinking is to set up IO3 with a PWM frequency of 1kHz or higher. Connect IO3 to an optoisolator and use the optoisolator to drive the gate on the MOSFET.

The Ulka pump runs on a half-wave rectified AC voltage. For 50Hz mains, each pulse that reaches the pump is 10ms long. So if you used a PWM frequency of 1kHz, you would chop the AC pulse up into 10 subintervals, each 1ms long. Using PWM you would fire the MOSFET for some fraction of each 1ms subinterval.

My thinking is that the pump won't "feel" the 1ms mini-pulses, but will instead react to the RMS voltage of the 10ms AC pulse instead.

Just an idea.

I've attached a plot showing what I think the pump would see at a duty cycle of 50% on a 1kHz PWM signal.

Jim
JimG attached the following image:
ulka002.jpg
 
Web
Bhante
Top  #143 Print Post
Posted on 09/02/2011 5:42 PM

Quote

JimG wrote:
I have been thinking about this problem, and have an idea (untested, of course) that you might want to consider.

Thanks for the ideas, Jim. That would be interesting to try. I've got a little circuit planned at the moment for using an AC switch, ACS120, just as soon as I can find the time to get a couple of basic components that I lack. That should be able to do just what you propose.

Another thought, partially related and partially different: one of the few things I have managed to find on the internet is a patent for a drinks vending machine based on an Ulka pump (presumably one of the 28V DC models).

http://www.patent...05373.html

That first talks about using a fixed width 15ms square-wave pulse at a variable spacing ranging from 15ms to 185ms (50% to 7.5% duty cycles; although when you consider the nature of the Ulka perhaps you could consider it as 100% to 15%) - rather different from the normal PWM signal, but it's not difficult to imagine that it would be an effective control of the Ulka output. Then he goes on to propose a similar signal with narrower on-pulse for less viscous fluids going down to 15/16ths of a millisecond (1/16th of the output power). That seems to show a two-dimensional PWM which is rather interesting. My experiments show that my current implementation can reach a pressure of over 10 bar (and that with a significant flow through the OPV) as long as flow is sufficiently restricted. Ultimately I am not limiting pressure as such but flow, and pressure only as a secondary effect. What the above patent is effectively doing is: (1) on the first dimension controlling flow rate at constant pressure by varying interpulse period; and (2) on the second dimension controlling pressure at constant flow by varying on-pulse width.

It would appear that both of these dimensions are relevant to espresso machines. Flow rate control is exemplified by the difference between a normal espresso and a ristretto, while pressure control is exemplified by the difference between the resistances of different coffee pucks. It may even be that by setting up two potentiometer knobs for controlling these two variables, we could vary these two parameters independently - one knob to select the appropriate flow rate for ristretto or normal espresso, and the other to select the desired pressure to compensate for any error in tamping or grind setting - or for pressure profiling during the shot. (Once initial experimentation is completed of course we could replace the first knob by software selection of shot type).

The Ulka E5 series pumps are nominally AC pumps, but I can imagine they could also be used in an effectively "DC" mode - i.e. by square-wave pulses along the lines described in the above patent. One problem might be the very rapid current decay of the square wave. Another might be the magnitude of the DC voltage required, although perhaps the rapid current collapse might reduce the magnitude of the DC voltage required, I don't know. Probably the DC square-wave voltage could also be generated simply with rectified mains, capacitors, and switching.

The AVR timers have options for detailed manual control of the waveform, but are notoriously complicated. Do you have any feeling for how difficult it would be to program such waveforms as those above, and whether it might be within reach?

Quote

JimG wrote:My thinking is that the pump won't "feel" the 1ms mini-pulses, but will instead react to the RMS voltage of the 10ms AC pulse instead.

The patent cited obviously refers to a different pump from that used in espresso machines, but I suspect the only differences lie in the coil windings, lack of diode, and control systems (and perhaps also piston dimensions). It probably will feel a 1ms pulse provided it has an adequate minimum spacing (presumably 10ms for the Ulka E5 series), but will only generate a very low pressure from it, whereas a full 10ms pulse followed by at least 10ms pause would develop the full 15 bar pressure. On this theory the E5 pumps would have a different resonant frequency to the drinks dispensing machines in the patent, and therefore the optimal on-pulse width and spacing would vary accordingly (it might also be a little shorter than 10ms, bearing in mind that the start and end of the mains pulse is of low amplitude).

It may also be possible using a different approach, namely simply using one standard PWM signal to modulate a second.

Bhante
Edited by Bhante on 09/02/2011 5:54 PM
 
JimG
Top  #144 Print Post
Posted on 09/03/2011 6:41 PM

Quote

JimG wrote:This weekend I will put something in the mcEEPROM library that does a better job of error checking.

I have added some code to the mcEEPROM library that checks to see if the string "TC4" is found where it is expected in the block of EEPROM set aside for the calibration info. If it finds this string, it presumes that the other calibration values are also OK.

This new code has now been incorporated into the Bourbon and Cataui programs, and can be downloaded from the project googlecode site:

http://code.googl...loads/list

If the attempt to read the EEPROM fails, both of these programs will fall back to default values, i.e., no corrections to the values returned by the hardware.

The new versions of Bourbon and Cataui also support more thermocouple types: K, J, and T now.

Jim
 
Web
arriflex
Top  #145 Print Post
Posted on 09/04/2011 12:11 AM

Quote

JimG wrote:
If the attempt to read the EEPROM fails, both of these programs will fall back to default values, i.e., no corrections to the values returned by the hardware.


Nice. Worked for me:
Code Download source  

—??# Failed to read EEPROM.  Using default calibration data. 

# time,ambient,T0,rate0,T1,rate1,[power1],[power2]

1.0,79.6,51.7,-0.5,311.7,-28.5,60,55


I'll upload the default values to the eeprom so they're there. Thanks for all your work!

arri
 
UNM
Top  #146 Print Post
Posted on 09/14/2011 6:32 AM
Got my TC4 and LCDadapter yesterday afternoon. It's been many years since I wielded a soldering iron for anything electronic, but got the TC4 together without any major problem.
Bent the I2C pins sideways so I could wire to SDA and SCL on the Mega1280 with a jumper cable (would attach a picture but I can't work out how to).

Finally tracked down an RJ11 connector that fits the LCDadapter in the second parts store I visited.

Had a few problems getting the LCDadapter assembled as I bought a cheap LCD shield (cheaper than a separate LCD) and had to desolder the LCD display - wont do that again as it took far longer than expected and LCD took a dive off the workbench when it finally came free from the shield.

Setup aBourbon/pBourbon tonight and fired up (no TC attached). No LCD display (just dim image of dark rectangles on top line), pBourbon was tracking environment temp accurately in Celsius.

I thought I might have hooked the LCD with wrong polarity and blown something so checked again and no luck. Finally pressed reset on the TC4 board and the LCD sprang into life. All working now - displays time and 'E', 'B' temps both at 22C, ROR1 at +00.

All is good. No doubt much learning and troubleshooting ahead, but so far remarkably easy to get up and running with the basics with nothing but expected teething issues.
I can confirm the Arduino Mega1280 works fine with the TC4/LCDadapter.

Next step test with thermocouples (need to set up a laptop and connect to roaster for that), then start reading code.
Edited by UNM on 09/14/2011 6:33 AM
 
JimG
Top  #147 Print Post
Posted on 09/14/2011 9:21 AM
UNM -

Glad to hear you have joined the TC4 crowd :)

I'm not sure if this applies in your case, but I have found that the LCDapter and panel need to be connected to the TC4/arduino, and then everything powered up together, to work reliably.

Jim
 
Web
Bhante
Top  #148 Print Post
Posted on 09/15/2011 10:23 AM

Quote

Bhante wrote:
What I observe is that the pump output stops altogether a few times per second. For the rest of the time the pump pumps either more regularly or splutters more, according to the frequency used. The length of the pauses depends directly on the duty cycle.
...
Is is possible that the PWM output gets interrupted during part or parts of the 1 second loop in the Arduino program? At first I suspected something going on in the main loop which takes temperature samples and sends data to the serial port that might be interfering with the PWM generation, but the period is well under a second so it should not be that. Perhaps another loop?

It seems I've finally managed to narrow this down a bit. By varying the loop delay length, number of channels, and the PWM period I believe I have established that the spluttering is coming from the 1 second loop, but it is also affected by the number of TC channels operating as well as the delaytime (length of the loop). The spluttering of the pump has a period of about 1/3 of a second, which is roughly the time required for each TC channel.

It looks like the PWM is being stopped/blocked during the reading of the thermocouples, and then re-enabled around 300 ms later - hence the circa 300 ms period of the spluttering. If the delay is shortened so that the idle time is well under 100ms (but the serial output to Processing is still flawless), then the PWM signal sometimes doesn't seem to get turned back on. It is also affected by the length of the PWM period - in some cases with a long period the signal is less affected by the 300 ms cycle, while in other cases the long period can be much more badly chopped, especially with low duty rates. With a 4 second period when a pulse is missed nothing happens for at least 4 seconds thereafter. If the duty rate is set to 100% within this 4 seconds, it still takes the full 4 seconds (i.e. much more than the length of the 1000 ms cycle) before it comes back on. This leads me to suspect that the Timer1 counter is counting normally as it should, but the pulse edges are sometimes blocked - seems rather suggestive of an interrupt-related problem. When the edges of the PWM signal occur at certain critical points in the main loop a single pulse is lost. When the idle time is about 12 ms and the duty cycle is low, it sometimes results that the pulses are completely or almost completely blocked, with only the occasional pulse.

This may also explain why I am short of power on my Hottop when I roast with Catuai - on what should be maximum power the heater is only on 2/3rds of the time.

What is really needed is an oscilloscope to look at the PWM outputs, but of course I don't have one. Although I heard there is some way of connecting a signal to a sound card to get it displayed in an audio program like an audio wave, but I am not sure I want to risk my computer on that.

How exactly does this main 1000 ms loop work? Is what is labelled in the program as idle time really idle, or is something else happening during that time? Is there something that could interfere with interrupts?
Edited by Bhante on 09/15/2011 10:26 AM
 
JimG
Top  #149 Print Post
Posted on 09/15/2011 2:46 PM
The main loop first performs an "active delay" while waiting for the system timer to reach the next multiple of 1000ms. The "active delay" checks for changes to the two analog inputs (potentiometers), checks to see if a button has been pushed, and checks for new serial input.

Still in the main loop, when the next 1000ms marker comes up, then the "active delay" ends and control shifts to gathering samples from the ADC. The sampling routine also has an active delay (300ms per channel). During this time, the buttons and pots are being monitored in parallel with the ADC performing a conversion. Interrupts should be enabled during this 300ms period.

Once all the channels are sampled, control returns to the main loop. The samples are then sent to the serial line and the output on OT1 is adjusted to whatever the currently user-requested value is. The time mark for the next loop is incremented, and the main loop starts over again.

There is never any strictly idle time. During all timing delays, something is going on. Either the ADC samples are being converted, or inputs are being monitored, or both. And interrupts are never disabled in aCatuai.

Something to note is that while the pots are sensed almost continuously, the actual duty cycle OT1 is only updated once per second. The way the timer registers work, supposedly, the new value for duty cycle can be sent to the timer register at any time, but the new value will only become active after the last full cycle of the timer has ended.

I don't immediately see anything in the aCatuai code that explains what you are observing, but when I have a chance I will put a scope on OT1 and see what I can learn.

Jim
 
Web
JimG
Top  #150 Print Post
Posted on 09/16/2011 9:30 AM
I've watched the waveform on OT1 across a range of PWM base frequencies (2 sec, 1Hz, 4Hz, 16Hz, 50Hz, and 60Hz). I didn't find any pulse skips, etc., that would explain what Bhante is observing with his pump, so the mystery remains.

Two things I did notice, however, that were interesting:

1. In order to get a clean waveform on OT1, there needs to be a little bit of a load present. When only the high impedance scope leads were connected, the wave form was pretty messy. So I put an LED and 500R resistor across the OT1 terminals. The waveform became steady and clean with this load present.

2. There is a 60Hz waveform (mains frequency), with an amplitude of around 1V, superimposed on the square wave PWM output. I saw this "noise" both when connected to USB power and with a 9V battery (alone) powering the arduino. For most components, like SSR's, this 1V noise will be below the switching threshold. But for some sensitive gate components, a low pass filter might be needed?

@Bhante: In lieu of a scope, suggest that you connect an LED (and current limiting resistor) across the OT1 terminals to see if output pulses are being skipped. You can have this in place while the pump is also connected to see if there is any correlation between pump behavior and LED pulses.

Jim
 
Web
Page 6 of 13: 1...3456789...13
Jump to Forum: