There are lots of laser cutters and other CNC machines available for a decent price online, but the major hurdle to getting these machines running won’t be the price or the parts. It’s usually the controller PC, which might be running Windows XP or NT if you’re lucky, but some of them are still using IBM XT computers from the ’80s. Even if the hardware in these machines is working, it might be impossible to get the software, and even then it will be dated and lacking features of modern computers. Enter the Super Gerbil.
[Paul] was able to find a laser cutter with one of these obsolete controllers, but figured there was a better way to getting it running again. As the name suggests, it uses GRBL, a G-Code parser and CNC controller software package that was originally made to run on an 8-bit AVR microcontroller, but [Paul] designed the Super Gerbil to run on a 32 bit ARM platform. He also added Z-axis control to it, so it now sports more degrees of freedom than the original software.
By way of a proof of concept, once he was finished building the Super Gerbil he ordered a CNC machine from China with an obsolete controller and was able to get it running within a day. As an added bonus, he made everything open so there are no license fees or cloud storage requirements if you want to use his controller. [Paul] also has a Kickstarter page for this project as well. Hopefully controllers haven’t been the only thing stopping you from getting a CNC machine for your lab, though, but if they have you now have a great solution for a 3040 or 3020 CNC machine’s controller, or any other CNC machine you might want to have.
Nice port of the Grbl software. One of the things that LinuxCNC has that I find useful is the ability to compensate for backlash. Larger machines seem to have a small amount of backlash and LinuxCNC does a nice job of allowing this to be compensated for. The end result is circles that have the proper shape. I asked the question a couple of years ago and the answer was that Grbl didn’t have it because it required having the compensated axis come to a complete stop before making the compensation adjustment – and it wasn’t on their roadmap. If that was added, it would be very useful for larger machines.
LinuxCNC has a kinematics model that can handle interpolated splines with a constant cutter surface velocity. Usually fairly slow by comparison to other systems, as we can barely get 5-axis out of our clubs pi3B+ RT OS. See user name link to sf, as we are still flagged as spam on HaD posts for some reason. :-)
GRBL is fast due to its simplicity, and is better for things like belt-driven 2.5D engravers or photo-plotters. However, one also can’t expect the same precision out it as a EMC2/LinuxCNC machine.
Neat project,
J
For a while now, the open-source CNC community has been between a rock and something else hard. GRBL running on microcontrollers is great for low latency, but is not powerful enough (due to the 8-bit microcontroller) to handle difficult kinematics. LinuxCNC takes care of that, since it (generally) uses a desktop PC, but in order to get low enough latency to handle reasonable speeds, has to have a parallel port. It is NOT sufficient to use a USB parallel port because of the additional latency involved with USB, making it impractical to use this within a closed control loop. There MAY be modern PCs with parallel ports, but I haven’t seen one in a while. Porting GRBL to ARM means that it can still run as a real time application, but without the speed and code size limits of microcontrollers, and there are plenty of ARM chips that have directly-controlled I/O pins, eliminating the need for an old-fashioned printer port.
I haven’t tried LinuxCNC on a RPi, but my concern there is that even an RTOS running on an RPi will have latency issues, just due to multitasking overhead. Using a port of GRBL on ARM without an OS seems like a good solution.
I would predict that there will be, for a while, separate forks for ARM and AVR ports of GRBL, but eventually all development will focus on the less limited ARM platform.
Using an ARM with a couple PRUs, or something like the Propeller might now be possible.
AFAIK this is what Machinekit (http://www.machinekit.io/) does.
Machinekit is EMC / LinuxCNC fork
oui
There is the grbl-lpc ARM port for the lpc1769 already. I have it running my CO2 laser for about a year now.
For Linuxcnc, instead of the parallel port, many have begun to use Mesa FPGA based controller cards. For about $100, this adds multiple I/O and low jitter step pulsing. Really good Linuxcnc support too. The parallel port is only good for about 60khz step rated where the FPGA based card is good for many times that. Needed for high resolution servo encoders and even newer stepper drivers that have 32microstepping or more capability.
Modern PCs have this newfangled thing called expansion slots, just find a PCIe Parallel port card and insert it into one of those – voilà!
I haven’t delved into it but 32-bit ARMs are getting pretty quick these days and many have floating-point built in, I can’t help but question exactly how much horsepower you need to move a cutter in a smooth way even with fancy kinematics?
It’s not so much the processing power as the real time requirements. You really need very predictable latency, which is hard to do with standard GPIO on most ARM chips. Going forward, ARM chips with added PRU cores or FPGA coprocessors are probably the way to go. You get the benefit of both, a nice snappy CPU for handling kinematics and parsing, with a separate unit dedicated to generating pulses.
HaD did a story on a project that used a driver board with dedicated timing and pulse generation. Could even be daisy-chained. Pretty small and capable for the size and price. Adafruit might carry the board.
A FPGA with hard cores like Zynq would be a good next step.
Yeah, backlash compensation is essential for high precision work. My machine is tiny and uses SFU1204 ballscrews, but still needs 6 micrometers compensation on the X and Y axes.
Coming to a stop to apply backlash compensation wouldn’t be a problem if it were done in firmware. It’s only a problem when you have to do it as normal movements in the gcode. I deal with it by milling circles in 4 quadrants where I arc to the X or Y axis crossing and then do a short linear move applying the compensation while moving to a point on the circle 30 micrometers past the axis crossing. But in firmware, the compensation motion could be done at maximum speed while continuing to move the other axis independently at the current feedrate. You could probably even use a higher than normal acceleration rate for it, since you’re only accelerating the mass of the leadscrew rather than the whole spindle carriage.
I tried to find his grbl port for the stm32f103 but haven’t found it. The ones on GitHub haven’t been updated in a long time.
Similar to his last Kickstarter GRBL centric project he didn’t release the modified soruce code till well after the campaign was completed and delivered. I assume this campaign would be no different if it reaches it’s goal.
Ok thanks. I have a few stm32 boards I would like to test his version of grbl. I already run grbl on several different micro controllers including the lpc1769 ARM version. Just wanted to see if there are any speed increase with the STM32/grbl.
So we have an old Bridgeport mill that the settings battery died on and while doing maintenance on it got disconnected from power. So the configuration got wiped out. And noone in our office can figure out the system. Do you think something like this could help us get it back up and running?
You probably want to get a classic high-powered parallel-port style modular controller, so your feed-rates and tool-pressure will be tolerable. There are many stepper-style retrofits on the EMC2/LinuxCNC website, and certainly worth trying if your machine isn’t servo based.
Ahh. So it probably isn’t going to be remove board, insert super gerbil and back to milling. Thanks. I will let our shop guy know.
@ Hal H
We have older Fanuc 5T and 5M systems in the shop. We lost all the parameters on the Fanuc 5T/Mori Seiki lathe. It took months of working through the binary parameters to figure out what each one did and how and what they affected. I can’t speak for the Bridgeport, but we got some small leads from the original tool builder (built in 1978) and directly from Fanuc about the parameters, options, and settings.
There are complete retrofit systems for about $10k + and, to be completely forward, it would have been cheaper for us to purchase the retrofit than to reverse engineer the old NC control parameters. It would have also brought the system a modern controller and extended the life of the tool.
I’d expect your Bridgeport would use big servo motors and encoders, not stepper motors, so you might be out of luck. There are various people making retro-fit CNC kits and replacement/upgrade electronics for mills like yours though, it’s worth having a google.
Thanks JohnU. I will look into those retro kits.
Our bridgeport uses a ProtoTrak controller. Best bet is to get ahold of the MFR and see if they can help you out. I thought our unit had died when it turns out the 3.5″ floppy the OS runs from had just died. They pointed me to the part of their site that has the file and luckily we had an old PC around with a floppy drive. Back up and running nice and quick.
Connor Wolf on youtube had a video a couple years ago where he mentions he needed to enter 60 or 70 codes after it lost them – https://youtu.be/5MlEco5dYI4 – CNC 2 – Bridgeport Series 1 R2C3 Initial bringup
I continued on and forgot he also replaced his controller with Linux CNC – https://youtu.be/gKBFxyBw6kE – it was a bit more then plug it in required
Isn’t this exactly what TinyG does? I swear you could search-replace the names and leave the rest of the text the same, and I wouldn’t be able to tell.
TinyG does have a much better trajectory planner than grbl however it only runs on a few compatible boards. I just don’t care for any of the compatible TinyG gcode senders available. Grbl runs on many micro controllers, the most recent is a ESP32 port. I use the grbl-lpc version on my laser running Lightburn.
I’m a little surprised that no one has jumped on the the “added z-axis control” article typo/mistake yet.
“By way of a proof of concept, once he was finished building the Super Gerbil he ordered a CNC machine from China with an obsolete controller and was able to get it running within a day.”
Surprised they haven’t realized that and glommed onto his effort.
So from the video, the host software is Windows only? Hard pass.
bCNC + TinyG
Forgive me, but how is this any better than a smoothie board or any other 32 bit mcu G code interpreter? Looking more closely at it, it looks like just another 3D printer controller.
Honestly I feel like it is straight up inadequate for running a proper CNC system. The moment I saw pololu like stepper drivers I lost interest. Sure you could tap in to step/direction with jumper rails, but really I wouldn’t use this to retrofit anything beyond those silly belt driven routers.
The beauty of Linux CNC is that you can scale it like crazy. You can run a basic bootstrap machine with iron gas pipe ways and a Dremel spindle, or you can use it to control a full blown 5 axis horizontal machining center with servo driven axii, coolant, and tool change. The feature set of LinuxCNC is immense, that is partially why it doesn’t change much. The software is already capable of so much. Your humble parallel port is fine for a garage setup, but toss in a mesa card and you can drive modern machining centers as good as commercial offerings that cost upwards of 5 figures.
This project is a Kickstarter propaganda He grabs some open-source code on github from other people who did the port of GRBL, makes a kickstarter with it to cash money in, does not release the source code of his project, the board is not particularly well designed (it´s just a remake of another board), and the pricing is meeee.
Take a much more well finished smothieboard or machinekit, and you have something well-supported, well-designed, with a big community behind, better performances, and better pricing.
So this article is just free advertising for something that really does not deserves it. It´s just a PR Kickstarter stunt.
@SeaShadow, @walter:
100% ACK.
The problem in free, open source world is not motion control. It is the CAM.
3axis is more or less possible, but 4 axis is still not much more than operations like engraving on a cylindrical face.
grbl for stm32, grbl for arm, grbl for avr, grbl for pic32… isn’t it about time grbl gets abstracted?
Oh wait… it has.
Why hasn’t shine potted Linux cnc to Windows and running with a cheap stm32f103c8? Just curious.
afaiu linuxcnc needs a realtime kernel and hardware
I meant, “why hasn’t anyone ported”…too early to see properly.
But the architecture of Linux CNC could be made so the computer just send the gcode to stm, then stm is the real-time kernel to handle all the motion /acceleration curves.
using linuxcnc doesn’t make much sense if you don’t use it to interpret gcode and handle motions
But that “interpret and handle motion” part is just code. Why can’t it be ported to stm? I DON’T want to use Linux. Just the “interpret and handle motion”part of LinuxCnc on an stm , so I can use a cheap laptop without a parallel port.
then why do you want linuxcnc?, all you need grbl running on STM and one of the many GUIs to stream gcode to it
Backlash compensation for one….
But backlash comp is done in “interpret gcode and handle motions” layer
BTW Has anyone seen alive port of GRBL (or TinyG) on STM?
I’ve never been that much of a fan of Grbl, I think due to it’s latency issues when used with a rpi / Chillipepr (such as ignoring zero out commands for work offsets on odd occations).
TinyG or G2Core as it’s now been renamed for 32bit seems to work a lot better with Chillipepr
I discovered recently that CNCjs which can run on a Rpi3, but also allows for web access works a lot better with grbl / solves a lot of the latency problems since cncjs has a backend on the pi to cache the g-code
From a hardware point of view I’m hoping to move to a duetwifi board
since the steppers drivers are trinamic which makes them a lot more configurable and silent if you want but also strong enough for nema 23’s (there’s also the potential for measuring torque)
the tricky bit is getting the software working which is only partial I think with cncjs at the moment
Can someone explain how this is different from the 32 bit 3D printer controllers like SmoothieBoard or Duet?
It looks like it uses the same stepper driver modules used in crappier 3D printer controllers with the tiny, easily broken pots that set motor current, and no real heat dissipation for the driver chips (heatsinks stuck to plastic IC packages don’t really do much).
Seriously, just get a DDCS, install Pandora on it, and be done with all this janky CNC hardware. Grbl, and associated hardware is, without looking up a more appropriate term, trash. Any body who wants more than a toy, such as an Eggbot or similar, should seriously consider something else. There ARE many other options, and have been for some time.