G-code Explainer & Simulator

A nine-line mill program, checked by hand (LinuxCNC rules, rapids at 5,000 mm/min):

G21 G17 G90 G94
M03 S1000
G00 X0 Y0 Z5
G01 Z-1 F100
X30 F300
G03 X40 Y10 I0 J10
G00 Z5
M05
M30

Line 1 sets millimetres, the XY plane, absolute positions and feed per minute; line 2 starts the spindle at 1,000 rpm. Line 3 rapids to X0 Y0 Z5, but nobody knows where the tool was before it, so this first move is plotted as a start point and not counted.
Line 4 feeds Z from 5 to −1: 6 mm at 100 mm/min = 6 ÷ 100 min = 3.6 s.
Line 5 (G01 still active) feeds X from 0 to 30: 30 mm at 300 mm/min = 6 s.
Line 6 is an anticlockwise arc. I0 J10 puts the centre 10 mm above the start, at X30 Y10, so the radius is 10 mm. The start (X30 Y0) is straight below the centre and the end (X40 Y10) is to its right: a quarter turn, 90°. Arc length = 2π × 10 × 90/360 = 15.708 mm, at 300 mm/min = 3.142 s.
Line 7 rapids Z from −1 to 5: 6 mm at 5,000 mm/min = 0.072 s. Lines 8 and 9 stop the spindle and end the program.
Totals: cut distance 6 + 30 + 15.708 = 51.708 mm, rapid distance 6 mm, estimated time 3.6 + 6 + 3.142 + 0.072 = 12.81 s. Run this example.

The common mistake: an arc end point that is not on the circle. Type G03 X40 Y12 I0 J10 instead. The centre is still X30 Y10 (I and J are measured from the start), so the start is 10 mm from the centre but the end is √(10² + 2²) = √104 = 10.198 mm away. The two radii differ by 0.198 mm. LinuxCNC refuses an arc whose radii differ by more than 0.005 mm and 0.1% of the radius (here 0.010 mm), or by more than 0.5 mm, with the error “Radius to end of arc differs from radius to start”; the NIST RS274/NGC interpreter of 2000 allowed only 0.002 mm. This tool flags the line as an error and still draws the spiral the numbers describe, so you can see how far off it is. Run the mistake.

Same rapid, two time estimates. G00 from X0 Y0 to X30 Y10 is a straight line of √(30² + 10²) = 31.623 mm. LinuxCNC moves the axes together along that line, so at 5,000 mm/min it takes 31.623 ÷ 5,000 min = 0.379 s. Haas describes its rapids as each axis moving at full speed, so the time is set by the longer axis: 30 ÷ 5,000 min = 0.360 s, and the path is a dog-leg, not a straight line. The Dialect option switches between the two, and the plot always shows the straight line between the end points.

How a program is read. Each line is split into words (a letter and a number), with comments in ( ) or after ; set aside. Codes on one line run in the order LinuxCNC documents, not the order they are written: feed mode, F, S, T, M06, spindle, coolant, dwell, plane, units, cutter compensation, tool length, work offset, distance mode, return mode, G28/G92, then the move, then M00/M02/M30. Modal codes stay in force until another code from the same group replaces them, which is why a bare X40. line still feeds at the last F.

What is not guessed. A code that is not in this tool’s list is flagged and skipped, never interpreted. Macros (#1, [2+3]), O-word loops and subprogram calls are not run. Positions the tool cannot know are shown as “?”: the start of the program, after G28 or G53 (machine coordinates), after a change of work offset, or after a cycle it does not simulate (G70–G72 and G76 on lathes, Haas G90/G94 lathe cycles, probing). Moves from or to such a point are not counted. Cutter compensation (G41/G42) and tool length offsets (G43) are explained but the plot shows the programmed path, not the offset one. The time leaves out acceleration, tool changes, spindle start-up and operator stops, so a real machine takes longer.

Lathes. The side view puts Z across and X up from the centreline, with the other half of the part shown faintly below it, so G02 is drawn clockwise as seen from the front of the screen. LinuxCNC’s lathe notes point out that on a typical lathe, where +Y points at the floor, G02 and G03 only look like their names when seen from below, so from above they appear reversed. X words are diameters in the Haas dialect (its G71 page gives the X finish allowance U as a diameter) and distances from the centreline in LinuxCNC unless G7 is active. Arc I offsets are distances from the start to the centre, so they stay radii; LinuxCNC says so explicitly for G7.

Sources: LinuxCNC documentation, G-Codes, M-Codes, G-code Overview (modal groups, order of execution, comments) and Lathe User Information; T. R. Kramer, F. M. Proctor and E. Messina, The NIST RS274NGC Interpreter, Version 3, NISTIR 6556, 2000; Haas Automation’s mill and lathe G-code and M-code pages (G00, G01, G02/G03, G04, G17, G20, G28, G40–G43, G54, G73, G80, G81, G83, G90, G94, G98; lathe G00–G02, G28, G50, G71, G90, G94, G96–G99; M02, M03–M06, M08/M09, M30); the Grbl v1.1 README for its supported-code list.

RS274. G-code is the everyday name for RS274, a programming language for numerically controlled machine tools. NIST’s interpreter report describes the most recent standard version, RS274-D, as completed in 1979 and published by the Electronic Industries Association as EIA-274-D, and adds a warning that still holds: implementations differ from machine to machine, so a program that runs on one maker’s machine probably will not run on another’s. That is why this tool has a dialect switch.

RS274/NGC. The Next Generation Controller (NGC) project wrote a fuller specification. Allen-Bradley prepared the first draft, “RS274/NGC for the LOW END CONTROLLER”, dated 24 August 1992; the National Center for Manufacturing Sciences released a second draft in August 1994. At the National Institute of Standards and Technology, the Enhanced Machine Controller (EMC) project built an interpreter for the language: version 1 was described in April 1994, and version 3, the report this tool cites, by Thomas Kramer, Frederick Proctor and Elena Messina, is dated 17 August 2000. Its RS274/VGER variant was written to read Fanuc-flavoured code for a retrofitted 5-axis machine.

Today. LinuxCNC’s documentation states that its G-code language is based on RS274/NGC, and its modal groups and order of execution are the ones used here. Industrial controls such as Haas’s keep the same core (G00–G03, G17–G21, G40–G43, G54–G59, G81, G83, M03–M06, M08/M09, M30) but differ in the details this tool flags, such as dwell units, rapid paths and the lathe codes. Small controllers support less: Grbl v1.1 lists G0–G3, G38.2–G38.5 and G80 as its motion modes, with no drilling cycles, no G41/G42 cutter compensation and no M6 tool change.

Reference: Surface Finish (Ra) Chart.

Reference: Speeds & Feeds Chart.

Reference: M-Code Reference by Controller.

Reference: Canned Cycles Reference.

This tool reads a CNC program the way a controller does, one block at a time with its modal state, and turns it into three things: a plain-English explanation of every word on every line, a plot of the toolpath with rapids, feeds and true arcs in a top and a front view (or a side view for lathes), and totals for cut distance, rapid distance, extents, tools and an estimated run time. Six checks run on every program: feed moves with no F, arcs whose end point is off the circle, units, plane and distance mode not set before the first move, cutting with the spindle off, cutter compensation left on, and a missing M30 or M02.

What it adds to a plain G-code viewer: each code’s meaning is taken from published documentation (LinuxCNC, the NIST RS274/NGC report and Haas’s code pages), the places where machines disagree are named rather than silently picked, and anything it does not know is flagged instead of guessed. Everything runs in your browser; the program you paste is not uploaded. For the code meanings alone, see the G-code and M-code reference.

It is for machinists and CNC students reading a program before running it, hobbyists checking a CAM post for a LinuxCNC or Grbl machine, and programmers learning how a modal language works. It is not a substitute for the machine’s own graphics and a dry run.

Related tools: Execution Visualizer, Circle Calculator, and Unit Converter.