Wrong Units or Decimal Format: Off by a Factor of 1000

One wrong mode word, and the whole part comes out at a thousand times the size

Of all the ways a G-code program can be wrong, this is the one with the most spectacular failure mode. Get the units or the number format wrong and every coordinate in the program is off — not by a little, but by a factor. A part meant to be 25.4 mm comes out at 25400, or at 0.0254. Depending on which way the error runs, you get a wildly oversized part, a part machined into nothing, or a rapid move that slams the machine to a hard limit at full speed.

And like the other quiet killers, the program itself often looks perfectly reasonable. The numbers are all there, the syntax is clean. The mistake isn't in any single line — it's in the scale the control reads them at.

The two ways it happens

Inch vs. metric (G20 / G21). The program is written in one unit system and run under the other. A metric program executed in inch mode, or vice versa, mis-scales every coordinate by 25.4. The classic cause: a program or subprogram that assumes a units mode without commanding it, run on a machine whose active mode was left set by the previous job.

Decimal-point format. This is the factor-of-1000 killer. Some controls and older programs interpret a number without an explicit decimal point differently than one with it — a value like X1000 may be read as 1.000 or as 1000. depending on the control's format setting and whether the decimal is present. Mix conventions — a hand edit that drops a decimal point, a post set to the wrong output format, code moved between controls with different format rules — and a coordinate silently shifts by three orders of magnitude.

Both share a root cause that has nothing to do with the geometry: the program's numbers are fine, but the mode in which the control interprets them is wrong.

Why this slips through until it's too late

It reads as valid. There's no syntax error to flag. X1000 is a legal word; G20 and G21 are both legal. Nothing about the text is malformed — the program will load and run.

Eyeballing the listing doesn't reveal it. A programmer scanning the code sees plausible numbers. The error is only visible when those numbers are interpreted at the wrong scale, which happens on the control, at run time — not on the page.

CAM sim shows the intended scale. If the program came from CAM, the CAM's own simulation renders it at the units the CAM used — so it looks correct. The mismatch only appears when the real program is executed under the real control's active units and format settings, which is precisely what a CAM toolpath simulation doesn't reproduce.

The result is an error that stays invisible right up until the machine moves — at which point it announces itself as a scrapped part, or a full-speed rapid into a limit.

Where Eureka 3X Pro fits

Eureka 3X Pro simulates the actual program against a controller-accurate twin, interpreting units and number format the way the control will. A factor-of-1000 or factor-of-25.4 error doesn't hide in that simulation — it's the most obvious thing on screen. The part is suddenly a thousand times too big for the stock, or the toolpath vanishes into a speck, or a rapid drives straight off the end of the machine's travel. What's nearly impossible to spot in a text listing becomes impossible to miss in a controller-accurate run.

This is verification catching an error before it becomes an event. On the machine, a units or format mistake is a crash or a scrap part; in the simulation, it's a glaringly wrong picture you catch in seconds — and fix before loading the program. It sits in the same family as the other "the code looks fine, the result isn't" failures: the only reliable check is to run the real program the way the control runs it, and look at what actually happens.

Take a program that's been moved between machines, hand-edited, or run through an unfamiliar post — the situations where units and format mismatches creep in — and simulate it in Eureka 3X Pro. If the scale is wrong, you'll see it instantly, on the twin, instead of at full rapid on the real machine.

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

FAQ

How can a program be off by a factor of 1000? Usually a decimal-format mismatch: on some controls a number without an explicit decimal point is interpreted differently than one with it, so a value like X1000 can be read as 1.000 or 1000. depending on the format setting. Mix conventions and a coordinate shifts by three orders of magnitude — with no syntax error to warn you.

What causes an inch/metric mix-up? A program written for one units mode (G20 inch / G21 metric) run under the other — often because the program assumes a mode without commanding it, and the machine was left in the other mode by the previous job. Every coordinate is then mis-scaled by 25.4.

Why doesn't my CAM simulation catch it? CAM simulation renders the program at the units the CAM used, so it looks correct. The mismatch only appears when the real program executes under the control's active units and format settings — which a CAM toolpath simulation doesn't reproduce.

Will this crash the machine or just scrap the part? Either, depending on which way the error runs. Scaling up can send a rapid off the end of travel at full speed; scaling down can machine the part into nothing. Both are avoidable by running the program on a controller-accurate twin first.

Does Eureka 3X Pro catch this on hand-written programs? Yes. It reads the actual .nc and interprets units and format the way the control will, so the error shows up regardless of whether a CAM system or a person wrote the program.

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