Advertisements

Posts Tagged MPCNC

MPCNC: Drag Knife Holder Spring Constant vs. Stiction

Sliding a drag knife body in a PETG holder, even after boring the plastic to fit, shows plenty of stiction along 2 mm of travel:

MPCNC - Drag Knife Holder - spring constant

MPCNC – Drag Knife Holder – spring constant

Punching the Z axis downward in 0.5 or 1.0 mm steps produced the lower line at 210 g/mm. Dividing by three springs, each one has a 70 g/mm spring constant, which may come in handy later.

The wavy upper line shows the stiction as the Z axis drops in 0.1 mm steps. The line is eyeballometrically fit to be parallel to the “good” line, but it’s obvious you can’t depend on the Z axis value to put a repeatable force on the knife.

I cranked about a turn onto the three screws to preload the springs and ensure the disk with the knife body settles onto the bottom of the holder:

MPCNC - DW660 adapter drag knife holder - spring loaded

MPCNC – DW660 adapter drag knife holder – spring loaded

The screws are M4×0.7, so one turn should apply about 140 g of preload force to the pen holder. Re-taking a few data points with a 0.5 mm step and more attention to an accurate zero position puts the intercept at 200 g, so the screws may have been slightly tighter than I expected. Close enough, anyway.

The stiction is exquisitely sensitive to the tightness of the two DW660 mount clamp screws (on the black ring), so the orange plastic disk isn’t a rigid body. No surprise there, either.

Loosening the bored slip fit would allow more lateral motion at the tip. Perhaps top-and-bottom Delrin bushings (in a taller mount) would improve the situation? A full-on linear bearing seems excessive, even to me, particularly because I don’t want to bore out a 16 mm shaft for the blade holder.

It’s certainly Good Enough™ as-is for the purpose, as I can set the cut depth to, say, 0.5 mm to apply around 250-ish g of downforce or 1.0 mm for 350-ish g. The key point is having enough Z axis compliance to soak up small  table height variations without needing to scan and apply compensation.

Advertisements

,

1 Comment

Cheap Scale Calibration Check

Before doing another spring constant test with the old Harbor Freight scale, I found deployed my cheap calibration weight sets to verify it displayed the right numbers:

US-Magnum Scale - calibration check

US-Magnum Scale – calibration check

It’s spot on for all weights above 1 g, although I must tap the pan to settle on the reading from above for it get the last 0.1 g right.

Below 1 g, it’s the wrong hammer for the job; I expected no better from it.

,

6 Comments

MPCNC: Drag Knife Holder

My attempt to use a HP 7475A plotter as a vinyl cutter failed due to its 19 g pen load limit:

HP 7475A knife stabilizer - big nut weight

HP 7475A knife stabilizer – big nut weight

The MPCNC, however, can apply plenty of downforce, so I tinkered up a quick-and-dirty adapter to put the drag knife “pen” body into the MPCNC’s standard DW660 router holder:

MPCNC - DW660 adapter drag knife holder - fixed position

MPCNC – DW660 adapter drag knife holder – fixed position

That’s using the DW660 adapter upside-down to get the business end of the knife closer to the platform. The solid model descends from the linear-bearing Sakura pen holder by ruthless pruning.

It didn’t work well at all, because you really need a spring for some vertical compliance and control over the downforce pressure.

Back to the Comfy Chair:

Drag Knife Holder - DW660 Mount - solid model

Drag Knife Holder – DW660 Mount – solid model

A trio of the lightest springs from a 200 piece assortment (in the front left compartment) pushes the upper plate downward against the drag knife’s flange:

MPCNC - DW660 adapter drag knife holder - spring loaded

MPCNC – DW660 adapter drag knife holder – spring loaded

There’s a bit more going on than may be obvious at first glance.

The screws slide in brass tubing press-fit into the upper plate, because otherwise their threads hang up on the usual 3D printed layers inside the (drilled-out) holes. Smaller free-floating brass tubing snippets inside the springs keep them away from the screw threads; the gap between the top of the tubing and the screw head limits the vertical compliance to 3 mm. The screws thread into brass inserts epoxied into the bottom disk, with a dab of low-strength Loctite for stay-put adjustment.

I bored the orange PETG disk to a nice slip fit around the knife body:

DW660 drag knife holder - boring body

DW660 drag knife holder – boring body

The upper plate also required fitting:

DW660 drag knife holder - boring plate

DW660 drag knife holder – boring plate

A few iterations produced reasonably smooth motion over a few millimeters, but it’s definitely not a low-friction / low-stiction drag knife holder. It ought to be good for some proof-of-concept vinyl cutting, though.

The OpenSCAD source code as a GitHub Gist:

 

,

2 Comments

MPCNC: Jogging Keypad for bCNC

The bCNC G-Code sender sends jogging commands to GRBL from an ordinary numeric keypad:

MPCNC - Jogging keypad

MPCNC – Jogging keypad

Unlike the keypads on my streaming radio players, this one requires no configuration at all, because bCNC regards it as just another keyboard input. The catch: you must select any screen element other than a text entry field to have bCNC recognize the keystrokes as “not text”.

You would get the same results from the numeric keys on the right side of a full-size / 104-key plank. I’m using a small “tenkeyless” keyboard, which means I can put the keypad wherever it’s easiest to reach while tweaking the MPCNC.

The ÷10 and ×10 keys along the top row alter the step size by factors of ten, which is pretty much what you need: jog to within a big step of the target, drop to the next lower decade, jog a few more times, maybe drop another decade, jog once, and you’re as close as you need to be with an MPCNC. The -1 and +1 keys aren’t as useful, at least to me: changing from 5 mm to 4 mm or 6 mm doesn’t make much difference.

Jogging to align the spindle (well, a pen or drag knife) with a target using the video camera works really well:

bCNC - Video align

bCNC – Video align

GRBL and bCNC don’t do smooth jogging and the discrete steps aren’t as nifty as the Joggy Thing with LinuxCNC, but it gets the job done.

, ,

4 Comments

Raspberry Pi vs. MicroSD-as-Disk Memory

The MPCNC has bCNC running on a Raspberry Pi, with a Samsung EVO MicroSD card serving as the “hard drive”:

Sandisk Extreme Plus vs. Samsung EVO MicroSD cards

Sandisk Extreme Plus vs. Samsung EVO MicroSD cards

The picture also shows a defunct Sandisk Extreme Plus killed by continuous video recording in my Fly6 bike camera. I later replaced the EVO with a video-rated Samsung card which has been running fine ever since, albeit with the occasional crash-and-reformat expected with “action” cameras.

With that as background, a different Samsung EVO card from the same batch has been running the MPCNC’s Raspberry Pi for about a year. Over the course of a few days last week, the RPi went from an occasional stall to a complete lockup, although waiting for minutes to hours would sometimes resolve the problem. As I’ve learned by now, it’s not a software crash, it’s the controller inside the card suffering from write amplification while trying to move data from failing sectors.

Applying f3write to the card shows the problem:

MPCNC MicroSD - f3write slowdown

MPCNC MicroSD – f3write slowdown

The write speed started out absurdly high as the card’s write cache fills, then slowed to to the flash memory’s ability to absorb data, and eventually ran out of steam during the last few files.

But, as you might not expect, f3read reported the data was fine:

sudo f3read /mnt/part
F3 read 7.0
Copyright (C) 2010 Digirati Internet LTDA.
This is free software; see the source for copying conditions.

                  SECTORS      ok/corrupted/changed/overwritten
Validating file 1.h2w ... 2097152/        0/      0/      0
Validating file 2.h2w ... 2097152/        0/      0/      0
Validating file 3.h2w ... 2097152/        0/      0/      0
Validating file 4.h2w ... 2097152/        0/      0/      0
Validating file 5.h2w ... 2097152/        0/      0/      0
Validating file 6.h2w ... 2097152/        0/      0/      0
Validating file 7.h2w ... 2097152/        0/      0/      0
Validating file 8.h2w ... 2097152/        0/      0/      0
Validating file 9.h2w ... 2097152/        0/      0/      0
Validating file 10.h2w ... 2097152/        0/      0/      0
Validating file 11.h2w ... 2097152/        0/      0/      0
Validating file 12.h2w ... 2097152/        0/      0/      0
Validating file 13.h2w ... 2097152/        0/      0/      0
Validating file 14.h2w ... 2097152/        0/      0/      0
Validating file 15.h2w ... 2097152/        0/      0/      0
Validating file 16.h2w ... 2097152/        0/      0/      0
Validating file 17.h2w ... 2097152/        0/      0/      0
Validating file 18.h2w ... 2097152/        0/      0/      0
Validating file 19.h2w ... 2097152/        0/      0/      0
Validating file 20.h2w ... 2097152/        0/      0/      0
Validating file 21.h2w ... 1322894/        0/      0/      0

  Data OK: 20.63 GB (43265934 sectors)
Data LOST: 0.00 Byte (0 sectors)
	       Corrupted: 0.00 Byte (0 sectors)
	Slightly changed: 0.00 Byte (0 sectors)
	     Overwritten: 0.00 Byte (0 sectors)
Average reading speed: 43.04 MB/s

Obviously, the card’s read speed isn’t affected by the write problems.

Assuming the actual data & programs on the card were still good, I slurped the partitions:

sudo partimage save /dev/sdf1 mpcnc_boot.gz
sudo partimage save /dev/sdf2 mpcnc_partition.gz

And wrote them back:

sudo partimage restmbr  mpcnc_boot.gz.000 
sudo partimage restore /dev/sdf1 mpcnc_boot.gz.000 
sudo partimage restore /dev/sdf2 mpcnc_partition.gz.000

Unshown: a finger fumble requiring MBR restoration.

Having forced the card controller to reallocate all the failed sectors, the card works now fine and runs at full speed again. This won’t last long, but it’ll be interesting to see how it plays out.

While I was at it, I wrote the partitions to a new-ish / unused Samsung EVO Plus card, now tucked under the MPCNC’s monitor in case of emergency.

An old SFF Optiplex with an SSD may be a better fallback.

, ,

Leave a comment

MPCNC: Acrylic Engraving First Light

Just to see what happened, I chucked a drag knife in the collet pen holder:

MPCNC Collet Pen Holder - drag knife

MPCNC Collet Pen Holder – drag knife

The blade, being fixed in the collet and lashed to the adapter, doesn’t rotate: it’s not behaving as a true drag knife.

Twiddling the cut depth to about 0.2 mm produced a credible Guilloché pattern in some scrap acrylic:

MPCNC Collet Pen Holder - drag engraved acrylic - 0.2 mm depth

MPCNC Collet Pen Holder – drag engraved acrylic – 0.2 mm depth

The sidelight comes from an LED flashlight off to the side, with a bit of contrast tweaking to suppress the workbench clutter.

The MPCNC’s lack of rigidity produces visible jitters in the Guilloché pattern and backlash makes the characters somewhat wobbly, but it’s OK for a large and inexpensive CNC gantry machine.

A brace of diamond-point engraving bits are making their way around the planet even as I type. A symmetric 60° point may reduce the swarf thrown out by the drag knife, although it surely won’t improve the overall jitter and backlash.

 

3 Comments

GCMC Guilloche Plot Generator

It turns out the Spirograph patterns I’d been using to wring out the MPCNC are also known as Guilloché, perhaps after the guy who invented a lathe-turning machine to engrave them. Sounds pretentious, but they still look nice:

Guilloche 591991062 - scanned

Guilloche 591991062 – scanned

With the ballpoint pen / knife collet holder in mind, I stripped the tool changes out of the Spirograph generator GCMC source code, set the “paper size” to a convenient 100 mm square, and tidied up the code a bit.

As with Spirograph patterns, changing the random number seed produces entirely different results. A collection differing in the last digit, previewed online:

Seed = 213478836:

Guilloche 213478836

Guilloche 213478836

Seed = 213478837:

Guilloche 213478837

Guilloche 213478837

Seed = 213478838:

Guilloche 213478838

Guilloche 213478838

Seed = 213478839:

Guilloche 213478839

Guilloche 213478839

They’re such unique snowflakes …

The Bash script now accepts a single parameter to force the PRNG seed to a value you presumably want to plot again, rather than just accept whatever the Gods of Cosmic Jest will pick for you.

The GCMC source code and Bash (or whatever) script feeding it as a GitHub Gist:

2 Comments