A basic soldering station for Weller RT tips
So, since the last project log, (actually, since Monday) I've actually switched microcontrollers twice: first, from the Nano to the Pro Mini, and then to the Pro Micro. (the Pro Mini doesn't have enough code space to fit the library for the OLED screen I'm using and still have room for anything else) Oh yeah... I also added an OLED screen!Read more »
So, I had a realization earlier... the USB interface on the Nano DCCduino is actually on a separate chip. On a hunch, I plugged it into the breadboard to see if it would light up if I powered it externally...
Well, then. That makes things easier.
So, in light of this... I'll be switching back to using the Nano for this project. (more pins makes a lot of things easier, and I won't need to worry about weird DigiSpark-specific library ports) I just need to solder the ICSP pins on and hook up my BusPirate, and I'll be back in business.
Now that I've switched to the Digispark for the brain of this project, I've updated the code to support it (using a preprocessor define so we can switch between that and the Nano) and added in a software-based serial port for communication. (I couldn't get the Digispark's software serial-over-USB to work, and it doesn't have a hardware serial port apparently)
The weirdest thing here is that I got no output on the serial port TX line at all for quite a while... until I unplugged the heat sensor amp circuit from the Digispark. The heater control circuit is apparently fine, but something about the OPA4228PA's output was apparently killing the Digispark - when it was plugged in, I couldn't even get lights to blink!
I'm really kinda stumped on this one... I don't understand why connecting the output of an op-amp to an input pin would cause the whole microcontroller to freeze. I've pushed my latest changes to the GitLab project, if anyone reading this would like to take a look and maybe fill me in on what I'm doing wrong. (the Fritzing file for the Digistump version of the circuit is available here)
So, after I started troubleshooting why it was behaving as if the Mode button was always pressed, I found out that that actually was the case; the button I was using was broken, and was always a closed circuit. Once I removed it, suddenly the Nano shut off, and since then I haven't been able to get any response out of it; not even the power light comes on, and it doesn't show up in dmesg.
Rest in peace, Nano. The last couple of days were brief, but enjoyable.
Since the only Nano I have has now passed on, I needed to find something else to drive this whole project. I could have pulled out another of the PICs I have in store, but honestly... they're more of a pain than I want to deal with right now. So instead, I dug up this tiny one:
It's apparently a Digispark clone, and it was given to me a couple of years ago by the same friend who donated the Nano. (thanks, Rusty! I couldn't have done this project without you :D)
Turns out, if I'm not tied to driving an LED display, I can do everything on 4 I/O pins, and still have a serial connection for doing stuff like display, if I get creative. (maybe I'll make a companion app for my Raspberry Pi Zero or something) Sadly, it can't do the serial monitor over USB like the Arduinos can, but there's other ways to get output.
If all else fails, I have an MSP430 (also given to me by the same friend), and I also still have a new "Pro Mini" Arduino clone coming... which is basically a Nano without USB.
I just added a link to the new project on GitLab! Now everyone else can actually access the code and the Fritzing sketch for this project.
In other news, I'm still trying to figure out if one of the OPA4228PA I have on hand will suffice for reading the temperature sensor in the RT tip, or if I need to wait for the OPA344 that was used in @banjohat's project... The OPA4228PA isn't rail-to-rail, but it is "high precision, low noise". I'm going to try breadboarding it and see if I can get it to give me useful results.
Also, I realized that the common anodes on the LED display will actually each need a transistor to drive them, possibly paired with a resistor to limit the current. That makes things significantly more complicated, since it only seems to work if I use PNP transistors, and I only have 2 of them that actually do anything in the circuit right now. Looking at the possibility of a Darlington array chip (and maybe also a resistor array) to keep component count down.
I've now put together the driver for the heating element in the soldering iron, and started testing. Here's a close-up of the second stage of the driver (soldered to cheap perfboard because this MOSFET is in an SO-8 package):
Note that the first version of this was just leads soldered to one of the chips, but on that one, the gate pin ended up breaking off, despite some attempted strain relief. I should really have known better.
Next, I plugged everything in, and set up the soldering iron tip with a thermocouple touching it so I can check the temperature as it heats:
Look at how nice and clean that tip is! Well... it didn't stay that way for long. I made the mistake of actually following the schematic and connecting the iron supply to 12V... and I wasn't able to disconnect it quickly enough when it started heating like crazy, so it ended up getting up to around 500 degrees Fahrenheit. This oxidized the tip, though I was able to fix that with some flux and re-tinning... but the rest of the tip piece is now nicely blued:
Good news, though: I didn't burn out the tip or any of the components! (though some smoke did emanate from the headphone jack, and it looks like the insulator in it has melted some... I might have to see about replacing that with a jack that makes a better connection)
I've been able to test out heating using different duty cycles (so far I'm using a 200ms period, though I may increase that) and it seems that the iron actually heats pretty quickly even on 5V instead of 12V. (though I'll need to check whether or not I can actually pull 2.63A from the Arduino's supply pins... I get the feeling that might not be feasible, which will mean I'll need to use something other than USB for the 5V supply) It even works OK on 3.3V, but doesn't actually heat very quickly. (though, to be fair, I've only tried that with up to a 15% duty cycle, so it may still give somewhat passable results if I try a higher duty cycle... and at 3.3V the heater will only draw 1.74A)
Next step will be to get the temperature sensor hooked up so I can start building a model based on my thermocouple readings... and then, on to PID control!
Also, since the heater switching causes my power supply to click audibly, I should probably figure out how to filter the transients out of the supply rails before trying to run this thing entirely off USB.
I've been having issues getting the PIC to do anything. I tried a bunch of different things, even attempting to just make an LED blink, and... nothing.
So, last night I realized I had an Arduino Nano clone sitting around, and I decided to give that a shot instead. Works great! But I still couldn't get the HPDL2416 (the LED display) to actually display anything, so now I've switched to a different one I had bought a while back. (a LEDtech LN5674-11-M1) Now I actually have it displaying one digit that counts up from 0 to 9 and then loops!
Next step will be to make it display a full 4-digit number (or maybe 3-digit with "C"/"F" after it), and then hook up the encoder... which reminds me: apparently my rotary encoder is also broken - it only gives me a signal out of one of the A/B pins. So I may have to wait for the new one to come in.
I wonder what happened to break all my components... maybe moving across the country, and then moving again a year later.
I've put together the schematic and breadboard layout in Fritzing (I'll be uploading the files soon) and put together the first part of the circuit on my breadboard - the PIC, display, rotary encoder, ICSP header, and Mode button. Now, to program the PIC so I can test this stuff out...
And now I'm starting to realize why AVR/Arduino has been replacing PIC as the darling of hobbyists in recent years. PIC's architecture is... peculiar. The few open source tools that support PIC programming aren't updated like they used to be. (PikLab no longer builds on my system, for instance, and SDCC's PIC support is still experimental) There's very little library code available from the community. (it looks like I'm going to have to code my own PID controller) AVR, on the other hand, is quite well supported by open source tools, and has an active community contributing reusable code for it.
In short... if I actually had some AVRs on hand, I'd probably use them instead of the PIC. But since I don't... on with the coding.
I've already soldered together the jack for plugging in the RT tip, but now I need to figure out which PIC to use... so I'm going to use this post to catalog what pins I'll need.
I'm still undecided as to whether or not I want to expose the ICSP pins, since my plan is to use a DIP socket, and I have a separate programmer socket I can use to program the PIC. On the other hand, it may be much more convenient to be able to simply connect the programmer to the soldering station directly.
Total I/O pins: 12 (or, with ICSP, 15)
Given the above pin lists, we should be able to use a 20-pin PIC. I have a few of these available:
Looks like I'm going with the PIC16F690 again. :)
I'd also like to understand the MOSFET output stage used by the Soldering pen project better - especially why one of the MOSFETs shown on the schematic there is N-channel and the other is P-channel. (even though only one part number is shown in the BOM) I've been reading up on using MOSFETs to control heaters, but I'm still not sure if any of the parts I have on hand will be sufficient to drive the tip, and I'm not entirely sure whether it's possible to build a correctly-working output stage using various mixes of P-channel and N-channel parts. (P/P vs. P/N vs. N/N) Luckily, none of this should affect the pin count, so it shouldn't influence the PIC choice directly.