Debug G-Code the Way Developers Debug Code

You wouldn't troubleshoot software by running it in production. So why debug G-code on the spindle?

A programmer chasing a bug in software sets a breakpoint, steps through line by line, and watches the program's state change until the mistake reveals itself. A machinist chasing a bug in a G-code program usually does something far more expensive: loads it on the machine, runs it in single block with a finger on the feed hold, and watches metal — hoping to hit the stop before the crash, not after.

That's not troubleshooting. That's defusing a bomb with the timer running. There's a better way, and it's the way every other kind of program gets debugged.

What "debugging G-code" actually means

The reason G-code feels impossible to debug is that on a real control you can't see why the machine is about to do something — you only see it move. The information that would explain the move is hidden: the active modal codes, the current work offset, the tool-length value in play, the value a macro variable resolved to on this pass. By the time the axis moves, it's too late to inspect any of it.

A real debugger surfaces exactly that hidden state, and lets you stop time to look at it:

• Breakpoints. Halt the program at any line — the tool change, the line before the deep plunge, the call into a subprogram — without babysitting every block from the start.
• Line-by-line stepping. Advance one block at a time, forward through the program, watching each move before it happens rather than after.
• Live controller state. At every stop, see what the control sees: active G/M modal codes, the current G54–G59 work offset, tool and length offset in effect, absolute and work-coordinate position, spindle and feed state.
• Variable and macro inspection. For parametric programs, watch what #100 or a Q-parameter actually evaluated to on this iteration — the single hardest thing to reason about from a static listing.

This turns "why is it doing that?" from a question you answer by crashing into one you answer by looking.

Why single-block and dry runs aren't debugging

The shop-floor substitutes for a debugger each fall short in the same way — they cost machine time and still hide the state you need:

• Single block advances one line at a time, but on the real machine — it ties up the spindle, depends on the operator's reflexes, and shows you the motion without showing you the modal state, offset, or variable value that caused it.
• A dry run above the part proves nothing about the logic; it just moves the crash up in Z.
• Reading the listing at a desk can't tell you what a variable resolved to, what offset was active three subprogram calls deep, or which modal state carried over from the previous block.

All three make you infer the controller's state. A debugger just shows it.

Where Eureka 3X Pro fits

Eureka 3X Pro includes an integrated G-code editor with real debugging tools — breakpoints, stepping, and live controller status — running against a controller-accurate twin of your machine. You debug the program the same way you'd debug code: stop it where you're suspicious, inspect the state, find the mistake, fix it in the editor, and resume from that exact point — all off-machine, with nothing at risk.

Two places this earns its keep every week:

• Hand-edited and parametric programs. Macro and subprogram logic is where bugs hide, precisely because you can't see variable values in a static listing. Stepping through with live variable inspection is the fastest way to find the one that drives the tool somewhere it shouldn't go.
• Inherited and legacy code. When you're handed a program someone else wrote and told to "figure out why it crashes," breakpoints and state inspection turn a guessing game into a methodical hunt.

Unlike a CAM simulator, this isn't a one-shot check at the end of programming — it's a tool you keep open while you write and troubleshoot. That's the difference between software you buy for insurance and software you actually use.

Take the program that's been fighting you — the macro that occasionally does something weird, the inherited job nobody fully understands — set a breakpoint, and step into it. You'll find the bug faster than you'd find a parking spot at the machine.

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

FAQ

Can you set breakpoints in G-code? In Eureka 3X Pro, yes. Halt the program at any line and inspect the controller state there, instead of running every block on the machine to reach the one you care about.

How do I debug a macro or parametric (variable-based) program? Step through it and watch the variables resolve. Because the debugger shows what each variable actually evaluated to on this pass, you can see where the logic sends the tool — the thing a static listing can never tell you.

Isn't single block on the machine the same thing? No. Single block advances one line at a time on the real spindle, using machine time and operator reflexes, and it shows you the motion without the modal state, active offset, or variable value behind it. A debugger shows the state and risks nothing.

Can I fix the program and keep going? Yes. Pause, edit the line in the integrated editor, and resume from that point — no re-running from the top.

Does this work on programs my CAM didn't generate? Yes. It reads the actual .nc, so hand-written, edited, and legacy programs debug the same way.

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