[Jim Conner]’s DIY tab spot welder is the sweetest spot welder we’ve ever seen. And we’re not ashamed to admit that we’ve said that before.
The essence of a spot welder is nothing more than a microwave oven transformer rewound to produce low voltage and high current instead of vice-versa. Some people control the pulse-length during the weld with nothing more than their bare hands, while others feel that it’s better implemented with a 555 timer circuit. [Jim]’s version uses a NodeMCU board, which is desperately overkill, but it was on his desk at the time. His comments in GitHub about coding in Lua are all too familiar — how do arrays work again?
Using the fancier microcontroller means that he can do fancy things, like double-pulse welding and so on. He’s not even touching the WiFi features, but whatever. The OLED and rotary encoder system are sweet, but the star of the show here is the 3D printed case, complete with soft parts where [Jim]’s hand rests when he’s using the welder. It looks like he could have bought this thing.
The videos leave no stone unturned in documenting this project. If you’ve got the time, check them out. Highlights include an overview in Part 1, blowing out an SSR and case design in Part 2, smoking wood and a large battery pack time-lapse in part 3. There’s a bonus video going into detail about the electrodes.
Can’t get enough spot welders? We’ve posted too many to list. So to amuse you, we went looking for the earliest spot-welder post on Hackaday. This one from 2005 seems to be the first, but it’s got dead links and no details. Boo bitrot. This spot welder from 2009 is a beauty. Find a better, earlier one? Let us know in the comments below.
That’s awesome looks off-the-shelf.
Nice job!
“I don’t know LUA and was too lazy to work it out properly”
Then why’d you use Lua? Seems like there are a lot of other scripting choices available these days. I’m just curious as to the ‘why’ of that design decision.
I’d guess it’s because Lua is the language of nodemcu. I too learned (“learned”, I basically only copied code from the internet and made guesses based on python) because of that.
Another possibility is that he simply wanted to learn a new language
Well, there’s the hardware and the software. With the kind of spotty information available and what you have to seek out, it /seems/ like you have to use Lua with a NodeMCU board. It’s actually just an option. You can use, for example, the Arduino IDE, to do it all in C/C++.
(I’m still fiddling with Lua to see if it brings benefits worth the effort to learn it. Its proponents certainly think so, but then again so do the erlang proponents — which I know first-hand was not worth it.)
If you haven’t worked with a NodeMCU board before, you might not know that they take the easy-eo-understand esp8266 GPIO numbering and change it to their own D0, D1, … pinouts. If you use Lua, you just use those “D” number integers (I don’t know if they have constants for them somewhere). If you use Arduino stuff, you use the GPIO numbers, but they have handy #defines for D0, D1, …
So, the canonical first question everyone has to ask is, “Wait, pinouts, wtf?” It’s easy to find charts all over the place giving you the correspondence between the two systems, but I have yet to stumble across why the NodeMCU people (or maybe it was the AI-Thinker people) did it in the first place. I’d love to know.
LOL, pinouts. If you haven’t used an Arduino UNO before, you might not know that they took the easy PortB, Pin 1 style pin names of the native AVR and gave them these cryptic “Analog 1” and “Digital 12” names that bear no relation to the underlying hardware. :)
It seems every “simple” system maker starts off by re-numbering the pins, datasheets be damned. My guess is that it’s almost always hubris rather than malice. But that only makes it a tiny bit better…
I’m inclined to give Arduino some slack here and not inclined to do the same for NodeMCU. 99% of Arduino users will never have seen an AVR datasheet. The simplified pin labeling is pretty helpful to the target audience. The whole experience is shrink-wrapped. I agree, it would be helpful for “the rest of us” if they also put the original labels on the board.
OTOH, NodeMCU is more likely grabbed by someone who specifically wanted to use the ESP8266. I.e., they know something about something. I might forgive them a little if they had copious and clear documentation, but you really have to sniff around to see what’s going on, and then you have to add the puzzle pieces together yourself.
Still, I’m glad to have these inexpensive boards! (What a whiner I am!)
(I just checked, and the AI-Thinker module that the NodeMCU boards have does use the original GPIO labels from the ESP8266, so they are innocent.)
>”gave them these cryptic “Analog 1” and “Digital 12” names ”
That’s because the actual pins on the chip don’t go in a neat order. The available ports on a mega328 go D,B,C with the D port being 8 bits wide and B,C being 6 bits wide with the crystal in place, but B being 8 bits wide without the crystal so you can still address it by accident, and the C pins also being the analog inputs, so it’s just confusing for someone who will never read the datasheet.
lua doesnt have arrays, it has tables. which is more of a general purpose data structure in lua than any particular type. its your array, your struct, your class and a hell of a memory whore when you try to store any kind of big data. like storing image data sucked, using named keys for each rgb element for example wasted more memory than just storing them a [1], [2], and [3] (btw, lua starts counting at 1, not 0). even that two got problematic and ultimately i used a hack to just store all the data in strings, all wrapped up in a ‘class’ table with read and write operations defined in the metatable. good stuff that lua. not something id use at the embedded level though.
I recently played around and added micropython, bwBasic, and TinyBasic to one of my Reensas S7 boards. I was thinking of adding Lua as a fourth option but now that I’ve read your overview, I’ll look for something else as a fourth language option.
How about Forth as your Fourth
That sound like a good idea.
Obviously you should use forth, like God intended ;-)
It is a very nice build. I’ve got a small commercial spot welder (two if Dad’s Hobart is wasn’t stolen by movers), but it’s a bit too big for small jobs like battery packs. I’m collecting the bits and pieces to build something like this. Not likely to use Lua though, especially in view of Lord Nothing’s comments. I’ll certainly use either C or forth.
I don’t suppose you have the sources shared for any of these?
I wouldn’t mind trying those out on my Renesas S7 board…
Not sure what NodeMCU is using, but the most recent versions of Lua use an algorithm to detect that it would be more efficient to implement an actual array for numeric indexed table entries. Of course it’s still an array of Lua data types, each of which can be a string, number, function, or whatever, so still not very efficient, but much faster to access than large string-indexed tables.
it just takes throwing in a module to handle that ‘userdata’ type. userdata is the oft overlooked type and people who just want to keep it lua will avoid it like the plague. but its really powerful for when you need efficient handling of data. you usually have to break out your c compiler to take advantage of it though.
The NodeMCU board comes with the NodeMCU Lua firmware preinstalled, so that’s what you get if you don’t reflash the ESP8266 firmware. It’s very convenient because of the interactive console, which is kind of amazing on a chip as limited as the ESP8266. I’ve done a few small projects with them, such as a timed lapidary saw shutoff controller, but I use the wifi functions to monitor them remotely too.
There is another new take on a tab-welder being developed by one of the EEVBlog Forum posters, it is very compact because it uses an RC style pouch battery pack for it’s supply, no MOT, no capacitor bank, just plenty of Amps straight from the pack.
http://www.eevblog.com/forum/projects/guesses-on-what-i-am-attempting-here/50/
https://www.youtube.com/watch?v=Ceos88VO6p4
Should include a BMS to take care of the pack…
Should, maybe, but then your BMS has to be able to handle the full current, and most BMSs don’t have that many big MOSFETs in parallel. You can allow for that by putting a big capacitor bank on the output of the BMS that can supply all of the energy needed for a single weld, but now it starts getting expensive. Or you can just sense the battery voltage with the microcontroller, and give a warning and/or disable the system when the voltage is too low.
(forgot to hit the “notify” button).
“This one from 2005 seems to be the first, but it’s got dead links and no details. Boo bitrot.”
Wayback Machine to the rescue!
https://web.archive.org/web/20070213020823/http://philpem.me.uk/elec/welder/