CNC G code programming: how machine motion becomes a part

• 1
  What CNC G code programming actually controls
• 2
  How G codes and M codes divide the work
• 3
  Where CAM output stops being G code programming
• 4
  Where the language runs out of precision
• 5
  What we check before a program cuts metal
• 6
  When to hand-edit a program and when to leave it alone

A G code program is a list of word-address blocks. Each block holds letters followed by numbers: G for preparatory functions, X Y Z for linear position, I J K for arc centers, F for feed rate, S for spindle speed, T for tool selection, M for machine functions. The control reads the block, resolves it against its current modal state, and moves the axes to the commanded point. Nothing in the text is geometry. Geometry lives in the motion the control calculates.

That distinction matters when you review a program. A line like G01 X50.0 F800 does not say the tool is at X50. It says the tool should arrive at X50 while feeding at 800 mm/min. The control decides how, subject to acceleration limits and look-ahead. Two machines running the same text can produce different surface finishes.

Modal state is the part most people underestimate. G00, G01, G02, G03, G17, G40, G43 and the active feed all persist until another code replaces them. Skip a G40 after a cutter compensation block and the next tool path inherits the offset. The result is a gouge that appears twenty blocks later, far from the line that caused it.

So a program is not a drawing. It is a state machine with a tool attached. Reading it means tracking what the control believes at each line, not what the coordinates look like in isolation.

G codes describe where the tool goes. M codes describe what the machine does while the tool is there or before it moves. G01 feeds in a straight line, G02 and G03 cut arcs, G81 through G89 handle drilling and boring cycles, G28 sends axes to reference position, G54 to G59 select work coordinate systems. Those are the codes that shape metal.

M codes sit on the machine side. M03 and M04 start the spindle clockwise or counterclockwise, M05 stops it, M06 changes the tool, M08 and M09 control coolant, M30 ends the program and rewinds. Some M codes are builder-specific, which is why M07 on one control may do nothing on another. Always check the machine manual before trusting an M code you have not run.

The split matters for cycle time. Moving a tool with G01 is cheap. Every M06 tool change costs seconds of non-cutting time, and on a 16-tool program that adds up across a batch. Grouping features by tool, not by drawing order, is one of the few programming decisions that reliably pays back.

Spindle and feed codes also carry no physics. S12000 and F2000 are commands, not outcomes. Whether the cutter survives depends on chip load, radial engagement, and material hardness, which the program does not contain unless the programmer put it into the CAM parameters.

CAM software does the geometric work: toolpath strategy, stepover, rest machining, collision checks. What reaches the machine is the post-processed output, and that output is shaped by the post-processor configuration, not by the CAD model. Two shops cutting the same part from the same model can send very different programs to identical machines.

A post-processor decides arc output format, whether I J K or R is used, how tool length compensation is applied, decimal precision, and which canned cycles get expanded into longhand moves. Get the post wrong and the machine still runs. It just runs slowly, or leaves witness marks where a cycle should have retracted cleanly.

This is where hand editing enters. A programmer may raise a feed, insert a dwell with G04, split a deep pocket into depth passes, or add an M00 stop so an operator can check a feature. Those edits are where most crashes originate, because the changed block usually breaks a modal assumption made earlier in the file.

The practical rule: treat post output as a draft. The program is not finished until it has been verified against the setup sheet, the tool list, and the actual stock condition. Simulation helps, but it models the machine, not the fixture.

G code carries coordinates, not tolerances. The control interpolates along the commanded path and holds position within its servo and encoder resolution. On our machines that lands at ±0.005 mm on a qualified process, but the program itself does not guarantee it. Fixture rigidity, tool runout, thermal drift, and material springback decide what the part measures.

Every axis move is a trade between speed and accuracy. Look-ahead smoothing rounds corners to keep feed rates up. Tighten the tolerance band and the control slows down, sometimes by half. That is why a fine-finish pass often costs more cycle time than the roughing that removed most of the material.

Cutter compensation, G41 and G42, is the classic edge case. It works well on straight walls and generous radii. On internal corners smaller than the tool radius, the control has to invent a path, and the result can be a small gouge or an over-cut. CAM rest-machining handles these corners better than compensation alone.

Thread milling, deep pockets, thin walls, and features under 0.5 mm wide all push against what the language can express cleanly. They are machinable, but the program needs smaller stepovers and slower feeds, and someone has to decide where the extra time is worth it.

Simulation catches gross collisions. It does not catch a program that will chatter, so the first run happens on the real machine with the real fixture, at reduced feed and spindle override. We watch the load meter and the sound, then step up to the programmed values. That is faster than trusting the simulation and scrapping the first part.

Setup sheets matter as much as the code. Tool numbers, offsets, work coordinate origin, and stock size all have to match the program's assumptions. A G54 origin set 0.3 mm off shifts every feature on the part, no matter how clean the toolpaths look.

Verification is layered on purpose. Raw material is checked before cutting, dimensions are monitored in process, and every part is inspected before shipment, with reports on request. On a 10,000-part run the program is frozen early, because changing a feed mid-run invalidates the data behind the first article.

For prototypes the calculus flips. We would rather edit the program between parts than lock it. No minimum order quantity means a single piece can justify a custom setup, and the same programmer who wrote the roughing pass can adjust the finishing strategy after measuring the first article.