It was discovering the open source ‘GRBL’ CNC controller project that was one of the factors in tipping me into trying to buld a “cheap” CNC. I am new to Arduinos – I only really looked at them earlier this year (trying to make a reliable tacho for my jet engine). Prior to that, I was quite prejudiced against them and their ilk. It seemed to me that people were using them to solve problems that would be better to solved with “proper” electronics. I was familiar with analogue electronics and also with microcontrollers – I used to program PICs in assembly language – Arduinos just seemed to be being used as sledge-hammers to crack small nuts. Having looked at them properly, I’ll now conceed that I was (mostly) wrong. They really are handy little things, and now that generic clones are available, probably cheaper than anything more than a handful of discrete components.
Anyway, it was really easy to get a GRBL CNC controller running on an Arduino Uno and connected to the stepper drivers via a bog-standard breakout board (shield in Arduino speak). I was really impressed with how easy it was to configure and use GRBL.
Mission creep struck again, and I decided that it would be nice if the controller could be operated as a stand-alone device – it would be nice not to have to expose a laptop to the shed environment. GRBL pretty much maxes out the memory and IO of the ATmega328 chip in the arduino, so there’s nothing left to use for an SD card, for instance. (There are schemes around where people have used a second or third microcontroller to talk to the Arduino, but I didn’t examine them in detail.)
For about the same price as an Arduino, one can get an ESP32: A much faster, 32 bit controller with built in WiFI, Bluetooth, and more IO pins. A few people have also ported GRBL onto it… Another rabbit-hole opens up: I first found GRBL_ESP32 which led to Fluid NC (and I’ve since found grblHAL ).
A slight fly in the ointment is that the ESP32 runs on 3.3V and can’t really drive the stepper motor drivers directly (it *may work, but they’re usually expecting 5V).
There didn’t seem to be any readily available (and cheap) breakout boards that addressed this, so I thought I’d make a simple one of my own.
Behold MK1!
It didn’t work 🙁 – The nice, cheap, readily available, easy to use level shifters (the two small blue boards) didn’t have enough oomph.
MK 2:
This works well, and I could run G-Code from the attached SD card, or over WiFi using the GRBL ESP32 software.
Out of curiosity, I ran the same program on both the ESP32 and the Arduio UNO – it was a complicated 3D scroll carving with a lot of curves and 3 axis moves. On the Arduino it took 3minutes and 23 seconds to run at 100% feed rate and 3:07 at 200% feed rate. On the ESP32, with the same settings, the times were 3:03 and 2:46. The difference is down to the processing speed of the Arduino not being able to keep up with the moves.
Having made my mind up to go with the ESP32, I built the electronics into part of an old rack mount that I had. Something a bit bigger would have been good.
I thought that the heatsink for the drives was overkill, but I have had it knocking around for decades, and it fitted the space available quite nicely. In practice, it gets quite warm – possibly linked to that fact that the drives are not what they claim to be, so probably lucky that I used it.
I wanted to use the machine to cut its own front panel, so just roughly wired it together at this stage. Electricians and panel builders look away now.
Still not pretty, but it worked!
After a bit of cleaning up, I was very pleased with it
It was an absolute pleasure just to be able to fit all the parts to the panel without having to mark, drill, or file anything by hand.
I experimented with different versions of GRBL on the ESP32, but kept coming back to GRBL_ESP32, even though it is no longer being supported – it behaves just like GRBL on the Arduino and works well with my favourite G-Code sender program (Openbuilds Control). Being a port of the mature GRBL core, the need for support is moot.
I think that the way forward is probably FluidNC. I’m not using it currently because Openbuilds Control doesn’t recognise it (although they seem to be in the process of adding it currently).