comparing to Grbl, or FluidNC

but in theory, a Grbl component could completely replace the EMCMot+Stepgen components in LinuxCNC for stepper motors signal generation.


Hmmmm ok

the answer is simple,
GRBL,... is a firmware for CNC milling machines, laser cutters and the like.

LinuxCNC is a highly configurable motion control platform,
it can synchronize all kinds of input and output devices,
also from external not self-controlled movements.

It can handle all kinds of actuators, not only step/dir or RC servos. It can handle all kinds of protocols like Ethercat, CAN, Modbus, .... and even mixed.

It can handle
all kinds of inputs, glass scales, encoders, camera images, .....

It also doesn't need gCode as input, that's just another module in the chain


So if you want to operate a simple hobby CNC, you are well served with GRBL and so on, for everything else LinuxCNC is the best choice.

One aspect that I did not see mentioned is the time delay between inputs and action on some of the systems.
My Marlin based 3d printer takes ages to accept a feed override or pause instruction. (seems to finish the complete "look ahead", before it stops?)
Something that I would not be happy with. For a milling machine things quickly become expensive and messy when the machine is able to destroy itself.

Having received and assembled my new mill a couple of days ago, I have some fresh impressions on this topic.

I know most of you know all the background, but for those that don't (I didn't, until recently), I'll include it:

There are two parts to the Grbl ecosystem:  the firmware itself (and I'm including GrblHAL, and FluidNC in this), and the "G-Code sender" user interface.  They're connected by a USB-based serial port.

Choosing the first part should be easy:  go with one of the newer 32 bit firmwares, so you're not feature limited by the 8 bit code in original Grbl:  every time they add a feature, they also have to remove something, because they're completely out of code space.  But it's possible you won't have a choice, because you're using the controller that comes with your mill.  That's my situation.  My controller runs Grbl 1.1h, the latest 8 bit version.

For the "sender" UI side of things, there are many choices.  Of course, since I run linux exclusively, that cuts the number way down.  And so far, I've only found one that's a) pre-built and b) works for me, and that's UGS (Universal G-Code Sender) which seems to be the granddaddy of them all.  Happily, it's also reputed to be the most feature-complete, and the most complex as well.  (Hmmm.  Reminds me of LinuxCNC.  

So:  using it.  The included setup wizard (again, talking about UGS) is very nice, and very simple.  It should be, since there are only a handful of config variables.  I count 35 of them, and of course most come in threes, so that makes it just 10 or 15, though a few are bitmaps.  It takes just 4 or 5 simple tabs in the wizard to get through it all.

The rest of the UI is familiar -- a previewer, a g-code window, jogging controls, axis touch-off, etc.  Nothing I use every day in LinuxCNC seems to be missing.  The difference is that you won't find words like "G54 offset" anywhere, though the concept is present.  It's all less "technical".

The distance between the UI and the machine does become visible when things go wrong.  Hit almost any error (limit switch, for example) and the controller gives up, and needs to be reset, which involves rehoming.  Which I'm sure is safest.  But it's pretty different then LinuxCNC which is pretty hard to lock up.

I've only done one carving so far -- a simple v-carved text engraving created by F-Engrave, which I've used before.  Worked fine, as you'd expect, with one glitch:  grbl doesn't support all G-Codes, and F-Engrave included a G64 in the preamble.  I suspect I'll trip over others soon.

It's likely that someday I'll be converting to LinuxCNC, just because it's more flexible, and the technical support is outstanding.  (Truly -- thank you all.) But that's a biggish project, with a lot of rewiring, so I'm going to put it off for a while.

(BTW -- my new mill is an AnoleX 3060 Evo Ultra -- it's a fixed gantry design with a 12"x24" 8mm thick aluminum bed.  It's driven by three big (speaking very relatively) NEMA 17 motors, and the axes all have linear rails and ball screws.  It came with just a 1/8" collet 300W spindle, but since I already own the ubiquitous Makita 701 router, I've ordered the 65mm mount and will mostly use that.  I'll miss the quiet of the small spindle though.  :-/ )

paul
 

More things I learned today, about Grbl:

Say you start a jog, and realize you meant to go the other way, and select the other direction. In LinuxCNC, this Just Works. Using Grbl, first the errant jog has to finish, and only then the next queued jog is executed. Not terribly efficient.

If you try and start a jog that would take the axis too far, you get an error. To clear that error, you need to go to a different tab (I'm using UGS), clear it, then go back to the jogging tab. It may be that there's a way to have both displayed all the time, but even then, having to specifically clear an error from a jog that never happened, seems... difficult.

I'd only started using it recently in LinuxCNC, but I found out today that neither Grbl (not surprising) nor FluidNC (surprising) supports the R parameter to G10 L2/L20. R lets you specify rotation, which can be very handy in cases where it's easier to get your hold-down clamps set securely if you rotate the stock.

pgf wrote:

More things I learned today, about Grbl:

Say you start a jog, and realize you meant to go the other way, and select the other direction. In LinuxCNC, this Just Works. Using Grbl, first the errant jog has to finish, and only then the next queued jog is executed. Not terribly efficient.
 

Not only "not terribly efficient", but can become very ugly. It all depends on the situation or machine. Those jog functions for a heavy machine are outright dangerous. Imagine it beeing set to a 10 mm jog distance. Push the wrong direction and off it goes into whatever is in the way.
If you are lucky it goes (pling) and the tip of the 3d probe ( 40 moneys ) is the only victim.