bCNC Rounding vs. G-Code Arcs: GRBL Error 33

While cutting the top deck of the Pickett-flavored Tek Circuit Computer on the MPCNC, this happened:

I traced the off-center circle with a marker to make it more visible, as it’s the drag knife cut that should have been the exit move after completing the window.

Huh. It never did that before …

The bCNC plot looked fine, but the Terminal log showed three Error 33 reports:

The GRBL doc has this to say about Error 33:

The motion command has an invalid target. G2, G3, and G38.2 generates this error, if the arc is impossible to generate or if the probe target is the current position.

The error messages don’t occur immediately after the failing G2/G3 command, because bCNC sends enough commands to keep the GRBL serial input buffer topped off. After GRBL sends the error message, it continues chewing its way through the buffer and, when bCNC notices the first error, it stops sending more G-Code commands and shudders to a stop.

The great thing about Free Software is that when it breaks, you have all the pieces. Looking into the GRBL source code provides a definition of Error 33:

// [G2/3 Offset-Mode Errors]: No axis words and/or offsets in selected plane. The radius to the current
//   point and the radius to the target point differs more than 0.002mm (EMC def. 0.5mm OR 0.005mm and 0.1% radius).

Which doesn’t quite match the code, but it’s close enough:

// Compute difference between current location and target radii for final error-checks.
            float delta_r = fabs(target_r-gc_block.values.r);
            if (delta_r > 0.005) {
              if (delta_r > 0.5) { FAIL(STATUS_GCODE_INVALID_TARGET); } // [Arc definition error] > 0.5mm
              if (delta_r > (0.001*gc_block.values.r)) { FAIL(STATUS_GCODE_INVALID_TARGET); } // [Arc definition error] > 0.005mm AND 0.1% radius
            }

I’ve drag-knifed maybe a dozen top decks with no problem, so figuring out what broke took a while.

The key turned out to be in the Terminal log, where all coordinates in the G-Code commands had, at most, two decimal places. The GCMC program producing the G-Code emits three decimal places, so bCNC rounded off a digit before squirting commands to GRBL.

After more searching, it seems I’d told bCNC to do exactly that:

Perhaps I’d mistakenly set “Decimal digits” instead of “DRO Zero padding” when I reduced the DRO resolution from three decimals to two? It’s set to “2” in the CNC 3018XL configuration, so this seems like a typical one-off brain fade.

GRBL doesn’t execute invalid commands, so the tool position remains at the end of the window’s outer perimeter while the next two arc commands fail, because their center offsets produced completely invalid radii.

The three failed arc commands should have cut the right end of the window, the inner side, and the left end, but left the tool position unchanged. The final arc command should have withdrawn the blade along the outer side of the window, but became a complete circle, with the commanded end point equal to the leftover starting point at the same radius from the deck center.

The same G-Code file fails consistently with Decimal digits = 2 and runs perfectly with Decimal digits = 3, so at least I know a good fix.

Protip: Keep your hands away from moving machinery, because you never know what might happen!

This seems sufficiently obscure to merit becoming a Digital Machinist column. More analysis is in order …