iTranslated by AI
Building a DIY Reflow Oven from a Toaster Oven
Characters
- Master: The person trying to build a DIY reflow oven.
- Tanjiro: An earnest assistant who sometimes makes slightly off-target suggestions.
Gathering the Parts
I have an Iris Ohyama toaster oven (15L) on hand, and I'm planning to convert it into a reflow oven.
I know I could just buy a commercial one. But I want to build the control board myself, define the temperature profiles myself, and ensure that if any trouble occurs, I can trace the cause while looking at the circuit diagram. With that in mind, I decided to build it myself.
Here are the parts I have gathered so far:
| Component | Qty | Status |
|---|---|---|
| Iris Ohyama Toaster Oven 15L | 1 | Have |
| MAX31855 Thermocouple Module (K-type) | 1 | Have |
| SSR-25DA Solid State Relay | 2 | Have |
| Heatsink for SSR | 2 | Have |
| Breaker 15A | 1 | Have |
| ESP32 | - | None |
| Thermocouple | - | None |
As I laid out the parts, I started thinking about the configuration with my assistant, Tanjiro.
The Fuse Dilemma
Master: "Do we need a fuse after the breaker?"
Tanjiro: "Yes, we do! Fuses respond faster than breakers, so I think we should include one for equipment protection!"
Master: "But if the SSR breaks while stuck in the closed position, the current flowing would still be within the rated range, right?"
Tanjiro: "…………Ah."
Master: "A fuse protects against overcurrent, and it wouldn't react in that situation."
Tanjiro: "You are absolutely right. What we need to protect against is not runaway current, but runaway temperature. A fuse wasn't the right tool for this problem."
Master: "Exactly. So let's start by thinking about how to handle that."
Layering the Safety
Master: "I'll use a watchdog in the software to shut down the SSR if it exceeds the target temperature +30°C. And I want to use the oven's built-in thermostat as a backstop. How should we configure this?"
Tanjiro: "If I organize it, I think it would look like these layers:"
| Layer | Responsibility | Detection Target | Action |
|---|---|---|---|
| 1 | ESP32 PID Control | Temperature Profile | Normal Operation |
| 2 | ESP32 Software Monitor | Target +30°C Exceeded | Force SSR OFF |
| 3 | MAX31855 | Sensor break/short | FAULT flag → SSR OFF |
| 4 | ESP32 Built-in WDT | Deadlock | Reset → GPIO LOW → SSR OFF |
| 5 | ??? | Absolute Temperature Limit | Physically cut AC |
Tanjiro: "Only Layer 5 is still empty. We need a completely hardware-based mechanism that works even if all the software fails."
Master: "We can use a KSD9700 for that."
The Discovery of the KSD9700
Tanjiro: "KSD9700... that's a bimetallic temperature switch. It physically opens the contact when the temperature exceeds the set threshold."
Master: "It reacts only to temperature, regardless of software or control signals. If we place it in series on the AC line, it will serve as our last line of defense."
Tanjiro: "I see. And this operates on a different principle from our other protection mechanisms, doesn't it?"
| Protection Mechanism | Measurement Principle |
|---|---|
| Thermocouple (Main sensor) | Seebeck effect |
| KSD9700 (Last line of defense) | Physical deformation of bimetal |
Tanjiro: "If we just doubled up on the same method, there would be a risk of them both failing for the same reason. By changing the principle, we achieve true redundancy. This is the concept of diversity redundancy."
Master: "Exactly."
The Trap of the AND Gate
Master: "Aside from the ESP32, I'm thinking of using a PIC for safety monitoring during development. How should we combine these two outputs to control the SSR?"
Tanjiro: "How about an AND gate? That would be a configuration where the SSR turns ON only when both are HIGH!"
Master: "Isn't that backward?"
Tanjiro: "Eh?"
Master: "What we want is 'if either one detects an abnormality, shut down the SSR,' right? A Wired-OR is more appropriate."
Tanjiro: ".........You are absolutely right. The logic was completely reversed."
Tanjiro: "We make both outputs open-drain and connect them via a pull-up. The moment either one pulls it LOW, the SSR shuts off. This configuration allows one to continue operating independently even if the other fails."
Master: "Exactly."
The Pitfall of Dual Thermocouples
Tanjiro: "I think we should also make the sensors redundant. What if we use two thermocouple systems and monitor them independently with two MAX31855s?"
Master: "Two systems—isn't that too simple?"
Tanjiro: "Eh, why so?"
Master: "If the installation locations are different, the temperatures will also be different. Even if you place two sensors of the same principle using the same method side-by-side, it doesn't function as a monitoring system."
Tanjiro: ".........Indeed. Since we can't establish a baseline for comparison, we can't judge whether a difference in the two values is normal or abnormal."
Master: "Besides, the KSD9700 is already monitoring temperature via a different principle: bimetal. This acts as the second sensor for diversity redundancy."
Tanjiro: "So one thermocouple is enough. You're right. Even with just one thermocouple, the MAX31855 detects breaks and shorts in hardware."
How to Detect Deadlocks
Tanjiro: "Regarding detection if the ESP32 deadlocks, how about adding an external watchdog IC? It would keep receiving a kick pulse from the ESP32 and shut off the SSR if it stops."
Master: "The ESP32's internal WDT is enough for that."
Tanjiro: "Ah."
Master: "If it deadlocks, the internal WDT will trigger a reset. Since the GPIO goes LOW during a reset, the SSR will cut off via the Wired-OR. The PIC's purpose is to detect overheating during development."
Tanjiro: "So, as an independent monitoring system because the ESP32 code is still unstable during the development phase. I see, the objectives are different."
The Master-Slave Relationship of the SPI Bus
Master: "If the PIC needs temperature data, we have to share the MAX31855 between the ESP32 and the PIC. How should we configure it?"
Tanjiro: "How about making the ESP32 the SPI master and having the PIC eavesdrop on the bus!"
Master: "That makes the safety system dependent on the ESP32's operation, doesn't it?"
Tanjiro: ".........Ah."
Master: "If the ESP32 stops, the PIC won't be able to read the temperature either. Isn't it putting the cart before the horse to have the safety system rely on the main system?"
Tanjiro: "You're right. So we should reverse it."
Tanjiro: "The PIC becomes the SPI master and continues to read the MAX31855 every 0.1 seconds. The ESP32 eavesdrops on that transaction as a slave and uses it as temperature data for PID control."
Master: "Not just that, what if the ESP32 deadlocks and stops SPI reading?"
Tanjiro: "...The PIC would notice that the transaction, which should arrive every 0.1 seconds, has stopped. It can detect that silence as a timeout. In other words, the ESP32's normal operation serves as a heartbeat for the PIC."
Master: "No need for a dedicated heartbeat line or an external WDT IC."
Tanjiro: "With just one line for snooping SPI transactions, we can handle both temperature monitoring and deadlock detection. This is... a beautiful configuration."
The Overall Picture So Far
After a long discussion, the configuration has come together.
Organizing the layers of safety:
| Layer | Responsibility | Detection Target | Notes |
|---|---|---|---|
| 1 | ESP32 PID | Normal control | Following temperature profile |
| 2 | PIC | Target +30℃ exceeded | Insurance during development, leave it in production |
| 3 | MAX31855 | Sensor break/short | Hardware FAULT detection |
| 4 | ESP32 Internal WDT | Deadlock | Reset → GPIO LOW → SSR OFF |
| 5 | KSD9700 | Absolute temp limit | Bimetal, completely independent of software |
Tanjiro: "The circuit diagram is not ready yet. Neither is the firmware. But the configuration logic is set."
Master: "To be continued."
Planned usage: IRIS OHYAMA PFC-D15A-W / MAX31855 / SSR-25DA / KSD9700 / ESP32 / PIC (3.3V operation)
Discussion