The Most Dangerous Fanuc Canned Cycle Mistakes

One line, a dozen behaviors — and one wrong parameter is all it takes

Canned cycles are the most efficient thing in G-code and, for the same reason, among the most dangerous. A single G83 line carries a retract mode, an R plane, a final depth, a peck increment, a dwell, a feed — a whole stack of decisions compressed into a few words. Get any one of them wrong and the cycle still runs perfectly; it just runs wrong, repeating the mistake at every position you listed. Some of these errors crash the machine. Others quietly scrap the part. The worst ones do the first while looking, on paper, exactly like the ones that don't.

Below are the ten that cause the most crashes and scrap in practice — why each is dangerous, and the common thread that ties them together.

1. Forgetting G80 (not cancelling the cycle)

A canned cycle stays active until G80 cancels it. Forget it, and the next positioning moves are still treated as cycle points — so the tool plunges at every rapid position you thought was just a move. A modal cycle left running is one of the classic ways a program drills holes exactly where you never wanted them. Crash / scrap, depending on where those phantom holes land.

2. Wrong G98/G99 retract mode

G98 retracts to the initial level, above the fixture; G99 retracts only to the low R plane. Fine on open stock, G99 drives the tool into any clamp or feature standing above the R plane as it transits between holes. Every hole is drilled correctly — the crash happens in between. Crash. (Covered in depth in Wrong Retract Mode: G98 vs G99.)

3. Incorrect R plane

The R plane sets where rapid ends and feed begins. Set it too low and the tool doesn't clear the part or fixture on approach; set it too high and you waste cycle time or, combined with G99, mis-position the retract. An R plane below the top of a clamp is a crash; an R plane inside the material is a broken tool. Crash / broken tool.

4. Wrong drilling depth (Z)

The final Z is the whole point of the cycle, and it's a single number easy to fat-finger or carry over from a copied cycle. Too deep and you punch through into the fixture or table; too shallow and the hole doesn't break through — a scrap part that looks finished. Crash / scrap.

5. Excessive peck depth (Q)

In peck cycles (G83), Q sets how far the tool advances per peck. Too large a Q in a deep or small-diameter hole overwhelms chip evacuation, packs the flutes, and snaps the drill. The hole positions are perfect; the tool breaks off inside one. Broken tool / scrap.

6. Incorrect tapping feed in G84

Tapping feed must match spindle speed and thread pitch exactly — feed equals speed times pitch. Get the feed wrong (or inconsistent with the pitch), and even with rigid tapping engaged you strip the thread or break the tap. Scrap / broken tap. (Related: Rigid Tapping Not Activated: The Missing M29.)

7. Wrong spindle direction

A drill or tap turning the wrong way — an M04 where M03 belonged, or a direction left over from a previous tool — rubs instead of cuts, work-hardens the hole, and destroys the tool. On a tap it's immediate destruction. Broken tool / scrap.

8. Drilling into fixtures due to low retract height

A cousin of the R-plane and G98/G99 problems: a retract height that doesn't clear the fixtures in the setup means the tool transits low and clips a clamp, or plunges where the fixture sits. This is the crash that only appears when the real fixture is in the simulation. Crash.

9. Incorrect dwell (P) in G82

G82 adds a dwell at the bottom for a clean, flat-bottomed hole or counterbore. A wrong P — wrong units, missing decimal, or an absurd value copied from elsewhere — either does nothing useful or parks the tool spinning at depth far too long, burning the tool and the hole. Scrap / tool wear.

10. Copy-pasting a canned cycle without updating its parameters

The meta-mistake that produces most of the nine above. A cycle copied from another program brings its depth, its R plane, its Q, its retract mode — none of which may fit the new job. The syntax is flawless; every parameter is wrong for where it now lives. Anything — crash, broken tool, or scrap.

What ties all ten together

Notice what almost none of these are: a syntax error. Every one of these programs loads and runs. The mistake is never in whether the code is valid — it's in whether the parameter is right for this job, and in how the control executes the cycle with the real fixture in place. That combination is exactly what a text listing can't show you and a toolpath-only simulation doesn't reproduce:

• The dangerous ones (1, 2, 3, 8) are crashes that depend on the fixture — invisible unless your simulation runs the real cycle over the real clamps.
• The others (4, 5, 6, 7, 9, 10) are safe-but-wrong — the machine survives, the part or the tool doesn't, and crash detection never sees them because nothing collides.

Reading the listing won't catch them, because the numbers all look plausible. Single-block on the machine catches them the hard way, one near-miss at a time, on the spindle. The only check that catches all of them before the program runs is to execute the actual cycle the way the control will — with the real fixtures, real R planes, real depths and pecks and dwells — and watch what happens.

Where Eureka 3X Pro fits

Eureka 3X Pro simulates the posted or hand-written program against a controller-accurate twin of your Fanuc-controlled machine, executing each canned cycle — its retract mode, R plane, depth, peck, dwell, and cancellation — the way the control actually will, with your real fixtures in the scene. The modal cycle that never got its G80, the copied G83 with the wrong depth, the G99 that clips a clamp, the tapping feed that strips the thread: all of them surface on the twin, before the tool moves on the real machine.

For a Fusion or Mastercam user, the fixtures, stock, tools, and work origins come across automatically through the cascade post, so the cycles are verified over your real setup, not an empty table. And you get a controller-accurate cycle time from the same run — the number to quote from.

Take your most canned-cycle-heavy program — a drill-and-tap job over clamps is ideal — and run it through Eureka 3X Pro. Watching every cycle execute over your real fixture, before the spindle turns, is how these ten mistakes get caught at a desk instead of at the machine.

Eureka 3X Pro — 30-day free trial, no credit card required.

FAQ

What's the most common canned-cycle mistake? Copy-pasting a cycle without updating its parameters is the root of most of the others — it carries the wrong depth, R plane, peck, or retract mode into a new job where every value looks plausible but fits the old part, not the new one.

Why don't these show up as errors when the program loads? Because they're not syntax errors. The cycle is valid G-code; the problem is that a parameter is wrong for the job, or the control executes the cycle into a fixture. Only running the real cycle on a controller-accurate twin reveals it.

Which of these does collision detection catch? The crashes that depend on the fixture — forgetting G80, wrong G98/G99, a low R plane, a low retract height — but only if the fixture is accurately modeled and placed. The rest (wrong depth, excessive peck, bad tapping feed, wrong spindle direction, bad dwell) don't collide with anything, so collision detection alone misses them.

Does this apply only to Fanuc controls? The specific G-codes here are the Fanuc convention, but the underlying mistakes — wrong retract, wrong depth, un-cancelled cycles, copied parameters — happen on any control with canned cycles. Eureka 3X Pro also emulates Haas, Siemens, and Heidenhain behavior.

Can it check hand-written and edited cycles? Yes. It reads the actual .nc regardless of origin, so hand-typed and edited canned cycles are verified exactly as posted ones.

Run every G-code program risk-free — before it touches your machine.