TinyG Wiki · GitHub

7/25/2019 TinyG Wiki GitHub

1/4

Explor e Feat ur es Ent er pr is e Blog

Clone this wiki locally

Alden Hart edited this page on Aug 13, 2014 42 revis ions

>

The TinyG project is a mult i-axis motion control system. It is designed for CNC

applications and other applications that require highly precise motion control. TinyG is

meant to be a complete embedded solution for small/medium motor control. Here are

some of the main features of the v8 hardware.

Integrated motion control system with embedded microcontroller (Atmel

ATxmega192)

4 stepper motor drivers (TI DRV8818) integrated on a ~4 inch square board

Stepper drivers handle 2.5 amps per winding which will handle NEMA17 motors and

most NEMA23s

Accepts Gcode from USB port and interprets it locally on the board

6-axis control (XYZ + ABC rotary axes) maps to any 4 motors

Constant jerk acceleration planning (3rd order S curves) for smooth and fast motion

transitions

Very smooth step pulse generation using phase-optimized fractional-step DDA

running at 50 Khz with very low jitter

Microstepping up to 1/8 (optimized DDA makes this smoother than many 1/16

implementations)

TinyG implements a sub-set of the NIST RS274v3/ngc dialect of Gcode.

See Gcode Supportfor details.

We try to adhere as closely as possible to the NIST Gcode and LinuxCNC Gcode

specifications:

Kramer's NIST RS274NGCv3 Gcode Specification

LinuxCNC Gcode Specification

Feedhold and cycle start with full planning (pause and resume motion)

Homing cycle

Probing

Jogging support

Feedhold and resume (cycle start)

Various stepper motor power management modes

Real-time status reports for DRO style readouts

Independent, per-axis control of jerk, maximum seek and feed rate and other

parameters to enable fine tuning a wide variety of machine types

Axis/motor mapping to support dual gantry and other configurations (e.g. XYYZ,

Sign up Sign in

62 184 83 Watch Star Forksynthetos / TinyG

Clone in Desktop

Gcode Support

Additional CNC features

is TinyG synthetos/TinyG Wiki GitHub https://github.com/synthetos/TinyG/wiki/What

ng 4 3/1/2015 1


2/4


3/4

Both projects are currently widely deployed but are technically still in beta - with

production for both expected "any day now".

Some fundamental differences are:

grbl is an XYZ 3 axis controller (i.e. a cartesian robot). TinyG is a 6 axis controller

that runs XYZ and also ABC rotational axes. Many of the differences are attributable

to this fact. See the NIST specas to how rotary axes work.

TinyG has 4 motors, gShield has 3. It is possible (and common) for grbl to run dualgantry configs - like a dual Y by using 2 stepper drivers attached to the Y step and

dir lines. This can present some challenges in homing, but in general this works

pretty well. gShield only supports 3 axes, and the motors are tied to the X, Y and Z

axes. In TinyG the motors are configurable (mappable) to an axis. If you want 4 X

axes, map motors 1-4 to X and have a great day. Generally people map the 4th

motor to Y the or A axis.

TinyG runs 3rd order, constant jerk acceleration profiles, grbl runs 2nd order

constant acceleration profiles. What does this mean? In grbl the velocity profile

during acceleration and deceleration looks like a pure trapezoid in t ime. For example

the move starts at zero velocity, then velocity ramps in a straight line to the target

velocity, then decelerates in a straight l ine back to zero. In TinyG the velocity profileis an S curve that ramps to the target velocity during acceleration and in reverse

during the deceleration phase. The means that you can run to motors harder in

transition and hence operate at faster accelerations and decelerations. It also means

there are fewer machine resonances excited (that cause chatter and other problems)

as the jerk term is controlled. Jerk is a measure of the impact a machine is hit with

during a velocity change. See: TinyG driving an Ultimakerand driving a Shapeoko.

The machines are not fastened to the table and don't jump around because of the

jerk control.

TinyG has a lot more configuration parameters than grbl. This is both good and bad.

There are more axes on TinyG and all settings on TinyG are configurable on a per

axis or per motor basis. (In grbl one parameter used to apply to all axes (XYZ), but as

of 0.9 grbl has independent axis acceleration parameters).

TinyG also separates the motor configs from the axis configs to enable non-cartesian

machines. But this means more parameters as they are configured independently

and them mapped together. grbl treats them as the same object - which is fine given

its XYZ mission. TinyG does not have that luxury as it needs to support ABC axes

which need very different configurations that X Y and Z (to start with, they are in

degrees, not linear units...). Independent control also becomes an issue if the

dynamics of the Z axis are significantly different than X and Y, like on Shapeoko

where Z is a screw axis and X and Y are belts.

TinyG and grbl are both designed to be run "from the command line". Since there

are more configuration settings to worry about, TinyG offers a set of mnemonics for

configuration, machine state and configuration status inquiries.

TinyG offers real-time status reports (DRO-type output).

TinyG has a set of help screens available from the command prompt. grbl offers

some of these features but in general is more "silent". There are plans to add new

features to grbl in future releases.

In addition to command line operation, TinyG implements a JSON interface. This

gets pretty arcane, but is useful if you are writing a controller for TinyG. The JSON


ng 4 3/1/2015 1


4/4

interface is really a REST interface that treats the TinyG system as a collection of

resources (in the REST sense of that word). It's different from what people normally

think of as REST in that the transport is USB serial, not HTTP.

TinyG implements a set of embedded self tests to verify proper system operation and

assist in setup

Different embedded processors:

The processor chip for grbl is anAtmel ATmega328pthat runs on the Arduinohardware. Note that once you program grbl onto it it is no longer an "Arduino" as

you have taken over the chip and it it will not run Processing anymore (until you

re-flash it - then it's no longer grbl) The 328p runs at 16 Mhz, has 32K FLASH

memory (program memory) and 2K of RAM.

The processor chip on tinyg is anAtmel Xmega192A3that runs at 32 Mhz, has

192K FLASH and 16K RAM.

The difference in processors means that tinyg can do more computation and

have larger firmware and RAM usage. It also means that grbl is programmable

using a garden variety Atmel ISP programmer, and TinyG requires a

programmer that implements the newer PDI programming protocol - such as the

Atmel ISP MKII programmer (We are working on a boot loader). We also offer a

firmware upgrade service for the cost of postage back and forth, but really if you

are interested in keeping up with the project you should get a capable

programmer.

The processor difference also means that grbl generates step pulses at a rate of

30Khz, TinyG at 50Khz.

There are a number of other differences such as communications and various system

settings, but this really gets lost in the weeds.

Status API Training Shop Blog About 2015 GitHub, Inc. Terms Privacy Security Contact


ng 4 3/1/2015 1

TinyG Wiki · GitHub

Documents

Transcript of TinyG Wiki · GitHub