The steps/precision topic is more complex than it first seems. The full-step resolution of the stepper motors is will defined (1.8deg or 0.9deg) and the H-Bridge driver chips can sub-step this to improve step resolution - but at the expense of holding torque. Turning up the drive current on the driver can re-increase torque, but the stepper motors have limits and the drivers too.
The highest resolution is not always the most accurate, there being a world of difference between the two terms. I don’t want dropped steps if cuts get more aggressive, but I do want the best accuracy I can have from the hardware.
I concocted a few test cuts where I knew I could turn up speeds/feeds and push the steppers to their limits and then experiment with micro-steps and drive current until I felt I had the best of all worlds. I read up on the stock Carbide controller PCB driver chips, looked at the component values and (with a little uncertainty) concluded that the drive current and torque had ended up at or just above the original machine’s, but with the TCM2209’s ‘Trinamic’ logic, the steppers run much quieter.
There is a default behaviour on the 2209 to reduce holding current when the steppers are not moving, relying on the fact that maximum stepper torque is when static and trading a bit of that for overall reduced current draw. The 2209’s have to be hooked up to a UART interface to adjust this setting, and if I recall turning this behaviour off is a ‘one time, permanent’ action on the chips - so I decided not to and to see if I had good enough holding torque, which I believe I have
FWIW, I’ve gone down a bunch of routes for controllers by now (i.e. wired the following to my machine in some manner):
- Boring GRBL board
- g2core on an Arduino Due
- EdingCNC (specifically CNC720)
- LinuxCNC with a Mesa Ethernet I/O board
- LinuxCNC with EtherCAT servo drives, VFD and soon I/O
My thoughts on this thread based on this experience is:
- A GRBL or GRBL-like board is probably the right choice if you don’t already know it isn’t. GRBL is cheap enough and wiring is flexible enough that I don’t think you should feel the need to jump out and jump into something more capable right this second. I love my LinuxCNC but it’s painful and somewhat costly to set up, so why bother if you don’t even know you need it? If you find you need something more capable later, you can buy it and wire it up then.
- Trinamic stepper drivers are
(I used these, they’re made to play nice with many of the GRBL boards and they’re high-powered).
The path I followed was this:
- I was annoyed at how loud the Nomad 883 Pro was. When I put it into a well soundproofed box, the spindle noise was gone but the damn steppers are crazy loud, so I wanted to use Trinamic drivers. That meant replacing the controller.
- I played around with some GRBL or GRBL-like boards (like g2core with the Arduino Due) but was ultimately unsatisfied. GRBL was waaay too limited (couldn’t even hook up alarm pins from the Trinamic drivers for step-loss E-stop) and g2core didn’t feel ready for prime time (badly documented, really hard to set up).
- An aquaintance recommended EdingCNC, so I tried it and ended up sticking with it for quite a while. The board has plenty of I/O for all my I/O needs and the hardware has accompanying software that’s very “batteries included”. Combined with the Trinamic drivers (on a custom carrier PCB), it worked really nicely, it even fit in the Nomad’s electronics box.
- After a while I started lusting for closed-loop control and ended up buying servo drivers. EdingCNC would have been able to shout instructions at them but it wasn’t able to count their encoder pulses, so only the driver → motor loop would have been closed, the controller → motor loop would still be open. This got me looking at LinuxCNC.
- I started running LinuxCNC on a Mesa card for a while but found that the wiring was a massive pain in the arse, a pain to set up and I couldn’t get the closed-loop control working with the particular board I bought.
- So I switched to EtherCAT for everything. The wiring is literally just Ethernet cables, the configuration is just a few text files. There’s no breakout board at all, you just wire the daisy-chained servo drivers and VFD to the computer running LinuxCNC.
And that’s where I am today. I haven’t yet run the latest iteration of my machine though because I need to buy some laser-cut panels to complete its enclosure and I’m waiting for the car I just bought to be delivered so I can pick up the panels instead of paying ~$200 for the supplier to send an entire truck to me.
There are two ways you can set it:
- OTP: Of course, this is a one-time thing. Once you flip the OTP bit, you can’t flip it back, being OTP and all.
- UART: This makes the change until power is cycled. I had an ESP32 wired to my drivers so that I could change the configuration on startup, fiddle with parameters on my computer while the machine was running and for monitoring (the Trinamic drivers have nice monitoring metrics).
One thing I really wanted to get to but never did is CoolStep. You can configure the driver to dynamically adjust current to match the detected load, kinda like a servo. This means much lower power usage (so less heat).
Currently working up a GRBLHAL build with this board. https://www.grbl.org/grblhal-breakout-board
Additional input, outputs, and supports an another axis (or two). I am converting a Shapeoko 3 standard rebuild to a 4-axis machine. For drivers, I’m thinking about TMC5160 step sticks, but they’re hard to come by ATM.
Have a look on AliExpress, there are plenty there.
Just scanning the available GRBL versions, given that my research into this was originally over a year ago, and GRBL HAL has come on in leaps and bounds. Were I starting from scratch, I would certainly take a look at this and see what hardware/PCB options made sense from there at the more budget end of the scale - a cursory look this morning doesn’t seem to show much as yet.
MEGA-5X is possibly a bit of a dead-end fork knowing this, without (I hope) any disrespect to anyone involved in its creation.
But this can and will likely forever be a no-win game of what’s best, and tomorrow that will have changed. If the goal is a working machine, then today’s solutions are best. If the goal is freedom to eternally extend and upgrade etc., then maybe HAL is the smarter option.
What I have works perfectly and as a ‘working machine’ complete with its controller, I have zero complaints… but what if Vectrics or Fusion 360 etc introduce a new feature not supported? If that bridge ever needs crossing, I will have to cross it then. I have what I set out to get.
When I chose to buy my Pro4 XXL, the main deciding factor for me was the mechanical construction of the machine, and not the electronics. I am not a fan of grbl, as I have been using Mach3 for over 15 years on my Sieg X2 mill I converted to CNC.
If I was to change the controller, it would either be a Mach3 setup, using a Windows pc, a Warp9 SmoothStepper, a PMDX Breakout boar, and a slew of Geckodrive’s stepperdrives.
2nd choice would be the Duet3, as I use the Duet2 WiFi in one of my 3D printers.
I have run into the “I’m not a fan of GRBL” line many times while perusing board/associated software offerings. Could anyone in this camp expand on this concretely? Like, what are 5 things I’m missing out on because I currently use CM (and the underlying GRBL hardware/protocol)?
GRBL is the Toyota Camry of the CNC world. It is a very basic CNC firmware that gets the job done.
Most GRBL controllers are still 8bit microcontrollers with limited memory and low clock speeds. This includes the Carbide board as far as I know. For the few boards that are running 32bit the GRBL firmware running on it has not been programmed to utilize the hardware as of yet so it is like running MS-DOS on a modern PC. Sure it is fast as hell, but it lacks 99% of the features you would expect.
I like the Duet + RepRapFirmware because RepRapFirmware was designed from the ground up around 32bit microcontrollers. It is fast and feature rich because it was never limited by 8bit. I have a ton of experience with it from 3D printing. It is however not a perfect match for running a CNC as it does lack certain Gcodes for things like tool changes and making circles. That however can be overcome with a good post processor and with custom Macros to implement those Gcodes. You just create a Macro called M6.g and when an M6 call is made that file gets executed.
Most GRBL controllers are still 8bit microcontrollers with limited memory and low clock speeds.
What are the real world implications of this? Like if I ran a part today with my original controller and then swapped for the Duet and ran the same part, what would I observe due to the 8bit vs. 32bit upgrade and higher clock speeds?
It is however not a perfect match for running a CNC as it does lack certain Gcodes for things like tool changes and making circles.
Are you mainly programming gcode by hand? I have only used Fusion360 to export my nc files and use them as-is. Would I notice a difference in behavior with this use-case, or would the benefits you’re referring to apply to those who are directly programming their own gcode?
If you are using a properly built GRBL based board like the Carbide Motion Board, you would not notice any difference in the parts. It is when you want to go beyond what the Carbide Motion Board can do where that has a major impact.
My Duet can support 6 independent stepper motors without any of the expansion boards they offer. With the expansion boards I believe it can support up to 127 stepper motors. Those motors can be tied together in different combinations for various axes (X,Y,Z,A,B,C,D,E,F, … ). They can be moved independently or as a combined axis. Meaning I can have two home switches for my X axis, home each side independently, adjust one of them to compensate for any offset in those homing switches positions, then move both steppers together as one axis. Other things I can do include build an automatic tool changer, build a dust shoe that automatically adjusts for the height of the stock independent of the Z axis, build a 4th or even 5th axis system, the list goes on.
When you configured Fusion360 to export your nc files you had to select a post processor to output your Gcode in a way that GRBL / Carbide Motion could process. RepRapFirmware has a post processor for Fusion360 as well. It takes care of most of the hard work for you. There are a few things that you need to program for yourself in a Gcode Macro though like handling tool changes. Here for instance is my M6 macro:
if exists(param.T)
if ( global.EndMillNum != param.T)
set global.EndMillNum = param.T
G53 G0 Z0 ; Go to 0 Z in Machine Co-ordanates
; Move to the tool change location
G53 G0 X{global.ToolChngXLoc} Y{global.ToolChngYLoc}
M291 R"Tool Change" P{"Please load tool number " ^ param.T ^ " into the spindle and click OK"} S2
M98 P"/macros/BitSetter.g"
G53 G0 Z0 ; Go to 0 Z in Machine Co-ordanates
M291 R"Set Spindle Speed" P{"Please Set Your Spindle Speed and click OK"} S2
else
M291 R"Tool Change Error" P"T Parameter Not Set" S2
M0
It makes sure that the M6 Gcode was passed a tool number, then it moves the Z axis to 0 which is all the way up. Then it moves the tool to a globally defined tool change location (which is just all the way forward in my case. Then it prompts me to load the tool on the Duet web interface. Once I have I click OK on the prompt window in the Duet web interface it executes my BitSetter macro and then continues on with the Gcode file I am running. For an example of a bit more complex Macro this is my surfacing one:
; Constants
var Debug = false;
var ProbeThickness = 15.5;
var CoordSystem = 20;
var StepOver = 10;
var DepthOfCut = 0.5;
var FeedRate = 8000;
var RPM = 24000;
var ZClearanceHeight = 25;
; Variables
var StartX = 0; ; The X starting position
var StartY = 0; ; The Y starting position
var EndX = 0; ; The X ending position
var EndY = 0; ; The Y ending position
var YDir = 0; ; The direction to go in Y
var YDist = 0; ; The distance to go in Y
var YPos = 0; ; The position in Y to move to
var YDistLeft = 0; ; How much we have left to move in Y
var ZDepth = 0; ; How far down we should be in Z
var XSorE = "End" ; Whether X should move towards the start or the end position
; If the printer hasn't been homed, home it
if !move.axes[0].homed || !move.axes[1].homed || !move.axes[2].homed
G28
; Adjust probe for low speed probing
M558 K0 P8 C"!io3.in" H20 F120 T300 ; Z probe number - Z probe switch type - probe recovery 1s probe speed and travel speed
G31 K0 P500 X0 Y0 Z0 ; Set trigger value - set offset and trigger height - Z probe number
M291 P"Insert your surfacing bit into your spindle and position it above the probe plate" R"Probing" S3 X1 Y1 Z1
; Set bit above center of probe
G91 ; relative positioning
; Probe Z component
G38.2 Z{move.axes[2].userPosition - (var.ProbeThickness + 2.25)} ; seek until the probe circuit is closed Z-axis 25 mm
G0 Z{var.ZClearanceHeight} ; rapid move Z axis 5 mm
G10 P1 L{var.CoordSystem} Z{var.ProbeThickness + var.ZClearanceHeight} ; store relative probe offset for coordinates system 1
G90 ; Absolute positioning
M291 P"Move to the starting X Y position for surfacing" R"Start Position" S3 X1 Y1 Z0
set var.StartX = move.axes[0].userPosition;
set var.StartY = move.axes[1].userPosition;
if var.Debug
M118 P0 S{"StartX = " ^ var.StartX} L2
M118 P0 S{"StartY = " ^ var.StartY} L2
M291 P"Move to the ending X Y position for surfacing" R"End Position" S3 X1 Y1 Z0
set var.EndX = move.axes[0].userPosition;
set var.EndY = move.axes[1].userPosition;
if var.Debug
M118 P0 S{"EndX = " ^ var.EndX} L2
M118 P0 S{"EndY = " ^ var.EndY} L2
M291 P"Are you ready to begin surfacing?" S3 X0 Y0 Z0
; Figure out which direction in Y we are going
if var.EndY < var.StartY
set var.YDir = -1;
elif var.EndY > var.StartY
set var.YDir = 1;
else
set var.YDir = 0;
if var.Debug
M118 P0 S{"YDir = " ^ var.YDir} L2
set var.YDist = {abs(var.StartY - var.EndY)};
if var.Debug
M118 P0 S{"YDist = " ^ var.YDist} L2
; Begin surfacing loop
while true
if var.Debug
M118 P0 S"Begin Layer Loop" L2;
set var.ZDepth = {var.ZDepth - var.DepthOfCut};
set var.YDistLeft = {var.YDist};
; go to the start X and Y position then down to Z Depth
if var.Debug
M118 P0 S{"Move to start X" ^ var.StartX ^ ",Y" ^ var.StartY} L2
G0 X{var.StartX} Y{var.StartY}
if var.Debug
M118 P0 S{"Move to start Z" ^ var.ZDepth} L2
G1 Z{var.ZDepth}
; we should be at the Start X position so move to the End X position
if var.Debug
M118 P0 S{"Move to X" ^ var.EndX} L2
G1 X{var.EndX} F{var.FeedRate}
set var.XSorE = "Start"
while var.YDistLeft > var.StepOver
if var.Debug
M118 P0 S"Begin Y Loop" L2
; move in Y by StepOver
set var.YPos = {move.axes[1].userPosition + (var.StepOver * var.YDir)}
if var.Debug
M118 P0 S{"Move to Y" ^ var.YPos} L2
G1 Y{var.YPos} F{var.FeedRate}
set var.YDistLeft = {var.YDistLeft - var.StepOver}
if var.XSorE == "Start"
; move X to the start position
if var.Debug
M118 P0 S{"Move to X" ^ var.StartX} L2
G1 X{var.StartX} F{var.FeedRate}
set var.XSorE = "End"
else
; move X to the end position
if var.Debug
M118 P0 S{"Move to X" ^ var.EndX} L2
G1 X{var.EndX} F{var.FeedRate}
set var.XSorE = "Start"
; move in Y the rest of the distance left
set var.YPos = {move.axes[1].userPosition + (var.YDistLeft * var.YDir)}
if var.Debug
M118 P0 S{"Move to Y" ^ var.YPos} L2
G1 Y{var.YPos} F{var.FeedRate}
; one last move in X
if var.XSorE == "Start"
; move X to the start position
if var.Debug
M118 P0 S{"Move to X" ^ var.StartX} L2
G1 X{var.StartX} F{var.FeedRate}
set var.XSorE = "End"
else
; move X to the end position
if var.Debug
M118 P0 S{"Move to X" ^ var.EndX} L2
G1 X{var.EndX} F{var.FeedRate}
set var.XSorE = "Start"
G0 Z{var.ZClearanceHeight} ; get out of the way
M400 ; wait for the movement buffer to catch up
M291 P"Surface another layer?" S3 X0 Y0 Z0 ; then prompt the user if they want to do another layer
Before you freak out though and think you need to be a computer programmer to use something like this there are online configuration tools, a vast community of people using this, and people like me who are more than willing to share their configs / macros. Most of my configs came from a default config for a WorkBeeCNC which uses Duet boards in their product. I took those and tweaked settings and added features specific to my setup.
None really. As it is, GRBL is great. My issue, is lack of 4th axis support, because original GRBL doesn’t support it. Also, GRBL isn’t actively maintained anymore.
GRBLHAL is a beast, in comparison,
https://www.grbl.org/benefits-of-grblhal
What GRBL does, it does well. The “problem” is that GRBL has zero room for new features and improvements. What GRBL does now uses the entire microcontroller.
Here are some things GRBL can’t do off the top of my head:
- More axes
- More GPIO for solenoids, sensors, servo drives and whatnot
- High-precision, high-speed movement (GRBL supports a theoretical maximum step rate of 100kHz but people seem to achieve around 40kHz. That means if you have 1 step/um, your maximum speed will be 2400mm/min). GRBL can do fast or precise but not both.
- Full closed-loop control (e.g. with linear scales)
- Full support for advanced G-code programming with macros, subroutines and the like
Like others have said, if you don’t feel limited by the Carbide 3D machine already, most of this doesn’t matter to you. If you start hacking on your machine and upgrading it though, you’ll probably run into the limitations of GRBL eventually.
There’s a difference between:
Essentially finished project which doesn’t have any reported issues or bugs to fix
and
…not maintained
where one worries about not getting stuff fixed — I’m sure that if there was something which warranted it, @chamnit or one of the other Grbl devs would fix it — and I find myself most productive on coding systems which are stable, and are not a moving target. I think it’s telling that the Shapeoko HDM still uses Grbl 1.1, just w/ a board which has the oomph necessary for the larger motors.
You could interpret it in multiple ways, it could just as easily be interpreted as a “cost reduction” method.
I will say that if Carbide 3D did offer an advanced 32bit control board option that was a plug in replacement for their existing board that offered advanced features like more axes, more gpio, web interface, I would probably have chosen to buy that instead.
I’ve effectively had to retire from developing Grbl due to a demanding new job and family needs. That said, Grbl on the 8-bit 328p is stable, and doesn’t have any major issues, as far as I know. I‘ve always viewed reliability as more important than feature sets, particularly when you are dealing with machines that are cutting metal.
That said, going to 32-bit is the obvious path forward. Sorry that I couldn’t help out in that department. A few years ago, I did look into and made a few ARM ports (and even a HAL) but didn’t feel like it was ready enough release and build upon. I didn’t think there was a killer ARM platform that would work for everyone. But I do think the RPi foundation’s new RP2040 looks very intriguing. A lot of pins, fast enough, cheap, and accessible. I’ve got a lot of unfinished features I’ve been wanting to add.
Apologies Will, and you are correct. Yes, there is a difference… I meant to write it’s not actively being developed but is actively maintained.
It’s also a great setup; I wasn’t trying to knock GRBL. Stability is critical for most users, but for me, the limitations of the Atmega328p ( like additional axes, encoder input) drove me to look for something else. I set up a small CNC lathe that uses an ESP32 variant of GRBLHAL.
That’s most helpful; I like concrete explanations 
Indeed, a 4th axis is where I started running into the “not with GRBL” comments first. For the others, most of those items are catch-22’s right? As in, the more you make a Shapeoko into not-quite-a-Shapeoko (additional axes, controlling you spindle coolant with the board, swapping motors), the more the GRBL limitations start to matter?
I thought I’d read comments that alluded to the processing/sender aspects themselves being limited. Other than the microstepping nuance where higher would slow one down, is there anything else on the cutting front alone (as in, compare GRBL with anything else but on a stock SO3) where GRBL is sub-par vs. others? And I think we’re at 40 microsteps/mm, so quite the headroom away from the 1000/mm limitation, if I understood that correctly.
Additional axes is really the only one that plain old Grbl can’t handle. Grbl can manage coolant, spindle control and you can use the biggest motors you want as long as you have appropriate drivers and power supplies. Ultimately, this comes down to what do want the machine to do that it can’t right now?
Also, a Shapeoko can never become a “not-quite-a-Shapeoko”. It’s a rule.
Good to know re. GRBL capabilities.
Ultimately, this comes down to what do want the machine to do that it can’t right now?
Good question. This started at looking at the new C3D spindle addition, which was desirable for reduced noise, precision, and power… but due to my machine’s age, I’d need the newer C3D board. I also do 2-sided and have wanted to try cylindrical machining, so I’ve already considered 4th axes and read GRBL would be limited here. Since the spindle would force an electronics purchase now, I felt it was worth considering if I should put that $140 into something more future proof, given my potential to need something different anyway.
That said, I also like asking “what could I be doing?” even if you have no obvious need for upgrading… as you don’t know what you don’t know I like hearing from modders and those with more experience, even if my use cases aren’t anywhere close to being extreme. It’s cool to realize where things could go: these custom macros (basically hearing about for the first time), seeing tool changers, other IO for automation.
Also, a Shapeoko can never become a “not-quite-a-Shapeoko”. It’s a rule.
Ha, fair… I just meant “not-quite-a-stock-Shapeoko” to acknowledge that C3D is making “packages” where everything works for the features they currently support. Going 4th axis, using other probes, implementing closed-loop motors and so on are not features C3D supports. It makes sense that when deviating from the features C3D supports, one might exceed the board they chose to support these features.
And I also wanted to understand if there are ways GRBL is universally worse than other things. As in, “If you cut the same part with Mach4 and GRBL, the Mach4 one will be better.” I don’t think this is what I’m hearing. That’s different than the other ways GRBL could be “worse” (or simply “limited”), which involve departing from the current Shapeoko mechanical/electrical configuration and wanting to add features.