Join us on Wednesday, July 8 at noon Pacific for the Linux in the Machine Shop Hack Chat with Andy Pugh!
From the time that numeric control started making inroads into machine shops in the middle of the last century until relatively recently, the power of being able to control machine tools with something other than a skilled human hand was evident. Unfortunately, the equipment to do so was expensive, and so NC technology remained firmly in the big shops, where a decent return on investment could be realized.
Fast forward a few decades, and everything that makes the computerized version of NC possible is cheap and easily available. Servos, steppers, drivers, and motion control components can be plugged together into CNC machines that can move a tool to a fixed point in space with incredible accuracy and repeatability. But without CNC software, none of it means a thing.
Enter Linux CNC, the free and open-source CNC package. With support for realtime operation, one-step installations, and a huge range of capabilities provided by a team of volunteer developers and supported by an active community, Linux CNC has democratized the world of CNC machines.
Andy Pugh is a frequent contributor to the Linux CNC codebase and a moderator on the forum. He knows a thing or two about Linux CNC in particular and Linux in the machine shop in general. He’ll stop by the Hack Chat to share his experiences with the Linux CNC project, tell us how Linux can revolutionize the machine shop, and maybe share a few stories from the world of CAD, CAM, and using Linux to make a few chips.
Our Hack Chats are live community events in the Hackaday.io Hack Chat group messaging. This week we’ll be sitting down on Wednesday, July 8 at 12:00 PM Pacific time. If time zones have you down, we have a handy time zone converter.
Click that speech bubble to the right, and you’ll be taken directly to the Hack Chat group on Hackaday.io. You don’t have to wait until Wednesday; join whenever you want and you can see what the community is talking about.
Doing CNC on Linux is like snowboarding on a toilet seat. Sure you can but why? It makes sense to use hard realtime system like FreeDOS.
Linux has RTOS kernels; and from the look of the wiki page the defaults ISO’s for LinuxCNC come with one of the RTOS enabled kernels. Linux is all about modularity; swapping out kernels is an easy thing.
> … it is typically bundled as an ISO file with a modified version of 32-bit Ubuntu Linux which provides the required real-time kernel.
https://en.wikipedia.org/wiki/LinuxCNC
It also appears you run the programs on a standard kernel as well; which is useful for dry-runs and simulations on your desktop/laptop outside of the shop.
Color me misguided, but doesn’t LinuxCNC actually run the Linux kernel as a task under the actual hard real-time kernel.
I beleive the LinuxCNC runs itself as task with realtime priority under Linux kernel compiled with support for realtime applications (not sure if completely mainlined in kernel already or needs some minor patching)
It was (RTAI-kernel) but now it seems preempt-RT is the way to go.
“Doing CNC on Linux is like snowboarding on a toilet seat.”
Isn’t that how Dr. Brown came up with the idea of the Flux Capacitor?
Standing on the toilet seat, hanging a picture.
It just struck me that the German translation of the “Flux Capacitor” is not correct. The translation is “Fluxkompensator” which re-translates to flux compensator instead of capacitor.
And back to opic, I use dedicated real time hardware for all my machines as I have to talk to steppers/servos anyway in the end. I do not see the benefit of not using just a micro controller as this kind of hardware is really cheap today thanks to the 3D printing wave.
I mean, a simple smoothieboard clone is changing hands for 20€ (e.g. SKR 1.4).
It probably lip-syncs better for the dub.
Germans are weird.
You may have noticed they also put bicycles into their capacitors. Though small capacitors only get a tiny fraction of a bicycle.
“flux” is also “Fluss” in German, so flux capacitor should have been translated Flusskondensator, back in 1985.
How do I know? I translated Fluxkompensator back to english, and everybody laughed at me.
Thanks to web translators, I now understand [paulvdh]s joke.
In Deutsch, a bicycle is “fahrrad”
B^)
… and I’m sure they think the quirks of English are the gift that keeps on giving.
TurboCNC is still a viable CNC control option to use on DOS and I’d be willing to bet its considerably more performant than LinuxCNC given its lower overhead, RTkernel or not.
Speaking of overhead, I’ve noticed on the same exact hardware Windows XP+Mach3 will achieve noticeably less pulsetrain jitter than LinuxCNC running on the same machine, something like 20-40% less jitter.
This is using the parallel port of course rather than an external motion controller which I’m sure some will scoff at but in my experience the parallel port is more reliable than an external motion controller if the machine is setup correctly since the software processing the G-code has more direct access to the steppers/servos rather than having to go through another layer of abstraction that buffers it’s outputs and has its own firmware with its own potential problems.
I’ve found that even specialized LinuxCNC distros tend to load a bunch of unnecessary drivers, many of which end up causing timing jitter. So yeah, just having a realtime kernel does not solve all problems.
TurboCNC was a pretty great program, but it suffered from a bug where it would slow down or even pause on G02 or G03 arc moves, rendering it essentially unusable. I wished for years that it would be corrected but it never was. LinuxCNC on the other hand is very fast, smooth, and stable in my experience, though can have issues with certain hardware.
Isn’t HeROS(Heidenhain) some sort of linux?
I run Agie Charmillies HD 1200 die mills at work- all run in Heidenhain control- and when shutting down, an Xfce screen with a mouse pops up- it may very well be running in Linux on the backend.
Good enough for the lathe I use at work. Hell we even have a mill running on win98. (setting it up on the network with win10 was fun)
I have a CNC background and experience in electronics and as a Control Engineer. I have no experience with Linuxcnc. I find the trouble with it is that not only is the install process not consistent, but the various level of support is varied from expert to hackers. So the advice often given fails to address the needs of the beginner and the differences in hardware and PC bios as well as basic hardware differences. Linuxcnc has great potential, and if structured the right way could be very useful. If the distros were able to be installed like Mach 3 from the beginning as a learning curve it would be used by more people instead of Mach3 or some other alternative. Making it more simple from the start could make Linuxcnc a great machine control software alternative.
How do you know that the install process is not consistent if you have no experience with it?
The default clean install onto a dedicated PC should be pretty consistent, and identical to any other Debian installation.
Where the variation cones in is that it is also possible to install it on other Operating Systems and on to pre-existing systems if that is what you want to do.
It’s like if Mach supported 3.11, NT and OS2/Warp as well as Windows7 (or whatever the default OS is)
There is also the problem that after 16 years of existence there is a lot of outdated information out there on the web, which might have been correct, partially correct or even wrong even when it was posted some years ago.
It was only last week that I found out that there is a LinuxCNC Facebook support group. I don’t know who is offering the advice on there.
Am looking at putting together a custom small CNC mill of high precision by end of year, and I’m a native linux user, so I know of LinuxCNC, but have never used it- and ironically my day job starts at the exact time this begins this week only, on an off shift.
I have to miss discussing how to learn linux use with CNC to go to day job running CNC. Irony.
Check out Marco Reps vids on YouTube, he has some great videos that show off some of the capabilities of Linux CNC.
Thanks for the tip!
The EMC2/LinuxCNC project has been around a long time, and people have used the LinuxRT kernel to drive several machines including orbital rockets. Just Download the CD image distro from the LinuxCNC site if you want it to work properly on a PC, as most people make the mistake in assuming it is just an application… it requires profiling the OS latency and setting your error tolerances in the config.
We published our mill/lathe attempt to connect ROS with LinuxCNC + NativeCAM, but on the Pi3 it was rather slow (anything above 4 axis seems unfeasible with an atmega/pi3). However, it was a good way for our group to get an introduction to the manual configuration process by setting up a mini stepper based Taig mill and CNC Sherline lathe.
There are now FPGA based LinuxCNC compatible PCI driver cards around with full sized servo retrofit kits. People eventually realize it is usually the practical long-term option for rebuilding a full sized mill.
The NativeCAM author should get some sort of award for his macro based rapid gcode tool-path generator. The default macro jobs usually cover 95% of our project needs around here, and it is a lot faster than waiting hours for some tool path generator to figure it out…
;-)
Hmm, do you have more details or code on how the connection between LinuxCNC and ROS worked? I’ve been thinking about something similar. I looked at the linked website (http://www.micrometer.xyz/) but couldn’t find a clear description.
People rarely update the public site since being stuck indoors… we all have other projects that took priority. ;-)
I will be the first to admit the linuxCNC documentation is not great, but basic profile templates were included to give people a chance to navigate an Arduino based ini file.
There are better documented solutions around these days, YMMV:
https://machinekoder.com/machinekit-ros-open-source-robots/
Oh, but that is the opposite way of what I want. Instead of combining low-level side of LinuxCNC/MK with high-level of ROS, I want to combine the low-level kinematics of ROS/Moveit with high-level g-code and GUI of LinuxCNC.
Ironically- it was going to be a Taig CNC mill with ballscrews and an upgraded ER25 spindle cartridge with secondary grind ABEC 9 bearings from Glock CNC.
Was looking at doing either Pokeys or CSMIO control board, and eventually upgrading to servomotors from encoder steppers, and VFD on a brushless spindle motor.
I know professional controls backwards and forwards- but my understanding of linux as my os is still kinda low, so learning more on how to use it for CNC control would be a learning curve I gotta tackle somehow.
Most of the stuff I do on my own is smallish high precision toolmaking, so that would be perfect for my needs. Vulcan mill would be better, but they are still building them and they look to be high teens when all is done- outta my current price range.
Our 3-axis open-loop Taig config is setup on the old pi3 OS image, and is based on the original long-bed model with steel slide (not the modern aluminum version). It was fine for the slow-feed and high-rpm 2mm carbide end-mills we needed for some projects. We just use drip-fed detergent free oil-lines on the metric lead-screws and spindle… I don’t see the advantage of ball-screws on little machines as sometimes we do messy work with brass. ;-)
NativeCAM makes the LinuxCNC specific gcode pretty easy to run even without a CAD/CAM background.
The author’s channel is here:
https://www.youtube.com/channel/UCjOe4VxKL86HyVrshTmiUBQ/videos
It was the only easy option we found to handle the CNC lathe process steps.
I’ve been using LinuxCNC for a long time on my Taig Mill with a parallel port interface to Xylotex drivers. I found getting the mill running on LinuxCNC to be pretty straightforward. Just install the prebuilt OS with LinuxCNC, run Stepconf to configure it , then let the chips fly. You can test it out by running it from the install media before doing an install.
The problems I’ve had are when I’ve tried to do something more like get NativeCAM running. The latest LinuxCNC build uses Linux Wheezy and the long term support for it ended in 2018. When I tried to install NativeCAM it required other packages that I could not figure out how to install. I did get it partially running, but not to the point where it was useful.
So just getting LinuxCNC to control the Taig doesn’t require much Linux experience, but added some customizations might.
We are also running NativeCAM on the old wheezy image… as it was the last RT kernel branch that seemed stable ;-)
Backup your install, then try this snippet:
sudo apt-get install python-lxml
mkdir ~/SRC
cd ~/SRC
git clone https://github.com/FernV/NativeCAM.git –depth 1
cd ~/SRC
git clone git://timeguy.com/truetype-tracer.git –depth 1
cd truetype-tracer
dpkg-buildpackage -b -uc
sudo dpkg -i ../truetype-tracer_*_armhf.deb
cd /home/pi/SRC/NativeCAM
dpkg-buildpackage -b -uc
sudo dpkg -i ../nativecam_*_all.deb
cd
ncam -i/home/pi/linuxcnc/configs/taig-mill/taig-mill.ini -c’mill’ -t
#We had to remove ‘-c gladevcp’ in taig-mill.ini
# and verify the toolbox install flag was setup right..
# -U –catalog=mill
# ncam/my-stuff:ncam/lib/mill:ncam/lib/utilities
Thanks all of you for the input. My understanding of professional windows CAD/CAM software and coding directly at the machine in EIA is very high, and I do use linux as my OS on laptop, but still a relative beginner in that.
Wish there was a forum of linux using CNC people so I could learn what I really need to know to get everything at serious results level.
I’m going to do ballscrews and a modified headstock because the machine properly adjusted should be able to hold 0.0002″ tolerance at bleeding edge with setup I mentioned, as Taig is going to start using more accurate ballscrews from next batch soon… Been using the manual extended bed for over 13 years, so very familiar with it.
My work is horological and toolmaking in nature, so I need very high accuracy and repeatability. I’m not sure if LinuxCNC supports servomotors or just steppers, and how well it plays with external controler boards like PoKeys and CSMIO.
No one currently makes them, but I have custom shielded bellows on mine so chips won’t matter at all. Thinking of making them and selling.
Joel, thanks, I tried it, but I couldn’t get it to work. “sudo apt-get install python-lxml” was unable to install python-lmxl. I think it’s because Wheezy is too old and all the packages are gone.
I tried to use “pip install lxml”, but pip is missing too. I continued down that path, but eventually gave up.
Several years ago I bought a few BeagleBones Black, with the intention to use it with Machinekit on my home built CNC router.
I did not find it a satisfying experience, although I did get it to turn some motors.
The firmware for the PRU was weird. Instead of using one of them for step generation and the other for auxillary stuff, everything was run on one PRU, and it was very slow code so I could not get a high enough step rate to do more then 2 bit microstepping. It was usable, but not very optimal.
Then I had to control it from some external PC somehow, and I ran the interface over SSH. It also did work, but I had an abysmal framerate. Somewhere around 3 frames per second, which is still sort of acceptable for CNC. It is comparable with for example a Digital Multimeter.
I may have been able to build a better interface with “GladeVCP” (I think that’s what it’s called).
Then at some point I got curious and I burned GRBL into a blue pill and soldered some 74LS buffers to it to drive the optocouplers in the stepper motor drivers (Nema 23 motors 112mm long), and some other small components.
To feed G-Code to the machine I use bCNC.
It took some time getting used to, but I learned to quite like this combination. Both the C code in the Blue Pill, and bCNC are simple enough to make my own modifications if needed, while the total complexity of the BeagleBoneBlack with Machinekit is a bit over my head. bCNC is also steadily improving. The latest version runs on Python3 now. I also like the post processing capabilities of bCNC. In bCNC you can open a standard dxf (I think also svg and some other formats), and then add tool radius offsets, add depths for the thickness of materials, add tabs and more stuff.
I may switch to the Path workbench in FreeCAD some day. The last time I checked it seemed to be a bit experimental and not complete enough, but I do not use my CNC machine much.
In the mean time it looks like Machinekit has not gained enough momentum to become more then an experimental platform. If I ever wanted to build a more capable CNC machine I may examine the route of LinuxCNC again, but then I would not use the BeagleBone anymore, but would go for one of the Mesa FPGA cards for the step generation, combined with some small PC board that runs LinuxCNC itself.
Thanks for sharing this. It led me to find your post on the stm32duino forum from a while back and then down a further rabbit hole of reading for whenever I get some additional free time
freecad path is somewhat usable but you really have to be careful. I ran a job on it last night, and while all the X and Y locations were right, it partially inverted a bunch of the Z stuff because I’m not good at figuring out how to set up some of the process defaults. But the backplotter in path does help give you an idea of what you’re going to get. The adaptive milling strategy is quite impressive, and I think the planner does a better job of optimizing fast moves between cuts than either pycam or heekscam manages.
I really got interested in trying to use FreeCAD as a replacement for Fusion360 (because FOSS & actual ownership of my files) but haven’t seen much yet written about the supposed CAM end on it.
Haven’t gotten FreeCAD working yet, was gonna try setting it up in Mint 20 tomm.
I got used to having access to a legit station of Autodesk Inventor for over a decade, and exporting my designs, but lost access changing jobs- so tried Fusion360, but hate the lack of permanent file access.
FreeCAD seemed far along for 3d parametric drafting- but it was the fact that some CAM seemed built in too now. You’re the first I’ve seen comment on its use.
I currently use grbl on Arduino Uno, FreeCAD, and custom stepper drivers (step, dir). It works very well!
FreeCAD is nice once you figure out the minimal set of clicks to produce gcode.
I made a video tutorial because it is finicky.
For example, you can set it up so multiple holes can be edited via changing only one hole’s diameter.
-TheRainHarvester on YouTube
I’ve played around with FreeCAD a fair bit and will say like many open projects the documentation is often outdated or lacking clarity. But its actually quite good once you figure out its foibles. Though I do tend to use it more as a doodle pad to help figure out how to openscad my design parametrically and efficently.
Hopefully like many open projects as it gets more ‘finished’ the documentation can catch up and there will be better help guides.. For now though its good fun to play with and very functional once you get it working right.
The latest, 32 bit, versions of GRBL are quite capable and simple to set up. The grblHAL version (https://github.com/terjeio/grblHAL) runs on numerous ARM processors, even M7s at 600 MHz. Step rates can be as high as 160 kHz and lots of customization is easy. All open source. There are breakout boards available. I’ve looked at Linux CNC and it didn’t like it for a number of reasons – seems like the “anti-plug-n-play” approach and I want a tiny box doing all the motion control, not some PC.
I currently prefer GRBL (or grblHAL) setups… With bCNC sending g-code to it.
However i think we should write simple (non-gcode) motion controller based on FPGA and use PC to translate g-code to some bytecode before streaming it to FPGA. That would mean we would have robust and fast FPGA motion control, while we would also be able to easily implement new features (new g-code commands) on PC side using the primitives implemented in FPGA…
I’m curious as to weather a raspberry pi4 plus mesa 7C81 is a vaible solution to replace the aging desktop with parallel port that I’m currently running linuxCNC on. The ~$140 total solution seems like it could be quite neat.
I’d really rather not have to keep setting up the BIOS on my machine every time I want to run it since I leave it unpowered so long between use.
Before anyone asks, replacing the coin cell would be a waste of time since it would still be dead every other time I went to use it.
I can never tell whether the weather is nice.
Let Larry the Cucumber help you with that!
https://youtu.be/K0J-T2lr0Ms?list=PLUXKiZQjOK5KXLDmNEao4jzYgPpeGH9t-
Nice.
Don’t bother.
If you use it so little that you can’t even keep the coin cell charged just donate it to the nearest hackerspace. If you aren’t a member make it part of the deal that you still get to use it. Then when you want to mill something once every.. what is that 5, 10 years if your coin cell can’t last that long, just drive there and do so. Hopefully someone at the space will use it more often so they will be keeping the battery charged for you!
Heh. I’m a bit rural to have a hackerspace close enough to be convenient when I actually need to use it. I also plan to use it more in the future, and in my experience, the battery lasts about 2 years, and I use it about once a year. Having a couple kids has eaten up a lot of time time lately, but the oldest one is starting to get to the age where they might actually have a little interest.
But yeah, anyway, that’s beside the point and donating it is not going to happen.
I don’t mind spending a little money on a better solution.. if the rpi is going to be low enough jitter.
Hmm, hopefully you find more time soon.
I would think the Pi4 based system would be an improvement. But I have not tried it myself, and how much tinkering will be required to get everything just right is always an argument to not ‘upgrading’ if the current system still does everything you need well. Not like its hard work to tell the bios to shut and get back to work. What 3 button presses, I admit it would annoy me but not enough to spend money even on Pi’s (which anybody reading previous posts will realise I quite like).
This announcement of an upcoming Hack Chat certainly has generated a lot of comments prior to the actual chat!
(“Thank you, Mr. Obvious.”)
Ren?! Is that you?!?!
Wait right there. Do NOT push the History Eraser Button again. I’ll be right over!
You mean dis button???
Reading through the comments…
Wow!
Windows 98? Wheezy?
It’s like CNC machines live in a reality where steampunk is real!
Well you don’t expect Crimean war surplus Bridgeports to work well with 21st century stuff?
Yes, it is a bit embarassing that the RTAI version of LinuxCNC is stuck on 32-bit Wheezy. This is due to issues with RTAI on newer kernels. We are working on this but it is pretty deep level kernel hacking and hellish hard to debug.
(The symptom is a complete system lockup after a few hours of running, leaving a stack trace that, as far as I can tell, is lying. I would love to talk to anyone with experience of debugging this sort of issue)
However:
For PC hardware that runs adequately with preempt-rt There is a system installer for Stretch and packages are currently being built for Buster (as well as for Jessie, Stretch, Wheezy, Lucid and Precise)
I’m not a big fan of grbl personally since it runs on a 8bit cpu and has limits on the g code it supports (along with some glitches I’ve run into).
I’m going to be trying out a duet wifi board since they have TMC2660 stepper drivers with up to 256 microstepping. (also there might be support for measuring the torque)
Although I’d be interested in seeing what the comparisons would be like with linuxcnc / machinekit on a rpi4 or beaglebone
I’ve been doing a little research since my last post above about the rpi4… came across a few things, but possibly the most interesting has been a channel called samcoinc on youtube. Lots of playing with a pi4 plus a mesa ethernet board in LinuxCNC.
The upshot seems to be that it works fine, but there’s some tweaks that need to happen first. Odd things like the rpi’s clock updating from the internet seemed to cause some bad issues until he manually changed the method used. People suggested adding an RTC would actually be the best solution there.
Another thing he did was change the rpi’s OpenGL driver.
Pi has always had slower gpio than Arduino. It also has to pause gpio operations to take care of system events. For cnc machines, Arduino/GRBL is better and cheaper isn’t it?
If not, what am I not considering? Are people running CAD/CAM in the workshop on the rPi so that is why they want to use pi?
Oh regarding, glitches on grbl, I ran into one years ago, but even at that time, it turned out to be an old version I was using. Since upgrading a few years ago, I’ve never had a glitch and I run jobs with 3D engraving (ie plunge while moving xy), which really exercises all the combinations of moves and accelerations.
It’s true grbl doesn’t support some g codes, but I’ve always just clicked on the CAMs options to turn the unsupported gcodes onto other gcodes.
Using the Pi like a GRBL controller and generating step pulses with GPIO is apparently doable, up to about 10khz. Not really viable for anything except the most basic and slow or low precision machines.
However, there are FPGA motion controller cards (google mesa cnc) that communicate with the Pi over ethernet or SPI, and generate that stuff. Should in theory allow 10Mhz control frequencies.
Pi4 4Gb plus SPI mesa card looks to be about $150 total package. Much neater solution with much less to go wrong than a PC, but much more capable than a GRBL controller and would interface with a keyboard, mouse, and HDMI monitor.
Shonkey, samcoinc’s channel is liquid gold for both linuxcnc customization and polygonal boring using outputs of linux cnc spindle position. I think I remember his work being on HaD before. Subbed. Rainharvester, subbed you too- your vids are good explanations as well.
Grbl has a long running thread in the comments on github that they have to make too many concessions to keep it running on an Atmega328 and there is no room to add new features. The thread was started on 2016-12-15 and has 299 comments:
https://github.com/gnea/grbl/issues/67
STM32 is mentioned, but also STC variants and AtSAM and other uC’s.
It seems nobody is willing to make some “official” decision.
In the mean time, there are some 20+ forks of Grbl on github.
As I posted earlier, I started with a STM32 port on a Blue Pill (STM32F103C8T6).
Until now (most?) forks are relatively straight 1 to 1 copies, with minimal modifications to get it to work on that uC. The fork I use for example uses the hardware USB port of that processor. No wanky RS232 converters (which also have reliability issues with “arduiono’s” on 16MHz crystal)
Recently I found a fork from a French guy, who has extended Grbl on the Blue Pill to 6-axis, but I have not tried that yet. (But I do have a 4th axis).
In that long thread it has also been mentioned that such a port could make use of much more modern peripherals such as DMA, multiple ISR levels, hardware floating point coprocessor and other nice features.
I just took the Blue Pill because I had some lying around and was curious.
I have not done real performance checks, but the simple Blue Pill seems to have plenty of resources left for some growing potential, even though it does not have a coprocessor.
I currently use 4 bit microstepping and can push the (closed loop) stepper motors a few thousand RPM, but have very little torque at that speed, which is expected. The Blue Pill generates step pulses around 100kHz at those speeds though. And that is without the software optimizations mentioned earlier. This is plenty fast for stepper motors. More microstepping is not very usefull. It would neither get noise reduction, nor better resolution. Maybe it’s useful for BLDC or PMSM “servo motors” (Those are the same thing btw :)
Grbl was “just the first I tried”. I have not made comparisons with for example Tiny-G. There may also be other projects around.
Interesting about the rs232. Where is the problematic rs232? Between the usb chip and atmega?
I use an “official Arduino uno”. Should I have this rs232 problem? Mine just plugs into the usb port. ( I’ve never noticed.)
More about Grbl:
To keep myself up to date I just read the additions on github to that thread, starting from 2020-01-01. Several people are busy with the Teensy.
Also, terjeio is mentioned:
https://github.com/terjeio/grblHAL/
This version of Grbl apparently has (some?) support for:
MSP432
PSOC5LP
SAMD21
STM32F103
LPX17xx
ESP32
SAM3x8e
MSP430F5529
IMXRT1062
I quite like the support of different processors, have not checked how much complication that adds to the development cycle.
The Blue Pill I have running on 72MHz seems quite capable, still I think Grbl could benefit from a processor with a Math Coprocessor…
A list of missing features in Grbl compared to LinuxCNC is also posted:
1). Lack of spindle synchronization for lathe threading.
2). Only 3 axis, (There are forks with more axis now).
3). No backlash compensation
4). No cutter radius compensation.
5). No native canned cycle support.
LinuxCNC also has a big an complex extra functions, such as built in software PLC and alternate reverse kinematics for for example stewart platforms, but it has been years since I spend time in that direction.
You missed a few things about grblHAL. Add iMXRT 1062 (M7) to that list (Teensy 4.x). Up to 5 Axes are supported. Canned cycles are supported. Quite a few of the Linux CNC features are there as well.
No possibility for closed loop encoder feedback on any of the Grbl style systems last time I looked.
If you’re going to actually do real work, why would anyone not expect closed loop support? That’s kinda a no brainer in my book