Sheesh, let me start off by saying ChatGPT isn’t taking anyone’s job any time soon. I decided to complete the coding segment of this project with ChatGPT (shorting this to GPT from here on) on openAI mostly as an experiment to see how it would go start to finish. It did not go well. It took about 3 and a half days since the last article/coding session. It didn’t just take a long time either, it was extraordinarily frustrating.

The biggest problem was GPT seems to have short-term memory loss. I offered a bit of advice in my ChatGPT article, one of the main points was to name your application for reference for communicating specifically with GPT. Whenever I ask GPT to revise code I also ask it to repost the complete application code. If you don’t do this you will have a lot of trouble, mostly because it will shift functions all over the place for no reason making it very difficult to locate the code that changed and ensure you have all the functions back in the code, until it crashes.

For $20 per month you get 25 messages per 3 hours on the GPT 4 model. This means each error wastes a very finite amount of resources. I started off the “conversation” with the request to always post the complete code every time with zero omissions because I’ve already had a good deal of trouble with this. I still constantly had to tell it to post the entire code. Additionally there’s a character limit per message so usually the complete code is at least 2 messages, sometimes 3. All of this lead to me only getting 10 or 15 useful messages per 3 hours.

Anyway, the biggest problem was GPT would often omit already completed functions from the code without warning and because it also frequently reshuffled the order of the code it was quite difficult to identify these issues until the code was run and an error caused a crash. It’s also worth noting this is node.js which is javascript which is not compiled meaning there’s no code validation prior to launch.

This should run on any system running Node.JS but I’m running it on Debian, my go to for anything I can get away with running on Debian. Don’t forget to update the IP’s and ports and the Twilio keys and phone numbers. I’m using a Twilio trial account for now. It gave me something like $15 and a number. I have no idea how long that will last. Also with a trial account you have to verify the destination number, which is fine with me.

Please note if you attempt to build this thing and use my code I did my best to test it (something like 30 hours of cycles) but it might not work right and might set your house on fire. I’m also playing with enough electricity to harm or kill. Please read the disclaimer at the bottom of the page but also remember anything you do with my work is on you, I accept no responsibility. By reading any single character on this page you agree to these terms. Got em.

So after all that here is the code:

SmelterServer.js

So you can see from that code we’re doing a lot of stuff. Here’s the webpage it hosts:

Nothing too fancy but it works. It starts with one row, click the button to add as many cycles as you want. Enter the duration you want on the left and the temperature you want maintained on the right.

From here the first set of values is sent to the MCU. The MCU confirms receipt and begins its work including counting the timer itself and monitoring and maintaining the temperature. There are a number of other processes that happen to keep everything running smoothly as well. There is a watchdog packet sent every 30 seconds. If the SmelterServer doesn’t get a response it sends an SMS message with Twilio notifying me something bad is happening. There is also a post message sent to the SmelterMonitor.js application at port 4000. This is the monitoring page to keep an eye on the smelter remotely.

And here’s the SmelterMonitor.js:

And here’s what that page looks like:

As you can see its function is pretty simple. Take the values from SmelterServer, shove them in some variables, post some HTML so we can see what’s going on anywhere on my network. It’s also not 46 degrees in my office, the thermocouple seems to be quite a ways off but 30 degrees in the scheme of 1000s doesn’t mean much, plus that’s not actually the thermocouple that’s mortared into the smelter.

And lastly here is the SmelterMCU code designed to live on a NodeMCU/ESP8266:

This code is fairly complicated but the function is pretty simple.
1. Initialize everything
you might notice a safteypin that’s turned on during the setup function. This is our mechanical contactor. To turn on the smelter you hold down a button that activates the contactor which powers the NodeMCU which then powers the contactor circuit itself. If thermal runaway is ever detected we’ll assume one of the solid state relays failed closed and cut the power to everything by releasing the contactor. One of those SSRs almost started a fire on a 3D printer I built a long time ago when it failed closed and this is way more juice than that was.
2. Wait for instructions from SmelterServer.
3. Confirm receipt
4. Start the timer, Turn on the heat, Monitor the temp, Turn off the heat when temp is reached, cycle to maintain.
5. Wait for watchdog packets
6. Respond to watchdog with current Temp reading
7. Repeat until timer runs out
8.Shutdown

And that’s it, all done!
Next up, finalizing the wiring, and real world testing. Then we go to town on the 60lbs of 1 inch aluminum cubes I just got.

Leave a Reply

Your email address will not be published. Required fields are marked *