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.
But the move was far from being a piece of cake. In fact I must admit this board is somehow hostile as a firmware for milling in its current status. In this post I wanted to share my experience so far.
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.
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.
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.
But milling jobs are way more complex to handle. The user often need to check, calibrate and prepare the work, set axes and references. And doing so require a real interface.
So I connect to the Smoothieboard via USB (the blue cable in the first picture of this post), and I drive it from a full-featured 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.
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 on each start (so it will fail when the network is down!). It also was made initally 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. 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.
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 realible work, you need to reduce the stuff that can get in your (tool)path in my opinion. But they are pretty, and LaserWeb was proven more than once to work very well with laser cutters.
Eventually, I settled on a 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...
Here is the pain now. Here are the main issues I need to solve to get me running at least as well as before with LinuxCNC.
The path planner component in Smoothieware may make it hard to fix, but the board simply does not want to pause the movement when you ask it (as I read, "If you want to pause you should simply stop sending gcode to smoothie" -- er, what?!!!). That is, it will keep on processing all buffered commands independently of the action to the "pause" button in the GUI. This often results in more broken end mills. Note that the explicit GRBL "!" (feed hold) and "~" (cycle start/resume) do not work better.
Actually I am not even sure what the "grbl_mode true" really does in smoothieware, since most "GRBL" ready CAM tools I tried had specific issues with Smoothieboards. And obviously, GRBL does pause via M0.
This lack of a reactive pause command is a huge pain for changing tools.
Right now, it looks like the firmware asks all the feeding applications to handle it the way it wants, e.g. by using M600 (which does not seem to be an option since it will still empty the queued commands). 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... For example, a tool change is one block of gcode, which embeds the fundamental M0 for the pause, so the user can actually change the end mill manually. Ignoring the pause will keep the existing tool and ruin the job. On a 3D printer this may not be too dangerous, but on a mill it often break things. In this case two separate blocks may be required, so that the second (after the tool change) is not queued before the first one is done.
I suspect it would be easier to "fix" smoothieware lack of M0 by messing with bCNC instead. But it may break it for other firmwares, and it will impact the readability of the software. For sure, implementing M0 correctly in Smoothiewrae would help it become a nicer CNC firmware in my opinion, but it may be harder to implement.
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 -- Chilipeppr is a huge win in this respect as it helps you figure out interactively where to restart the gcode!). The issue may be with bCNC, but since I found no one complaining with other firmware I think smoothieware does it its own way here again. In fact, even a Control-X (reset) fails to reset the board, neither will $X or M999 (specific?). The communication is plain dead.
I know there is also a leveling procedure within Smoothieware, but I want to avoid investing in redundant or firmware-specific behaviors or features. Moreover, I want to avoid reciprocal changes in bCNC (e.g. how to configure this embedded bed leveling?). I also feel like I can 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!
The problem here is that G0 movement will depend on whatever G1 g-code was send beforehand. I.e. jogging at only 25mm/s because a preliminary probing had set this speed is awfully slow (and movement cannot be interrupted, so if it is a long one, be prepared to lose some time). The value has to be overwritten in the interface 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).
Note also that the main developer of Smoothieware disagrees on the issue. I suspect it boils down to how badly g-code is normalized, and that the firmware originally comes from and for 3D printing. It may be "fixable" with the default_seek_rate in the configuration of Smoothie (just set it to your maximum machine speed to get some more compatibility -- but, well, better then chose the slowest axis!).
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.
And I need to say that it works to the point I cannot tell the difference with Smoothie.
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 is the signal 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 feature introduced with GRBL 1.1).
Now, keep in mind that you still need the stepper drivers. They are included on the Smoothieboards (though they are not really powerful). 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.
I highly suggest to go 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? No. It just does not run slowly. Due to the fast stream of pixels that laser rasterization requires, I would have understood that the Arduino is significantly slower than any bigger and faster microcontroller, But here also, I read that the difference was not significant due to the highly optimized code in GRBL. Moreover, 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 turn 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 an XATCv04 tool changer (do go check it, there are tons of very smart ideas in this project!). But it only need 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 I need to check one day.
And eventually, there is even already a port of GRBL ... to the Smoothieboard! Yep.
 |
| 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). |
Now, I think I will be able to sort it out one day, as some others (hopefully without breaking more stuff). But my expectation was to benefit from it as much as one can benefit from it for 3D printers. But even though my current hardware setup is much enjoyable, the milling process ends up requiring more manual and careful operations than before. I will probably end up having to tweak and modify an existing CAM tool just to handle the specific "features" of this board.
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. |
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.
 |
| Smoothie web interface: certainly not for milling! |
Stand-alone vs. interfaced controller?
Smoothie comes with an embedded webserver, so as to be able to work un-tethered. 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).But milling jobs are way more complex to handle. The user often need to check, calibrate and prepare the work, set axes and references. And doing so require a real interface.
So I connect to the Smoothieboard via USB (the blue cable in the first picture of this post), and I drive it from a full-featured 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 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 on each start (so it will fail when the network is down!). It also was made initally 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. 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.
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 realible work, you need to reduce the stuff that can get in your (tool)path in my opinion. But they are pretty, and LaserWeb was proven more than once to work very well with laser cutters.
 |
| 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 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.Here is the pain now. Here are the main issues I need to solve to get me running at least as well as before with LinuxCNC.
1) Smoothieware has no "feed hold"? 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 (i.e. pause). But this is just compulsory for changing tools manually!The path planner component in Smoothieware may make it hard to fix, but the board simply does not want to pause the movement when you ask it (as I read, "If you want to pause you should simply stop sending gcode to smoothie" -- er, what?!!!). That is, it will keep on processing all buffered commands independently of the action to the "pause" button in the GUI. This often results in more broken end mills. Note that the explicit GRBL "!" (feed hold) and "~" (cycle start/resume) do not work better.
Actually I am not even sure what the "grbl_mode true" really does in smoothieware, since most "GRBL" ready CAM tools I tried had specific issues with Smoothieboards. And obviously, GRBL does pause via M0.
This lack of a reactive pause command is a huge pain for changing tools.
Right now, it looks like the firmware asks all the feeding applications to handle it the way it wants, e.g. by using M600 (which does not seem to be an option since it will still empty the queued commands). 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... For example, a tool change is one block of gcode, which embeds the fundamental M0 for the pause, so the user can actually change the end mill manually. Ignoring the pause will keep the existing tool and ruin the job. On a 3D printer this may not be too dangerous, but on a mill it often break things. In this case two separate blocks may be required, so that the second (after the tool change) is not queued before the first one is done.
I suspect it would be easier to "fix" smoothieware lack of M0 by messing with bCNC instead. But it may break it for other firmwares, and it will impact the readability of the software. For sure, implementing M0 correctly in Smoothiewrae would help it become a nicer CNC firmware in my opinion, but it may be harder to implement.
2) The super sticky alarm state
This is a very annoying, possibly major issue. For example, it will occur 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 -- Chilipeppr is a huge win in this respect as it helps you figure out interactively where to restart the gcode!). The issue may be with bCNC, but since I found no one complaining with other firmware I think smoothieware does it its own way here again. In fact, even a Control-X (reset) fails to reset the board, neither will $X or M999 (specific?). The communication is plain dead.
3) The communications hangs 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 firmwares, it does not change a lot of code, and it may help other people.I know there is also a leveling procedure within Smoothieware, but I want to avoid investing in redundant or firmware-specific behaviors or features. Moreover, I want to avoid reciprocal changes in bCNC (e.g. how to configure this embedded bed leveling?). I also feel like I can 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!
4) Rapid G0 moves are not rapid!
Smoothieware G0 "rapid moves" are not necessarily rapid... they strangely inherit the last F speed that was in use by G1 "linear (slow) moves", instead of moving at (max) machine speeds. The g-code norm is quite fuzzy, but mostly because the 3D printers did not respect it enough originally. As CNC milling is concerned though, there is a better defined set of behaviors.The problem here is that G0 movement will depend on whatever G1 g-code was send beforehand. I.e. jogging at only 25mm/s because a preliminary probing had set this speed is awfully slow (and movement cannot be interrupted, so if it is a long one, be prepared to lose some time). The value has to be overwritten in the interface 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).
Note also that the main developer of Smoothieware disagrees on the issue. I suspect it boils down to how badly g-code is normalized, and that the firmware originally comes from and for 3D printing. It may be "fixable" with the default_seek_rate in the configuration of Smoothie (just set it to your maximum machine speed to get some more compatibility -- but, well, better then chose the slowest axis!).
5) Spindle control
This is a major issue but I should be able to sort it out (the spindle module seem to work, may be I misconfigured it) I really must find why I cannot control my spindle (M3+speed then M5). Handling the spindle manually is both annoying and risky: I broke some more end mills.Is Smoothie actually ready for milling?
I certainly do not want to sound too 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 works well for 3D printers, 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 well?
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...And I need to say that it works to the point I cannot tell the difference with Smoothie.
 |
| 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. |
Admittedly, I did not check how good is the signal 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 feature introduced with GRBL 1.1).
Now, keep in mind that you still need the stepper drivers. They are included on the Smoothieboards (though they are not really powerful). 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 to go 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.
GRBL is slow? No. It just does not run slowly. Due to the fast stream of pixels that laser rasterization requires, I would have understood that the Arduino is significantly slower than any bigger and faster microcontroller, But here also, I read that the difference was not significant due to the highly optimized code in GRBL. Moreover, 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 turn 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 an XATCv04 tool changer (do go check it, there are tons of very smart ideas in this project!). But it only need 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 I need to check one day.
And eventually, there is even already a port of GRBL ... to the Smoothieboard! Yep.