Replacing LinuxCNC with a Smoothieboard for CNC milling. Not as easy as for 3D printing!

I was running LinuxCNC for the last years and I wanted a smaller setup, with room for improvement. Since I had a Smoothieboard around, which is a very capable 32 bit ARM controller for 3D printers, I thought it would be a good idea to give it a try.

A bulky, obsolete but usual milling setup with a PC running LinuxCNC (a parallel-port is required),
versus a Pipo X8 which is interfaced to a Smoothieboard (hidden in the CNC driving box itself).

But the move is not a piece of cake when you expect a drop-in replacement. In fact, I must admit this board is somehow hostile as a firmware for milling in its current status (Smoothieware), even though the hardware is fully capable (Smoothieboard). In this post, I wanted to share my experience so far. Sure I could have asked for help (and yes, I did RTFM eventually). But it takes time, it will not solve the issues below and I think most people would have done like me: just try, then investigate.

With time, I think it may be sorted out, probably with help from others if they are welcomed (and hopefully without breaking more mill bits). But my expectation here was to benefit from Smoothie as much as one can benefit from it for 3D printers. Even though my current overall hardware setup is much convenient and lighter, the milling process ends up requiring more manual and careful operations than before. More annoyingly, I would end up having to tweak and modify an existing CAM tool just to handle the specific "milling behaviors" of this board. I would think that the reciprocal would benefit everybody though.

Smoothieware is a firmware that runs on Smoothieboards and a few other 32 bit ARM controllers, like the Azteeg X5 Mini or the Cohesion3D ReMix. It is modern and it is an easy upgrade for 3D printers that still run on outdated Marlin dead-ends. It is extremely easy to setup compared to the latter: for example, you simply change one value in a text file from your explorer to tell that your printer is a delta!

But the board and the firmware are also known for driving other types of CNC machines.

Why drop LinuxCNC in the first place?

LinuxCNC is a very capable piece of software for driving a milling machine, including very professional ones. Actually, it comes with a special Linux operating system, and as such, it is not just an application that you can install on your usual computer.

Moreover, the PC that runs LinuxCNC needs to have a parallel port. Yes. The kind of plug that no printer uses anymore anywhere.

Why? LinuxCNC handles everything, including the precise timing of the electric pulses for the stepper motors, that are precisely what the controller boards like RAMPS or Smoothieboards handle for 3D printers.

In fact, parallel port interfaces are the only "real time" ports that exist on regular PC, unless you buy expensive special hardware cards. If you try to drive stepper motors with other interfaces you will get timing issues, because they have some buffering and delays that introduce jitter in the signals (which in turns means shaking, vibrations, poor movement).

So my existing problem was I had to use an old, heavy and specific PC with a parallel port just for milling. All the laptops I could try did not have a proper "real-time ready" parallel port either.

A smoothieboard added within the stepper controller which came with my CNC.
It is plugged directly onto the various driving and probing signals, and it does
all the timings properly. This way I can get rid of the former, bulky, obsolete desktop PC.
BTW, I found a use for a CD-Rom case!

As shown above, a Smoothieboard is small enough to fit in the case of my existing stepper driver controller, so I thought it would be a very compact solution.

I also wanted some hardware options to hack around the CNC: sensors, automatic tool changers and so. In this respect, all the signals on the parallel port of the PC were already used, so I was in a dead end anyway.

Stand-alone vs. interfaced controller?

Smoothie web interface:
certainly not for milling!

Smoothie comes with an embedded webserver, so as to be able to work untethered. But it never was an option to me, even for 3D printing: it sounds like I would be trying to control a caterpillar with a primitive gamepad (and without a screen -- unless you buy a really expensive one). Working blindly may be enough for a 3D printer, where you often simply upload a g-code file and leave it alone (which is a very reliable practice at least).

So far, the LCD and rotary encoders that come with Marlin are just so efficient to fine tune and learn about the impact of tiny changes in the printing process.

But milling jobs are way more complex to handle. The user often needs to check, calibrate and prepare the work, set axes and references. And doing so require a real interface. In this regards, even touchscreens are barely usable in my opinion.

So I connected to the Smoothieboard via USB -- this is the blue cable in the first picture of this post, and I drive it from a full-featured CNC software.

Yes, even though I really do not like unreliable USB links and I always 3D-print via my printer LCD interfaces and an SD card. But I hate even more Ethernet cables across my house, which is the other, more reliable and recommended option. Huh.

Which software to prepare and to control milling jobs?

There are many well made software to run a milling machine. Actually, LinuxCNC would be a good one, or Mach3 on Windows. But they both want to handle the raw stepper signals also by themselves... hence the requirement for a parallel port. Huh. No way, we are in 2017!

Chilipeppr is a web application to drive the CNC milling machine.
It has an amazing list of features.

Chilipeppr is an impressive CAM tool which runs... in your web browser! It even includes a very nice g-code debugging toolset! There are a few drawbacks though: it cannot be installed offline as it downloads every component from the internet at each start (so it will fail when the network is down!). It also was made initially for TinyG and GRBL, though it says it supports Smoothieware. Now, frankly, I could not have it talk correctly with my board even when it is configured in GRBL compatibility mode (which I suspect it does not very well, see below).

Other web-based applications like cncjs or LaserWeb are promising and very active, but I was not able to install it on the little "Pipo X8" running Windows 10 which I bought for the interface, and that I naively thought I could upgrade it to Linux easily. I think it boiled down to the many inter-dependencies, tons of ugly node.js stuff and my incompatibility with Windows in the first place. My bad, but I do not want to run a malware-ready OS anyhow soon :)

Web-based CAM tools also rely on a small bridge for the link between the browser and the controlling board. It adds one too many software layer for me to feel safe: for reliable work, I like to reduce the stuff that gets in my (tool)path. But they are pretty, and LaserWeb was proven more than once to work very well with laser cutters and at high speed (with some initial issues with... Smoothieware!)

bCNC is a really nice piece of software to prepare, control
and feed g-code to a CNC mill, e.g. for PCB milling.
It even runs on a Raspberry Pi!

Eventually, I settled on a very nice CAM software named bCNC.

It is written in Python and it is small, well written, and very readable (read: hackable a lot!). The interface makes sense and it does not require megabytes of javascript and a huge browser to run either (as such, it will run fine on a Raspberry Pi for example).

It really has many and nice features, including options that are not always present like leveling, i.e. probing at multiple points to interpolate and compensate the surface to mill (many 3D printer controllers have this also).

bCNC is a really good choice, and even Smoothieware promote it. But let us see the issues now...

Unexpected issues with Smoothieware for milling

OK, the hardware is fine. And the software is installed and running.

Smoothieware configuration file has a promising "grbl_mode true" switch. To be honest, I am not completely sure what it does or does not. All the CAM "feeding" tools I tried (gcode senders) had specific issues with the board even with this mode. I read it was related to syntax and feedback information from the board to the controlling software, but it falls short in my opinion. Update: it might well better be called "CNC mode", as in the word of one of the author! This would explain that.

So here are the main issues I need to solve to get me running at least as well as before with LinuxCNC.

1a) Smoothieware has no "feed hold" M0 command? I cannot believe it!

This is a critical issue. It does not seem to support the very common and important M0 / feed hold gcode command (vs. e.g. GRBL). This is a programmed pause. It is just compulsory for manual operations, just like when you would switch filaments or need to clean the workspace or adjust something during the operation.

This is critical for changing tools though!

For example, in bCNC like many other, a tool change is a procedure that embeds multiple gcode statements, and which embeds a fundamental M0 for pausing, so as to let the user actually change the end mill manually before resuming.

Ignoring the pause will keep the existing tool and often ruin the job. On a 3D printer this may not be too dangerous, but on a mill it often break things. So, in this case, two separate blocks may be required and the second is sent only after the first one is "finished" (to be tested by the software). The second (i.e. resuming after the tool change) shall not be queued before the first one is done.

I hope it is a temporary point of view, but the firmware developers keep on telling that it is the job of the feeding application. In the case of bCNC, it means deep and specific changes due to the way blocks of gcode are often prepared as a whole, and then sent for the driver to process them... Do they really ask that each and every software adjust to this lack of command?

1b) Smoothieware has no user "pause"?

The board does not pause the movement either when you ask for it yourself during the milling job. It is probably harder to implement such unexpected pauses within the path planner component in Smoothieware, but we may not expect a fix anyhow early: "If you want to pause you should simply stop sending gcode to smoothie" -- er, what?!). 

In any case, all commands that were already sent will be processed before you have a chance to stop something (non-standard codes like M600 still empty the queued commands before acting). E.g. the spindle will keep on moving even though you know you are going to hit a clamp... unless you cancel the whole job with the emergency red button! No chance you can pause, move the clamp away and resume. The results are more broken end mills or parts.

Reciprocally, GRBL has a few explicit, certainly non-standard and weird commands like "!" (feed hold) and "~" (cycle start/resume). But these are welcomed addition, if not vital in some case. Version 1.1 even lets you pause in the middle of a movement, which is really great and saves a lot of time and mill bits. This really would be cool if it was enforced in Smoothie in GRBL compatibility mode as it is part of the expectations in my opinion.

2) The super sticky alarm state

This is a very annoying, possibly major issue but I am still unsure where the problem is. For example, it occurs when a probing ends before making contact, and in other unexpected cases. This is a good behavior... but the user should be able to resume work after he has fixed the problem!

In my case and so far, I found no other way than to reset the serial link, or even power-cycle the board (which most often ruins the current job).

I want to be clear on this issue: the issue may be with bCNC, but since I found no one complaining with other firmware, and since bCNC driving GRBL does NOT have the issue, I think smoothieware does something one way or another, because of some specificity. Even Control-X (i.e. reset asked from software) will not reset the board either, neither does $X or M999 (specific?). The communication is plain dead.

3) The communications hang during mesh leveling (wait states)

It took me some time to figure it out, but the job was hanging during mesh leveling (probing multiple points to compensate for a non-level surface to mill). I had to add some %wait statements in bCNC for it to work (GRBL does not seem to require this). I submitted this fix to bCNC since it should not impact other firmware, it does not change a lot of code, and it may help other people. Update: see below the comments from the main developer regarding G0 and this answer by the author of GRBL himself.

I know there is also a leveling procedure that comes bundled with the Smoothieware firmware, but I want to avoid investing in redundant knowledge, or board-specific behaviors or features. I also feel like I could contribute and be more productive for bCNC than for smoothieware: the mesh leveling in bCNC is certainly easier to modify and enrich in Python compared to modifying a C++ firmware to compile and upload on a constrained microcontroller! But board-specific changes in bCNC are anyhow to be avoided (e.g. to configure this embedded bed leveling specifically).

4) Rapid G0 moves are sometimes slow

Smoothieware G0 "rapid moves" are not necessarily rapid... they either rely on their own setting, or on some F speed that can be altered by other gcodes (may be other "linear (slow) moves" or probing). The common and ubiquitous interpretation is that G0 is fixed and shall use the maximum machine speeds. Sure, the g-code "norm" is a bit fuzzy, and furthermore when the 3D printing RepRap implementation introduced yet another variant to the NIST specifications. But as CNC milling is concerned though, there is a better-defined set of behaviors, and G0 is well known.

If you need details, the problem seems to be that G0 movement may be impacted by previous G1 g-code (update: it could have been only due to probing with G38.2, i.e. a bug that was fixed in between). It means/meant that jogging around may suddenly drop to 25mm/s because of a preliminary probing (which ought to be done very slowly). Since the possibly long jog move cannot be interrupted, be prepared to lose some time moving your spindle around like a turtle, unless you re-specify F for your G0 move.

So far, the feedrate value had to be set again in the interface of bCNC each time, but it is too easy to forget. Moreover, it is very annoying with bCNC mesh leveling, as the "rapid moves" become as slow as the probing moves (fixed with point 3 above).

Update: the main developer of Smoothieware harshly disagrees on the issue. He stands on his ground here and he states instead that GRBL and all others are wrong (but, imho, why then add a "GRBL compatibility mode"?). Put it short: in his opinion, all controlling software shall comply with their own interpretation.

All in all, most of it boils down to how g-code is normalized, and also that Smoothie originally is a 3D printer firmware. Note also that this specific issue with G0 might be "fixable" with the default_seek_rate in the configuration of Smoothie, and that there was a bug in probing (it used G0 in the background and corrupted its value -- something that makes no sense in the usual interpretation). Set the default seek rate to your maximum machine speed and you will probably get a more compatible mode (but better set it to the slowest axis as it can still overshoot the value when moving on multiple axes at the same time -- another weird "feature").

5) Spindle control

I was not able to control my spindle but I think I misconfigured something as many other could fix it (M3+speed then M5). Handling the spindle manually as I was recommended initially is a no-go: it is both annoying and risky (I broke some more end mills).

Is Smoothie actually ready for milling?

I certainly do not want to sound harsh: Smoothieware is a brilliant piece of software engineering, and it is open source, free to use. Anyone can contribute to it (or try to...). It really shines for 3D printing, and the documentation is outstanding. Many of you know I really liked and promoted it for 3D printing during the last years.

But I feel like some important fixes need to be done before it becomes as friendly for CNC milling.

I really did not expect these behaviors (or lack of), hence this post. If I had known beforehand, I would probably have used another board. Now, I cannot even simply wait and see because of the broken tool change procedure. But I feel like I switched too early in order to stay as productive at least as before.

...when a dirt cheap Arduino Nano and a DB25 work enough?

I ended up checking the lastest GRBL first hand, with the highly skilled job you can see below: wiring a Arduino Nano directly to a DB25, which plugs into the existing stepper controller...

Note: I need to give MachineKit a try, based on a BeagleBone Black and a Replicape shield (together they make a marvelous setup, and it brings a full-featured Linux to the deal).

Back to GRBL on a dump Arduino Nano... I must admit they work for 3 axes to the point I cannot tell the difference with Smoothie or LinuxCNC.

A quick and dirty hack with an Arduino Nano, which runs GRBL v1.1 (fully supported by bCNC).
When you already have the stepper drivers as here, a $5 setup like this works so well
that using a $100 Smoothieboard is kind of silly for a CNC.

This  $30 GRBL all-in-one 3 axis controller will drive
engravers and laser cutters. But you can get a much powerful
setup at the same price with three TB6560 3A drivers.

I did not expect it, because I remember two years ago the impressive improvement after I ditched an Arduino-based RAMPS which could barely move a CoreXY printer, and switched to a shiny $150 Smoothiebobard X5.

Admittedly, I did not check how good the signal is here with a scope (i.e. how large is the jitter?). But the sound is almost identical and speed and accelerations are identical... so it must be pretty OK.

Moreover, I eventually can hold the job immediately, even within a long move (a really cool feature that was introduced with GRBL 1.1).

Now, keep in mind that you still need the stepper drivers. They are included on the Smoothieboard (they are not really powerful though). But there are plenty to buy on the web for as low as $7 per axis. So if you add a $5 Arduino Nano, then you are done, and you will run a flawless firmware that is extremely well supported by most CAM.

Still... issues with GRBL on an Arduino!

When your need is only to drive a 3 axis CNC I would say: no drawbacks.

I highly suggest going with an Arduino and GRBL 1.1 until Smoothieware is "fixed" for CNC milling and engraving. Now, if you already bought a Smoothieboard, then keep it for a better use, like driving a 3D printer. It has it all, it was designed for 3D printing, so it brings all the needed extra electronics to drive the stepper motors and the heated elements alike. This extra is lost money for a CNC.

In my case, however, GRBL on an Arduino is still a temporary solution.

GRBL is slow? Take the worst case, which probably is laser engraving of rasterized hi-density images. With its large stream of "pixels", I would understand that an Arduino is really not a good idea. But still, I was told that the difference was not significant due to the highly optimized code in GRBL. Also, version 1.1 throws some very nice features in for laser engraving: what really counts is how much energy is absorbed by the target, hence the power needs to be lowered when the speed is reduced, e.g. because of the way sharp turns are planned due to inertia.

GRBL uses all the pins of an Arduino! Yes, actually I will end up in need for more GPIO pins than what is left on an Arduino, i.e. mostly none!

A short-term goal of mine is to add a XATCv04 tool changer (do go check it, there are tons of very smart ideas in this project!). But it only needs one pin and I could recycle one the unused "coolant enable" of GRBL as the author did.

However I would like to drive a fourth axis (2 more signals: step and direction), and I would like to add more switches. Less than for 3D printing world, it is still useful to home the spindle at some time in the process, and avoid hitting the limits (which naturally triggers a serious alarm, contrary to 3D printers). And this requires more pins than an Arduino Nano provides.

GRBL on other Platforms: lots of options!

There is an official port of GRBL to the Arduino Mega, and it has tons of additional GPIO pins.

But upgrading would then better also benefit from more memory, and more importantly a faster CPU (it is really pushed to its limits with GRBL). In this regard, there are already third-party ports of GRBL to the STM32F ARM32 family for example (the "blue pills" are even cheaper than a 8-bit Arduino, but they are much more powerful in every respect). There is also port to an uncommon but extremely interesting PSoC MCU that still I need to put to use after one or two years...

And eventually, there is even already a port of GRBL ... to the Smoothieboard! Yep.

Conclusion

Smoothieware (firmware) and the Smoothieboard (hardware) are straightforward for 3D printing.

Ditch your old RAMPS and throw one in your existing setup and you are up and running better in no time. As I always need to tell pros and cons, my only regret when 3D printing with a smoothie board is the lack of a full-featured, low cost, non-networked user interface (I always need to tweak stuff while printing directly on/from the printer -- a remote web interface is cumbersome IMHO, and possibly unreliable unless you go with a network cable, huh). The official screens are costly compared to that of the feeble but functional Marlin/RAMPS.

But as CNC milling is concerned, switching the boards is not enough. I naively thought that the "GRBL compatible" mode would make smoothieware behave like GRBL, but it does not.

When asking, it is quite annoying that the authors always start arguing that Smoothieware implement better behaviors than GRBL (and all the other paradigms). The offered GRBL compatibility mode is a good idea but it is misleading. Moreover, this mode should simply be not impacted by a counter-productive point of view in my opinion: it would help make Smoothieware more compatible with existing software (and get a bigger share of the market!).

When switched to the provided "GRBL compatibility" mode,
why should it willingly behave differently than GRBL?

Whether the possible interpretations are good or bad make no sense.

Nobody have complaints about the way Smoothieware does it for 3D printing. It handles g-code with no surprise, like most if not all other 3D printing firmwares.

But in its current state, people will keep on having weird and unsolved issues when they try to use Smoothieware for driving their CNC. Each and every critic hits either a defensive or even an aggressive response from the team behing Smoothie. As such I am skeptical that a pull request would be accepted, that would try to make Smoothieware more compatible with GRBL in GRBL compatibility mode, how sad.

What next?

I highly suspect that someone will end up forking a "rogue" version of Smoothieware just as to be able to implement these fixes himself and use his own non-cooperative CAM software suite. To be honest, I almost did, instead of trying to fix bCNC itself.

But forking is not a good idea, when we look at the state of Marlin and its gazillion versions in the 3D printing world. Still, the latter is so successful!

Smoothieware is an opensource project and the team really promote open source (and their products btw), which are both good! But I suddenly realize that being an opensource project does not necessarily mean that it is fully open for third-party improvements nor to constructive criticism (I hope I am constructive despite what they say).

To be honest, I already tried a couple of time to collaborate on very minor stuff, and either it was bluntly refused each time (e.g. make the whole project compatible with Eclipse IDE), or I raised an off-topic debate (as here, which eventually ended up in the public). As a developer, I would probably not spend time to try and contribute to Smoothieware. It would be easier in an alternate fork, or even another firmware (e.g. like I did for Marlin gcode core scheduling, or multi-line aliases, which were both accepted).

Since I need no more than 3 axis for the moment, I will keep on using GRBL and bCNC for a while, may be until Smoothieware runs my mill in a smooth, unsurprising way just as it does for my 3D printers. Or, for some people with no controlling hardware yet, I should note that the plain old GRBL was eventually ported to the smoothieboard. Weird at best, a bit saddening at worst :/