G-code and M-code Reference for CNC Programming and Verification
G-codes and M-codes are the structured command sets that CNC machine controls interpret to move axes, run spindles, and manage auxiliary functions. This discussion outlines the core code families, common code examples, typical syntax patterns, control-specific differences, and practical verification methods for preparing or reviewing programs before production.
What G-codes and M-codes represent in machine control
G-codes define motion, coordinate systems, interpolation modes, and canned cycles; they tell the machine how to position tooling and follow paths. M-codes manage machine state and auxiliaries such as spindle on/off, coolant, and program flow. Both families are part of the RS-274 style command set used by numerically controlled equipment and are interpreted by the controller firmware or software layer.
Categorized list of common codes and their typical intent
The following table groups representative codes by function and gives short descriptions of typical usage. Exact numeric assignments and parameter options vary between control vendors and firmware versions, so treat these as common patterns rather than universal mappings.
| Category | Representative Codes | Typical Purpose |
|---|---|---|
| Axis motion & interpolation | G0, G1, G2, G3 | Rapid traverse, linear move at feed, clockwise/counterclockwise arcs |
| Coordinate & plane selection | G17, G18, G19, G54–G59 | XY/XZ/YZ planes and work offsets for setting origins |
| Feed & compensation | G93, G94, G40, G41, G42 | Feed rate mode, cutter compensation off/left/right |
| Canned cycles | G81–G89 (drilling cycles) | Standardized hole-making cycles with retract and dwell options |
| Spindle and coolant | M3, M4, M5, M7, M8, M9 | Spindle clockwise/ccw/stop; coolant on/off variants |
| Program control | M0, M1, M2, M30 | Stops, optional stops, end of program, rewind |
| Tool change | M6, T-code | Tool change routines and tool number selection |
| Machine-specific/aux | Custom M-codes, user macros | Hydraulics, door locks, probing, and vendor extensions |
Control-specific variations and vendor-agnostic notes
Controllers implement subsets and extensions of the RS-274-style language, and many add proprietary M- and G-codes or change parameter formats. Expect differences in canned cycle arguments, tool-change handling, and spindle speed commands. Industry practice is to consult the target control’s reference for numeric mappings and to test small segments on identical hardware or a certified simulator before full production runs.
Syntax examples and parameter conventions
Typical block structure starts with a block number (optional), followed by modal codes and axis or parameter words. For example, a linear move to X10 Y5 at feed 200 looks like: G1 X10 Y5 F200. Arc moves commonly use center-format I/J or radius-format R; a clockwise arc might be: G2 X20 Y10 I5 J0 F150. Tool calls combine a T-word and a tool-change M-word, such as: T1 M6, then a spindle start: S1500 M3. Numeric formats (leading zeros, decimal separators) and modal behavior differ, so mirror the controller’s conventions in generated code.
Verification and simulation practices before running on hardware
Static checks should validate syntax, modal state transitions, coordinate frame usage, and that tool offsets are defined. Offline simulation replicates kinematics and can reveal collisions, missed retracts, and axis limit violations; use a simulator that supports the target control’s dialect when possible. Dry-run or single-block execution on the machine helps verify feed and spindle modal interactions under supervision, but physical verification requires adherence to shop safety rules and machine interlocks.
When to consult machine documentation and standards
Refer to machine and control documentation whenever code mapping, parameter ranges, or safety interlocks are unclear. Manufacturer release notes and control reference manuals document versioned changes to code interpretation and undocumented vendor extensions. For formatting norms and historical baseline behavior, consult the ISO 6983 (RS-274) specifications, which describe standard command semantics used across many systems.
Trade-offs and accessibility considerations
Balancing portability and expressiveness is a common trade-off: writing strictly to an ISO-style subset improves cross-platform compatibility but may prevent using vendor optimizations that reduce cycle time. Simulation fidelity varies—high-end simulators model joint limits and dynamics, while basic viewers only visualize toolpaths. Accessibility considerations include making program files and operator prompts readable for team members with different skill levels and ensuring control panels and verification logs are compatible with shop tooling and safety processes.
Which G-code editor fits CNC control?
How to verify M-code list for machines?
Where to find CNC tooling and docs?
Key takeaways for program verification
Understanding code families and their modal behavior supports safer, more predictable program preparation. Treat the representative G- and M-code mappings as starting points: confirm exact meanings against the target control manual and ISO references, simulate using a dialect-aware tool, and perform staged checks on the machine. These steps align program intent with machine capability while limiting surprises in production.
