These lines should be evaluate 'secondsTo150C' as TYPE_WHOLE_OVEN@L354.

I thought it might be useful to start an Issue for people to report on availability of different toaster ovens for this project.

I'll start: The actual toaster oven (Black & Decker TO1303SB) used in the tutorial (https://www.whizoo.com/reflowoven ) is not currently available at the usual big-name retailers in the US, online or at stores. However, that model IS available currently (2021-09) at Big Lots https://www.biglots.com/product/4-slice-toaster-oven/p810337894 , even though the web page doesn't specifically advertise the model. (I just bought one.)

As the tutorial mentions, there are other similar or virtually identical models available at different retailers, including TO1313 +letters to indicate different colors, I think, so no worries if you don't get the exact model in the tutorial. But for those interested in that exact model -- Big Lots is where they've ended up at the moment :-).

When clicking the temperature displayed in the top-right corner of the screen during a reflow, it prints the "bake at" string over the top of the reflow phase/status.
Additionally, pretty much any action on any screen always changes units back to C.

I just built my reflow oven. The kit rocks! Well done. Thanks.

I am planning to add a feature to the firmware and would appreciate your feedback. Also, if if is a feature you would be interested in adding I will do it in the spirit of your code and submit a PR when done. Otherwise I might play around for myself while I am in there and just keep the fork for myself (and anyone else that might be interested).

I would add a door lock mode. I will make a servo arm with another arm out in front. it would be clear enough not to interfere in the existing operation but then if you drive the servo past the closed position, that arm would engage the metal door plate on the other side and hold it firm against the oven. I am not sure if the existing servo will have sufficient range of motion but I assume I can one one that does if needed.

Why I am doing this...

My oven is a Black & Decker TO1760SS in which the door overlaps the oven frame and the curve of the glass door does not match the curve of the frame very well so adding the liner leaves big gaps. My solution was to lay a bead of the red silicone, wait 10-20 minutes, put a film of motor oil around the door where it would touch the bead and lightly pulse the door closed to mold the bead to the shape of the door. This worked pretty well but the door does not close tight on its own. It does not take much force to get it to make a tight seal, though.

--BobG

The link on the https://www.whizoo.com/update page is linking to the older v1.4 version that hangs after the 'play tune' command.

Additionally, the text says "Download the Controleo3 library from GitHub by clicking here.", but it's actually downloading the .zip from whizoo.com.

The library.properties file in GitHub still says version 1.1, while the one in the 1.4 zip file on the whizoo.com site says 1.4, so I imagine the GitHub version needs to be updated as well.

diff -r Controleo3-master/library.properties Controleo3-1.4/library.properties
1,2c1,2
< name=Controleo3
< version=1.1
---
> name=Controleo3 v1.4
> version=1.4

A live logging feature / output to pb would be helpful, to check that the profile is progressing as expected. It seems like a good idea, if the MCU is not getting too busy in it's main loop to print that data out every so often.

Compiled with Adruino IDE 1.89.
Playing the specific tune ReflowDone causes the UI to hang.
On line 102 in tones.ino there is a zero in the list of notes/duration. Changing this to a non zero value fixes the issue.

My understanding of current learning sequence is follows.

1. INITIAL_RAMP with WHOLE_OVEN
2. measuring CONSTANT with WHOLE_OVEN
3. measureing CONSTANT with BOTTOM_ELEMENT
4. measureing CONSTANT with TOP_ELEMENT
5. measuring INERTIA with WHOLE_OVEN
6. measuring Insulation while Cool-down
7. Stabilize with WHOLE_OVEN
8. measuring INERTIA with BOTTOM_ELEMENT
9. Cool-down
10. Stabilize with BOTTOM_ELEMENT
11. measuring INERTIA with TOP_ELEMENT
12. COOLING
13. DONE

My idea is follows.

1. INITIAL_RAMP with WHOLE_OVEN
2. measuring CONSTANT with WHOLE_OVEN
3. measuring INERTIA with WHOLE_OVEN
4. measuring Insulation while Cool-down
5. measureing CONSTANT with BOTTOM_ELEMENT
6. measuring INERTIA with BOTTOM_ELEMENT
7. Cool-down
8. measureing CONSTANT with TOP_ELEMENT
9. measuring INERTIA with TOP_ELEMENT
10. COOLING
11. DONE

It will reduce a waste time. (reduce a time of stabilizing after a measureing inertia.)

Hey there, I really appreciate all the work you've put into this project! I've started following your guide to build an oven and am porting the code to run on Teensy-LC (much smaller flash & memory).

I noticed that your README says the code is released under "the CC BY-NC-SA 3.0 license" but the LICENSE file indicates the GPL 3.0 – any case you meant to only release under one of those?

Some scenarios require the temperature to be at a certain level before the part is inserted, such as for annealing plastics. It would therefore be useful to have a pause command, where the Controleo profile execution pauses until it receives a screen tap, so that a part may be inserted in the oven and then the profile resumed.

An implementation could look like this:

Pause // Controleo pauses indefinitely until screen is tapped
Pause 60s // Controleo pauses for 60 seconds or until screen is tapped, whichever is first

or

Maintain 250C and pause // Maintain 250C indefinitely until screen is tapped
Maintain 250C and pause up to 60s // Maintain 250C for 60 seconds or until screen is tapped, whichever is first

There is no need for a resume command, in my opinion, as a screen tap would indicate the profile is ready to be resumed.

Though Controleo is excellent for reflow, it can readily be used for myriad other uses (such as annealing) with a pause command. Any consideration that could be given to adding this would be quite appreciated and would increase Controleo's flexibility.

I love my Controleo3, but find the process of creating and refining profiles very frustrating.

For reflow soldering profiles I usually start out with the solder manufacturer's recommendations, but almost inevitably there'll be some tweaking I'll want to do to make the profile work well with my particular oven and the particular boards I want to make. That process typically involves just changing temperatures by a few degrees or times by a few seconds, but currently requires removing and inserting the SD card many times to get to the right recipe.

I also use my Controleo3 for applications other than reflow soldering, where I typically just want to keep a one-off part at a given temperature for a given time, but both time and temperature tend to vary from part to part.

In both of those situations I'd find it really useful if the Controlleo3 firmware supported adjusting certain profile parameters on the fly, without having to plug the SD card into a different device to make a tiny change.

To address that frustration, I'd like to propose the idea of profile parameters.

Profile parameters would be declared within profiles using a new token, for example: Param soak_duration default 100s. Once declared, other profile commands should then be able to reference those parameters, for example: Ramp temperature to 165C in soak_duration.

When running a profile using parameters, the user interface would prompt the user to specify a value for each parameter by adjusting the profile default, and then execute the profile with the given values effectively substituted within the rest of the profile.

I'm not proposing anything more complicated than literal substitution. While I could see potential uses for an expression language that can represent Ramp temperature to 165C in soak_duration + 10s and similar things, that seems out of scope right now and could be added later. Similarly, while saving a set of parameter as a named profile or persisting past parameter values of a profile seems like it might be a useful feature if profile parameters were to become a thing, I'm not proposing any of those things at this time.

I'd love to hear people's thoughts on that idea, if the maintainers would be open to such a feature, and if so, if they'd have any thoughts on the specifics of the syntax and semantics of such a new profile language feature.

Thanks!

Looks like you copied the library.properties file from the SD library, but didn't update all the properties! Additionally the version doesn't match the actual current version of the software.

Thanks!

Dear Support !

I have an issue, when after 2-3 successful learning cycles, reflow program failed with overheat message. Do you have any recommendations how to eliminate it ? I am using example profile for leaded paste.

In Step 14 of the Controleo3 build guide, there's a Tip "in some cases static builds up on the thermocouple so the MAX31856 IC reports an over/under voltage error and Controleo3 won't display the oven's temperature. Touching the tip of the thermocouple with your finger removes the static and the error for the duration of the reflow session. [...] However, grounding the thermocouple fixes this as explained here [link to NI explanation]. "

But I don't think this makes sense. The NI document focuses on a thermocouple connected to differential inputs of an opamp or differential amplifier, which are very high impedance, but source or sink some bias current, and thereby might charge the thermocouple assembly.

But the Controleo3 uses MAX31856 that provides a bias terminal to deliberately set a common-mode voltage on the thermocouple wires. (And the PCB does use that bias terminal.) So static charge cannot build up on the thermocouple per se, in the manner discussed by the NI document.

Even if static could build up on the thermocouple as described in the NI doc (ie: not applicable to the MAX31856), then providing a path from the Controleo3 ground to the chassis ground wouldn't cure it, because that would not drain charge from the thermocouple.

So, if an error condition is indeed detected and reported by the Controleo3 (is this an established fact?), it seems to me it's not related to the thermocouple acquiring a static charge per se.

But if could be due to some aspect of the entire Controleo3 floating relative to the oven chassis. It would be good to elucidate what exactly is going on there, and determine whether the Controleo3's ground rail should be:

1. Not grounded, or
2. Provided with a high-resistance path to chassis ground, or
3. Grounded direct to chassis ground.

I would expect that option 3, which puts Controleo3 ground at the same potential as the chassis, would make best use of the chassis to shield against possible noise pickup by Controleo3 (or the thermocouple wiring). However, I don't know whether there's some other obtuse mechanism at work here, given that inside the oven, signal wires might be routed near the AC wiring for the heaters.