G43 Tool Length Compensation: Why It's the Most Dangerous Line in Your CNC Program

Every experienced CNC programmer knows what G43 does.

G43 activates tool length compensation. It tells the controller how far the tool tip extends from the spindle nose, so that Z-axis positions in the program correspond to the actual position of the cutting edge rather than the gauge line of the spindle. Without it, the machine has no idea how long the tool is. With it, every Z move is automatically corrected for the specific tool in the spindle.

This is not advanced knowledge. G43 is covered in every CNC programming course, every controller manual, every introductory tutorial. It is one of the first codes a new programmer learns.

And it is still one of the most common causes of machine crashes in production shops.

Not because programmers forget what G43 is. Because G43 errors are invisible — to the programmer reading the code, to the CAM simulation, and often to the operator at the machine — until the Z axis moves somewhere it should not go.

This article explains exactly where those invisible errors hide, why they survive every standard verification method, and how to catch them before the machine does.

What G43 Actually Does — and Why the Controller State Matters

G43 is a modal code. Once activated, it remains active until canceled with G49 or replaced by another G43 call with a different H address. The controller applies the stored offset value to every Z-axis move until the compensation is explicitly canceled.

This modality is both the feature and the risk.

When G43 H01 is active, the controller adds the value stored in tool offset register H01 to every commanded Z position. If H01 contains 125.000 (a tool 125mm long), a command of G01 Z-10.000 moves the spindle nose to Z-10.000 + 125.000 = Z115.000 in machine coordinates — which positions the tool tip at the programmed Z-10.000 relative to the work surface.

Remove G43, and the same command moves the spindle nose to Z-10.000 in machine coordinates. The tool tip, 125mm below the spindle nose, arrives at Z-10.000 - 125.000 = Z-135.000 — 125mm below where the program intended, and almost certainly into the workpiece, the fixture, or the machine table.

This is the G43 crash in its simplest form: Z compensation not active, tool moves to the programmed Z position relative to the wrong reference, spindle nose arrives where the tool tip was supposed to be.

The depth of the crash equals the length of the tool. For a short endmill, this might be 50mm of unexpected travel. For a long boring bar or a drill, it can exceed 200mm. At rapid traverse rate.

The Five G43 Errors That Actually Crash Machines

1. Missing G43 After Tool Change

This is the most common G43 crash scenario, and the most counterintuitive — because the programmer did not forget G43 entirely. The program has correct G43 calls. They just are not where the tool change left the machine.

The typical sequence in a multi-tool program:

T01 M06
G43 H01 Z100.    (length comp for tool 1 - correct)
... machining operations ...
G49 G00 Z200.    (cancel compensation, retract)

T02 M06
G00 X50. Y30.    (XY positioning - safe)
G01 Z-15. F200.  (CRASH - G43 not yet activated for tool 2)
G43 H02 Z5.      (compensation called too late)

The programmer intended to activate G43 for tool 2 before cutting. But a rapid XY positioning move was inserted before the G43 call, and then a plunge move was written before the compensation was active. The program reads logically when scanned line by line — the G43 H02 is there, it just appears one block too late.

In the CAM simulation, this program shows the toolpath correctly — the simulation applies compensation based on the tool model, not the sequence of G-code blocks. In the G-code file, the plunge at Z-15 executes against the machine gauge line before compensation is active.

2. Wrong H Address

G43 H01 and G43 H02 look nearly identical in a program. The difference — one digit in the H address — determines which offset register the controller reads. If H01 contains the length of a 50mm endmill and H02 contains the length of a 180mm drill, calling the wrong one produces a Z position error of 130mm.

Wrong H addresses occur in several ways:

• Manual program editing. A programmer copies a tool section from another program and edits the tool number but forgets to update the H address. T02 M06 followed by G43 H01 Z100 uses tool 2 with tool 1's length compensation.
• Post-processor misconfiguration. A post-processor that is configured to use a different H numbering scheme than the machine's tool table — or that does not increment H addresses correctly across tool changes — outputs systematically wrong H values that look correct in the code but reference the wrong register.
• Tool table mismatch. The program calls G43 H03 expecting the length of a 12mm drill stored in H03. An operator changed tool 3 to a different length drill and updated the tool table but did not update the offset in H03. The H address is correct. The value it references is wrong.

All three scenarios produce the same result at runtime — the wrong Z compensation is applied — and all three are invisible when reading the G-code. The H address looks correct. The offset table is not visible in the program file.

3. G43 Applied After the Z Move Toward the Part

G43 applies the offset on the next Z-axis move after the command is issued. If the tool is already close to the workpiece when G43 is called, the sudden application of the full tool length offset to the next Z move produces an instantaneous shift in Z position — toward the part.

T01 M06
G00 X0. Y0. Z10.  (rapid to Z10 - already near the part)
G43 H01 Z5.       (applies 125mm offset on a move from Z10 to Z5 
                   - actual Z shift: 120mm downward)

The programmer intended G43 to be a safe activation step. Because the tool was already near the work surface when G43 was called, the compensation application itself produced the crash.

The correct sequence activates G43 while the tool is at a safe height — typically at the machine Z home position or a high clearance plane — so the full offset is applied with the tool well clear of any obstruction.

4. G49 in the Wrong Place

G49 cancels tool length compensation. It is standard practice in the program header as a safety reset — ensuring that compensation from a previous program run is not still active. In this context, G49 is correct and important.

The problem occurs when G49 appears mid-program, between operations, while the tool is still within the work envelope. A program that calls G49 as part of a retract sequence before a tool change, but that then executes an additional Z move before the tool has fully cleared the part, loses compensation mid-retract.

G00 Z50.      (retract - compensation still active, tool tip at Z50)
G49           (cancel compensation - spindle nose now at Z50, 
               tool tip at Z50 minus tool length)
G00 Z100.     (additional retract - but now the Z reference has shifted 
               by the full tool length)
T02 M06       (tool change - but Z position is wrong)

After G49, the relationship between commanded Z positions and actual tool tip positions changes by the full tool length. Any subsequent move before the next G43 call uses the wrong reference — which may position the tool tip anywhere from well above the part to well inside it, depending on the tool length and the commanded Z value.

5. Modal Compensation Inherited from the Previous Program

CNC controllers do not reset modal states between programs. If the previous program ended with G43 still active — no G49 call, or G49 called before the final retract rather than after — the compensation from that tool remains active when the next program begins.

The next program's first tool may have a completely different length than the tool that was in the spindle when the previous program ended. If the next program begins with a Z move before its own G43 call — or if it relies on the safety block's G49 to cancel the inherited compensation but issues a Z move before that block executes — the first move of the new program uses the wrong compensation.

This is particularly insidious because it is a setup-dependent error. The program may run correctly when the machine is started fresh or when it follows a specific previous program. It fails only when run in a particular sequence — which may not be discovered until a production run where programs are executed in a different order than during prove-out.

Why Standard Verification Methods Do Not Catch These Errors

The CAM Simulation

CAM simulation applies tool length compensation based on the tool model in the CAM system, not based on the G43 H address in the posted G-code. The simulation assumes that the correct compensation is active for each operation — because it knows which tool is assigned to each operation. It does not read the G43 blocks in the NC file or check whether they appear in the correct sequence, reference the correct H address, or are active at the moment of each Z move.

A program with a missing G43 after a tool change shows the correct toolpath in the CAM simulation, because the simulation applies the correct compensation regardless. The G-code has no compensation. The simulation shows it as if compensation is present.

Single Block Mode and Dry Run

Single block mode and dry run execute the G-code on the machine, one block at a time. They catch errors that produce visible, observable behavior — a rapid move toward a visible fixture, an obviously wrong XY position.

They are significantly less reliable for G43 errors, for two reasons:

• The error manifests as a wrong Z position, which is difficult to observe. The Z axis of a machining center moves vertically. Unless the operator is watching the Z position display and knows what value to expect at each moment in the program, an incorrect Z offset may not be visually apparent until the tool is already at the wrong position. At dry run speed, the time between the wrong Z position and the collision is milliseconds.
• The error depends on the machine state at the moment of execution. A wrong H address produces an error whose magnitude is the difference between two offset register values — which may be small enough that the tool appears to be in approximately the right position during dry run. In production, if the tool in H02 is replaced with a significantly different length, the same H address error produces a much larger Z deviation.

Reading the Code

G43 errors in the H address and in sequencing look correct when the code is read line by line. G43 H02 is syntactically valid. T02 M06 followed by G43 H02 looks like correct tool change programming. The error is in the relationship between the H address and the offset table — information that is not in the G-code file — or in the execution sequence relative to other blocks — which requires understanding the full program state at each point, not just the block in isolation.

What G43 Errors Look Like in Simulation

A G-code simulator that executes the posted file against a complete machine model — with the actual tool table values, the correct machine Z reference, and the full program state at each block — makes G43 errors immediately visible.

• Missing G43 after tool change: The simulated tool tip arrives at Z-15 relative to the spindle nose reference, 125mm below the intended position. The collision with the workpiece or fixture is visible on screen before the program runs.
• Wrong H address: The simulated Z position shifts by the difference between the correct and incorrect offset values. If H01 = 50mm and H02 = 180mm, calling G43 H01 for tool 2 produces a Z error of 130mm — the tool tip appears 130mm above where it should be, and every cut in that operation removes no material.
• G43 after the first Z move: The simulation shows the tool tip at the correct Z position for the first block (no compensation), then a sudden shift when G43 activates on the second block — which, if the tool is near the work surface, appears as the tool tip moving through the workpiece or fixture.
• Inherited modal compensation: The simulation, configured to start with the modal state left by the previous program, shows the wrong Z reference from the first block of the new program — making the inherited state error visible before the second program runs.

In each case, the error is visible as a clear geometric discrepancy between where the simulated tool tip is and where it should be, before the program touches the machine.

Eureka 3X Pro: G43 Errors Caught Before Cycle Start

Eureka 3X Pro simulates the actual posted G-code against a digital twin of your 3-axis CNC machine, including the tool table, the machine Z reference, and the full program state at each block.

G43 is executed as the controller executes it — sequentially, in the order it appears in the G-code, using the H address specified in the program to look up the offset value from the tool table. The simulation does not assume correct compensation based on the tool model. It reads the G43 block, applies the specified H value from the configured tool table, and positions the simulated tool tip accordingly.

This means every G43 error listed in this article is visible in Eureka before the program runs:

• A missing G43 shows the tool at the wrong Z reference
• A wrong H address shows the tool at an incorrect Z depth for every operation in that tool section
• G43 applied after a Z move shows the compensation shift mid-approach
• G49 in the wrong place shows the Z reference change at the moment of cancellation
• Inherited modal state errors are visible from the first block of the program

When the simulation shows a G43 error, you pause, fix the G-code in the integrated editor — correct the H address, move the G43 call before the first Z move, add the missing G43 block — and resume from the same point. The corrected program is verified in the same session before going to the machine.

Frequently Asked Questions

I always use G43 in my programs. Why am I still getting crashes? The presence of G43 in the program is not sufficient — its position relative to the first Z move for each tool, and the correctness of the H address it references, determine whether compensation is applied correctly. A G43 call after the first Z move toward the part, or with the wrong H address, produces a crash despite the code being present. Verification requires checking the execution sequence, not just the presence of the code.

My post-processor generates G43 automatically. Can I trust it? Post-processors generate G43 based on their configuration and the tool assignments in the CAM system. The H address the post generates may not match your machine's tool table numbering convention, or may be correct for a standard setup but wrong for a specific program where tools are not in their default positions. Verifying the post output — not just trusting that the post generates correct code — is the only reliable check.

Is G49 necessary at the end of every tool section? G49 is necessary before tool changes to ensure that compensation from the previous tool does not carry over to the tool change sequence. It is also standard in the program header as a safety reset. What matters is placement: G49 should cancel compensation after the tool has fully retracted to a safe Z position, not before. A G49 call followed by additional Z motion before the next G43 uses an uncompensated Z reference for those moves.

Can I test G43 behavior with dry run before I run the program? Dry run executes the G-code at a modified feed rate. It will show the wrong Z position produced by a G43 error, but the operator must be watching the Z position display and must know what value to expect at each step. In practice, G43 errors during dry run are often not caught until the tool reaches a visibly wrong position — which may be at the workpiece or fixture. Simulation shows the wrong position before execution begins, without occupying the machine.

What is the difference between G43 H0 and G49? G43 H0 activates tool length compensation using offset register 0, which is typically zero — effectively canceling the active compensation without changing the modal state. G49 explicitly cancels the G43/G44 modal code. Both achieve similar results in most situations, but G49 is the explicit cancellation and is preferred for clarity. Some post-processors use G43 H0 as a cancellation method; either is acceptable as long as it is used correctly in sequence.

My program works correctly for the first few parts and then crashes on the tool change. Why? This is a classic symptom of a tool table state error. The first few parts run with a specific tool table configuration. An operator changes a tool between parts, updates the spindle but not the offset table (or updates the offset but not the H value), and the discrepancy only becomes critical when a specific operation reaches the wrong Z depth. Alternatively, a program that runs correctly in one execution order fails when run in a different sequence due to inherited modal state. Both require examination of the G43 H address and the offset table state at the moment of each tool change, not just at program start.