What Is Gcode in CNC Machine Control

• 1
  How Gcode in CNC Machine Lines Is Built
• 2
  From CAD Model to Machine Instructions
• 3
  Why Multi-Axis Work Raises the Stakes
• 4
  How Engineers Read and Verify a Program
• 5
  Where Gcode Stops Being the Whole Story
• 6
  Core G and M Words and What They Do

A Gcode program is a list of blocks, and one block is one line of text. Most controllers follow ISO 6983 word address format: a letter addresses a register, a number gives the value. N10 G01 X45.0 Y12.5 F250 is four words in one block. The N number is a sequence label, useful when you restart a program mid-run. G tells the controller the operation mode. X, Y, and Z carry coordinates. F sets feed rate, S sets spindle speed, and T selects the tool.

Modal behavior matters more than beginners expect. Once G01 is called, every following block stays in feed motion until another G motion word replaces it. G90 and G91 decide whether coordinates are absolute from part zero or incremental from the last point. A program that mixes the two without a clear switch will cut in the wrong place. On our 27 three-axis machines and 12 four-axis mills, the first check after loading is always the modal state at the top of the file.

Coordinates are usually written in millimeters or inches depending on G21 or G20. Feed is mm/min in milling and often mm/rev in turning, so the same F value means different things on a mill and a lathe. Units, plane selection with G17 to G19, and cutter compensation with G41 and G42 are all modal. Post-processors handle these switches, but the machinist still reads the header to confirm them before cycle start.

The chain starts with a CAD model and a defined stock. CAM software compares the two, then calculates toolpaths that remove material without gouging the part or hitting the fixture. The output is not yet Gcode. It is a toolpath in the CAM system's own internal format. A post-processor then translates that toolpath into the dialect your controller expects.

The post-processor is where most problems are born. Fanuc, Siemens, Heidenhain, and Haas controllers share the core G words but differ in canned cycles, tool change syntax, and rotary axis naming. A post written for a 3-axis Haas will not drive a 5-axis Hermle correctly. For simultaneous 5-axis work, the post must also handle RTCP or TCPM so the controller keeps the tool tip on path while the rotary table tilts.

At GreatLight we run 16 simultaneous 5-axis machining centers, 16 mill-turn centers, and 27 three-axis machines. Each machine family has its own verified post. When a job moves from a three-axis mill to a 5-axis center, the post changes and so does the code. The part model does not change, but the program that cuts it does. That is why we treat post verification as a separate step from toolpath review.

On a three-axis mill, the tool axis stays vertical. The program is mostly 2D contours at stepped Z depths, and a mistake usually shows as a wrong depth or a gouged wall. On a 5-axis center, the tool vector tilts while the part rotates. A and B or C axis motion is synchronized with X, Y, and Z inside the same block. If the synchronization is off by a fraction of a degree, the tool tip drifts off the intended surface.

That drift is not always visible in the first pass. It shows up later as an uneven finish, a wall that is not true to the model, or a gouge on a rib that cannot be reworked. Aerospace and automotive parts with deep pockets, undercuts, and compound angles are the classic case. They often cannot be reached in three setups on a three-axis machine, so the program has to carry the full rotary motion.

RTCP, sometimes called TCPM on other controls, keeps the programmed point at the tool tip regardless of how the rotary axes move. Without it, the CAM system has to calculate the offset itself, and small post errors become large surface errors at long tool lengths. On our 5-axis centers with a Ø400 mm rotary table, we always confirm RTCP is active before the first cutting move. If it is not, the program is paused and the post is corrected.

Reading Gcode by eye is still useful, even with simulation tools. Start at the header: units, work offset, plane, and modal state. Then follow the tool changes and confirm each H and T number matches the tool list. A wrong H number is one of the most common causes of a crash because the machine trusts it completely.

Next, check the approach and retract moves. G00 blocks near the part are where collisions happen. Confirm the clearance plane is above the stock and the fixture. On deep cavities, watch for the retract height dropping as the cutter follows the floor. A program that clears the part at the start can still hit a clamp halfway through.

Simulation catches most of this, but it uses the same stock and fixture model you gave it. If the model is wrong, the simulation is wrong. We run a dry pass or a single-block run on the first article of a new program, especially on 5-axis jobs and on parts larger than 1,000 mm. On our 4,000 mm travel machines, a dry run costs minutes. A collision costs a spindle.

Gcode describes motion, not intent. It does not know the material hardness, the tool wear state, or whether the stock is 1 mm oversize. A program that cuts 6061 cleanly may chatter in 17-4PH stainless unless feed and speed are adjusted. The code is the same, the result is not.

Controllers also vary in how they look ahead. Some buffer hundreds of blocks and smooth the motion to hold feed through corners. Others stop at each block, which leaves witness marks on a finish pass. High-speed machining options and NURBS interpolation change the surface result without changing a single coordinate. When a finish is not meeting Ra 1.6 μm, the first question is often the control mode, not the Gcode.

Finally, Gcode does not carry inspection data. It cannot confirm that the part is within ±0.005 mm. That comes from in-process measurement and final inspection. A clean program is a starting point, not proof of a good part. We inspect 100% of parts before shipment and can supply reports on request.