What is TinyG – and why?

A V3 TinyG board in an laser cut plexiglass enclosure.TinyG is a many-axis motion control system. TinyG components execute G code directly without the need for a general-purpose microcomputer. TinyG is meant to be a complete embedded solution for small motor control. The design goals are to build a board that can handle most motors up thru NEMA23 and be networked for multi-axis motion control well beyond just 3 or 4 axes. Technical details can be found here. In this post I’d like to discuss the goals in a little more detail and lay out some of the design choices that support the goals.

In short – TinyG should be a cheap, reliable way to drive DIY CNC projects of various kinds:

  • “classic” CNC robots like milling machines, 3D printers, and other systems that typically require 3 or 4 motors
  • multi-motor robotic CNC like 6 axis arms and other complex constructions that can take dozens of motors
  • motion control projects that take dozens to hundreds of coordinated motors – for example:
    • a CNC marimba (ok, so you could use solenoids)
    • a multi-machine automated production line
    • a moving head conference room simulation

The biggest challenges are:

  • cost
  • control
  • scalability

COST: All-in cost for a controlled stepper axis (control CPU + software + stepper driver) is optimistically about $25 per axis for a low-end 3 axis solution – e.g. three Allegro A4983 boards, an Arduino (AdafruitMakershed), and grbl for Gcode control. If you want better power handling and other features you can move to Makerbot electronics ($35 per axis + Arduino), or to commercial systems like the Geckodrive 540 four axis controller ($299 or $75 per axis + whatever you want to drive it with). As the price goes up so does the power handling, features, and reliability. So any solution that you could afford to deploy a with large number of motors had better be towards the low end of the range – and be prepared to ride the cost curve downward over time. (I suppose you could bit bang some MOSFETs or H bridges directly from a CPU, but you probably want circuit protection, perhaps microstepping, and I don’t know that the costs are significantly cheaper when you add it all up).

We chose the Atmel xmega processor and the TI DRV8811 stepper drivers as a good base to work from, figuring this provided a good balance between cost and capability. If a better CPU or driver chip becomes available we’ll probably use it. We ported Simen Svale Skogsrud’s grbl code to the xmega as an excellent way to do 3 axis CNC. It’s driven fro serial input, so parallel ports are not needed. The board accepts USB or direct TTL serial from an Arduino or similar.

CONTROL: By running the Gcode interpreter directly on the chip it avoids the expense and problems of trying to precisely control step timing with a general purpose computer that has other things on its mind (and non-deteministic interrupt latencies – “Index files now?”). PC based CNC controllers are happy if pulse jitter (uncertainty between pulses) is less than 20 microseconds. The less jitter the smoother the movement and the faster the motor can be run, particularly atTinyG close up image.high microstep values. The pulse timing is therefore the most heavily optimized code in the system. There is also a dedicated timer for each axis (no DDA required), so the timing accuracy is about 35 ns. (32 Mhz clock) – but this can degrade significantly to about 2 microseconds if the step interrupts collide (still pretty happy with the result). This means the board can maintain very high motion accuracy, very short arc segments, and so forth. By limiting the workload of each CPU to 4 axes it means at least that part of the motion control won’t degrade as things scale up. So doing 12 axes requires 3 boards, each with their own CPU.

SCALABILITY: Now that we’ve got a network of motion controllers, the next problem is, well, networking. Again, latency and jitter is the enemy. TinyG uses an RS485 network running at 500 Kbps and a fairly efficient packet protocol – in total supporting about 4000 packets per second with true broadcast. That’s about 250 microseconds per packet, so for some applications that’s OK, for others it won’t be. The simplest way we’ve come up with to control a network of controllers is to put the entire interpreter in each CPU, broadcast the command stream to the entire array, have each board build the full model, but only actuate the axes it actually has. This is similar to the way the big screens in Times Square work – each LED panel gets the full video signal but only displays the portion of the image it’s responsible for. In this environment the latency doesn’t really matter – as long as it’s consistent across the broadcast (so you can’t use a ring network, it must actually be a broadcast). If that doesn’t work (too slow, model too big for each unit, or some other barrier) we will need a time-triggered protocol like OSC or an OSC-lite.

STATUS: The units are running a fairly reliable Gcode system right now. We are working to fully test it and round out those features we think are necessary for DIY or manual Gcode operation – like a good stop/start/end control (harder than it sounds), zeroing and table homing, easy configuration, error trapping for hand-generated Gcode, and some other features. Focus on networking and making other interpreters comes next.

Alden

Comments

  • Great idea! Can’t wait to see what comes of this project.

    Kevin G.October 23, 2010
  • I would love to see something like this with OSC/lite support ! I have some other hardware based off Atmel’s ARM7 platform and find it speed and easy to interface with in various operating environments . KG

    Kevin G.October 23, 2010
  • Does your Tiny G interpreter support accelerations?

    MikeNovember 1, 2010
  • I am working on that now. I am integrating velocity splicing with constant jerk equations (cubic splines). I have the equations working in simulation and expect it should be this coded in the next few weeks.

    AldenNovember 1, 2010
  • I saw the videos, and it looks way cool. Congratulations for all the hard work come to fruition. When can I buy one? (TinyG controler). I know the answer to my next question, but when do you think you might create interresting patterns for the christmas balls to follow? I know you must have busted your butt just to get things working. Maybe next christmas you can provide an interesting ballet? Anyway I really take my hat off to you. Love the sound of the stepper motors.
    Regards, Hampton.

    Hampton SailerJanuary 5, 2011
  • I am testing Grbl with stepper driver board V2.3 of Reprap. Official release of Grbl doesn’t include Accel/Deaccel. Therefore it generates some stepper noise at proper load. Owing to Simen, I am testing new code now which updates Accel/Deaccel.
    By the way, do you sell the TinyG board ? Or how can I make the board ?
    So far I have been using Arduino Duemilinova.

    Paul JayFebruary 6, 2011
  • Not yet Paul, Hopefully soon however. This board is the hardest board I have assembled by hand. We have gotten pretty good at it.. However in no way will this be a “diy kit” its nearly impossible to troubleshoot problems.

    ril3y

    Ril3yFebruary 12, 2011
  • Please let me know whenever commercial TinyG is available.

    Paul JayFebruary 13, 2011
  • Am i blind or didnt you release the source code? All i can find is this hex file.
    I really would like to have the source code, i did my own fork of grbl to support xmega processor and some more functions last week but stopped working on is the moment i saw tinyg. It would be stupid if we do the same work twice.
    If you didnt release the source yet, could you please spend 3 minutes to setup a github/sf/whatever account and dump the current source there?

    Greeting
    Drk

    DrkJune 13, 2011
  • Yes, I absolutely need to do that. I’m on vacation this week and (of course) am doing a bunch of code. Part if that is getting the codebase out on our github. Give me a few days.

    AldenJune 25, 2011
  • When is the TinyG board available?
    I am anxious waiting for it.

    with many regards,

    Martin

    Martin PalmenJuly 1, 2011
  • Martin, after many, many months of code and test, TinyG is finally going into production this week! It will be on pre-order on the store soon, and shipping sometime mid-August. The code has been posted to github: https://github.com/synthetos/TinyG

    aldenJuly 18, 2011
  • September 23, 2011

    […] and computer-aided manufacturing software. Check out some details at http://cnccontroller.org/.A CNC controller accounts for the movement of a machine using CNC software. CNC software have progra…board. The electrical system from the CNC controller is attached to the software. The CNC controller […]

  • Great project! Is it out there yet? I’d really like some updates about it.

    Wish you lots of luck with it

    Motion controlSeptember 26, 2011
  • We’ve been shaking down the final production boards for the past few weeks and expect to be putting them on the site for sale this week. The current code base if on github as synthetos/tinyg. I’ll post to this thread when we do.

    AldenSeptember 26, 2011
  • November 2, 2011

    […] and computer-aided manufacturing software. Check out some details at http://cnccontroller.org/.A CNC controller accounts for the movement of a machine using CNC software. CNC software have progra…t board. The electrical system of the CNC controller is attached to the software. The CNC controller […]

  • Excellent! I look forward to hearing more

    Creative AutomationFebruary 27, 2012
  • Thanks for the comment. TinyG is currently in pre-release revision 0.92, with 0.93 being tested and due for release shortly. At this point it’s pretty complete for CNC operations. 0.93 adds homing operations, multiple coordinate systems, JSON operation and a number of other features. The 0.92 code base is available for review and download at github synthetos/tinyg.

    aldenFebruary 27, 2012
  • OK, I’m still confused… What is the difference between TinyG, and a grblShield + arduino?

    todd kreinFebruary 28, 2012
  • Good question. Grblshield is a 3 axis stepper hardware solution for grbl. The “package” is (1) Arduino hardware running (2) grbl + (3) grblshield. TinyG is a 4 axis integrated controller that has the hardware and software together on a single board. TinyG runs a somewhat more powerful microcontroller (Atmel xmega192A3 w/192K ROM / 16K RAM / 32 Mhz as opposed to Arduino’s 16 Mhz atmega328p w/32K ROM / 2K RAM / 16 Mhz). The TinyG code base is aimed at slightly higher performance and capability than grbl. We are active in both projects (obviously), and the support for features and Gcode is similar. Some similarities:
    – Support G0,G1,G2,G3,G10,G17,G18,G19,G20,G21,G53,G54-G59,G80,G90,G91,G92,G93,G94 and a similar set of M codes.
    – Both are written in open source C.
    Some differences:
    – grbl runs 3 axes (XYZ), TinyG runs 6 (XYZ and ABC rotary axes)
    – grbl controls 3 motors, TinyG controls 4 – map any 4 axes to motors or dual gantry axes, e.g. X,Y1,Y2,Z
    – grbl runs a constant acceleration planner (aka “trapezoid” or second-order), TinyG runs a constant jerk planner (aka S curve, or third-order).
    – Stepper pulse generation is slightly faster on TinyG, running 50 Khz max as opposed to 30 Khz
    – TinyG supports a text-based command line interface and a JSON interface (as of 0.93) – grbl just the text based.

    So basically you have a choice depending on your requirements.

    aldenFebruary 29, 2012
  • Ordered Tinyg 2~3 weeks ago, so looking forward to it until an email notification from paypal saying that the postage had been cancelled due to “Changed Mind”….I mean..WDF…

    FreddyMarch 2, 2012
  • This was an issue on our side with shipping. No worries.

    Ril3yMarch 12, 2012
  • Do you have any plan to implement gcode support for extruders? Like Reprap and other RP projects. The spindle PWM and dir pins could be used for extruder and heater control.

    JowanSeptember 25, 2012
  • Yes, but not directly. We are working on a modular control bus that will allow extruders, heated beds, rotating knives, specialized PWM (e.g. for laster utters) and a wide variety of other peripherals to be added to a baseline motion control system. The preliminary spec is on github under Open Controller Bus.
    https://github.com/synthetos/ocb

    We will be at the Open Hardware Summit this week and MakerFaire this weekend talking about it.

    aldenSeptember 25, 2012
  • I think that is a great way to handle it, allowing you to choose the head/tool module for job in hand.
    Also, just wanted to say, I ordered a board from the UK and it arrived in one week so thanks.
    (But do need V7 documentation please!)

    jowan512September 28, 2012
  • Yes! We are working on this. We got out ahead of ourselves a bit on this one! This should be up soon. If you have any questions in the mean time be sure to post them on the forums.

    ril3y

    RileyOctober 1, 2012
  • Can this controlled by configured to work with an X/Y axis where two motors move in unison to move on one axis and counter to each other to move the other axis? Specifically, a configuration as described here:

    http://corexy.com

    Wayne

    WayneNovember 4, 2012
  • Wayne,

    We have not tried a corexy setup. However, I think its just a matter of slaving to motors to 1 axis and then reversing the polarity one? I am not 100% on that and its a bit late here 🙂

    If you use the forums for questions, you will get a more prompt response.

    Riley

    RileyNovember 7, 2012
Comments Are Closed