There was a question asked over at the Inventables forum on Grbl vs TinyG. The answer is fairly complicated, so I decided to put together a matrix based on my take on the debate and to help folks understand the differences. Keep in mind, this is the way I see it, not necessarily every aspect under the sun for this debate. This blog post will likely get debated and that's ok, so keep in mind this is my view of it.
One thing to note is that there are now two TinyG's on the market with the G2 being quite price competitive with Grbl especially with respect to TinyG G2's powerful processor. Effort has been made to try to only focus on features that are different across Grbl and TinyG, rather than show all of the features where the controllers are equal, i.e. support for work coordinates.
Feedback is welcome here.
This is largely a comparison of these 3 codebases and the processors they're capable of running on. There have been some ARM ports of Grbl, however none of these are in market as a purchaseable product.| Grbl | TinyG | TinyG G2 | |
Arduino Uno + Gshield  |
TinyG v8 Board |
Arduino Due + Gshield |
|
| Price (Real World) |
$60 Uno $10 + Gshield $50 |
$130 | $68 Due $18 + Gshield $50 |
| Buy It | Banggood.com + Synthetos | Synthetos | Banggood.com + Synthetos |
| Processor This matters for the sake of the overall capabilities of the controller |
Atmel ATmega328 | Atmel ATxmega192A3 | Atmel ATSAM3X8E |
| CPU This matters for the controller having the oomph to do fast/complex motion planning. |
8-bit AVR | 8-bit AVR | 32-bit ARM |
| Clock Speed This matters for the controller being able to generate enough steps for smooth motion as well as handle other processes at the same time. |
16 MHz | 32 MHz | 84 MHz |
| Baud This matters for the controller being able to take in Gcode fast to keep the planner buffer full when doing long/large/complex Gcode jobs like v-carving, 3D printing, laser toggling, etc. |
115,200 (0.1 Mbps) |
115,200 (0.1 Mbps) |
USB 2.0 Native (5 Mbps) |
| Flash Memory This matters for the controller having enough room to contain the code for all the fancy features the controller handles. If there is a smaller base of Flash memory, you have to limit features in the controller. |
32KB | 192KB | 512KB |
| SRAM This matters for having enough RAM to hold the buffers for the incoming Gcode and the planner buffer for motion. |
2KB | 16KB | 96KB |
| Motion TinyG's human-like motion planning and execution is considered one of the major differentiators to Grbl. |
AMASS algorithm | 3rd Order | 5th Order |
| Axes Supported How many axes the controller can handle in parallel. |
3 XYZ |
4 XYZA |
6 XYZABC |
| Map Multiple Motors to Axis If you are running a dual axis machine, for example, you can map two outputs to the same axis. |
No Could be done via circuit board |
Yes | Yes |
| Gcode Buffer Size Bigger is better. The more Gcode in the buffer, the more the controller can suck lines in faster for motion and planning. |
128 bytes This is size of serial buffer |
256 bytes This is size of serial buffer |
~20,000 bytes This is size of native USB buffer on-board and OS-side |
| Dual Port (Control/Data) When you get into higher IO speeds like native USB, you need a way to send real-time control to your CNC while still sending data in parallel so having your CNC expose 2 serial ports provides this method. |
No | No | Yes |
| Room for Growth We're always looking for the best features, so does the CNC controller have room for growth of features? Meaning, is there Flash Memory or SRAM left to add enhancements? |
No ATmega328 memory, processor, IO is maxed out. |
Somewhat About 75% of memory, processor, IO has been used. More RAM is left, but no room for more motors. I/O bound at 115,200 baud for more features. |
Yes About 10% of memory, processor, IO has been used. |
| Push Feedback This is an important feature with respect to programming a UI. Having the controller data pushed to you when it is relevant to be pushed makes coding a UI much easier. Without push you need to query the controller over and over for the same question regardless of whether the data has changed. |
No Must redundantly query |
Yes You are pushed relevant data when needed |
Yes You are pushed relevant data when needed |
| JSON/XML Feedback When the controller sends feedback, it's important to be able to parse it easily. |
No Text (non-markup) |
Yes JSON |
Yes JSON |
| Buffer Wipe Allows you to send % (or other cmd) to controller to clear it's buffer after a feedhold. Important for jogging operations as well. |
No | Yes | Yes |
| Compile via Arduino IDE If you want to edit the firmware, being able to compile from the IDE is nice. |
Yes | No | No |
| Tool Length Offsets If you do probing, you could use a tool offset to set your zero. |
Yes | No | No |
| Motor Power Setting from Software On newer controllers you can set your amperage for your motors from software rather than turning hardware pots. |
No | No | Yes (On v9 board) |
| Gcode Line Executed Tracking If the controller reports exactly when it executes a line, on failed jobs you can know exactly which line to resume from. |
No | Yes | Yes |
| Real-Time Feedrate Report Have the controller convey what feedrate it's running at. |
No Can turn on at compile time, but since not default not much GUI support |
Yes | Yes |
