G-Code

## Overview

* **G0** is *rapid move*. It moves the machine to the given coordinates, with the expectation that no machining takes place during the move (tool not in contact with the stock). Unless the mode is changed by other G-code commands, the coordinates are absolute: G0 X10 moves to X=10, G0 X10 again does nothing because you're already at X=10. If coordinates for two or more axes are given, the machine moves in a straight line to the specified point. Starting from X=0, Y=0, the command G0 X10 Y10 moves diagonally to X=10, Y=10. Even if the axes have different maximum speeds and accelerations, the machine still moves them in a coordinated fashion, so that the move is linear. Only the axes specified move; the others do not change position.
* **G1** is *linear move*. It moves the machine to the given coordinates, with the expectation that the tool would be cutting. It's exactly like G0, except it has an extra parameter, F, that gives the feed rate (the speed at which to move). The speed is expressed in units per minute (mm per minute or inches per minute, depending on mode -- default mm/min). So, with the machine at X=0, Y=0, the command G1 X100 Y100 F200 moves it diagonally to X=100, Y=100, a distance of about 141 mm, at 200 mm/min, so it takes about 43 seconds to get there.
* **G2** and **G3** are *arc moves* (clockwise and counter-clockwise), and they're described very well here. I would use only the I J form and not even bother with the R form.[1]

X, Y, Z, I, J and K are coordinates. They're in inches, and it makes no sense to preserve precision beyond one micron. Three decimals are plenty, but if you want four, so be it, as long as your lines are less than 50/70 characters long (so as to comply w/ Grbl's line length limits).

G-code is relatively easy to read. It consists of commands (which start with G, and some with M) followed by parameters. G0 moves as fast as the machine can go and is called "traverse", G1 moves at the speed given by the F parameter and is called "feed", G2 and G3 draw arcs, clockwise and counterclockwise. The expectation is that milling occurs during G1, G2 and G3, but not G0, which is why there's no speed ("feed rate") control for G0. Of the parameters, X, Y and Z are the coordinates to move to (usually absolute, but there's a relative mode too), and, for arcs, I, J and K are the coordinates of the center (usually relative, and K is for modes that are rarely used). If a coordinate does not change during a move, it can be omitted (which is why you see almost no Z parameters). With some commands (G0 to G3 included), you don't need to repeat the command on a new line if it's the same as before: you can supply just the new set of parameters (coordinates, and maybe feed rate), which is why most of your lines are just X, Y, I, J and F. Linear moves would be just X and Y (and/or Z if moving vertically too, and/or F if speed has to change).

G-code is not compiled; the Arduino runs an interpreter which receives it line by line and executes it. It doesn't move right away, then read another line. In order to avoid starting and stopping for each little move, it processes several commands ahead and feeds them into a movement planner, which schedules the moves as fast as it can while making sure that (a) it doesn't exceed the pre-programmed speed, acceleration (and/or jerk) limits of the machine, (b) it doesn't exceed the given feed rates, (c) it keeps the movements coordinated, that is, if several axes move simultaneously, they accelerate and decelerate together so that the resultant movement is a straight line (or an arc), and (d) it can stop at the end of the last command processed so far, while still obeying the same limits. It's fairly tricky to do this, and even trickier to do it on the Arduino Uno, which has only limited processing power. The Uno also generates pulses for every single microstep each motor has to move, each perfectly timed, while also doing what I described above. Be suitably impressed!

You can tell most CAM programs how many decimals to generate. Sometimes that's part of a post-processing step for the G-code. Some G-code senders can do that for you too. Failing that, just read the file and round any number after a letter X, Y, Z, I, J or K to 3-5 decimals (3 should be plenty for mm, 4 should be good for inch coordinates too).

The "AutoCAD to G-code" is what "CAM" is about. You design the part (essentially a shape) in CAD, and then design the manufacturing process for it in CAM. It's not as easy as converting, say, JPG to PNG, which any dumb computer can do. While there are programs that attempt to guess, and maybe even do a good job for simple parts, in most cases you have to tell the CAM program what to do and how to do it for each feature of your part (type of operation, choice of tool, other parameters). The CAM program helps a lot: once you've told it how you'd like it to mill a certain feature, it'll calculate what could be a very complex toolpath for you (the G-code), taking into account the geometry of the part, the geometry of the tool, and the practical limits of your manufacturing process (e.g. you can't mill more than this much material with every pass, you can't plunge more than this much at a time, you have to do a roughing pass stopping slightly short of the final shape followed by a finishing pass with a different tool, and so on). The CAM program will help you visualize the planned movement of the tool and the resulting object. It'll keep track of features and help you optimize the order of operations, and do all sorts of other things to make the process easier. But, ultimately, it's still a blend of design and engineering, with a human involved.

## G-code

In G-code, each "action" (modal group) should be on a separate line.

Grbl accepts coordinates in various forms ("0", "0." and "0.0000" are all ok), but some CNC machines require a decimal point to follow the number, which is why you'll see things like "0." in G-code. Please note that GRBL is limited in how long of a line it will accept. If your job is previewing correctly, but not running properly, check to see that line lengths are w/in its limits (50 for older versions, 70 for 0.8c dev or later).

For further details, please see Wikipedia:G-code and Grbl: How it works and other thought. --- includes a list of “currently supported g-code commands and unsupported commands from Grbl.

### Overview

The following table lists all of the letter codes for G-code, with the ones most likely to be used bolded.

Sources: Wikipedia:G-code, Smid 2008, Smid 2010

### Comments

Comments may be prefaced by a semi-colon (which are terminated at the end of the line), or enclosed w/in parentheses.

### Checksums

Some firmware may have an option for checksumming a line, indicated by the checksum value appearing at the end of a line preceded by an \*.

### Feed Rate (F)

It can be on a separate line or on the same line as a G1/G2/G3 command. There's no 'scope of visibility' though, so it will be valid of the following commands, too, until the next F command.

### Spindle Speed (S)

Set the spindle speed in revolutions per minute (r.p.m.).

### Tooling (T)

Tooling commands are not supported by Grbl. Most don't make sense unless one has an automatic tool changer (ATC).

Note that some Communication / Control programs will intercept these and allow on to change tools.

## G-code *Not* supported by Grbl

Please note that unsupported G-code may cause Grbl to behave oddly, for example drifting into a corner.

 G41
 G83
 G91.1
**Note** this is now supported in Grbl v0.9i

G12 and 13 cut circular pockets to the specified radius and depth, using a helix or spiral motion.

## References

* http://www.warrensbrain.com/gcode-to-english-translator.html [33]
* G-Code Commenter
* grbl wiki
* The NIST RS274/NGC Interpreter
* LinuxCNC G Codes
* http://linuxcnc.org/docs/html/gcode/gcode.html
* GCODE Introduction for Programmers
* Sherline: G- and M-Codes for CNC
* Tormach Machine Code Reference
* http://smoothieware.org/supported-g-codes
* http://carbide3d.com/docs/list-of-supported-gcodes/
* G-Code Shapeoko