Ed Nisley's Blog: Shop notes, electronics, firmware, machinery, 3D printing, laser cuttery, and curiosities. Contents: 100% human thinking, 0% AI slop.
The battered corner of my bench scale shows it’s been knocking around for quite a while, but the drag knife blade tip seems pretty close to the first 0.5 mm division:
Scribbling the blade across a scrap of laminated yellow card stock (about 0.4 mm thick) showed it didn’t cut all the way through the bottom plastic layer, even with the spring mashed flat.
So I screwed it out to 0.7 mm:
Drag Knife Blade – 0.7 mm
The scale isn’t quite parallel to the blade axis and maybe it’s sticking out 0.8 mm; setting a drag knife’s blade extension obviously isn’t an exact science.
In any event, another scribble slashed all the way through the laminated deck without gashing the sacrificial cardboard atop my desk, which seems good enough.
One of two new round rubber soaker hoses arrived with a slight crimp, enough to suggest it would crumble at an inopportune moment. Rather than return the hose for something that’s not an obvious failure, I clamped the crimp:
Round Soaker Hose Splice – top
Unlike the clamps for the punctured flat soaker hoses, this one doesn’t need to withstand much pressure and hold back a major leak, so I made the pieces a bit thicker and dispensed with the aluminum backing plates:
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Our Young Engineer recently rented a house, now knows why our sinks have CNC-machined strainers, and asked for something better than the disgusting stainless mesh strainer in the kitchen sink.
Being a doting father, I turned out a pair to get a pretty one:
CNC Sink Strainer – overview
They’re made from the same scrap smoked acrylic as the ones in our sinks:
CNC Sink Strainer
They’re definitely upscale from the (not watertight!) 3D printed version I built for a Digital Machinist column to explain OpenSCAD modeling:
Strainer plate fill
This time around, though, I rewrote the subtractive design in GCMC, with helical milling for all the holes to eliminate the need to change tools:
Sink Strainer – tool path simulation – CAMotics
They’re done on the Sherline, because it has real clamps:
CNC Sink Strainer – on Sherline
Four tabs eliminated the need to reclamp the stock before cutting the perimeter, but I should have ramped, not plunged, through the final cut between the tabs:
CNC Sink Strainer – tab surface fracture
The handles come from the same chunk of hex acrylic as before, eyeballed to length, tapped 8-32, and secured with acrylic adhesive.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
When programming arcs an error due to rounding can result from using a precision of less than 4 decimal places (0.0000) for inch and less than 3 decimal places (0.000) for millimeters.
A closer look at the coordinates in the lower right part of the spreadsheets (from yesterday) shows the limited accuracy with two decimal digits:
Spreadsheet – GCMC 2 digit – full path – detail
The red blocks mark the first failing arc, where the relative error falls out of tolerance. If GRBL were less fussy (which it should not be), then the next arcs would proceed as shown.
Rounding to three decimal digits pushes the errors into to the third place, with the yellow highlight marking the worst errors:
Spreadsheet – GCMC 3 digit – detail
As you should expect, the smallest arcs have the largest relative errors, although they’re now well within GRBL’s (and LinuxCNC’s, for that matter) limits.
Rounding to four decimal digits makes the errors vanishingly small:
Spreadsheet – GCMC 4 digit – detail
So, by and large, don’t scrimp on the decimal digits … but we knew that already.
I’d been setting GRBL to produce three decimal places, but now I’m using four. Adding a few characters to each G-Code command reduces the number of commands fitting into GRBL’s buffer space, but bCNC normally keeps it around 90% full, so the path planner should remain perfectly happy.
The bCNC Terminal trace stops at the first failure, so I set GCMC to produce two-place fractions (“Number of decimals less than 3 severely limits accuracy”), then rammed the NGC file’s G-Code into a spreadsheet:
Spreadsheet – GCMC 2 digit – full path
The last two columns (perhaps you must open the image in a new tab to see the whole thing) compute the GRBL error values: the absolute difference between the two radii and that difference as a fraction of the radius. The R Error header under Start should be X, of course; I’ll regenerate the images for the DM column.
The reduced accuracy of the two-digit fractions triggers the error marked by the red cells, where the radii differ by 0.0082 mm (>0.005) and the relative error is 0.17% (>0.1%).
Suppressing the first failed arc by passing the same starting point to the next arc simulates the second failure:
Spreadsheet – GCMC 2 digit – suppress first failed arc
Similarly, the third arc from the same point fails:
Spreadsheet – GCMC 2 digit – suppress second failed arc
The fourth arc becomes a full circle and produces the circular gash across the deck:
Spreadsheet – GCMC 2 digit – suppress third failed arc
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:
Failed arc command – bCNC screen – terminal and plot
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:
bCNC Config – Round 2 digits – highlighted
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 …
The Smell of Molten Projects in the Morning 