Forgotten Modals: When Leftover State Crashes the Next Move

G-code has a memory — and that memory is what bites you

Most G-codes are modal: you set a mode once and it stays active, block after block, until something changes it. That's what makes G-code efficient — you don't re-declare absolute mode or the feed type on every line. But it's also a quiet trap, because a mode you set (or inherited) a hundred lines ago is still in force now, and the block in front of you behaves according to state you can no longer see.

Most "why did it do that?" crashes aren't a bad line. They're a good line executing under a leftover mode from earlier — a modal that should have been cancelled and wasn't.

The usual culprits

Each of these is a mode that quietly carries forward and turns a routine block into an unintended one:

• G91 left active (incremental). A block of incremental moves that never returned to G90, so the next operation's positions — written as absolute — are interpreted as distances from wherever the tool happens to be. The result is a runaway move to somewhere far off, at rapid.
• G93 inverse-time feed not cancelled. Inverse-time feed reinterprets every F value as "finish this move in 1/F minutes." Leave it on when the next moves expect a normal feed (G94), and feeds become wildly wrong — either a crawl or a lurch — and the machine may alarm or gouge.
• G40/G49 not reset (comp left on). Cutter compensation or tool-length comp left active into a section that assumes it's off (or vice versa) shifts the path by a radius or a length — a gouge, a wrong-size feature, or a crash on the approach.
• G54–G59 not restored. An operation that switched work offset and never switched back cuts the next setup at the wrong origin — correct geometry, wrong place, into the fixture.
• Plane or units modals carried over. A stray G18/G19, or an inch/metric mode left from a previous program, and cycles and arcs execute in a frame or scale you didn't intend.

The pattern is always the same: the dangerous block is written correctly for the mode the programmer assumed — and executes under a different mode that's still hanging around.

Why this is so hard to catch by eye

Modal errors are invisible precisely because the cause and the symptom are far apart. The block that crashes is fine in isolation; the mistake is the absence of a cancel line somewhere earlier. Reading the crashing block tells you nothing, because what's wrong isn't there — it's the modal state carried into it, which no single line displays.

This is also why importing a subprogram, reusing a block from another program, or hand-editing a section is so prone to it: the borrowed code assumed one modal context and now runs in another. And a CAM simulation, running on its own toolpath with its own assumptions, doesn't necessarily reproduce the exact modal state of the posted, edited program the machine will actually run.

Shops defend against this with a modal reset block at the start of a program or operation — something like G90 G94 G17 G40 G49 G80 G69 — that forces a known safe state. It's good practice and it prevents a lot of this. But it doesn't help with a modal left dangling mid-program, and it relies on the block being there and correct in the first place. The only way to know the real modal state at every point is to track it the way the control does.

Where Eureka 3X Pro fits

Eureka 3X Pro simulates the posted or hand-written program against a controller-accurate twin, tracking modal state exactly as the control carries it — so a block that executes under a leftover G91, an un-cancelled G93, a stale comp mode, or the wrong active offset does, in the simulation, exactly what it would do on the machine. The runaway incremental move, the inverse-time feed disaster, the gouge from leftover compensation: all of them surface on the twin, with your real stock and fixtures in place, before the tool moves for real.

Because it carries the same modal memory the control does, it catches the class of error where the mistake isn't in the line that fails — it's in the state that reached it. For a Fusion or Mastercam user, the posted program comes across through the cascade post exactly as it'll run; for hand-editors, you open the .nc directly — either way, the modal state you verify is the one the machine will actually execute.

Take a program that stitches together subprograms or reused blocks — the situations where modal state gets muddled — and run it through the twin. Watching each move execute under the real accumulated modal state, before the spindle turns, is how leftover-modal crashes get caught at a desk.

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

FAQ

What does "modal" mean in G-code? A modal code stays active until changed. G90 (absolute), G94 (feed per minute), G54 (work offset), and cutter/tool comp all persist block after block. That persistence is efficient — and dangerous when a mode is left active into a section that assumed a different one.

Why did my machine suddenly run extremely slow, or lurch? A common cause is G93 inverse-time feed left active — every F value is then reinterpreted as a time, so feeds go wildly wrong until G94 restores normal feed-per-minute.

Why did an absolute move run away to the wrong place? Often G91 left active from an earlier incremental section — the absolute positions are then read as distances from the current point, sending the tool somewhere unintended at rapid.

Does a safety reset block fix this? A modal reset block (e.g. G90 G94 G17 G40 G49 G80) at the start of a program or operation prevents a lot of it, and it's good practice. But it doesn't catch a modal left dangling mid-program, and it depends on being present and correct. Verifying the real modal state throughout the program is the reliable check.

How does Eureka 3X Pro catch modal errors? It tracks modal state the way the control does, so every block executes under the real accumulated state in simulation. A leftover mode produces the same wrong behavior on the twin that it would on the machine — visible before you cut.

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