Friday, June 12, 2015

Grbl vs TinyG

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