I’m interested in a discussion on the benefits and drawbacks of using the GRBL Arduino controller or the TinyG controller in terms of performance and usability. @JohnLauer, I’m interested in hearing your opinion on this because one of my primary interests with getting an X Carve is PCB milling. I’m also interested in 3D carving, so probably Fusion360, and would like to hear what the community has to say about the GRBL shield and TinyG’s capability with this as well.
@NathanButler you are asking a hotly debated question, but it’s such an important one I figured I’d try to give a really well thought out response. Although, I full-well expect a lot of heat off this posting. Here goes anyway. You’ll have to navigate to a blog post I just put up because I needed to do a table layout and this forum doesn’t allow custom HTML.
-John
3 Likes
Oh interesting, it looks like for the price of an Arduino Due (~$18), an X-Carve user could swap from grbl to TinyG G2, since they both use the gshield. Thanks for that write-up, very informative!
Wow, thank you so much John, this is more than I could have hoped for. I’m curious though, you list the Arduino Due + G-Shield GTiny G2 controller as not being programmable through the Arduino IDE. Was this a type-o? And I’m assuming the TinyG G2 is compatible with your Chilipeppr TinyG workspace?
1 Like
Oh, it just means you have to program your Due via the command line using Bossac. Actually, the new version of ChiliPeppr is about to have it’s own Arduino programmer built-in so it’ll be even easier. The comment on the IDE simply means you can actually open the source code and then compile/upload.
Thanks @JohnLauer! The table layout is exactly what this comparison needed to make the options clear. 
Two questions:
-
Your table lists the G2 option (third column) as supporting 6 axis (XYZABC)… But isn’t it only a 3-axis solution as there are only three drivers on the gShield?
-
The “motor power setting from software” option is listed as only being available on the v9 board… Do you have any information on when that hardware might become available?
A fourth column in the table, with the v9 hardware/feature specs, would also be great information!
Thanks!
I have not actually seen anyone do it yet, but you would technically connect the 1st gShield like any Arduino shield, and then just connect a 2nd gShield off to the side with the wiring a bit different to ensure the step/dir pins for ABC off the Due connect correctly to the 2nd gShield. The key here is that the Due with the TinyG software has the sophistication to generate steps for 6 axes. I think the wiring is the fairly easy part even if it’s as crude as a breadboard for the 2nd shield. Or, perhaps you just want an A axis so you use a Pololu driver for that rather than an entire gShield. You’d have to look at the firmware on Github to see what pins map by default to ABC.
You can technically use the “motor power settings from software” if you create your own circuit board or breadboard. I’m guessing what Synthetos is doing is using the PWM outputs on the Due (because there’s 54 of them just sitting there waiting to use) and a low-pass filter to generate the equivalent of the variable voltage you’d get from a manual pot and that feeds in nicely to the Texas Instruments drivers to pick the amperage that the driver shoves over to the stepper motor. I don’t think you’ve seen this on other controllers because there weren’t enough outputs to have these be used for such a luxurious use case. Manual pots have never been that bad to deal with, although I will say controlling the amperage from software is pretty sexy.
As far as I know the v9 is out in the field today via embedded devices like the Othermachine Co’s Othermill and the Shopbot. Not sure if they’re going to sell those retail though.
1 Like
Here’s Alden Hart’s answer to you mimicking the low pass filters on the v9 board with your gShield so you can do “software control of motor power.”
Yes. Use the same technique we did on the v9 board. We have the Vref’s labeled on the Due pinout. The PWM from the Vref pin goes to the 2.7K resistor which conects to the 0.1 uF cap. The cap goes to ground and the junction f the 2 is the analog out to the TI chip’s A and B Vrefs (8825). The 8818 would work as well.
Trying to get a list together of what I need to order so I can get my X-Carve order in but been trying to figure out a few things. I am interested in going the TinyG G2 route. Will Easel communicate with the TinyG G2 or just the Grbl? With the way the G2 works I could always start out with an Uno and move to a Due.
A. I’m fairly certain Easel is GRBL only, and B. I agree, having a programmed Uno and Due would mean having the flexability to use either GRBL or TinyG. I was actually thinking of setting up a dual Uno/Due shield to allow me to switch between them at will.
@jlauer : Here’s a repost of my comment on your blog for the benefit of the people here. Disclaimer: I’m the lead developer of Grbl.
Your analysis is a bit misleading. There are a lot of things that you compare that are not that important or general philosophical differences between the two, Grbl and TinyG (rather than Grbl vs. two versions of TinyG).
First is the cost analysis. You really should be comparing the cost with Arduinos that support the Arduino project, rather than cheap and undependable Chinese knockoffs (which often don’t work).
Things like baud rate or comm speed don’t matter. 115200 communicates asynchronously at a rate of 30 characters per 2.5 milliseconds. This is faster than either TinyG or Grbl can physical go. The fact you have native USB in TinyG doesn’t really add much performance, if at all.
The speed of the controllers doesn’t matter either. Grbl can easily run a ShapeOko at 25,000 mm/min at 5000mm/sec^2, five times faster than current defaults, without breaking a sweat. Do machines need to run any faster than that? I don’t see what using a faster or 32-bit controller really provides you.
G-code buffer size also is misleading. Grbl plans up to 18 g-code MOTIONs in real-time. Line buffer size has no relevance to how fast something goes or how efficiently it is planned. TinyG’s overall planner is based on Grbl and has the same limitations as it does. If you do a side-side performance comparison between the two, like the total time to complete a job, I’m certain you’ll find that there isn’t much difference and likely Grbl is faster, since it doesn’t do the slower, but smoother, 3rd-order motion profiles.
The dual port comparison has no meaning at all either. Grbl accepts both sets of data, g-code strings and real-time commands, in a single serial port. It’s really simple and works asynchronously and in real-time. To say that TinyG is better that it needs two connections to operate correctly isn’t something that is arguably better. Both ways are lend to complexity for the same solution.
Push feedback, JSON, buffer wipe, g-code line tracking, and motor settings via software. This has no effect the end user or how they interact with either Grbl or TInyG This is nearly all GUI developer related (there are solutions to all these problems or they are trivial in practice) or are a one time setup with a motor driver board.
In fact, most of the analysis here has no bearing on the actual comparison of the two, which is.
- Grbl is designed specifically to run on an Arduino Uno so that it is available to anyone that wants to get into CNCing. It’s 3-axis only and concentrates on clean, simple, and robust motion control, which should be the most important aspect of its job.
- TinyG, a Grbl derivative, is designed to take advantage of the extra processing power (XMega/ARM) to give you up to 6-axes, a 3rd-order motion planner, and all the extra bells and whistles.
In reality, users should just use what they find that works for them.
1 Like
Does TinyG support two Y axis limit switches? I read today that GRBL does not support dual Y axis limit switches.
Well, I think you typically wire the limit switches in series as normally closed, so that if any of them are opened, it triggers the alarm. It typically doesn’t matter which limit switch is triggered during operation, as the result is going to be the same (stop the presses!).
So basically any controller that supports limit switches can be set up with multiple switches per axis.
TinyG does support two limit switches for X Y and Z. One is a min switch. The other is a max switch. They are wired separately on the TinyG board.
Be sure to use shielded wires on all limit switches to avoid false trips and ruining mill jobs. Also make sure you ground the shielding on the controller end or it does you little good.
I don’t think anything I’ve stated in my blog post at ChiliPeppr: Grbl vs TinyG is misleading and I stand behind all of it. I wrote a very well thought out post with just facts. Given the amount of time I’ve spent writing ChiliPeppr, I have possibly the most experience in the industry with what issues matter.
The cost analysis I did is real. The cost of boards has come down dramatically. The cost of powerful chips has come down. We all need to move forward to more powerful processors and not be stuck in a world of the Atmel 328p.
Baud rate does matter. You aren’t taking into account that a modern controller, like TinyG, sends back about 10 times more data than is sent into it. That data is amazing to get when programming a good UI like ChiliPeppr. 115,200 isn’t enough bandwidth to handle it.
Native USB matters. Dealing with the serial port buffers was the hardest part of coding the Serial Port JSON Server. You have to make sure you don’t overflow the buffer heading into the CNC controller. That’s surmountable, but what many people don’t realize is you also have to deal with the reverse path as well. If the app has any slowdown like from garbage collection (which is a huge problem in Java), it could miss the data coming back as it falls off the buffers. Native USB has massive buffers compared to raw serial. It’s a game changer for reliability and never losing data.
The speed of the controller does matter. You are basing your math on just generating steps. A modern CNC controller will now spend more time on providing data back to the user and other niceties and thus the speed matters to do all of this heavy lifting while also planning, replanning, and generating steps. Grbl doesn’t do much to send data back, thus you’ve never run into this problem.
Push feedback matters. A modern controller, like TinyG, sends coordinate updates over on an interval, but also exactly at the end of Gcode moves. Only the controller knows when the end of a move occurs, so only it can push the data when relevant. On Grbl you have to query on an interval which results in always having laggy coordinate data. Other push feedback like when the user goes from G54 to G55 is great to have push feedback on so the UI can update itself across multiple devices. The list goes on with how nice it is to have the controller sending push feedback on every state change.
Buffer wipe matters. Jogging is a big deal to the human operator and a buffer wipe command becomes key to enjoyable jogging. Buffer wipe allows folks to change their mind. This makes for a very enjoyable experience.
Gcode link tracking matters. If you ever need to restart or save your job where it messed up, the only way to do it is to know exactly what your last line was.
I’m open to constructive criticism to my blog post, but I don’t think anything I’ve stated is misleading. Rather I think it’s all very well thought out and intelligent conclusions on the state of CNC controllers out there.
5 Likes
John, you’ve definitely got a lot of experience in the industry, but it’s not fair to claim having the most. There are a host of other developers out there, like Will Winder, Andrew Hodel, and all of the Marlin-based GUIs (which are all based on Grbl’s “limited” serial port throughput). Most of which have been dealing with Grbl streaming for years longer. In addition, because I’ve been the lead/sole developer for Grbl over the last 4-5 years, I’d like to think that I have a fairly intimate knowledge of the exact workings of how a CNC machine controller works. What it’s limitations are, what the performance critical requirements are, etc. It’s just as important to understand those details before settling on the conclusions in your blog.
Sure, if you are running TinyG and have a ton of data flowing back from it in realtime, you may need more throughput and even native USB, but most of that data is redundant and non-critical. If I recall, Chilipeppr for Grbl is running just fine with “less data”. In addition, Grbl and Marlin GUIs have gotten by fine so far with the “lowly” serial port. As an exercise, please try calculating the character rate you really need. I think you’ll find that 115200 baud is sufficient especially when data flows asynchronously over RX/TX serial. Even if you still feel that it’s not enough, Grbl works great at 250,000 baud (as does Marlin). Do you really need the flow rate of a fire hydrant for a simple faucet? Not really.
I would also argue that TinyG’s buffer control problems are due to its use XON/XOFF software flow control. (AFAIK it still uses this). I’ve written about the problems with software flow control on Grbl’s Wiki. If you don’t have a big enough buffer, you have communication failures. And it requires fine tuning. It’s not robust. Grbl’s and Marlin’s communication protocol doesn’t have this problem because it’s 100% deterministic.
The cost analysis may be real for a hobbyist who is pulling together there machine themselves, but OEMs generally will usually buy brand-name boards for several reasons. Mainly, they do to help support the community and to have support if something is wrong with the boards (Chinese manufacturers don’t do that).
The speed of the controller matters if you can’t generate steps fast enough and the system isn’t robust. So far, Grbl does a fine job of keep ing up on a lowly AVR, as does Marlin. TinyG requires more than an AVR because it does more complex math. Just for reference the original TinyG boards used an XMega, which is only twice as fast as an Arduino 328p AVR.
BUffer wipe is still dangerous and can corrupt a g-code program. There are other ways to deal with a buffer wipe problem. I’ve outlined a couple of techniques in the Grbl interface wiki. To say, there is only one solution to a problem is a little short-sighted.
G-code link tracking can be done by the GUI with Grbl by counting the responses. It’s not that difficult. IF you really need it, you can enable it as a compile-time option. For now, I’m reserving precious flash space for the last things I’d like to install into Grbl. Later, I can enable things like line number tracking (for you) and realtime velocity reporting, if space allows.
I still believe that your blog post is not a good analysis based on what’s actually important for an end-user. It’s more of a specification comparison, like how PCs are often compared to Macs, that is based on your experience purely as a GUI-developer and what you think is important for CNC and machining. Given the fact that Grbl works great in Chilipeppr nullifies most of your arguments.
Because I work with machinists in the machine shop down the hall and design aerospace parts from aluminum, titanium, composites, and steels daily for my research day job, I would like to think I have a really good insight on what’s truly required for making something.
2 Likes
I am very new and inexperienced, and do not have a current interest in doing this myself. But, would something like this (with a second board in tandem) : http://www.instructables.com/id/I2C-between-Arduinos/?ALLSTEPS work for someone trying to increase some capacity of their Uno in a cnc application ?
My apologies if the inquiry is a little inept or redundant, but seemed potentially relative to discussion and development.
I have since stumbled across this, which seems to indicate that two Uno’s can certainly be used… not that I understand very much beyond that.
One thing I can mention is that I first bought a TinyG, but decided to return it because it did not seem as accessible, outside of Chilipepper online, for my approach or level of knowledge, and possibly more difficult to set up as well.
I understand the idea of better performance being involved, but I was, and am, intentionally trying to get started as simply and unlimitedly as possible, and then go from there based on what I prefer or need beyond my initial set up.
I am pretty far from any expertise in cnc or many related parts of the operation. But, one thing I think I usually am fairly efficient at is recognizing where missing information is being left out, assumed, or incorrect and limiting accessibility for people without the background or somewhat arbitrary knowledge to begin to utilize something from a beginner’s point or position.
JohnLauer, thank you for the post, and also your work on Chilipeppr: amazing stuff. I’m a HW/SW guy by trade and typically have an aversion to “cloud based” solutions, but your work is awesome and prolific. I’m a convert.
SungeunJeon, thank you too, and from the sounds of it I routinely enjoy the fruits of your labors as well. I’m using a GRBL based solution on my Shapeoko2.
As a fellow developer and CNC tinkerer, I appreciate both your work. I don’t judge the correctness of your points by how long you’ve been doing any of this stuff, but on technical merit. The other stuff isn’t helpful.
Two important things I love about Chilipeppr: awesome features, and how well it is integrated with the motion controller - specifically the TinyG controller. Buffer wipe seems like a critical part of this. If the same level of control can be accomplished without that, then why isn’t it? There are a few other things like this. Chilipeppr really is amazing in a lot of ways. The proof is in the pudding - so to speak. Maybe SungeonJeon will help with a GRBL workspace for Chilipeppr that is as solid as the TinyG workspace?
I’m planning to put together another machine, and was initially thinking Gecko drives and Linux CNC. Finally gave Chilipeppr a try and decided to go TinyG2/Chilipeppr instead. Thanks again guys! Keep up the amazing work.