Posts Tagged MPCNC
That’s a PNG converted from the SVG original, because WordPress regards SVG and DXF files as security risks.
Run the DXF through
dxf2gcode (from the Ubuntu repository) to produce G-Code suitable for my MPCNC’s GRBL controller, tape a sheet of paper to a sacrificial acrylic sheet, fire up bCNC, set the origins, and run the G-Code:
As expected, the cut paper pulled off the acrylic, because it’s not glued down; I have some Cricut adhesive cutting mats which are definitely in the nature of fine tuning. In any event, the paper showed I could get from a DXF image to drag knife cutting action.
This being a crown, gaudy gold vinyl seemed appropriate:
The weeding process removes everything that’s not the crown; I used a razor knife to cut a square and remove the vinyl around the crown. A good needle-nose tweezer works wonders!
Apply transfer film to the weeded crown and peel it from its backing paper:
Stick it on something desperately in need of decoration and peel off the transfer film:
The tricky part is setting the drag knife cutting depth to match the vinyl sheet thickness (14 mil = 0.36 mm), so the blade cuts the vinyl without cutting through the backing paper. This seems best done with manual trial cuts on scrap vinyl, pressing the drag knife holder down firmly by hand and tweaking the depth adjustment for a clean cut.
The G-Code cuts at 400 mm/min = 6.7 mm/s, perhaps a bit on the slow side.
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:
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:
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.
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.
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:
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:
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:
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:
The upper plate also required fitting:
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:
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.
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.
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.
f3write to the card shows the problem:
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.
Just to see what happened, I chucked a drag knife in the collet pen holder:
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:
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.