Posts Tagged MPCNC
Shortening the 12 mm shaft wasn’t going to happen, so I knocked a little bit off the blade holder to give the knurled lock ring slightly more travel:
The lathe cutoff blade is a bit to the right of the new cut, but you get the general idea: not a whole lot of clearance in there.
The middle deck is a disk with a notch exposing the FL scale, a cutout window exposing the inductive time constant / risetime scale, and a wee circle for the Chicago screw in the middle:
Three angles define the notch:
FLNotchArc = 85deg; // width exposing FL scale FLRampArc = 7deg; // … width of entry & exit ramps FLNotchOffset = 2deg; // … start angle from 0°
Given those, along with the deck radius and notch height (equals the underlying scale height), calculate four points defining the start and end of the ramps and connect the dots:
local a0 = FLNotchOffset; local p0 = DeckRad * [cos(a0),sin(a0),-]; local a1 = a0 + FLNotchArc; local p1 = DeckRad * [cos(a1),sin(a1),-]; goto(p0); move([-,-,KnifeZ]); arc_cw(p1,-DeckRad); // largest arc local r = DeckRad - ScaleHeight; local a3 = a1 - FLRampArc; local p3 = r * [cos(a3),sin(a3),-]; local a4 = a0 + FLRampArc; local p4 = r * [cos(a4),sin(a4),-]; move(p3); arc_cw(p4,r); // smallest arc move(p0); // end of notch arc_cw([DeckRad,0,-],DeckRad); // round off corner
arc_cw() functions draw arcs, as you’d expect, with a positive radius tracing the shortest arc and a negative radius for the longest arc. Although I know how that works, I must still preview the result to verify the G-Code does what I want, not what I said.
The unhappy result of a wrong sign:
GCMC uses the (signed) radius to generate the XY coordinates and IJ offsets for
G2 commands in the preferred center format:
G0 X88.846 Y3.103 G1 Z-2.000 G2 X4.653 Y88.778 I-88.846 J-3.103
Cutting the window starts from its angular width and offset, which are hardcoded magic numbers from the Tek artifact, and proceeds similarly:
local WindowArc = 39deg; local ac = -6 * ScaleArc; // center of window arc local r0 = DeckRad - ScaleHeight; // outer local r1 = DeckRad - 2 * ScaleHeight; // inner local aw = WindowArc - to_deg(atan(ScaleHeight,(r0 + r1)/2)); // window arc minus endcaps local p0 = r0 * [cos(ac + aw/2),sin(ac + aw/2),-]; local p1 = r0 * [cos(ac - aw/2),sin(ac - aw/2),-]; local p2 = r1 * [cos(ac - aw/2),sin(ac - aw/2),-]; local p3 = r1 * [cos(ac + aw/2),sin(ac + aw/2),-]; goto(p0); move([-,-,KnifeZ]); arc_cw(p1,r0); // smallest arc arc_cw(p2,ScaleHeight/2); // half a circle arc_ccw(p3,r1); arc_cw(p0,ScaleHeight/2);
Trust me on this: incorrect radius signs generate unrecognizable outlines. Which, of course, is why you preview the G-Code before actually cutting anything:
A similar hunk of code cuts the top deck; the bottom deck is a simple circle.
The workflow, such as it is:
- Tape a sheet of paper (Index stock, Basis 110 = 10 mil = 0.25 mm) at the center of the 3018-ProXL platform
- Plot (“engrave”) the scales with a pen
- Affix paper to a Cricut sticky mat taped to the MPCNC platform
- Touch off the origin at the middle
- Drag-cut (“mill”) the outlines
Less complex than it may appear, but the GCMC file now spits out two G-Code files per deck: one to engrave / draw the scales on the 3018 and another to mill / cut the outlines on the MPCNC.
Following a linkie I can no longer find led me to retrieve the Tektronix Circuit Computer in my Box o’ Slide Rules:
I’m pretty sure it came from Mad Phil’s collection. One can line up the discolored parts of the decks under their cutout windows to restore it to its previous alignment; most likely it sat at the end of a row of books (remember books?) on his reference shelf.
The reverse side lists the equations it can solve, plus pictorial help for the puzzled:
Some searching reveals the original version had three aluminum disks, shaped and milled and photo-printed, with a honkin’ hex nut holding the cursor in place. The one I have seems like laser-printed card stock between plastic laminating film; they don’t make ’em like that any more, either.
TEK PN 003-023 (the paper edition) runs about thirty bucks (modulo the occasional outlier) on eBay, so we’re not dealing in priceless antiquity here. The manual is readily available as a PDF, with photos in the back.
Some doodling produced key measurements:
All the dimensions are hard inches, of course.
Each log decade spans 18°, with the Inductive Frequency scale at 36° for the square root required to calculate circuit resonance.
Generating the log scales requires handling all possible combinations of:
- Scales increase clockwise
- Scales increase counterclockwise
- Ticks point outward
- Ticks point inward
- Text reads from center
- Text reads from rim
I used the 1×100 tick on the outer scale of each deck as the 0° reference for the other scales on that deck. The 0° tick appears at the far right of plots & engravings & suchlike.
The L/R Time Constant (tau = τ) pointer on the top deck and the corresponding τL scale on the bottom deck has (what seems like) an arbitrary -150° offset from the 0° reference.
The Inductive Frequency scale has an offset of 2π, the log of which is 0.79818 = 14.37°.
The risetime calculations have a factor of 2.197, offsetting those pointers from their corresponding τ pointer by 0.342 = log(2.197) = 6.15°.
A fair bit of effort produced a GCMC program creating a full-size check plot of the bottom deck on the MPCNC:
By the conservation of perversity, the image is rotated 90° to put the 1 H tick straight up.
The 3018 can’t handle a 7.75 inch = 196 mm disk, but a CD-size (120 mm OD) engraving came out OK on white plastic filled with black crayon:
The millimeter scale over on the right shows the letters stand a bit under 1 mm tall. And, yes, the middle scale should read upside-down.
Properly filling the engraved lines remains an ongoing experiment. More downforce on the diamond or more passes through the G-Code should produce deeper trenches, perhaps with correspondingly higher ridges along the sides. Sanding & polishing the plastic without removing the ink seems tedious.
The Great Dragorn of Kismet observes I have a gift for picking projects at the cutting edge of consumer demand.
More doodles while figuring the GCMC code produced a summary of the scale offsets:
Musings on the parameters of each scale:
How to draw decades of tick marks:
It turned out easier to build vectors of tick mark values and their corresponding lengths, with another list of ticks to be labeled, than to figure out how to automate those values.
More on all this to come …
I set up an orthotic shoe insert on the MPCNC and unleashed the Z-Axis height probe on it:
In principle, the grid keeps the object aligned with the machine axes and the blocks put the upper surface more-or-less parallel with the platform. The XY origin, at the G28 location I’ve been using for tool changes, is on the midline of the sole, with Z touched off by probing the platform beside the sole.
The only interesting part of the orthotic is the rigid white plastic plate, which extends about 20 mm into a pocket in the black foam, so the probe area excludes the bendy part.
I’m abusing the bCNC Auto-level probe routine to get the height map, because it produces a tidy file of XYZ coordinates with three header lines describing the overall probe area:
-50 140 39 -50 50 21 -2 35 500 -50 -50 0.11 -45 -50 0.06 -40 -50 0.005
The first two lines give the X and Y coordinate ranges and number of samples. The third line is the Z axis range and probe speed (?). After that, it’s just probed XYZ coordinates, all the way down.
Meshlab can import ASC files consisting of XYZ coordinates, with the ability to skip a specific number of header lines:
If you don’t skip those three lines, then you get three additional points, far off in XYZ space, that will confuse the next step.
Checking the Grid Triangulation box (the default) produces a nicely lofted sheet:
It is, however, a single-sided sheet, not a manifold 3D object. After a few days of screwing around, I’m unable to find any (automatic, reliable, non-manual) way to solidify the thing in Meshlab, so just save it as a PLY file in ASCII format:
Import it into Meshmixer, Ctrl-A to select the whole thing, click (Select →) Edit → Extrude, pick Y-Axis and Flat EndType, then extrude a convenient base in the negative direction:
For whatever reason, some 3D programs show machine-tool coordinates with Z pointing upward and others aim the Z axis at your face. Both must have made sense at the time, because Meshmixer defaults to swapping the Y and Z coordinates on import / export.
The Density slider controls the number of generated faces in the extruded section, so tune for best results.
I have no idea what Harden does.
Accept the result and you have a solid object suitable for further modeling.
A slight modification to the MPCNC LM12UU collet pen holder turns it into a long-reach Z-Axis Height Probe:
A flange on the top plate holds a Makerbot-style endstop switch:
The brass probe rod sports a 3/32 inch ball epoxied on its tip, although for my simple needs I could probably use the bare rod:
I clamped the rod to extend a bit beyond the plate, where it can soak up most of the switch release travel, leaving just enough to reset the clickiness after each probe:
The probe responds only to Z motion, not tip deflection in XY, so it’s not particularly good for soft objects with sloped sides, like the insole shown above. It works fine for rigid objects and should suffice to figure the modeling workflow.
The bCNC Auto-Level probe routine scans a grid over a rectangular region:
Which Meshlab turns into a solid model:
That’s the bottom of the insole probed on a 5 mm grid, which takes something over an hour to accomplish.
The OpenSCAD code as a GitHub Gist:
I’m sure I’ll do this again some time …
Focus the camera at whatever distance needed to clear the longest tooling you’ll use or, at least, some convenient distance from the platform. You must touch off Z=0 at the surface before using bCNC’s probe camera alignment, because it will move the camera to the preset focus distance.
Align the camera’s optical axis perpendicular to the table by making it stare into a mirror flat on the platform, then tweaking the camera angles until the crosshair centers on the reflected lens image. This isn’t dead centered, but it’s pretty close:
The camera will be focused on the mirror, not the reflection, as you can tell by the in-focus crud on the mirror. Whenever you focus the lens, you’ll probably move the optical axis, so do the best you can with the fuzzy image.
You can adjust small misalignments with the Haircross (seems backwards to me) Offset values.
A cheap camera’s lens barrel may not be aligned with its optical axis, giving the lens a jaunty tilt when it’s correctly set up:
With the camera focus set correctly, calibrate the camera Offset from the tool (a.k.a. Spindle) axis:
- Put a pointy tool at XY=0
- Touch off Z=0 on a stack of masking tape
- Put a dent in the tape with the bit
- Move to the camera’s focused Z level
- Make the dent more conspicuous with a Sharpie, as needed
- Register the spindle location
- Jog to center the crosshair on the dent
- Register the camera location
Calibrate the Crosshair ring diameter thusly:
- Put an object with a known size on the platform
- Touch off Z=0 at its surface
- Move to the camera’s focused Z level
- Set the Crosshair diameter equal to the known object size
- Adjust the Scale value to make the Crosshair overlay reality
For example, calibrating the diameter to 10 mm against a shop scale:
At 10 mm above the CD, setting the camera’s resolution to 11.5 pixel/mm:
Makes the outer circle exactly 15.0 mm in diameter to match the CD hub ring ID:
I doubt anybody can find the pixel/mm value from first principles, so you must work backwards from an object’s actual size.
The smaller and more rigid CNC 3018-Pro should be able to engrave text faster than the larger and rather springy MPCNC, which could engrave text at about 50 mm/min. This test pattern pushes both cutting depth and engraving speed to absurd values:
Compile the GCMC source to generate G-Code, lash a CD / DVD to the platform (masking tape works fine), touch off the XY coordinates in the center, touch off Z=0 on the surface, then see what happens:
The “engraving depth” translates directly into the force applied to the diamond point, because the spring converts displacement into force. Knowing the Z depth, you can calculate or guesstimate the force.
Early results from the 3018 suggest it can engrave good-looking text about 20 times faster than the MPCNC:
You must trade off speed with accuracy on your very own machine, as your mileage will certainly differ!
The GCMC source code as a GitHub Gist: