Posts Tagged CNC
GCMC includes a
typeset function converting a more-or-less ASCII string into the coordinate points (a “vectorlist” containing a “path”) defining its character strokes and pen motions. The coordinates are relative to an origin at the lower-left corner of the line, with the font’s capital-X height set to 1.0, so you apply a
scale function to make them whatever size you want and hand them to the
engrave library routine, which squirts the corresponding G-Code into the output file.
Such G-Code can annotate plots:
The scaled coordinates cover a distance L along a straight line, so putting them on an arc will cover the same distance. The arc is part of a circle with radius R and a circumference 2πR, so … polar coordinates to the rescue!
The total text length L corresponds to the total angle A along the arc:
A = 360° L / 2πR
It’s entirely possible to have a text line longer than the entire circumference of the circle, whereupon the right end overlaps the left. Smaller characters fit better on smaller circles:
The X coordinate of each point in the path (always positive from the X origin) in the path gives its angle (positive counterclockwise) from 0°:
a = 360° x / 2πR (say "eks")
You can add a constant angle of either sign to slew the whole text arc around the center point.
The letter baseline Y=0 sits at radius R, so the Y coordinate of each point (positive above and negative below the Y=0 baseline) gives its radius r:
r = R - y
That puts the bottom of the text outward, so it reads properly when you’re facing the center point.
Homework: Tweak the signs so it reads properly when you’re standing inside the circle reading outward.
Converting from polar back to XY:
x = r × cos(a) (say "times") y = r × sin(a)
You can add an XY offset to the result, thereby plunking the point wherever you want.
This obviously works best for small characters relative to the arc radius, as the lines connecting the points remain resolutely straight. That’s probably what you wanted anyway, but letters like, say, “m” definitely manspread.
Overall, it looks pretty good:
A doodle helped lay out the geometry:
The GCMC source code as a GitHub Gist:
Gripping a diamond engraver in a collet chuck worked well enough, but the MPCNC’s pen holder lacks sufficient downforce and lateral stiffness. The bit has a chrome-ish plated 3 mm shank, so I tinkered up a mount for a pair of LM3UU linear bearings from the LM12UU drag knife holder:
The shank isn’t exactly a precision part, but a few licks with a diamond file knocked off enough of the high spots so it slides reasonably well through the bearings. The bearing alignment is more critical than a simple 3D printed plastic part can provide, so a real version may need bearings in a metal shaft press-fit into the plastic; brute-forcing the bearings into alignment sufficed for now.
The butt end of the shank press-fits into a disk held down with three springs, similar to the LM12UU mount:
It draws Guilloché patterns just fine:
I don’t like how the spring-around-screw motion works, even if it’s OK for small excursions.
There’s a good reason this was the last pneumatic tee fitting on the rack:
The center fitting should be a male 1/4 inch NPT connection, but it’s completely un-machined. Alas, I no longer have a 1/4 NPT die in my tool chest, so it’s not an easy fix.
The two female connections are fine, so it must have been one of those rare QC escapes.
Lowe’s marked it down to $0.47 on clearance and I still couldn’t justify buying the thing.
The cover for Mary’s favorite seam ripper cracked long ago, has been repaired several times, and now needs a replacement:
The first pass (at the top) matched the interior and exterior shapes, but was entirely too rigid. Unlike the Clover seam ripper, the handle has too much taper for a thick-walled piece of plastic.
The flexy thinwall cover on the ripper comes from a model of the interior shape:
It’s not conspicuously tapered, but OpenSCAD’s perspective view makes the taper hard to see. The wedge on top helps the slicer bridge the opening; it’s not perfect, just close enough to work.
A similar model of the outer surface is one thread width wider on all sides, so subtracting the handle model from the interior produces a single-thread shell with a wedge-shaped interior invisible in this Slic3r preview:
The brim around the bottom improves platform griptivity. The rounded top (because pretty) precludes building it upside-down, but if you could tolerate a square-ish top, that’s the way to go.
Both models consist of hulls around eight strategically placed spheres, with the wedge on the top of the handle due to the intersection of the hull and a suitable cube. This view shows the situation without the hull:
The spheres overlap, with the top set barely distinguishable, to produce the proper taper. I measured the handle and cover’s wall thicknesses, then guesstimated the cover’s interior dimensions from its outer size.
The handle’s spheres have a radius matching its curvature. The cover’s spheres have a radius exactly one thread width larger, so the difference produces the one-thread-wide shell.
Came out pretty nicely, if I do say so myself: the cover seats fully with an easy push-on fit and stays firmly in place. Best of all, should it get lost (despite the retina-burn orange PETG plastic), I can make another with nearly zero effort.
The Basement Laboratory remains winter-cool, so I taped a paper shield over the platform as insulation from the fan cooling the PETG:
The shield goes on after the nozzle finishes the first layer. The masking tape adhesive turned into loathesome goo and required acetone to get it off the platform; fortunately, the borosilicate glass didn’t mind.
The OpenSCAD source code as a GitHub Gist:
I’ve been using YAGV (Yet Another G-Code Viewer) as a quick command-line Guilloché visualizer, even though it’s really intended for 3D printing previews:
Oddly (for a command-line program), it (seems to) lack any obvious keyboard shortcut to bail out; none of my usual finger macros work.
A quick hack to the main
/usr/share/yagv/yagv file makes Ctrl-Q bail out, thusly:
diff yagv /usr/share/yagv/yagv 18a19 > import sys 364a366,367 > if symbol==pyglet.window.key.Q and modifiers & pyglet.window.key.MOD_CTRL: > sys.exit()
I tacked the code onto an existing issue, but yagv may be a defunct project. Tweaking the source works for me.
The Ubuntu 18.04 LTS repo has what claims to be version 0.4, but the yagv GitHub repository (also claiming to be 0.4) includes code ignoring G-Code comments. Best to build the files from source (which, being Python, they already are), then add my Ctrl-Q hack, because my GCMC Guilloché generator adds plenty of comments.
Flushed with success from engraving a hard drive platter for the 21HB5A tube, I bandsawed an acrylic square from a scrap sheet and unleashed the diamond drag bit on it:
That’s side-lit against a dark blue background. The long scratch and assorted dirt come from its protracted stay in the scrap pile.
If you look closely, you’ll see a few slightly wider loops, which came from a false start at Z=-0.1 mm.
Engraving at -0.5 mm looked pretty good:
Despite an angular resolution of 2°, the curves came out entirely smooth enough. The gritty scratchiness resulted in a pile of chaff covering the engraved area; perhaps some oil or lube or whatever would help.
Rescaling the pattern to fit a CD platter worked fine, too:
Polycarbonate seems to deform slightly, rather than scratch, leaving the final product with no chaff at all:
In this case, the doubled lines come from the reflection off the aluminized lower surface holding all the data.
That CD should be unreadable by now …
[Update: It seems I interchanged “em” and “de” throughout this post. ]
Up to this point, I’ve been labeling printed parts with
emdebossed legends that look OK on the solid model:
Alas, the recessed letters become lost in their perimeter threads:
Raising the legend above the surface (“
deembossing”) works reasonably well, but raised letters would interfere with sliding the battery into the holder and tend to get lost amid the surface infill pattern.
The blindingly obvious solution, after far too long, raises the letters above a frame embossed into the surface:
Which looks OK in the real world, too:
The frame is one thread deep and the legend is one thread tall, putting the letters flush with the surrounding surface and allowing the battery to slide smoothly.
The legend on the bottom surface shows even more improvement:
An OpenSCAD program can’t get the size of a rendered text string, so the fixed-size frame must surround the largest possible text, which isn’t much of a problem for my simple needs.