This Bluetooth serial link is nothing new. I had it working on the existing setup to send data from the ReactorForge control board to the Processing visualization program. The HC-06 Bluetooth module enabled me to see the live telemetry coming from the ReactorForge. That helps you to understand what is going on and tweak parameters such as the PID settings.
Consolidation of Development Process
I’m excited to get the entire development process in one operating system. Before, I was bouncing between macOS, Windows in VMWare Fusion on the Mac, and a separate Windows machine. It’s a long story, but this was partly due to the Windows-only compiler I used at the time. Other shortcuts I made early in the process just to get things working enough to get the induction heater to Daniel’s shop also helped put me in that spot.
Problems Connecting to the HC-06 Bluetooth Module on Mac
Getting the HC-06 Bluetooth to Serial module working on macOS wasn’t hard, but I did have one issue. The HC-06 seemed to just disconnect randomly after a minute or two of being connected. Then when I would try to reconnect to it, the port would be busy. I knew it wasn’t busy or open using lsof | grep HC-06 or whatever your’s is named, Reactor-Link in my case.
I fired up Windows in VMware Fusion and paired the HC-06 Bluetooth module. Then I opened a connection to it using a terminal program. I also began a screen session (terminal) on the Mac side with a USB to serial adapter. The USB serial adapter was connected to the HC-06 Bluetooth module to monitor it (and send data from it).
Anyway, this worked fine, and the HC-06 Bluetooth module never lost connection on the Windows side. I did notice that on the Windows side, the HC-06 Bluetooth module asked me for asked me for the pin number during the pairing process, but it did not ask on the Mac side. I removed the device from on the Mac side in the Bluetooth manager and re-Paired it. To my annoyance and relief, this fixed the disconnecting issue. Maybe I changed the pin in the past since the last time it had been connected to the Mac.
Bluetooth on macOS
So this is the simple test setup. The photos say it all I think.
Libraries, Drivers, Etc.
With that working, I’m going to work on the libraries now. I’m looking at whether or not to get the existing libraries working in the new environment or use new libraries. I’m leaning toward new libraries because there are quite a few compiler warnings and even some errors from the old ones. I’ll have to update function names and setup code, but I’d prefer to start with something cleaner and updated. I’m pushing it all to GitHub as I go!
Addition Terminal Jargon
The astute reader might notice that I am using the /dev/tty.* version of the device rather than the /dev/cu.* version. So, what’s the difference? TTY devices are for calling into UNIX systems, whereas CU (Call-Up) devices are for calling out from them (e.g., modems). We want to call-out, so /dev/cu.* is the correct device to use.
The technical difference is that /dev/tty.* devices will wait (or listen) for DCD (data-carrier-detect) e.g., someone calling in, before responding. /dev/cu.* devices do not assert DCD, so they will always connect (respond or succeed) immediately. Since neither the HC-06 Bluetooth module or the USB to serial adapter support DCD it’s not an issue. Still, following best practice, you should use the correct port.
So why did I use the wrong one in the photos? I switched to /dev/tty.* when I was having the connection issue and just forgot to switch back before documenting it.
If you follow the GitHub repository https://github.com/ThingEngineer/ReactorForge by clicking [Watch] you may have noticed work on the firmware. I’ve begun setting up the new development environment. Going forward, I don’t want to deal with switching to Windows to work in AVR Studio. I never liked that environment anyway. I had talked about possibly moving everything into the Arduino environment because of its popularity, however that has its own set of issues. For starters, support for the AT90PWM family of chips isn’t there, and I don’t want to spend the time to add it. Then there’s this:
Beginning Development Environment
Arduino is a great prototyping platform and IDE to get started on if you have never worked with microcontrollers. As a beginner, it can get you building projects faster than any other platform out there. But eventually, the features that make it convenient and easy to use can hold you back. It lacks many features which make writing code quicker, easier, and have become quite standard in modern text editors. There are also bits of code that get inserted into your code that can cause some very head-scratching issues.
Moving Beyond Arduino
The next logical step is to leave the Arduino IDE behind. We do that by working in a more fully-featured development environment. Atom + PlatformIO is my new favorite open source cross-platform IDE. It even comes with the Arduino framework among others. That lets you test drive it with a code structure you are familiar. When you are ready, you can remove the training wheels and go full native C++. There is so much more I could brag about with both of these tools. But I’ll let you discover the awesomeness yourself!
What’s next? I’m going to begin porting over the libraries used in the existing project. Then the main code, and start rewriting, optimizing, etc. The photo above is a test rig I used for setting up the new IDE. I will continue to use it throughout the porting process. Once the code is stable in its new environment, I’ll switch over to the ReactorForge!
I had also planned on using this setup to demo and explain the basics behind the AT90PMW software PLL setup. I’ll get to that but for now, it’s back to work in the new development environment!
There has been a lot of confusion created by they way Patreon charges its patrons and paying creators. You can find the official information can here: https://patreon.zendesk.com/hc/en-us/articles/115005631963 And here is another excellent article on the topic by TechCrunch.
TLDR; The short version is, Patreon moved its credit card processing service fees from the creator to the patron. Because of this change, Patreon was able to lower the overall fee amount and give more to the creator. The fee amount is (2.9% + $0.35) for each monthly pledge.
Because I have worked on unique e-commerce projects, I understand the intricacies and complications of bulk credit card processing, multiple payees, and the associated charges and chargeback liabilities. However, I do not support Patreon’s decision, and I firmly believe there is a better solution. Because Patreon is a goodwill engine, I think this move is, for lack of better terms, just weird. In addition, I won’t personally be canceling any of my Patreon pledges. Nevertheless, as a patron myself and now a fledgling creator, I do hope that we see these processing fees moved back to the creator.
Other Support Options
Your support is much appreciated, but entirely voluntary. You may continue to make a small donation to support the project and website using Patreon. If you decide to cancel out of principal, I understand entirely. If you prefer I’ve added a PayPal button on the pledge page “Coffee” to enable you to make a small reoccurring monthly pledge that you can change or cancel it at any time.
Or you can send a one-time pledge. Please include a note to let me know it’s a gift and what made you decide to support ReactorForge!
I may add members only functionality to the website linked to Patreon PayPal as well, to mirror and even enhance the capabilities Patreon offers. But I’m not sure there is indeed a need for that yet, or possibly ever. Thank you all again for your support, be it monetary, intellectual, or constructive criticism. I value all of it!
ReactorForge Parts Delivery
I just received the first shipment of parts for building more ReactorForge induction heaters, 258 pounds worth. This component is of one particular importance and one I have settled on despite other possible changes I will be making to the design. Anyone care to take a guess what part this is?
This is the last mains power update for the ReactorForge Induction Heater. It will be the last because it’s complete! Here is how the last couple days of that process went.
I started by connecting the jumpers from the custom splice connector to the 60 Amp 240-volt dual pole breaker and ground bus. The photo shows green hooked to the neutral bus. I later moved this as I did not need to tap 120-volt like I thought I would have to since the ATX power supply runs on 240-volt now. (I just forgot, it’s been a while.)
And here is the 240-volt quick disconnect assembly installed and ready. I will print another version of the slide lock. The slides should be solid so the splice connectors are not accessible while the wires are disconnected.
Next, I prepared the 2 AWG mains power feeder lines. These will connect the splice block directly to the input of the ReactorForge.
The splice block side has thick metal tabs that are double layered with heat-shrink tubing. These provide a high current, high durability connection to the screw terminal that will stand up to multiple connect/disconnect cycles.
The Induction Heater side has heavy duty lugs that will accept the terminal post. These are also insulated with double layers heat-shrink.
Bringing It All Together
And here you can see the feeder lines connected to the input of terminal posts on the back of the ReactorForge. I also ran a USB extension with a small hub for connecting the Atmel ISP programmer. I put the Bluetooth dongle here as well. It communicates with the mainboard to send/receive commands and system telemetry.
I then installed a variac between the mains contactor and the inverter input filter.
When software activates the contactor, 240 volts directly feeds the inverter typically. Since I have a decent amount of testing to do, I severed that connection and installed the variac to allow lower power testing.
I taped up the small areas where 240 volts was accessible in the front to avoid accidental contact or tools shorting things out. Getting my fingers across 240-volt mains power is not something I want to experience twice!
On To The CODE!
That’s it for cooling and mains power connections. The next step is to get the programming environment set back up. I will turn things up as is and do some testing to make sure everything is still good. Once that is done I will get right to the next big task, I’ve decided to port the entire thing to Arduino. This won’t be too difficult since the code is already in C and I will be glad to get away from AVR Studio, to be honest. I made the choice to move to Arduino due to is massive use and rise in popularity over the last few years. Since this is an open source project I want to use a platform that people are familiar with. Let’s put industrial level induction heaters right up there with open source 3D printer firmware!
Don’t silence humanities most successful form of communication!
Despite what country you live in the topic of Net Neutrality once again affects you. I will get back to updates and work on the ReactorForge Induction Heater tonight, but this is a pressing issue, and we should all be very concerned. More so than concerned we should be active and involved. Voicing your opinion requires only minimal effort. If you don’t have an opinion or have never even heard of the issue, don’t just repeat someone else’s. A quick google search of “Net Neutrality 2017” will help explain the problem. Yes, do include 2017, because this happened already, back in 2015. The following paragraph is my synopsis and view on the matter.
Net Neutrality 2017
I rarely voice my opinion publicly on political matters but hear me out. Our policymakers disgust me. Despite the fact that both parties support net neutrality, they yet again go against our voice. The internet is by far, the most successful form of communication humans have ever invented. We can not give away control of that medium to entities who would redefine it for their financial gain. ISPs or any corporate entity for that matter SHOULD NOT be in control of Internet services. Internet traffic should be treated equally – email, files, web content, can’t be blocked, slowed or discarded by ISPs. I hope our state reps continue to back us up. Call, Facebook, Twitter, and or snail mail your rep! https://www.house.gov/representatives/find-your-representative
From left to right.
- The first MOSFET version on a PCB. It worked great but didn’t couldn’t handle the power level I wanted. I ended up pushing it to failure and moving to brick IGBTs.
- The first IGBT version on a PCB. This design is based on a CD4046 PLL and uses gate drive transformer to drive the large brick IGBTs (the ReactorForge now uses hybrid drivers). If you are into electronics and you’ve never worked with a PLL, even if just on a breadboard you should. PLL’s are very well documented, fascinating little devices. This circuit works great but its frequency operation range was limited by the external passives for the VCO (voltage controlled oscillator). Due to its reliance on these passive components, it is also affected by temperature.
- For mainly that and a few other reasons I decided to explore a software PLL solution. After going around the usual suspects and understanding how a PLL worked I thought there must be some way to do it with a low-cost MCU, not a freaking FPGA or high power processor. Maybe some type of PWM/comparator combination I thought. I found my solution in a motor controller, or power stage controller chip made by Atmel, the PSC216,316 microcontroller. That’s what this breadboard is, the early testing for what is now a rock-solid way to find the resonant frequency (Fr) and adjust power levels by offsetting that frequency from the current Fr all while soft switching (i.e. not making heat in the wrong places and exploding electronics). This was the result of those early tests…
One more board redesign may be in order but we’ll see. I may look into reducing the size of the board down the standard Eurocard PCB size of 100mm x 160mm. Although the current size is still within the free size limit of 160mm^2 for Autodesk Eagle.
Before putting it back on the cart I replaced the top plastic liner with 16 gauge sheet metal that I cleaned and lightly wiped down with oil. I think I’ll go back and add a lip around 3 sides with the box break to catch any falling sparks and molten beads of metal that try to escape.
Back on the cart!
And here it is with cooling set up on the new cart.
Now to move on to power. I am making a quick disconnect near the breaker box. I will need to draw and 3D print a small enclosure for the 3/8″ dual splicers. More on that progress here.
One trip the hardware store later and I’m ready to hook utilities up to the induction heater.
Hooking up cooling water isn’t the only step… Power!
I also ordered a larger variac, a 5000VA 220V model to aid in testing and firmware optimization. I have a small 2000VA 120V variac but running it on such low voltage skewed a lot of the readings. The variac is nice because running full power while testing new features can a bit nerve-racking and wasteful.