TinyG motion planning vs Smoothie

So I’ve used a TinyG, and have read a lot about how smooth the motion planning is with its constant jerk acceleration etc.

As I understand it Smoothie is based off the GRBL implementation, so how does the motion planning compare? Can you do the same kind of cool demonstrations seen here on make recently?


(Can’t post links being a new user…)

My TinyG board recently died, so I’m considering getting a Smoothie compatible board like the Azteeg X5 or the Smoothieboard itself, just want to know if I’m going to lose accuracy on my CNC because of it.

Imported from wikidot

Hi !

I have never used TinyG, but I have looked at the code.

From what I can see, the code structure is very similar to GRBL.

Major advantages of TinyG I can see is that it supports 6 axis ( though I heard reports that’s not up to the task yet ), and does S-curve acceleration.
Somebody that knows it better could tell of more major features but that’s all I could find from a quick look at the code and the Wiki.

Smoothie has very good motion planning, I would expect no difference in the way the machine is run. And Smoothie having a faster MCU and more RAM, I would expect Smoothie to be able to look longer ahead ( and so being smarter about moves ).

TinyG is very barebones and does only one thing ( and apparently does it well ).
Smoothie is designed to do -many- things ( very well too, we have a big community building it ), and be very simple to configure, use, and extend.

To answer the question specifically about seeing a change in how your machine is run, I would be surprised if you saw a difference, but if you saw one ( it’s going to depend on the machine ) it’ll probably be Smoothie doing things better. So no, you won’t loose accuracy.

About the link : http://makezine.com/2013/09/23/why-your-machine-needs-a-tinyg/
We don’t have any cool demos like that :slight_smile: Though Smoothie is more than capable of executing all of them ( and more ).
We try to regroup some cool things we find here : http://smoothieware.org/gallery

Also, if that matters to you, Smoothie has the advantage of being Open Hardware :slight_smile:

Some things you’ll get with Smoothie you won’t with TinyG : 

  • Ethernet with web interface, telnet port for sending G-code
  • USB Mass storage ( exposing the SD Card ), USB Serial
  • Play files from the SD card
  • Configuration is very simple via a config file : https://github.com/arthurwolf/Smoothie/blob/edge/ConfigSamples/Smoothieboard/config accessible via the USB Mass storage.
  • Controls lasers, CNC mills, 3D printers ( also meaning people from those 3 fields work on the firmware, not just people coming from one type of machine )
  • 1/16 microstepping ( 1/8 for TinyG electronics, and can run up to 150khz, compared to 50 for TinyG )
  • More powerful 32bits microcontroller
  • Support for multiple arm solutions
  • Very modular firmware making it easy to add new features
  • Supports panel controllers
  • Much more :slight_smile:

I’m around if you have any question.

Cheers :slight_smile:

So on closer inspection and for future reference the Smoothieware and Smoothieboard has no s-curve motion planning like the TInyG at all, and is based on an older version of GRBL.

Hi Arthur, Ben,

I’m Rob Giseburt, one of the primary committers to the TinyG project.

I’d just like to point out a few inaccuracies (outdated information, some of it) in your statements above.

Most of our recent development effort is in the G2 project: github - dot - com/synthetos/g2/

G2 currently runs on the Arduino Due, along with prototypes that contains the ARM-based Atmel SAM3X8C sister-chip to that used on the Due. We don’t currently sell hardware for the G2, since it’s still in development, but it can be used freely with the Due and any stepper-motor drivers you wish. We sell the gShield that works nicely with the Due, if three axes and 1/8th stepping are enough for your project. Otherwise, you can use drivers with virtually any microstepping you can find, and it’s simple to configure the TinyG with the serial command-line interface or via JSON (if you’re wishing to write a UI or automate it).

With the Motate framework at the base of G2, it can be easily ported to many different platforms (including the Smoothie hardware, I suppose). After this next major release, we’ll be merging the Motate XMega layer into G2 so that both the ARM and XMega (current TinyG) versions compile from the same unified code base.

We have very strong support for CNC now, as that has been where our core market has been. I am testing the 3D printer support now (we really only needed to add heat controls), and will be adding better support for laser cutting/engraving in soon as well. I personally have a great deal of 3D printing experience, and we’re working closely with other contributors in the 3D printing world as well. We’re also talking with contributors about supporting the specific needs of laser cutters/engravers.

We don’t just do CNC. What we do is motion control, and we aim to do it very well. We’re now both planning and executing motion with quintic (5th order) motion-control profiles. Linear acceleration (what I believe Smoothieware is using now) would be 1st order, and “constant Jerk” (what we had in TinyG a year ago) would be quadratic or 3rd order. We’ve moved past that to 5th order in order to increase control and actually simplify the math. We’re only just beginning to explore what that additional control affords us.

You’re right that we don’t have support for ethernet or a TCP/IP stack. We consider the stepper-timing and precision to be the processor’s highest priority, and with single-board linux-based machines being so cheap and powerful, we decided to suggest offloading the networking and UI tasks to one of those, and to provide a clean and easily-automated interface over a USB virtual serial-port connection. An Intel Edison, Raspberry Pi, or Beagle Bone Black will do quite nicely. Of course, any desktop/laptop will work as well.

For a Web-based UI, there’s John Lauer’s excellent Chilipeppr. chilipeppr - dot - com/tinyg He uses our JSON communications (via a light weight WebSocket-to-serial-port proxy) to easily glue web tech to hardware control, and then he added a bunch of UI awesomesauce.

We don’t have SD card support in our mainline codebase yet, but there are at least two forks (that I’m aware of) provided by the community that have it, and we’ll be looking at consolidating and rolling that in soon.

I don’t wish to take anything away from the Smoothie project. I just wanted to clarify some of the details of your post. As open-source projects, I’d be happy to see more friendly collaboration and communication in this arena. We’re all putting blood, sweat, and tears into our projects, and sharing them openly with the world for a reason.


Hey !

Thanks for dropping by.

I was indeed comparing the “old” tinyG, not G2, to Smoothie, a year ago. I haven’t read G2’s code yet.
I was also comparing the Smoothieboard hardware your XMega board from the time.
And I did admit I’m not a TinyG specialist, I just looked at the hardware specs, and read most of the code.
Obviously you can run TinyG on more than one board, and with more than one type of driver, same with Smoothie.

About the code by the way, I found it much harder to read and understand than GRBL’s. It’s obviously in part because you are doing much more complex work there, and it also looks very optimized, but in GRBL there is a very obvious attempt at making it -extremely- readable ( which we try to emulate in Smoothie ), which I found to be lacking.

That’s been limiting how much of TinyG’s neatness we’ve been able to port into Smoothie.

For example recently Jim Morris has been implementing per-step acceleration and time-based acceleration math into Smoothie. It was a great opportunity to implement S-curve too, but we didn’t find TinyG’s code helpful enough there. Doing all that work from scratch instead of emulating what you do, is obviously much more work, so it’s been put aside for now.

We are also finding limitations with the GRBL concept of junction_deviation, and I’m pretty sure what you do is better there, so again it’d be great if it was easier to port things over.

Smoothie firmware is all about the modular stuff, being able to do many things with one firmware, and making it as easy as possible for people to contribute. Aside for that key thing, there is nothing in the code which I’m really attached to, so anything that’s better than what we have now, we want to come in.

I have not read G2 yet, I hope I’ll have time soon. I hope it’ll be easier to read, but if it’s not, my personal wish is you’d make it so. I’ve found that documentation, both of the code and of the usage, are really key to making this kind of project go forward.
There are some pretty awesome projects around ( my eyes turn to MachineKit/LinuxCNC ) that really suffer a lot from lacking documentation.

I think we make Open-Source code specifically so that people can use it to make awesomer things than what we originally did, and making it easy for code to cross-polinate across projects would in my opinion make for generally increased awesomess for everybody :slight_smile:

We code things in a different fashion, so I don’t think we’d port TinyG code directly to Smoothie, or that you’d do the opposite, but code is documentation, and well commented code makes it much easier to implement things in a different firmware.

That was my tiny rant, after reading the TinyG code, I had a strong wish that it’d be easier to understand :slight_smile: I know coding with understandability in mind is slower and is more work, and is often done at the expense of optimisation, so if you are not ready to do that, I’d also be glad to chat with you about your code, maybe you can help me understand it better ( maybe I’m just missing a few key things. GRBL was great at explaining key things ).

I don’t actually code Smoothie anymore, we have awesome people doing that much better than I did, now I’m mostly helping people get familiar with the codebase so that it’s easier for them to contribute. So if I understood what TinyG does better, I’d probably be able to help some people implement your ideas into Smoothie.

Cheers :slight_smile: