Open Source SMD Reflow Hotplate for small PCBA
To make the experience fit your profile, pick a username and tell us what interests you.
We found and based on your interests.
ReflowController_Gerber.zipThe thing that makes it get hotx-zip-compressed - 144.34 kB - 04/24/2024 at 03:23 |
|
|
HotplateAlum_Gerber.zipThe thing that gets hotx-zip-compressed - 151.60 kB - 04/24/2024 at 03:23 |
|
|
REFLOW_Controller_SCH.pdfAdobe Portable Document Format - 1.20 MB - 04/24/2024 at 03:22 |
|
|
Doing one final post after uploading the scraps of documentation I was able to salvage. There’s a bit of a story here, I’m not expecting anyone to read it, but it feels good to vent…
History
This was a passion project & capstone for my electrical engineering degree. The project was about 3 months, from conception to final deliverables (demo, documentation, and formal-ish presentation). I’ll be blunt… this timeline is incredibly idiotic, and the department should have made it 2-terms. My partner worked on the firmware, and I managed schematic, layout, and test. I also had some help from professors and lab technicians in the department who were kind enough to participate in design reviews.
For the most part my partner and I worked in parallel (he had a dev board), and I had LTSpice and enough of a home lab to get by. When it came time to integrate the system, it was HELL!!! I soldered the first board by hand, and flashed it. All was working great then the STM32 stopped talking. I desoldered the MCU and tried again…. After about 30minutes I had another dead STM32.
After way too much debugging I found it was caused by bad part selection. My 3V3 switcher was meant to be a fixed 2V5 output. The impedance in my voltage divider was obliterating the transient performance of the device. In desperation I tried lowering the impedance of the divider (pissing away power as a result), and this helped for some time but eventually another STM32 fell victim to my bad design. In the end we cut our losses, and demo’d the systems separately. FW using the dev board fly wired to the display of our case, and HW a newly populated PCBA and some of my lab equipment (sans 3v3 switcher). [See Demonstration Day – Log]
I should also mention that this integration hell happened the night before the final demo. We were already working on a tight deadline and hadn’t budgeted in any hiccups. My friend and I were debugging until 2am, and crawled back to university the next morning for demo day. Here’s (I think) a funny picture showing the state of my “lab” at the time, the morning after the debugging hell. (cold coffee and all!)
Demo
Never before seen demo! The thing did actually work, albeit this was just my chopper circuit operating w/o the STM32 at the time.
Minor update before I shelve this project. The current version was a good first prototype but was completed as part of a school project. I will likely re-create this project in the future using my own approach; change documentation format, move design to KiCad (open source), and independently develop firmware.
Some other minor changes that I will be making include:
The initial draft for this design has been completed. Apologies for the somewhat sparse documentation; since this project is being completed as part of a course, much of the documentation is being developed by a team of 4 engineering students.
For now, the main hardware and firmware design for this project was completed separately. They were combined for one board, but that resulted in a fried STM32… I now know what the issue was, and I’ll be resolving the issue in a later revision (transients on 3V3 rail). The 100W buck worked perfectly, I originally designed it to be somewhat loosely regulated, since its only used to power the hotplate and case fan. Despite this the 12V rail saw at maximum 200mV peak to peak ripple, and similar transient overshoot/undershoot, even with 9A steps on its output.
In the future I would like to document this validation more rigorously, but for the time being this project will be put onto the back burner until I complete my job search (graduating from university : ) ). Anyhow here is a picture of the project during the demonstration day.
P.S. Big shout out to Joel for troubleshooting the design with me until 2am the night before our demo day
Somehow, I’ve never actually used a rotary encoder in a project until now. Since I’m not too familiar with this input I thought I’d do a quick project log for my findings.
The recommended configuration for the rotary encoder is shown below. When the rotary encoder knob is turned, the switches (seen below) pull terminal A/B to terminal C (GND). Depending on the which direction the knob is turned, terminals A or terminal B will be shorted to terminal C first.
An example for turning left and turning right is shown below. This circuit mirrors the recommended layout shown above (debounce circuit). When turning clockwise (CW) channel 2 leads, and when turning CCW channel 1 leads.
To decode the turning direction in firmware, I have an external interrupt setup on one of the output terminals (either A or B). The callback function executes on the falling edge of channel 1. If channel 2 is low, then the knob was turned CW, else it was turned CCW.
School’s been fairly busy over the past bit so I haven’t had much of a chance to add any posts here. In this log, I’m going to dump a basic overview for the various sheets of the SMD reflow hotplate project. This board is the controller board, it will connect to a passive hot plate made from an aluminum PCB (testing on that to come).
The first sheet contains all the hierarchical blocks. I split the schematic into 4 sections, power, microcontroller, sensors/peripherals, and FET drivers.
The power block is the largest schematic in the project (I probably should increase the sheet size a bit). It contains a 3V3@600mA and 12V@8A buck. Both these DC-DC converters step down a voltage from an external 24V wall adapter. Originally the hot plate was going to handle AC-DC rectification, but due to the 3-month timeline it wasn’t feasible. I’ve highlighted several sections in the schematic. The reverse protection section provides OCP, OVP, and UVP for the downstream components. It uses a PMOS transistor for reverse voltage protection and a TVS diode for ESD protection. On the topic of ESD, I’m not sure if the FET would survive even with the TVS diode (max Vgs 30V), ideally the PMOS would have a maximum Vgs above the clamping threshold of the TVS diode… but the component shortage won this round. Lastly, yes I’ve shorted GND with PGND without a net tie… I’m planning on tying these nets together with via’s and I couldn’t find a nice way of doing this in Altium. Note, the SIRA28 FET has since been tweaked for a higher power variant.
The microcontroller schematic is fairly self-explanatory. We are using an STM32F4 which will drive various pwm signals, run a PID controller, display a basic GUI, and interface with several I2C devices (I managed to swipe some from Digikey awhile back, otherwise this component is fairly unobtanium). Although I originally thought this MCU was overkill, we ended up using nearly all its I/O and most of its timers. To help with debugging I have 2 configurable inputs SEL_0/SEL_1 and 3 debug LED’s.
The sensors consist of 2 temperature sensors, one to measure the hot plate via inferred and one for ambient case temperature, and 1 inertial measurement unit (IMU). The IMU was added as an afterthought, I have a couple LIS2HH12TR’s in my parts drawer and I thought it could add some interesting safety features/functionality. These 3 peripherals can be hard reset via a PMOS switch. There is also a rotary encoder, a buzzer, and the LCD I/O. Note that both the rotary encoder, and LCD will be mounted to the case so I’ve just used basic 2.54mm pitch headers. Like the sensors, the display can also be completely disabled. This was included to allow the system to enter a deep-sleep state where all peripherals are switched off.
The last schematic is for the FET driver circuits. The FET drivers control DC-DC choppers that will drive a FAN and the main hot plate. Note that these two choppers use the same FET for BOM consolidation. I’ve included several test points so that this circuit can be tested independent of the rest of the system. Note, the SIRA28 FET has since been tweaked for a higher power variant.
The widget needs two identical FET driver circuits to help switch regulate the current through (a) the case fan, and (b) the Hot plate itself. The drivers will be controlled by a logic level signal. If we try to control the FET without the driver circuit, the FET would be switched inefficiently if at all (slow switching leading to switching losses, and insufficient drive leading to higher Rds_on). For BOM consolidation the two FET’s will be identical (This leads to a very overkill FET for the fan). The schematic for this circuit is shown below. Since the FET will be driving an inductive load a flyback diode was added across the power terminals to avoid.
This circuit works as explained below. When the input signal (FAN_pwm) is high the lower BJT is on (Q10). As a result, the base of the upper BJT is pulled to ~GND, and the gate of the FET is drained. When the input signal is low the lower BJT is turned off, allowing the upper BJT to turn on and charge the gate of the FET.
Here is a basic simulation of the circuit using some generic components. I used this to help confirm my understanding of the circuit, as explained above.
The circuit was also configured on a breadboard. I was curious if there would be any “coil whine” from the FAN (I’ve had issues with this in the past), and at what frequency the FAN should be driven. 100Hz seems to work well with this fan. In the screen captures below, CH1 is the input from a function generator, CH2 is the gate drive, and CH3 is Vds.
Here its being driven at 50%.
And here at 90%. The Fan is barely going at 90% duty cycle (note logic is inverted so this is 10% on).
Lastly, the transient. Ideally I’d have a the drain current as a waveform here, but I need to solder up a CSA for high current to make that measurement (and I’m waiting on some SMD potentiometers for that project).
Shown below is the basic block diagram for the project. This is only a rough outlined used to guide our team in the design process. Note there are some auxiliary requirements such as designing a website and creating a poster. These are required for course completion, so they likely won’t be touched on in these forums.
After creating this block diagram and presenting it to the team, I developed the Gannt chart shown below. It contains all crucial tasks and milestones for this project. As our team completes the design, the various task completion fields will be updated.
This is a capstone project for my engineering degree at UVic. The entire design process was limited to 3 months based on course requirements. 5 colleagues will be working with me throughout this design, and I’ll be leading the schematic and PCB design.
In general, I’ll be using these logs to document the hardware testing. Any posts that relate to work that is not my own will be credited as such. Once the project is completed, I will add relevant design documents and Gerber files.
Create an account to leave a comment. Already have an account? Log In.
Become a member to follow this project and never miss any updates