Posts Tagged MPCNC
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.
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:
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:
Seed = 213478837:
Seed = 213478838:
Seed = 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:
The bars on the original MPCNC drag knife / plotter pen adapter had a 100 g/mm spring constant:
Making the bars slightly thicker improved their print-ability:
The reddish tint marks the new bars, with their location carefully tweaked to be coincident with the stock STL.
Shoving the pen into the scale with 0.1 mm steps produces another unnervingly linear plot:
Real plotter pens want about 20 g of force, so this isn’t the holder you’re looking for.
A bunch of plots at Z=-1.0 mm turned out well with the ballpoint pen insert, though:
The globs apparently come from plotting too fast for conditions; reducing the speed to 1500 mm/min works better.
A trio of Cutter Cutting Plotter Blade Holders arrived:
Despite the name, they’re not well-suited for drag knife blades, because they’re collets gripping a 2 mm shaft. The blade doesn’t rotate unless the plotter / cutter rotates the entire holder, which is actually a thing.
I got ’em because the snout of a common ball-point pen refill measures about 2 mm:
The glob around the tip comes from plotting too fast for conditions; about 1500 mm/min works better for continuous lines and 250 mm/min improves text.
The stock MPCNC adapter has a single recess suited for Genuine Plotter Pens, but the knurled lock ring on these cheapies sticks out far enough to make them wobbly. This being an inconvenience up with which I need not put, a few lines of OpenSCAD tweak the stock STL:
The original STL is ivory, new cuts are cyan, and additions are reddish.
The two support beams are now 1.6 mm = four thread widths, for improved slicing with a 0.35 mm nozzle and a higher spring constant.
It’s by-and-large indistinguishable from the old adapter:
Which I was using upside-down, because the flange fit better.
The MPCNC works reasonably well as a pen plotter with a genuine ballpoint pen:
The OpenSCAD source code as a GitHub Gist:
Although the camera doesn’t hit anything, it seemed entirely too exposed out in front:
So I moved it to the back, where I can’t see it and maybe won’t clobber it:
The camera sensor is now almost exactly aligned with the XY axes, so the goofy rotation is gone and the offsets look better:
The size of the “10 mm” inner circle at the crosshair depends on the target distance, so it’ll be smaller for surfaces clamped onto and thus rising above the table. Depending on how much that matters, I can tweak the camera focus and scale factor to make the answer come out right.
The setup at the home position looked like this from a different perspective:
No operational change, just a cleanup.