Tag: MPCNC

Pimping and using a Mostly Printed CNC Machine

Machine Shop, Software

Drag Knife Calibration: Downforce and Speed

The drag knife faceplant suggested I must pay a bit more attention to fundamentals, so, with a 60° drag knife blade sticking out a reasonable amount, the next step is to see what effect the cutting “depth” (a.k.a. downforce) and speed have on the outcome.

A smidge of GCMC code later:

Drag Knife Cal - depth - overview - Camotics sim
Drag Knife Cal – depth – overview – Camotics sim

It’s not obvious, but each pattern steps downward by 0.5 mm from left to right. With the spring force equal to 375 g + 57 g/mm, the downforce ranges from 400 to 520 g over the five patterns.

Laminated scrap, meet drag knife:

Drag Knife Cal - Depth - as cut
Drag Knife Cal – Depth – as cut

Pulling up on the surrounding scrap left the patterns on the sticky mat:

Drag Knife Cal - Depth - extracted
Drag Knife Cal – Depth – extracted

Which suggested any cutting force would work just fine.

Flushed with success, I cut some speed variations at the minimum depth of Z=-0.5 mm = 400 g:

Drag Knife Cal - Speed - 0.5 mm - as cut
Drag Knife Cal – Speed – 0.5 mm – as cut

The blade cut through the top laminating film, the paper, and some sections of the bottom film, but mostly just scored the latter.

Repeating at Z=-1.5 mm = 460 g didn’t look much different:

Drag Knife Cal - Speed - 1.5 mm - as cut
Drag Knife Cal – Speed – 1.5 mm – as cut

However, the knife completely cut all the patterns:

Drag Knife Cal - Speed - 1.5 mm - extracted
Drag Knife Cal – Speed – 1.5 mm – extracted

As far as I can tell, the cutting speed doesn’t make much difference, although the test pattern is (deliberately) smooth & flowy like the Tek CC deck outlines. I’d been using 1000 mm/min and 2000 mm/min seems scary-fast, so 1500 mm/min may be a good compromise.

The GCMC source code as a GitHub Gist:

// Calibrate Drag Knife - speed & feed
// Ed Nisley - KE4ZNU
// 2020-03 values for MPCNC
//-----
// Dimensions
CutIncr = -0.5mm;
BottomCutZ = -2.5mm;
SpeedRatio = 2.0;
MaxSpeed = 2000mm;
MinSpeed = MaxSpeed / 8;
StripWidth = 10mm;
CornerRadius = StripWidth/2;
PatternSize = StripWidth * [3,3];
PatternSpace = 1.25;
SafeZ = 10.0mm; // above all obstructions
TravelZ = 2.0mm; // within engraving / milling area
FALSE = 0;
TRUE = !FALSE;
if (!isdefined("TestSelect")) {
TestSelect = "Depth";
}
comment("Test Selection: ",TestSelect);
//-----
// One complete pattern
// Centered at ctr, ctr.z=cut depth
function Pattern(ctr) {
local d1 = CornerRadius; // useful relative distances
local d2 = 2*d1;
local d3 = 3*d1;
local d4 = 4*d1;
goto([-,-,TravelZ]); // set up for entry move
goto(head(ctr,2) + [-d2,d3]);
move([ctr.x + d2,-,ctr.z]); // enter to cut depth
arc_cw_r([d1,-d1],d1);
move_r([0,-d4]);
arc_cw_r([-d1,-d1],d1);
move_r([-d4,0]);
arc_cw_r([0,d2],d1);
move_r([d2,0]);
arc_ccw_r([0,d2],d1);
move_r([-d2,0]);
arc_cw_r([0,d2],d1);
move_r([d4,0]); // re-cut entire entry path
goto([-,-,TravelZ]); // exit to surface
// goto(head(ctr,2));
}
//-----
// Start cutting!
goto([-,-,SafeZ]);
goto([0,0,-]);
goto([-,-,TravelZ]);
if (TestSelect == "Depth") {
comment("Depth variations");
s = MaxSpeed / 2;
feedrate(s);
c = [0,0,-]; // initial center at origin
for (c.z = CutIncr; c.z >= BottomCutZ; c.z += CutIncr) {
comment("At: ",c," speed:",s);
Pattern(c);
c.x += PatternSpace * PatternSize.x;
}
}
if (TestSelect == "Speed") {
comment("Speed variations");
c = [0,0,-2mm]; // initial center at origin
for (s = MinSpeed; s <= MaxSpeed; s *= SpeedRatio) {
comment("At: ",c," speed: ",s);
feedrate(s);
Pattern(c);
c.x += PatternSpace * PatternSize.x;
}
}
goto([-,-,SafeZ]);
goto([0,0,-]);
view raw Drag Knife Calibration.gcmc hosted with ❤ by GitHub
Machine Shop

Drag Knife Blade Extension

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:

Drag Knife Blade - 0.5 mm
Drag Knife Blade – 0.5 mm

The blade extends from the LM12UU holder for the MPCNC.

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
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.

Machine Shop

Drag Knife Blade Lengths

The distances from the sharp tip to the top end of the edge, measured parallel to the shank axis:

  • 60° = 1.3 mm
  • 45° = 0.7 mm
  • 30° = 0.6 mm

Here, the angle goes upward from the paper / Tek CC deck / whatever to the shank axis, so the 60° blade at the top of the picture has the longest blade edge.

Drag Knife Blades - unused 60 45 30 degree
Drag Knife Blades – unused 60 45 30 degree

That’s for one trio of blades from a single eBay seller. I expected no consistency between sellers and that’s exactly what I got when I sorted my collection by peering through the microscope:

Drag Knife Blades - inconsistent cap colors
Drag Knife Blades – inconsistent cap colors

Red seems consistently 45°, but blue & yellow caps can cover either 30° or 60° blades. The actual blade angle lies mostly within ±5° of the nominal value, with 45° between 40° and 50°, but I doubt my few samples span the QA space.

The flat shaping the backside of the blade should put the point 0.25 mm from the shank axis and, because the blades are 1.0 mm ⌀, also 0.25 mm from the OD. A few spot measurements suggest the point offset can be up to 0.4 mm from the axis, so any fancy calculations you might think of making seem pretty much irrelevant.

There’s not much practical difference between the 30° (“window tint”) and 45° (“vinyl”) blades, particularly given the angle and offset tolerances, but 60° blades (“card stock”) seem better suited to cutting the 0.3 mm to 0.4 mm thick laminated Tek Circuit Computer decks than the 45° blades I’ve been using.

Machine Shop, Software

GRBL Error 33: Arc Coordinates vs. Decimal Places

The LinuxCNC G2/G3 arc command doc has this to say about numerical precision:

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.

So I normally set GCMC to produce three decimal digits, because its default of eight digits seems excessive for my usual millimeter measurements, and assume whatever G-Code sender I use won’t chop digits off the end in passing. Mistakenly setting bCNC to round at two decimal places showed what happens with fewer digits, as bCNC’s default is four decimal digits.

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
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
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
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.

Machine Shop, Software

GRBL Error 33: G-Code Arc Tolerances

After figuring out how two-place decimal fractions caused this blooper, I had to poke into the debris field surrounding the crash:

Tek CC - top deck - failed arcs
Tek CC – top deck – failed arcs

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
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
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
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
Spreadsheet – GCMC 2 digit – suppress third failed arc

Two digits definitely aren’t enough!

Machine Shop, Software

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:

Tek CC - top deck - failed arcs
Tek CC – top deck – failed arcs

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
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
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 …

Machine Shop

Diamond Drag Tool Wear

The diamond drag tool now in the MPCNC LM3UU holder has appeared in several holders and suffered considerable misuse along the way:

Diamond Drag Tool tip - MPCNC
Diamond Drag Tool tip – MPCNC

A closer look at the spalled section on the flank:

Diamond Drag Tool tip - MPCNC - detail
Diamond Drag Tool tip – MPCNC – detail

The tool in the (much better) CNC 3018XL LM6UU holder has engraved mostly plastic, plus a few hard drive platters, and seems only slightly rounded:

Diamond Drag Tool tip - CNC 3018
Diamond Drag Tool tip – CNC 3018

An unused tip comes to a neat point:

Diamond Drag Tool tip - unused A
Diamond Drag Tool tip – unused A

As does its companion, arriving in a twofer deal from halfway around the planet:

Diamond Drag Tool tip - unused B
Diamond Drag Tool tip – unused B

They’re brazed on 3 mm OD shanks and ground to a 60° included angle.