The Bud Toaster - (currently: Model 14, version 3)

[Purple-Days]

It's funny how so many people think diamond is indestructible.

Yep, tool wear and electricity and taxes and a hell of a lot go into figuring the price of a vape (or other product). Folks sometimes look at the parts and forget it's more than marking up a bunch of curved yellow fruit at a roadside stand.

 

[Bubar]

My plan was to usea burr bit to put a divot, then a twist bit to actually drill through. I have access to mill, press, dremel, more tools than I can find uses for. I've already drilled the holes a few times through the mason jars I use as housing.

It worked good in a drill press. Didn't bother with anythign fancy. The burr bit was actually sufficient. Didn't need the twist bit. Soon I will post a video of the new glassware. Its cool that its really easy to see the vapor forming in the bowl with the lid of the mason jar is off.

 

[Hippie Dickie]

okay, cool.

i thought you might be going with the screen-less configuration using 0.75mm holes in the end of the glass. Those bits are the same diameter on the shank, so they are incredibly hard to hold in the dremel collet. i finally cut three lengths of wire insulation (about 28 gauge, i think, and remove the wire itself so the insulation is empty) ... i put these in the collet and that holds the 0.75mm bit very securely. It took me 4 years to discover this configuration ... i used to wrap the shank with tape, but that didn't work as well.

i know what you mean about seeing the vapor ... very satisfying ... and easy to see when the bud is cashed out.

i just woke up to a nasty surprise, my new best friend, version 4e, won't turn on this morning ... it worked perfectly fine at 11PM last night ... it lights the blue LED, flashes the green LED (so the power system and PIC are running just fine) ... when i hold the button to initiate the vape sequence, the red LED flashes one time and then ... nothing.

WTF???

! ... damn cats! ... MUST have been one of the cats, and i think i know which one. (we have a Mensa kittie).

 

[Hippie Dickie]

Whew! Just fixed it ... appeared to be a loose solder connection on the Gate connection for the MOSFET. i think the line from the PIC processor was loose from the use of the SOIC clip to attach the programmer to the PIC to do software updates. i must have attached/detached that clip 2 dozen times ... it is spring loaded and one or two times it snapped and jumped off the pins. Must have loosened the PIC pin 6 from the pcb.

Or, just the kind of thing that cat would do to deflect suspicion.

Anyway, when i tried a test run the temperature control is much better. i was seeing some weird behavior the last 3 or 4 sessions, so that is probably due to the cold solder joint, that would work better when the vape reached vape temperature.

So, it appears the PID coefficients are better than the last several runs would indicate.

Very exciting.

 

[chucku]

I wish there was a good tool for scraping down the insides of the vapor tube. Some vapor condensate gets trapped above where it gets hot if I just try to stick the tube straight into the vape. Right now to get rid of it I just use a lighter and hit it like a crack pipe.

Hippie Dickie
2010-02-07 08:11:41 pm
That stuff collects at the bottom of the tube i use for the whip. i just stick it into the oven tube and hit it - but it doesn't do much. better and easier to just swab it out with a rolled up piece of paper towel. Sometimes i shake some iso in the tube to clean it.

Guys,

If the bore of your draw tubes is big enough, consider using a gun cleaning kit. Instead of Hoppes #9 soak the patches in iso or everclear. The patches are cotton and cheap. If a 22 cal swage is too small a 25 cal or 9mm swage should do the trick.

 

[Hippie Dickie]

chucku - thanks for the suggestion -- it's really not that big a deal.

my previous analysis of why the BT4e wouldn't start was completely bogus ... it was just too cold in my office when i tried to start it up. The same thing happened today, supposedly after the above fix ... hmmmm ...

So i took the pcb out of the enclosure, did some heavy breathing on it to raise the temp above the 47F ambient in my office, reassembled it, plugged it in and it started right up. That's right! The PIC has a lower temperature limit and the ambient was simply too cold.

All is right in Hippie Dickie land again ... even if it is too friggin' cold.

 

[Bubar]

Wow. That is truly strange, because the manufacturer rates them as operating fine down to -40C.

 

[Hippie Dickie]

Damn, you're right! True for the MAX, MOSFET and vReg, too. It wasn't THAT cold in my office ... but this happened on two separate occasions. So i'm back to suspecting a cold solder joint.

i need to build a couple more to see if i can get some consistent data. i finally (FINALLY!!!!) found a hole saw that has almost the same thin kerf, so i'm good to go cutting the groove in the cherry wood discs for the top and bottom pieces of the enclosure.

And, i really want to use some hot pink leather i got on eBay for the next one ... going to a girl, of course.

 

[Bubar]

What PID constants are you using now?

 

[Hippie Dickie]

very ineffective ones, it seems ... i spent some time with Wikipedia rereading the PID stuff. i'm in the process of rewriting that algorithm right now ... check back later tonight.

 

[Bubar]

Too bad. What happened to the 1F swing?

I just rewrote my display code today to include 3 modes:

1 While heating a progress bar
T:XXXXXXS:XXXXXX
@@@@@@@ |

2 When in range of set point
T:XXXXXXS:XXXXXX
Wait for it....

3 After it's been at set point for a while and the vapor is starting to form (45s-1min?)
T:XXXXXXS:XXXXXX
Hit that shiat

 

[Hippie Dickie]

Cool on your 3 modes. i love this part of a project where it is possible to add cool stuff like that.

i get periods of extreme stability for several 10s of seconds, then it goes ape shit and does a 20F swing. i'm still trying to figure out wtf is going on.

 

[Bubar]

If the stability erodes I would say you probably have too low integral gain. The integral is what "eliminates" (theoretically) the steady state error. The errors close to the set point are near zero, and if there was much overshoot or oscillations above the set point, then a lot of the cumulative sum is gone. So if the integral gain is too low it will drop off until the proportional term kicks in or later when the integral kicks in, if the proportional gain is not high enough. You gotta read though the pid stuff and maybe play around with some of the java applets around the web that allow you to look at how it looks when you vary the constants. P increases speed and oscillations, integral fixes steady state error and provides a base line duty cycle to keep it on the set point when it is close, and derivative smooths/slows the response and decreases oscillations.

 

[Hippie Dickie]

Thanks - that's all beginning to make a lot more sense.

i've also just learned that the derivative term should be calculated from the actual measured output (the COILTEMP) rather than the error (SETPOINT - COILTEMP) to avoid a discontinuity when the SETPOINT changes.

Getting the PID right is my mission for today. That and relearning ASP.NET (via Visual Studio 2008).

 

[Hippie Dickie]

Some success today!

so the coefficients i am using are ... (Tada!) ...

DUTYCYCLEnew = DUTYCYCLEold + (8 * P) + (1/8 * I ) + (32 * D)

All shifts, so very easy to code.

Performance notes:

There is a lot of overshoot on startup - about 20F - it settles down to SETPOINT in about 30 seconds. Then it drifts around in a 3F band.

When i take a hit the temp drifts up about 5F - which is a pretty nice compensation if it's going to make some response.

And if i pause between hits, it drifts down about 5F - a power saving maneuver!?

If i blow into the oven tube to cool it off fast, it doesn't drop more than 5F.

All in all not bad for a first implementation of a genuine PID.

i'll probably continue messing with the algorithm, cause that's what i do. But right now i need to make some more Bud Toasters.

 

[Hippie Dickie]

Worked a bit on the code and implemented a simple integer multiply routine.

So i changed the coefficients to 10*P + (1/8) * I + 50 * D. (Integer divide isn't as easy as integer multiply - hey! i can't solve all the problems at once can i?). This wasn't too good -- drifting up too much on the high side.

Then i remembered that the derivative factor amplifies noise in the temperature reading, and, much to my disappointment, there is a lot of jitter in the temperature reading from the MAX6675. So i reduced the D factor to 25.

... testing ...

wow. this is much, much better. i hate how haphazard trying to determine the coefficients is, but that said, this is much, much better.

1) less overshoot on startup, and pretty rapid drop to about 10F above SETPOINT, which is now at 420F.

2) none of the drift to ever higher temperature i saw last night at 50*D. i guess that was from the jitter in the temp reading magnified by the "50" and since the heater gets hotter way faster than it gets cooler, random errors would push it higher ??? amazing the difference switching to "25" makes!

3) i absolutely love the way it seems how, when i take a toke, i "pull" the temperature just a bit hotter to compensate for the air flow. After the 10 second hit when i look at the thermometer it is reading 5F hotter. Then it drifts back to SETPOINT. i like thick vapor.

Okay. i'm an ass. PID is clearly a great way to do temperature control. i just know there is a more accurate way to characterize the physics of this device, but i'm not smart enough to figure it out. However, trial and error, i'm good at.

Performance at this point is orders of magnitude better than anything i have experienced in 8 years of designing and using a vaporizer. Cool. Last issue resolved!

 

[Hippie Dickie]

Status Update:

i made another pass through the dutycycle algorithm and cleaned up the code quite a bit -- reassigned variable names to be more meaningful, rearranged variable storage, corrected some erroneous flag tests that were doing the opposite of what they were intended to do.

While i was at it, i made the PID coefficients asymetric -- that is, i split the calculation apart so that when the COILTEMP is greater than SETPOINT a different set of coefficients apply than when COILTEMP is below SETPOINT.

my rationale for this is that the coil heats around 5 times faster than it cools, so the coefficients can be tuned for this physical reality.

What i am seeing now is incredible stability at a specific temperature, but there is still a "settling" problem -- i.e. reducing the steady-state error to zero -- and there is "ringing" -- that is, the temperature oscillates around the SETPOINT.

i'm not entirely sure, but it appears the SETPOINT is the minimum temperature for the oscillations, i.e. the green LED goes out, then the temp swings higher and it comes back on.

Another observation is the effect of a freshly charged battery pack -- there is more ringing then after the pack discharges a bit -- say, down to the last 3 sessions -- where the temperature can be rock solid.

So, i think i need to measure the state of charge (most easily done during the initial power up stage: from ambient to vape temperature) and reduce the coefficients a bit to eliminate the ringing. And then increase the size of the coefficients as the pack discharges.

Coefficients currently in use:

P = 10
I = .125
D = 25 (positive slope) / 20 (negative slope)

These are static and applied to both too hot and too cold condition.

Also, i limit the size of the D calculation to represent physical reality .. i.e. i know the temp can't cool faster than 1F per sample, nor heat faster than 5F per sample. This has helped stability quite a bit. Perhaps it helps filter any jitter in the readings coming from the MAX6675.

But all in all, the code is tight and the vapor is flowing.

 

[Bubar]

What I would do for the constants is try to figure out what output you want when the temp just barely drops below the set point. If you are oscillating above that means P is too high probably.

Also, you may not even need derivative. I would try taking it out entirely and testing. It improved stability greatly for me. Derivative is mainly used in more dynamic type situations. With the heating so much faster than cooling a PI controller may function better than PID.

As for the battery pack, you'd have to have the constants compensate for the loss of voltage. If you know what the drop is like you can either have the constants increase over time or read the battery voltage with the ADC and compensate that way.

 

[Hippie Dickie]

yeah, i've got a lot of testing to do with different values ... i still don't have much feel for the PID.

i don't have any spare input pins to read the battery, so the state of charge has to be inferred.

 

[Bubar]

You could write a counter to the eeprom that indicated how many times it has been run and that is reset somehow when u charge it back up. Maybe a certain button combo.

 

[Hippie Dickie]

Special button presses may be too much to expect of a medicated user - i'm pretty sure i wouldn't always remember.

well, it has the largest temp change per sample when it passes about 300 F. When the change drops below 11F it is about done. And the size of the oscillation/ringing should be a clue to adjust the factors.

it really is amazing to see it stable at a constant temperature, knowing how much is going on in the code.

 

[Bubar]

Yes. I suppose. It is important to automate things and not leave it in the hands of a potentially inexperienced or incompetent user. I am preparing a prototype to send to my brother who is a musician and doesn't know the first thing about electronics. I'm paranoid it will break somehow and he'll have a useless vape until I come visit. My strategy is to send replacement parts and record videos of the assembly/servicing so he can do at least minor repairs.

You could indirectly measure the voltage by comparing rise times. Heat up the first part without engaging the PID and then scale the gains by the rise time before engaging the algorithm.

The temperature would stay even more constant if the maxx6675 didn't have such a damn slow response time. Using the ADC on the pic I always operate at atleast a few hundred hertz, not 4Hz like the max6675. Although I guess that the high accuracy has a lot to do with the slow response

 

[Hippie Dickie]

Heat up the first part without engaging the PID

That's exactly what i do ... at power on, it goes maximum PWM until it passes the "trip" temperature of about 375F (30 seconds from power on), then it goes zero PWM until the temperature peak (about 40 seconds from power on), then it turns on the PID algorithm until timeout (7 minutes).

i'm reading the MAX at 3.3Hz (the system heartbeat is running at 100 millisec so it reads the MAX every three ticks) and running the PWM at 250Hz.

 

[vap999]

When i take a hit the temp drifts up about 5F - which is a pretty nice compensation if it's going to make some response.
And if i pause between hits, it drifts down about 5F - a power saving maneuver!?
If i blow into the oven tube to cool it off fast, it doesn't drop more than 5F.
[In a later posting:]
it really is amazing to see it stable at a constant temperature...
.

It looks as though you have, in all practical terms, reached your goal of attaining steady state temperature control under user-like conditions. Five degrees variation sounds negligible, trivial, in the context of the many things happening and dynamic variables (aerodynamics, heat transfer/loss, nichrome wire heating, etc.) involved in this or any vaporizer, and considering that you are measuring thermocouple and not actual output air temperature (or are you?). Add in that the Bud Toaster appears to work using a combination of convection, infrared and conduction heating, you could well be reaching the limit of what perfecting algorithms can do. You might consider moving on to use-oriented performance testing and optimization or other things, and revisit algorithms and the control system as needed or you get inspired.

Have you tested the current or a recent Bud Toaster under stress, particularly simulating heavy use and testing the unit's limits? For example, perhaps connect a variable speed air pump or use a hand bellows/pump to test the limits of how much air flow the heater can take (maintain constant temperature) under non-stop use; and how it reacts to repeated quick bursts of air of varying volume, time and frequency. Or, will the few small holes drilled in the glass test tube simply limit air flow such that the system can't even be stressed for real at all?

Have you considered adjusting algorithms to optimize user-oriented performance. For example, would it be better to have the steady-state/start temperature slightly higher than the temperature to be maintained under use conditions? I'm thinking of the air temperature starting at one temperature (steady-state temp.) and after the control system detects major heat loss (inhalation) and the heater cuts in, the system heats to just a few degrees lower. This seeks to provide extra heat in the very first part of the draw (first air that hits the herbal meterial), with this extra heat needed to initially evaporate water and other lower temperature-volatilized materials and heat the herbal material and the glass it is contacting up to vaporization range.

 

[Hippie Dickie]

All good questions, for which i don't have answers yet ... except that i agree this is "good enough" for now. i've got to get a better understanding of PID before i can attain the temperature accuracy that is obviously possible.

i think i am seeing that "dankness" and quantity of the load changes the operation.

The thermocouple that measures the temperature is outside the air flow, so there are two layers of glass and an air gap between the thermocouple and the trichomes. i measured about 40F lower temperature inside the bud vial (against the inner wall of the vial).

In an effort to get maximum speed at startup to vape temperature, there is an overshoot on start up, so
it does heat about 30F above the steady state SETPOINT temperature.

Yesterday i did a series of sessions to see how long a battery charge lasts. i had 9 sessions for the full 7 minutes each, for 63 minutes of power on vaping. The 10th session only got about 20 seconds on when the blue LED went out, indicating the batteries were done. This is almost twice what i was getting before this version of the algorithm and new MOSFET that doesn't waste any power. That also, is "good enough" for now.

i consider myself to be a "heavy use" simulator. While i can take a fast hit (3 seconds), there is not enough residency time of the hot air with the trichomes and as a result the vapor is much lighter than when i take a 20 second hit ... which seems about optimal. i'm thinking about playing with the hole pattern/quantity to see if i can pull a partial vaccuum in the vial.

i can not emphasis enough how important this fast heater response and accurate temperature control is to the "perfect" vape experience. At least that's been my (recent) experience.

So, yes, i need more/different user experience. i started work today on assembling "The Pink Toaster", for a special lady friend.