The Ultimate CNC G-Code Simulator & Program Verification Bible 2026 — Toolpath Simulation, FANUC, Haas, M98/M99, Collision Detection and G-Code Debugging

THE ULTIMATE CNC G-CODE SIMULATOR & PROGRAM VERIFICATION BIBLE 2026

CNC Toolpath Simulation, G-Code Debugging, FANUC, Haas, M98/M99, Macro Verification, Collision Detection and Digital Twins

The Complete Guide to Understanding, Checking, Visualizing and Verifying CNC Programs Before Machining

A CNC program can look correct and still contain a serious error.

A missing work offset, unexpected incremental move, incorrect arc center, wrong tool length, or misunderstood subprogram can produce a toolpath that differs dramatically from the programmer’s intention.

That is why CNC simulation and program verification are essential skills.

This guide explains how G-code simulators work, what they can detect, what they cannot detect, and how professional programmers use different levels of verification to reduce errors.

You will learn how to analyze CNC motion, inspect modal states, trace subprogram calls, understand common G-code errors, and distinguish simple backplotting from machine-accurate digital-twin simulation.

The fundamental rule: A successful simulation is evidence of what the simulator modeled—not proof that every real-machine risk has been eliminated.

Safety and compatibility notice

All examples in this guide are educational.

G-code interpretation depends on the controller, control series, machine builder, software options, machine kinematics, tooling, offsets, and setup.

Never execute unfamiliar CNC code without controller-specific verification, appropriate simulation, setup inspection, and approved prove-out procedures.

A browser-based toolpath viewer cannot automatically verify machine-specific M-codes, servo behavior, actual fixture clearances, tool changer motion, or safety-system conditions.

PART I — UNDERSTANDING CNC SIMULATION

SECTION 1 — WHAT IS A G-CODE SIMULATOR?

A G-code simulator is software that interprets CNC programming instructions and represents their expected behavior.

Depending on its capabilities, a simulator may display:

• Linear tool movement
• Rapid positioning
• Circular interpolation
• Drilling cycles
• Toolpath direction
• Feed movements
• Coordinate positions
• Program sequence
• Estimated machining time
• Material removal
• Tool and holder geometry
• Machine-axis movement
• Potential collisions

Not every simulator supports every function.

Some display only a geometric toolpath.

Others model the machine, tools, fixtures, controller behavior, and machining process.

These differences are critical.

SECTION 2 — G-CODE VIEWER VS G-CODE SIMULATOR

A G-code viewer generally displays programmed movement.

A simulator may additionally calculate the behavior of machining operations.

A machine simulation system may model actual machine components and kinematics.

Capability	Basic viewer	Toolpath simulator	Machine simulation
Display linear moves	Often	Usually	Usually
Display arcs	Often	Usually	Usually
Expand canned cycles	Varies	Often	Often
Model stock removal	Usually not	Sometimes	Often
Model tool holders	Usually not	Sometimes	Often
Model machine axes	Usually not	Sometimes	Yes, when configured
Detect machine collisions	No	Limited	Potentially
Interpret custom M-codes	Rarely	Varies	Requires configuration
Reproduce exact controller behavior	No	Varies	Depends on integration

Never confuse a colored toolpath line with complete machine verification.

SECTION 3 — WHY CNC PROGRAMS NEED VERIFICATION

Common programming problems include:

• Incorrect coordinate values
• Wrong coordinate system
• Incorrect tool length offset
• Wrong tool diameter compensation
• Unexpected modal state
• Incorrect arc geometry
• Invalid canned-cycle parameters
• Missing subprograms
• Unexpected loops
• Macro calculation errors
• Incorrect retracts
• Unsupported controller commands
• Wrong postprocessor output

Verification helps identify errors before they reach the physical machine.

SECTION 4 — THE FIVE LEVELS OF CNC VERIFICATION

LEVEL 1 — TEXT AND SYNTAX CHECKING

Check whether commands are recognized and formatted correctly.

LEVEL 2 — MODAL-STATE ANALYSIS

Track active programming modes and compensation states.

LEVEL 3 — TOOLPATH BACKPLOTTING

Visualize programmed movement and geometry.

LEVEL 4 — STOCK AND COLLISION SIMULATION

Model tool engagement, stock removal, and available collision geometry.

LEVEL 5 — MACHINE-AWARE VERIFICATION

Model machine kinematics, tooling, fixtures, and supported controller behavior.

Higher levels can reveal additional problems, but they still depend on accurate input data and model coverage.

PART II — CNC MOTION SIMULATION

SECTION 5 — G00 RAPID MOVEMENT SIMULATION

G00 commonly commands rapid positioning.

Example:

G90 G00 X100. Y50.

A simulator should identify the destination and display the modeled movement.

Important considerations:

• The starting position
• Active coordinate system
• Active tool compensation
• Machine travel limits
• Actual rapid trajectory
• Potential fixture interference

A basic viewer may draw a straight line between positions even when the physical controller uses different rapid-axis behavior.

SECTION 6 — G01 LINEAR INTERPOLATION

Example:

G90 G01 X80. Y40. F300.

A simulator should interpret this as a feed-controlled linear move under the active feed mode.

Useful information includes:

• Start point
• End point
• Programmed feedrate
• Distance
• Direction
• Tool engagement

A correct geometric line does not confirm that the programmed feed is appropriate for the cutting operation.

SECTION 7 — G02 CLOCKWISE ARC SIMULATION

G02 commonly commands clockwise circular interpolation in the active plane.

Example, assuming XY-plane operation and incremental I/J arc centers:

G17 G90

G00 X0. Y10.

G02 X10. Y0. I0. J-10.

The example describes a clockwise quarter-circle movement around the origin.

A simulator should check:

• Arc start
• Arc end
• Arc center
• Radius consistency
• Active plane
• Arc direction

Incorrect arc-center conventions can produce a very different result.

SECTION 8 — G03 COUNTERCLOCKWISE ARC SIMULATION

Example:

G17 G90

G00 X10. Y0.

G03 X0. Y10. I-10. J0.

This represents a counterclockwise quarter-circle arc under the stated assumptions.

A useful simulator should display arc direction and identify invalid geometry.

SECTION 9 — RADIUS-BASED ARC PROGRAMMING

Some controls support radius-based arc definitions.

Conceptual example:

G03 X0. Y10. R10.

The actual arc depends on the current starting position and the controller’s radius interpretation.

Potential problems include:

• Ambiguous major/minor arcs
• Incorrect radius sign
• Impossible geometry
• Unsupported syntax
• Incorrect active plane

Always use controller-specific arc conventions.

SECTION 10 — FULL-CIRCLE INTERPOLATION

A full circle can be represented in different ways depending on the control.

Some controls support full circles using center offsets.

Others require or benefit from multiple arcs.

A portable educational approach is to describe a circle using two semicircular movements.

Example:

G17 G90

G00 X10. Y0.

G03 X-10. Y0. I-10. J0.

G03 X10. Y0. I10. J0.

This example illustrates geometry only.

It does not establish cutting depth, clearance, tooling, or machining safety.

PART III — MODAL-STATE VERIFICATION

SECTION 11 — WHAT IS A CNC MODAL STATE?

Many CNC commands remain active until changed or canceled.

Common modal categories include:

• Motion mode
• Plane selection
• Unit selection
• Absolute/incremental positioning
• Feed mode
• Work coordinate system
• Cutter compensation
• Tool length compensation
• Canned-cycle state

A simulator that ignores modal state may misinterpret otherwise valid programs.

SECTION 12 — G90 ABSOLUTE POSITIONING

Example:

G90

G01 X10. F200.

X20.

X30.

Expected X destinations:

10

20

30

The coordinates refer to the active coordinate system.

SECTION 13 — G91 INCREMENTAL POSITIONING

Example:

G91

G01 X10. F200.

X10.

X10.

G90

Each move advances X by 10 units.

The final position depends on the initial position.

The last G90 restores absolute positioning.

SECTION 14 — THE HIDDEN G91 ERROR

Consider a program that calls a subprogram.

The subprogram changes to G91 but does not restore G90.

When the main program resumes, an X command may be interpreted incrementally rather than absolutely.

A modal-state analyzer should display:

Expected state: G90

Actual state: G91

Potential consequence: Unexpected positioning

This is one of the most valuable uses of program-state tracking.

SECTION 15 — G17, G18 AND G19 PLANE TRACKING

Common plane selections:

G17 — XY

G18 — XZ

G19 — YZ

The active plane affects circular interpolation.

A simulator must not assume every G02 or G03 command belongs to the XY plane.

SECTION 16 — G20 AND G21 UNIT VERIFICATION

G20 and G21 commonly select inch and metric programming.

A unit mismatch can produce a large geometric error.

For example:

A programmed distance of 25 may represent 25 mm or 25 inches, depending on the active unit system.

A simulator should prominently display the active units.

SECTION 17 — G54 THROUGH G59 WORK OFFSETS

Work offsets map programmed coordinates to the machine setup.

A toolpath viewer that does not know the actual stored offsets may correctly display part-relative geometry but cannot establish the real machine position.

This distinction matters for collision detection.

SECTION 18 — G43 TOOL LENGTH COMPENSATION

Tool length compensation affects the relationship between programmed coordinates and the physical tool.

A simulator should distinguish:

• Programmed tool-tip position
• Tool length offset
• Tool assembly geometry
• Machine-axis position

Without verified tool length and holder data, physical clearance checks are incomplete.

SECTION 19 — G41 AND G42 CUTTER COMPENSATION

Cutter compensation changes the tool-center path relative to programmed geometry.

A useful simulator may model:

• Compensation direction
• Tool radius
• Lead-in
• Lead-out
• Contour transitions
• Geometry conflicts

A simple viewer that ignores compensation can display a misleading toolpath.

SECTION 20 — G80 CANNED-CYCLE CANCELLATION

G80 commonly cancels active canned cycles.

Without correct modal tracking, a simulator may fail to identify repeated drilling operations at subsequent XY positions.

This is a frequent source of confusion when debugging drilling programs.

PART IV — DRILLING AND TAPPING SIMULATION

SECTION 21 — G81 DRILLING CYCLE

Example:

G90 G98 G81 X10. Y10. Z-12. R3. F120.

X30. Y10.

X50. Y10.

G80

On a compatible FANUC-style milling control, this describes repeated drilling positions.

A simulator should expand the cycle into its modeled movements.

Important values:

• Hole coordinates
• Initial level
• R plane
• Final depth
• Feedrate
• Return mode

SECTION 22 — G82 DWELL DRILLING

G82 commonly adds a dwell at the bottom of a drilling operation.

Simulation should account for:

• Approach
• Cutting feed
• Dwell
• Retract

Dwell units and parameter formats depend on the control.

SECTION 23 — G83 PECK DRILLING

Example:

G90 G98 G83 X20. Y20. Z-30. R3. Q5. F100.

G80

A simulator may show repeated pecks and retracts.

But peck behavior varies by controller.

A generic simulator may not reproduce the exact machine cycle.

SECTION 24 — G84 TAPPING SIMULATION

Tapping requires more than a vertical toolpath.

A realistic verification process considers:

• Thread pitch
• Feed mode
• Spindle speed
• Spindle synchronization
• Tapping direction
• Retract behavior
• Controller requirements

A simple geometric simulator cannot prove correct rigid-tapping synchronization.

SECTION 25 — G98 AND G99 RETURN MODES

On many FANUC-style milling controls, G98 and G99 affect canned-cycle return behavior.

In turning, these codes can have different meanings.

A controller-aware simulator must identify the machine type before interpreting them.

PART V — M98, M99 AND SUBPROGRAM SIMULATION

SECTION 26 — WHY SUBPROGRAMS ARE DIFFICULT TO SIMULATE

A program may contain calls to other programs.

A simulator must locate the target, preserve the execution context, and return correctly.

Potential problems:

• Missing subprogram
• Wrong program number
• Unsupported call syntax
• Incorrect repeat count
• Excessive nesting
• Unexpected return behavior
• Modal-state changes inside subprograms

SECTION 27 — M98 SUBPROGRAM CALL

Example:

O1000

M98 P2000

M30

Separate subprogram:

O2000

(EDUCATIONAL SUBPROGRAM)

M99

On compatible FANUC-style controls, M98 calls the subprogram and M99 returns.

A simulator should show the call relationship rather than treating the two programs as unrelated text.

SECTION 28 — M99 RETURN BEHAVIOR

M99 is commonly associated with subprogram return.

However, behavior depends on context and controller.

A simulator must distinguish:

• M99 inside a called subprogram
• M99 in a directly executed program
• Controller-specific repetition behavior
• Optional return formats

Incorrect assumptions can create false simulation results.

SECTION 29 — M97 HAAS LOCAL SUBPROGRAMS

On supported Haas controls, M97 can call a local subprogram using a sequence-number reference.

A generic FANUC interpreter may not support this structure.

This is why controller selection matters.

SECTION 30 — M198 EXTERNAL PROGRAM CALLS

M198 is associated with external program calls on certain controls.

A simulator must know:

• Whether the function is supported
• Where the program is stored
• How the program is identified
• How the return is handled

Without these details, complete execution cannot be verified.

SECTION 31 — SUBPROGRAM CALL GRAPH

A useful simulator can display:

MAIN PROGRAM

↓

SUBPROGRAM A

↓

SUBPROGRAM B

↓

RETURN TO A

↓

RETURN TO MAIN

This structure helps diagnose nested calls and unexpected loops.

SECTION 32 — SUBPROGRAM LOOP DETECTION

A debugger should detect possible repeated call chains.

Example:

Program A calls Program B.

Program B calls Program A.

Without a terminating condition, execution may become recursive or exceed controller limits.

A call-graph analyzer can identify this pattern before machine execution.

PART VI — MACRO B SIMULATION

SECTION 33 — WHY MACROS REQUIRE A REAL INTERPRETER

Macro programming includes variables, arithmetic, conditions, and loops.

A simulator must understand the macro language to calculate the actual toolpath.

Displaying the original text is not enough.

SECTION 34 — MACRO VARIABLE TRACKING

Example:

#100 = 10.

#101 = 20.

#102 = [#100 + #101]

A macro-aware debugger should display:

#100 = 10

#101 = 20

#102 = 30

Variable availability and syntax depend on the controller.

SECTION 35 — MACRO CONDITIONAL LOGIC

Example:

#100 = 5

IF [#100 GT 10] GOTO 100

#101 = 1

GOTO 200

N100 #101 = 2

N200

A debugger should show which branch executes.

This is more useful than simply displaying the final program text.

SECTION 36 — MACRO LOOP TRACKING

Example:

#100 = 1

WHILE [#100 LE 5] DO1

  #101 = [#100 * 10]

  #100 = [#100 + 1]

END1

A simulator should be able to display loop iterations and variable values.

Potential issues include:

• Infinite loops
• Incorrect exit conditions
• Invalid arithmetic
• Unexpected persistent values

SECTION 37 — MACRO RANGE CHECKING

A macro can calculate coordinates outside the intended work area.

For example:

Calculated X = 500 mm

Allowed part-relative range = 0–100 mm

A program checker should identify the mismatch.

The permitted range must come from verified setup information rather than arbitrary assumptions.

SECTION 38 — SYSTEM VARIABLES AND SIMULATION

Some macro programs read machine state using controller-specific system variables.

Examples of possible information include:

• Current position
• Work offsets
• Tool offsets
• Timers
• Machine status
• Probe results

A generic simulator may not have access to these values.

It must either model them explicitly or report that the result cannot be determined.

Never invent system-variable values to make a program appear valid.

PART VII — CNC COLLISION DETECTION

SECTION 39 — WHAT IS COLLISION DETECTION?

Collision detection attempts to identify intersections between modeled machine components.

Possible collision pairs include:

• Tool and fixture
• Holder and stock
• Holder and fixture
• Spindle and fixture
• Table and machine structure
• Rotary axis and machine structure
• Tool and machine enclosure

Detection quality depends on model accuracy.

SECTION 40 — TOOL VS PART COLLISION

Tool engagement with stock is often intentional.

A simulator must distinguish intended cutting from unintended interference.

This requires machining context and accurate tool geometry.

A simple geometric intersection test is not enough.

SECTION 41 — HOLDER VS FIXTURE COLLISION

A tool may clear the fixture while its holder does not.

This is one reason tool-center backplotting alone cannot guarantee safety.

Accurate holder geometry and tool stick-out are essential.

SECTION 42 — RAPID-MOVE COLLISION RISKS

Rapid positioning deserves special attention.

Potential issues include:

• Low clearance
• Unexpected diagonal movement
• Wrong coordinate mode
• Incorrect work offset
• Incorrect tool length
• Fixture interference

A simulator should clearly distinguish rapid movements from feed movements.

SECTION 43 — MACHINE OVERTRAVEL DETECTION

A machine-aware simulator may check commanded axis positions against configured travel limits.

However, part-relative toolpath coordinates are not enough.

Machine-axis positions depend on:

• Work offsets
• Tool length
• Kinematics
• Rotary-axis orientation
• Machine configuration

SECTION 44 — ROTARY-AXIS COLLISION RISKS

Four-axis and five-axis machines introduce additional motion.

Potential problems:

• Rotary table interference
• Tool holder clearance
• Head and table collisions
• Axis-limit conflicts
• Incorrect workpiece orientation

These require accurate machine kinematics.

PART VIII — 5-AXIS CNC SIMULATION

SECTION 45 — WHY 5-AXIS SIMULATION IS DIFFERENT

In three-axis machining, the tool orientation is typically fixed.

In five-axis machining, rotary axes change the tool orientation relative to the workpiece.

Simulation must consider:

• Linear axes
• Rotary axes
• Tool orientation
• Pivot geometry
• Machine kinematics
• Coordinate transformations
• Tool-center-point behavior

SECTION 46 — TOOL CENTER POINT CONTROL

TCP functions compensate for rotary-axis movement according to the controller and machine configuration.

Different manufacturers use different commands and implementation details.

A simulator must model the same kinematic assumptions as the physical machine.

SECTION 47 — SIEMENS TRAORI SIMULATION

On supported SINUMERIK systems, TRAORI is associated with transformation functions used in advanced machining.

Verification should consider:

• Machine kinematics
• Tool data
• Rotary-axis configuration
• Active transformations
• Postprocessor output

A generic G-code viewer is not a substitute for controller-aware transformation verification.

SECTION 48 — ADVANCED FANUC 5-AXIS FUNCTIONS

Supported FANUC configurations may include advanced transformation and tool-center-point functionality.

Exact G-codes, options, and syntax vary by series and machine builder.

A simulator must be configured for the actual machine.

PART IX — CNC DIGITAL TWINS

SECTION 49 — WHAT IS A CNC DIGITAL TWIN?

A CNC digital twin is a digital representation of relevant machine behavior and configuration.

Depending on the system, it may include:

• Machine geometry
• Axis kinematics
• Controller behavior
• Tools
• Holders
• Fixtures
• Stock
• Work offsets
• NC programs

The level of accuracy varies between implementations.

SECTION 50 — BACKPLOT VS DIGITAL TWIN

A backplot answers:

Where does the programmed toolpath go?

A machine-aware digital twin can help answer:

How does this specific machine execute the program with its configured axes, tools, and fixtures?

The second question requires significantly more information.

SECTION 51 — CONTROLLER-AWARE SIMULATION

Controller-aware simulation attempts to reproduce relevant control behavior.

Potential differences include:

• Canned cycles
• Subprogram calls
• Macro language
• Look-ahead
• High-speed modes
• Coordinate transformations
• Machine-specific M-codes

No simulator should claim complete controller equivalence unless that capability has been validated.

SECTION 52 — VIRTUAL COMMISSIONING

Virtual commissioning uses digital models to test aspects of machine or automation behavior before physical deployment.

Potential applications:

• Machine sequencing
• PLC logic
• Robot interaction
• Pallet handling
• Machine interfaces
• Production-cell coordination

This goes beyond basic G-code toolpath viewing.

PART X — CNC PROGRAM DEBUGGING

SECTION 53 — G-CODE SYNTAX CHECKER

A syntax checker may detect:

• Unknown commands
• Invalid numeric formats
• Missing required addresses
• Unsupported combinations
• Malformed program blocks

But syntax validity does not prove geometric or physical safety.

SECTION 54 — CNC MODAL-STATE ANALYZER

A modal-state analyzer should track the active state at each program block.

Recommended fields:

State	Example
Units	G21
Plane	G17
Positioning	G90
Work offset	G54
Motion	G01
Tool length compensation	G43
Canned cycle	G80
Feed mode	G94

A block-by-block state table is especially useful when diagnosing unexpected movement.

SECTION 55 — G-CODE PROGRAM DIFF

A CNC-aware comparison tool should highlight:

• Changed coordinates
• Changed feeds
• Changed spindle speeds
• Changed tool numbers
• Changed offsets
• Changed G-codes
• Changed M-codes
• Changed macro variables
• Changed subprogram calls

This helps programmers review revisions before releasing a new program.

SECTION 56 — CNC SAFE-START ANALYSIS

A program checker can identify which initial states a program establishes.

Examples:

• Units
• Plane
• Positioning mode
• Canned-cycle cancellation
• Cutter compensation
• Work offset
• Tool compensation

A generic safe-start block is not universally safe.

Correct initialization depends on the machine and operation.

SECTION 57 — TOOL AND OFFSET CONSISTENCY

A checker can compare:

• Programmed tool number
• Expected tool description
• Tool length offset
• Tool diameter offset
• Operation requirements

Actual tool data must be verified against the machine and setup records.

SECTION 58 — CNC PROGRAM RESTART VERIFICATION

Restarting a program in the middle can create problems when required states have not been restored.

Potential issues:

• Missing tool selection
• Wrong work offset
• Incorrect compensation
• Unexpected modal state
• Uninitialized macro variables
• Incorrect subprogram context

A simulator should not assume a mid-program restart is equivalent to execution from the beginning.

PART XI — COMMON SIMULATION ERRORS

SECTION 59 — ARC DOES NOT DISPLAY CORRECTLY

Check:

• G02/G03 direction
• Active plane
• Arc center
• Radius
• Start and end points
• Center-offset convention
• Simulator dialect

SECTION 60 — TOOLPATH IS MUCH LARGER THAN EXPECTED

Possible causes:

• G20/G21 mismatch
• Incorrect scaling
• Wrong units
• Unexpected coordinate interpretation
• Incorrect imported program settings

SECTION 61 — TOOLPATH IS IN THE WRONG LOCATION

Check:

• G54–G59
• G90/G91
• Program origin
• Tool length compensation
• Machine coordinate interpretation
• Simulator setup

SECTION 62 — DRILLING CYCLE DOES NOT APPEAR

Possible reasons:

• Simulator does not support the cycle
• Unsupported dialect
• Missing cycle parameters
• Incorrect cycle cancellation
• Program parsing problem

Do not conclude the CNC program is correct merely because the viewer ignored the cycle.

SECTION 63 — M98 SUBPROGRAM NOT FOUND

Check:

• Target program number
• Program availability
• File loading
• Supported call syntax
• Repeat-count format
• External storage assumptions

A simulator must have access to the called program to verify the complete execution path.

SECTION 64 — MACRO PROGRAM DOES NOT SIMULATE

Possible causes:

• Macro interpreter unavailable
• Unsupported variable syntax
• Missing system-variable data
• Unsupported control-flow commands
• Missing controller-specific functions

A tool that cannot interpret macros should clearly report that limitation.

SECTION 65 — SIMULATION PASSES BUT MACHINE ALARMS

Possible explanations:

• Unsupported controller function
• Machine-builder M-code
• Missing software option
• Incorrect tool data
• Machine-state restriction
• PLC sequence
• Servo or spindle fault
• Simulation model mismatch

Simulation and real-machine diagnostics are complementary.

PART XII — CHOOSING A CNC SIMULATOR

SECTION 66 — QUESTIONS TO ASK BEFORE CHOOSING

Which controllers does it support?

Does it interpret the required G-code dialect?

Can it load subprograms?

Does it support macros?

Can it expand canned cycles?

Does it model stock removal?

Does it include tool holders?

Can it represent the machine’s kinematics?

Does it support the required postprocessor?

Can it check machine-axis limits?

Does it provide program reports?

Does it clearly document unsupported commands?

SECTION 67 — ONLINE G-CODE SIMULATORS

Browser-based G-code tools can be useful for:

• Learning basic motion
• Visualizing simple programs
• Checking arcs
• Inspecting coordinates
• Understanding drilling patterns
• Reviewing small programs

However, online tools differ widely in capability.

Some are viewers rather than full simulators.

Do not assume an online viewer can validate machine-specific macros, M-codes, collision clearances, or five-axis transformations.

SECTION 68 — DESKTOP CNC SIMULATION SOFTWARE

Desktop software may offer additional capabilities such as:

• Larger program support
• Stock removal
• Tool libraries
• CAM integration
• Machine models
• Detailed verification reports

Actual features depend on the product and configuration.

SECTION 69 — CAM-INTEGRATED VERIFICATION

CAM systems can simulate toolpaths before postprocessing.

This is valuable, but there is an important distinction:

CAM toolpath verification is not always the same as verification of the final posted NC program.

The postprocessor can introduce machine-specific commands and transformations.

For high-risk operations, verifying the final NC output is especially important.

SECTION 70 — MACHINE-ACCURATE NC VERIFICATION

Machine-aware NC verification aims to check the program in the context of the actual machine.

Useful model inputs include:

• Final posted NC program
• Machine geometry
• Axis limits
• Kinematic model
• Tool assemblies
• Fixture geometry
• Stock model
• Work offsets
• Controller-specific behavior

Incorrect model data can produce misleading results.

PART XIII — CNC SIMULATOR WORKFLOWS

SECTION 71 — BEGINNER WORKFLOW

Start with a simple linear program.

Identify the origin.

Identify the active units.

Identify G90/G91.

Display the toolpath.

Inspect every move.

Then introduce arcs and drilling cycles.

This creates a foundation for understanding more complex programs.

SECTION 72 — INTERMEDIATE WORKFLOW

Use programs containing:

• Multiple tools
• Work offsets
• Drilling cycles
• Circular interpolation
• Cutter compensation
• Subprograms

Track modal states and verify the complete program sequence.

SECTION 73 — ADVANCED WORKFLOW

Use controller-aware verification for:

• Macro programs
• Nested subprograms
• Complex 3D machining
• High-speed functions
• Probing cycles
• Multi-axis machining
• Automation interfaces

Identify unsupported commands rather than silently ignoring them.

SECTION 74 — PRODUCTION RELEASE WORKFLOW

A professional release process may include:

1. Confirm part revision.
2. Confirm setup and workholding.
3. Confirm machine and controller.
4. Confirm tool list.
5. Confirm offsets and coordinate assumptions.
6. Verify final posted NC code.
7. Review rapid moves and clearances.
8. Review subprograms and macros.
9. Run appropriate simulation.
10. Review reported warnings.
11. Perform approved machine prove-out.
12. Inspect the first part.
13. Record the approved program revision.

PART XIV — BUILDING A CNC SIMULATOR KNOWLEDGE HUB

SECTION 75 — G-CODE EXAMPLE LIBRARY

A useful learning platform can provide examples for:

• G00
• G01
• G02
• G03
• G17
• G18
• G19
• G40
• G41
• G42
• G43
• G54
• G81
• G82
• G83
• G84
• G90
• G91

Each example should identify its controller assumptions.

SECTION 76 — M-CODE REFERENCE LIBRARY

A controller-aware M-code reference can include:

• M03
• M04
• M05
• M06
• M08
• M09
• M30
• M97
• M98
• M99
• M198

Machine-builder-specific behavior must be documented separately.

SECTION 77 — CNC ERROR EXAMPLES

Useful educational cases include:

• Incorrect arc center
• Missing G80
• Wrong positioning mode
• Wrong work offset
• Incorrect tool length
• Invalid subprogram call
• Unexpected M99 loop
• Invalid macro input
• Incorrect tapping feed
• Unsafe rapid clearance

The strongest examples show both the error and the reasoning used to identify it.

SECTION 78 — INTERACTIVE MODAL-STATE VIEWER

A future interactive tool could display:

NC BLOCK

G91 G01 X10. F200.

ACTIVE STATE

Positioning: Incremental

Motion: Linear

Feed: 200

EXPECTED EFFECT

Move X by +10 from the current position.

The tool should also explain which previous commands established the state.

SECTION 79 — INTERACTIVE SUBPROGRAM CALL GRAPH

A subprogram visualizer could display:

O1000 MAIN

   |

   +– M98 P2000

          |

          +– O2000

          |     |

          |     +– M98 P3000

          |            |

          |            +– O3000

          |            +– M99

          |

          +– M99

   |

   +– M30

This helps programmers understand nested program execution.

SECTION 80 — INTERACTIVE ARC CALCULATOR

Recommended inputs:

• Start X
• Start Y
• End X
• End Y
• Radius or center
• G02/G03
• Active plane
• Arc-center convention

Recommended outputs:

• Arc center
• Radius
• Sweep angle
• I/J/K values
• Geometry validity

A useful calculator should reject impossible arcs rather than invent coordinates.

SECTION 81 — INTERACTIVE DRILLING CYCLE VIEWER

Recommended inputs:

• Cycle type
• Hole position
• Initial level
• R plane
• Final depth
• Peck increment
• Return mode

Recommended outputs:

• Modeled movement sequence
• Hole depth
• Retract levels
• Cycle warnings
• Controller assumptions

SECTION 82 — INTERACTIVE G-CODE DIFF CHECKER

Compare two NC programs and identify:

• Added commands
• Removed commands
• Changed coordinates
• Changed tool numbers
• Changed offsets
• Changed spindle speeds
• Changed feeds
• Changed subprogram calls

This is particularly useful when reviewing production program revisions.

PART XV — FREQUENTLY ASKED QUESTIONS

SECTION 83 — WHAT IS THE BEST G-CODE SIMULATOR?

The best simulator depends on the controller, machine type, required accuracy, and whether you need simple toolpath visualization or machine-aware verification.

No single simulator is automatically the best choice for every CNC application.

SECTION 84 — CAN I SIMULATE G-CODE ONLINE?

Yes, some online tools can visualize supported G-code.

However, their supported dialects, cycles, macros, and machine models vary.

Always check the tool’s documented capabilities.

SECTION 85 — CAN A G-CODE SIMULATOR PREVENT CRASHES?

Simulation can help identify certain errors and collision risks.

It cannot guarantee crash prevention, especially when actual machine setup data or physical conditions differ from the simulation.

SECTION 86 — CAN A SIMULATOR READ FANUC G-CODE?

Some simulators support FANUC-style programming.

Advanced FANUC functions, Macro B, system variables, and machine-builder commands may require additional capabilities.

SECTION 87 — CAN A SIMULATOR READ HAAS G-CODE?

Some simulators support Haas programming conventions.

Compatibility should be verified for the installed Haas control generation and required functions.

SECTION 88 — CAN I SIMULATE M98 AND M99?

A simulator can trace M98/M99 behavior if it supports the relevant dialect and has access to the called programs.

A simple viewer may not support subprogram execution.

SECTION 89 — CAN I SIMULATE CNC MACROS?

Macro simulation requires a compatible interpreter.

A simulator must evaluate variables, calculations, branches, loops, and relevant system-variable behavior.

SECTION 90 — WHAT IS THE DIFFERENCE BETWEEN BACKPLOT AND COLLISION SIMULATION?

Backplot displays programmed movement.

Collision simulation attempts to identify interference between modeled physical objects.

A backplot alone cannot verify all tool, holder, fixture, or machine clearances.

SECTION 91 — WHY DOES MY G-CODE SIMULATOR SHOW THE WRONG TOOLPATH?

Common causes include:

• Wrong units
• Wrong coordinate mode
• Unsupported dialect
• Incorrect arc convention
• Missing offsets
• Unsupported macros
• Incorrect setup assumptions

SECTION 92 — IS A CNC DIGITAL TWIN THE SAME AS A SIMULATOR?

A digital twin may include simulation, but the terms are not identical.

A digital twin generally emphasizes a representation of a specific physical system and may incorporate configuration or operational data.

SECTION 93 — CAN AI VERIFY CNC G-CODE?

AI can assist with code explanation and identifying suspicious patterns.

It should not be treated as proof of machine safety or controller compatibility.

SECTION 94 — SHOULD I SIMULATE THE CAM TOOLPATH OR THE FINAL G-CODE?

Both can be valuable.

CAM toolpath verification checks the programmed machining strategy.

Final NC verification helps identify issues introduced by postprocessing or controller-specific output.

PART XVI — THE FUTURE OF CNC VERIFICATION IN 2026

SECTION 95 — AI-ASSISTED PROGRAM ANALYSIS

AI-assisted tools may help programmers:

• Explain unfamiliar commands
• Summarize program structure
• Identify suspicious modal changes
• Compare revisions
• Document machining operations
• Organize troubleshooting information

The quality of the result depends on the accuracy of the underlying controller and machine data.

SECTION 96 — DIGITAL TWIN AND AI INTEGRATION

Combining machine models with AI-assisted analysis may improve the usability of simulation results.

Potential applications include:

• Explaining verification warnings
• Identifying likely programming mistakes
• Summarizing collision reports
• Comparing machining strategies
• Supporting program documentation

The simulator’s verified physical model must remain distinct from AI-generated interpretation.

SECTION 97 — AUTOMATED PROGRAM QUALITY CHECKS

A future CNC verification workflow may automatically review:

• Missing initialization
• Suspicious coordinate changes
• Unexpected modal states
• Incorrect subprogram references
• Unvalidated macro inputs
• Unusual feed changes
• Potential travel-limit conflicts
• Unverified controller functions

Automated checks should explain their assumptions and limitations.

SECTION 98 — MACHINE-SPECIFIC KNOWLEDGE

The most valuable verification systems connect code with machine-specific knowledge.

Examples:

• Controller series
• Supported options
• Machine kinematics
• Tool changer behavior
• Tool and holder data
• Fixture configuration
• Work offsets
• Axis limits

This is what separates generic code viewing from more complete machine verification.

SECTION 99 — THE IDEAL CNC PROGRAM VERIFICATION PLATFORM

A comprehensive platform could combine:

G-CODE SEARCH

Understand individual commands.

G-CODE VIEWER

Inspect programmed geometry.

MODAL-STATE ANALYZER

Track active modes.

SUBPROGRAM DEBUGGER

Trace M98/M99 and related calls.

MACRO DEBUGGER

Evaluate variables and loops.

ARC CALCULATOR

Validate G02/G03 geometry.

DRILLING CYCLE VIEWER

Understand canned-cycle movements.

PROGRAM DIFF

Compare revisions.

CONTROLLER COMPATIBILITY DATABASE

Identify supported functions.

MACHINE SIMULATION

Verify modeled machine movement.

ALARM KNOWLEDGE BASE

Connect errors with troubleshooting information.

Each feature should clearly identify whether it is an actual working tool, an educational reference, or a planned capability.

SECTION 100 — THE PROFESSIONAL CNC VERIFICATION FORMULA

IDENTIFY THE CONTROLLER

↓

VERIFY THE PROGRAM DIALECT

↓

CHECK THE NC SYNTAX

↓

TRACK MODAL STATES

↓

VERIFY WORK OFFSETS

↓

VERIFY TOOL DATA

↓

TRACE SUBPROGRAMS

↓

EVALUATE MACROS

↓

VISUALIZE THE TOOLPATH

↓

CHECK RAPID MOVES

↓

SIMULATE STOCK AND FIXTURES

↓

VERIFY MACHINE KINEMATICS

↓

REVIEW WARNINGS

↓

PERFORM APPROVED MACHINE PROVE-OUT

↓

INSPECT THE RESULT

FINAL CNC SIMULATION QUICK REFERENCE

Feature	What it helps verify	Main limitation
G-code viewer	Basic motion geometry	Limited physical context
Syntax checker	Supported code format	Cannot prove safe motion
Modal-state analyzer	Active G-code modes	Requires accurate dialect
Arc calculator	G02/G03 geometry	Controller conventions vary
Canned-cycle viewer	Drilling sequence	Cycles vary by control
Subprogram debugger	Call and return logic	Needs all referenced programs
Macro interpreter	Variables and loops	System state may be unavailable
Toolpath backplot	Programmed path	Does not model all collisions
Stock simulation	Material removal	Depends on tool/stock models
Machine simulation	Machine-axis movement	Requires accurate kinematics
Digital twin	Specific machine behavior	Model fidelity varies
AI code analysis	Explanations and warnings	Can make incorrect assumptions

CONCLUSION — SIMULATE THE CODE, VERIFY THE MACHINE

CNC simulation is one of the most valuable tools in modern manufacturing, but its effectiveness depends on understanding what is being simulated.

A simple G-code viewer helps you understand motion.

A modal-state analyzer helps you understand programming context.

A subprogram debugger helps you understand execution flow.

A macro interpreter helps you understand calculated behavior.

A stock simulator helps you understand material removal.

A machine-aware simulator helps you understand the behavior of a modeled machine configuration.

No single verification method replaces the others.

THE PROFESSIONAL STANDARD:

CHECK THE CODE.

UNDERSTAND THE CONTROLLER.

VERIFY THE OFFSETS.

TRACE THE LOGIC.

SIMULATE THE TOOLPATH.

CHECK THE PHYSICAL SETUP.

PROVE OUT THE PROGRAM.

THEN MACHINE.

2026 Edition — CNC G-Code Simulation, Toolpath Visualization, FANUC and Haas Programming, M98/M99 Debugging, Macro Verification, Collision Detection and Digital Twin Reference.