[Jandyman]

Hello. I'm considering a machine upgrade that would involve moving from UCCNC and a custom screenset (cncwoodworker.com) to a GRBL based system. I'd like to get off Windows, and I like the idea of moving the motion control to a dedicated processor. Plus it would be economical to buy a combined controller and stepper motor driver.

I'm looking for input on this project. A simple question is recommendations on controller hardware. A more complicated question is about the software to run on the PC (regardless of OS). I use many of the features of the UCCNC custom screenset and its macros, I wouldn't want to give any of that up. And I want to be able to flexibly view the tool paths while seeing the position of the actual tool. Plus being able to program my own macros and functions is a big plus (I'm a professional programmer). I've seen a few free packages that get real close, but I've so far come up just a teensy bit short. I might be able to overcome this because they are open source, but I don't want to waste a ton of time programming as opposed to building.

OK, that's enough to start a discussion. I'll know how to ask better questions once a discussion starts ....

[hfjbuis]

I recently build my mill using an MKS TinyBee board (ESP32) and FluidNC firmware. The TinyBee board has 6 (5 are usable) sockets for stepstick drivers and also connectors for external drivers. I use TMC2209 step stick drivers at half their max current. That is enough to run my 56 mm 1.2 Nm Nema23 steppers that power my 4 mm pitch ball screws.
FLuidNC is by far the most easy firmware I have ever used to configure a grbl (ESP32) board.
FluidNC can run a file from a SD card and the TinyBee board has an SD card slot but I prefer to run the Gcodes on my computer using UGS as Gcode sender. In UGS you can make your own macro's.

[Jandyman]

Have you written any macros for probing? That's the area I would probably want to work on. And is there a way to present a simple dialog box to gather input for a macro?

I'm quickly realizing the piece of software I'm interested in is actually called the "Gcode Sender". I'm looking the most complete and modern one available with easy programmability.

[joeavaerage]

Hi,
GRBL was written for 3D printers rather than CNC machines. Do you not think going from UCCNC to GRBL would going backwards?
I use Mach4 and have done for eight years and I would not consider GRBL...its just too basic.

Craig

[hfjbuis]

Have you written any macros for probing? That's the area I would probably want to work on. And is there a way to present a simple dialog box to gather input for a macro?

I have written macro's for probing that uses a dialog box. It moves to the (fixed) probe position, probes the tool length and move to the corner of the vice.
G90G53F1000Z0;G59G90X0Y0;G59G91G38.2 Z-100 F500P50.83;G0G90F500Z60;G54;G10L20P0Z-0.12;G90Z{prompt|OffsetZ};G10L20P0Z0;G90G53Z0;G90G 54X-4Y-4
G59G91G38.2 Z-100 F500P50.83 probing with a probe height of 50.83 mm
G90Z{prompt|OffsetZ}; prompting for the height of the parallels

USG is opensource so you could adjust it to fit your needs.

GRBL was written for 3D printers rather than CNC machines. Do you not think going from UCCNC to GRBL would going backwards?

Grbl was written a long time before 3D printers exists. It does not support 3D printers.
Marlin, a fork of Grbl, is written for 3D printers.
FluidNC is a fork of GrblESP32 that is a fork of Grbl. It is more than adequate for controlling a CNC machine.

I use Mach4 and have done for eight years and I would not consider GRBL...its just too basic

Than you use Mach4 as Gcode sender and have also connected a controller board. Mach3 and Mach4 both can use wizzards to do CNC stuff. I have read that UGS also has wizzards but I have never tried these.

[joeavaerage]

Hi,

Than you use Mach4 as Gcode sender and have also connected a controller board. Mach3 and Mach4 both can use wizzards to do CNC stuff

Mach4 is not really a Gcode sender. It interprets Gcode and plans the machine trajectory. The trajectory is communicated to the motion controller as a set of numeric waypoints 1 millisecond apart.
The motion controller board, and there are about six or eight different manufacturers of them, converts the numeric data into pulse streams which in turn excite the motor drivers.

Where I think Mach4 has the advantage is that many of the industry standard Gcodes are supported whereas GRBL supports a subset of them. Additionally Mach4 has a scripting language
which allows the user to program machine behaviour specific to their machine. It also has a PLC function, and does ladder logic (called PMC), has a MODBUS module and more.
Mach4 and Mach3 which preceded it have been developing for nearly twenty years, and so it stands to reason that mach has features which GRBL has not had the time to develop.

It seems that if you are prepared to write code you can cause GRBL to have all the functionality of Mach, or UCCNC or LinuxCNC....but why?

Craig

[hfjbuis]

Hi,
It seems that if you are prepared to write code you can cause GRBL to have all the functionality of Mach, or UCCNC or LinuxCNC....but why?
Craig

Why, because for hobby use, a mach3/4 board and license can be quit expensive, especially if you want to use a "modern" PC running a modern Windows version.

Mach, Linux, CSlab, Eding, etc are all capable systems and absolutely suitable for professional use. Nevertheless, I run Grbl-L, Grbl-L-Mega for years on my lathes and recently FluidNC on my mill and I don't miss anything.
I also have a Mach3 license and board but it just doesn't fit my needs.

Huub

[joeavaerage]

Hi,
Yes, you certainly have to pay for Mach (3 or 4) and a motion controller like an ESS.

You can if you want pay big dollars for a PC, but you don't have to. My Mach4 machine is running on a dual core Atom single board PC, with no graphics card, 3G RAM and 64G SSD
running a 32 bit version of Windows 7. I've been using it for eight years and its fine. It would not 'pull the skin off a rice pudding' as the saying goes, but it works fine. The only time I notice
that it's such a low power PC is if I go to load a largish Gcode file, say 5M or bigger, it takes 30 or 40 seconds to load. Thereafter its fine, it's just the initial load which is slow.

I agree that Mach3 is nearly obsolete.

Either way, if you are of the opinion that Mach/motion controller/PC is too expensive then GRBL certainly has appeal.

Craig

[Jandyman]

This is all useful feedback. I kinda already stated my reasons for considering GRBL, but can add a few things.

First, I used Mach3 before and it left a lot to be desired. I had to use an ethernet based smooth stepper because of the lack of parallel ports. There were issues with that. And there were other things too, it was a long time ago so I don't remember it all. It really kinda pissed me off that I paid for Mach3 and then it was largely abandoned, no cheap upgrade path to Mach 4, nothing. Bad taste in my mouth.

So I went to UCCNC. I got a UC100 USB based interface to my Gecko box. It all works great. One vendor. I've also got decent support. A substantial upgrade. So why change from UCCNC?

1. Doesn't support both metric and imperial units. You have to set it up for one and not deviate.
2. Although the custom screenset is a huge upgrade, the preview window for the toolpaths isn't great. The zooming and panning is such that it is really hard to zoom in on a detail you want to double check before a cut.
3. Windows. I used to be a happy Windows user with Windows 7, but Windows 8 was the last straw and I moved to Mac and haven't looked back. And if I want to have a small dedicated PC for machine control, why wouldn't I just run Linux? No Windows licensing stuff, so many other things I don't have to worry about.
4. Cost. Not only do I not want to pay for Mach4 (see above), if I go with a GBRL system I can buy a fairly inexpensive combined motion controller and stepper motor driver, something like the Openbuilds Black Box, now they have a 32 bit version.
5. Decoupling the sender SW from the motion control frees up options for the sender sw. There are lots of options, most are free, and the open source option adds programmability (maybe, if I want to bother).
6. GRBL is probably good enough? See below, but I'm already stretching my budget get a really decent chassis. The reasons to upgrade my system at all are based on my machine not being stuff/accurate enough. I'm a woodworker building bass guitars and other random stuff.

So saying "it is kinda basic" is useless. Saying it doesn't support all the gcodes is more meaningful, but exactly which codes does GRBL not support that are likely to be a problem? That would be useful input.

Finally, what isn't said here is about the internal machine control specifics. I ran into problems with Mach 3 (now I'm starting to remember), when I finally got support on a problem with UCCNC, they pointed out some of the internal difficulties of the way the motion control and tolerances worked with Mach3. I don't recall the specifics. If there are difficulties with GRBL based systems in that the gcodes don't execute accurately or properly, THAT would be a giant problem.

If this reply generates any useful responses, it was worth writing.

[joeavaerage]

Hi,
as you say, useful input. I'm not saying anyone is right or wrong, just that we've have decided differently.

The problem is that I am only modestly familiar with GRBL, and there are many different flavours of GRBL....it seems each manufacturer has their own interpretation
of it. Many of the canned cycles (G73, G74, G76, G81-89) which are supported by regular CNC software are missing or truncated in GRBL.
Many would argue that it does not matter because you can generate all of those canned cycles from smaller atomic operations that GRBL does support.

You may recall the argument that was had some years ago when RISC computing became a thing. The pundits predicted that it would eliminate CISC. RISC has enjoyed
a lot of success.........but it has yet to make a dent in Intel and Intel like CISC computer chips.

If I am writing Gcode by hand then drilling cycles like G83 are required, in my opinion, I cannot be bothered writing a routine of atomic moves just to drill a hole. Again only personal opinion.
It must be said that I very seldom write Gcode by hand, its almost always generated by CAM, so even the prospect of having to expand a canned cycle becomes a non event.

As far as Windows go....I think that's a red herring, in that when I'm working at my machine I seldom if ever have to concern myself with Windows. Every once in a while I'll use Windows
file handling tools to archive past work, but that's about it, the rest of the time I'm using Mach4 and that's it. Certainly Windows is running in the background....but the key word is
'background', it does not interfere with the machining tasks I have in mind. Quite frankly a CNC machine should not be about a computer operating system......it should be about
safe, fast and reliable machine control. Windows PCs do a pretty fair job of that....and they don't come much cheaper than Windows PCs.

If there are difficulties with GRBL based systems in that the gcodes don't execute accurately or properly, THAT would be a giant problem.

Your right, that would be a giant problem, and I'm sure it would be known it it were the case. In the same manner that I can't tell you in huge detail about Mach4s trajectory planner nor can I tell you
about GRBLs trajectory planner. If either were faulty then we would know by now.

Craig

[hfjbuis]

Check the bugs list (issues) from the controller (firmware) you want to use to estimate the impact of know bugs on your work.
Not every controller is supported by every CAD/CAM system. You have to check your CAM system if the controller is supported.

Fusion360 supports Grbl.
I use FreeCad and Grbl is supported but the generated de burring tool path is not always flawlessly. If I don't select the whole edge (closed path) but just 1 segment, the de burring is some times on the wrong side. I noticed this problem in the Grbl post processor but I suspect the problem is in the library and all post processors are affected. It is not a big deal for me because I don't de burr just a part of an edge.

[Jandyman]

I use Fusion360, so no problem with CAM.

And I don't think the "canned cycles" are all that important to me, so no problem there either.

I will try to find the bugs list for candidate controllers. Thanks for that heads up

The only final comment would be on Windows. Yes, it's true that there are cheap Windows machines out there. I really haven't decided if I'm going to use a dedicated machine or share with other activities. If it is a dual purpose machine, I'll use MacOS, for zero friction with my other devices. If it is a dedicated machine, I just don't want to deal with the Windows purchase and/or activation and/or incessant updates and/or difficulty of just starting over with a fresh OS. So that's why I'd try Linux. I set I up once (or for a period of time). A that point it is a static setup, just a piece of equipment like any other, not a general purpose device. If at some point I need to update the OS, I can always start over. No license or activation. Drivers? Yes, maybe an issue, especially it is a laptop. But that has hardly been painless on Windows either in the past. A completely fresh install on a Windows laptop may be easier than in the past, but I have had painful experiences. If that's still an issue with Linux, then I'd consider buying a low end Mac mini and be done with the hassles. It would never go to waste regardless.

[joeavaerage]

Hi,

then I'd consider buying a low end Mac mini and be done with the hassles.

To my knowledge Mac does not have any CNC machine control software. If this is for a dedicated machine then Windows is all but transparent, and not really a drama. Just some el-cheapo ex lease
Windows box and your machine is set. It is never recommended to use a computer that controls a machine should do anything else BUT control that machine. The last thing you want is some
glitch in an unrelated piece of software/app/service cause you machine to go crazy and crash...too expensive and too damn dangerous.

Craig

[peteeng]

Hi JM - Have a look at Nighthawk and Commander by CNC3D. But its windows... but its grbl... does not need a computer to run files. Peter

https://www.cnc3d.com.au/nhc

https://www.cnc3d.com.au/commander

[routalot]

Have you downloaded LinuxCNC?It costs nothing and you can run it in live mode from a memory stick,so no changes to your machine.It would allow you to investigate the steps needed for setting up the machine and you could run a simulation with any of the desktops that are included.If you like it,great and if you don't like it you just pull out the memory stick and move on,having lost just a bit of time.

[jaguar36]

I've run GRBL for years using bCNC as the sender. I like it because the hardware was dirt cheap and does everything I need. I uses fusion for my CAM so I never have an issue with Gcode support. It seems like it would tick all of your boxes, and is open source if there is something minor missing it would be easy to add. Its got probing and macro support although I haven't used them a ton. It's cross platform as well. The only thing on your list is metric and imperial. I haven't had good luck getting it to play well with imperial units and finally just gave up and do everything in metric.

Regardless the hardware is dirt cheap (hell you probably already have a arduino or ESP lying around that you could run GRBL or one of its derivatives on), setup is pretty easy so you should be able to give it a try without committing to it.

[datac]

>>> Regardless the hardware is dirt cheap (hell you probably already have a arduino or ESP lying around that you could run GRBL or one of its derivatives on), setup is pretty easy so you should be able to give it a try without committing to it.

Because I run Flashcut on my personal machines, I tend to set up my hardware with a simple DB25 plug between the Control and the Drivers / I/O. SO it's been really easy to interface practically any control I want to try just by making a cable to go from the control and interface with the hardware via that DB25.

That said, I built my kid a nice machine. Set it up and dialed it in with Flashcut. But he has no money to buy controls with, so I put a teeny tiny android Nano in a small project box with a USB input plug on one side and a DB25 on the other with pin config to match the Flashcut pinout.

I gotta say, for practically FREE, grbl is pretty darn nifty. Smooth motion for 3 axis, enough I/O for homing, spindle and coolant. I guess you need an Arduino Mega for 4 axis and more I/O, but I never got to check that out.

The only hassles are picking one of the many "Front Ends" that are out there. Few excite me, but Candle comes the closest for traditional routing milling. My Kid does not run that though as he mostly uses the machine for a diode laser and for that its Lightburn. I've got that too on a laser I built and it works very well with a regular Arduino Uno.

I know one thing for sure..... I'll take grbl over Mach 3, any day for reliability.

[peteeng]

Hoi Datac - Look at Commander from cnc3D. Its free and will run grbl machines. Peter

CNC3D Home | CNC3D | CNC Routers & 3D Printers | Gold Coast | QLD | Australia

[joeavaerage]

Hi ,
given that all development on Mach3 ceased eight years ago I'm hardly surprised. Its obsolete and has been for a whaile.

Craig

[jaguar36]

Hoi Datac - Look at Commander from cnc3D. Its free and will run grbl machines. Peter

Commander is closed source and Windows only. Its also pretty far behind the other gcode senders for GRBL. No live position view, the 3D view's performance is terrible, and it only runs at a fixed resolution.

UGS and bCNC are my favorite gcode senders and both work on any platform.