Posts Tagged CNC
The stem fits into a slot made with a 3/8 inch end mill:
You move the cutter by the length of the sensor (10.0 mm will work) to make the slot. In practical terms, drill a hole at the midpoint, insert the cutter, then move ±5.0 mm from the center:
A bead of epoxy around the stem on the bottom of the panel should hold it in place forevermore.
The rectangular inner hole came out a tight push fit for the TCRT5000 sensor, so I didn’t bother gluing it in place and, surprisingly, it survived the day unscathed!
The OpenSCAD source code as a GitHub Gist:
I made the pencil guides to help Mary design ruler quilting patterns, but sometimes she must line up the ruler with a feature on an existing pattern. To that end, we now have a reticle guide:
The general idea is that it’s easier to see the pattern on paper through the crosshair than through a small hole. You put the button over a feature, align the reticle, put the ruler against the button, replace it with pencil guide, and away you go.
The solid model looks much more lively than you’d expect:
Printing up a pair of each button produces the same surface finish as before; life is good!
The OpenSCAD source code as a GitHub Gist:
One of the octal tubes in my collection has a broken spigot / key post that lets some light in through the bottom of the normally opaque Bakelite base:
Perhaps drilling out the base would let more light pass around the evacuation tip, but that requires a shell drill to clear the tip. Some doodling suggested a drill with 12 mm OD and 8 mm ID, which was close enough to one of the smaller homebrew drills in my collection that I decided to see how it worked:
You (well, I) can’t freehand such a hole, particularly with a glass tip in the middle, so I needed a way to clamp the tube in either the drill press or the Sherline. A pad for the clamp screw in a V-block seemed appropriate:
The screw hole sits at the 1/3 point to put more pressure near the pin end of the base. Maybe that matters.
The setup looks like this, with a small red laser dot near the front of the base:
The tube rests on a random scrap of plastic, with the hope that the drill won’t apply enough pressure to break the glass envelope.
In normal use, the V-block would be oriented the other way to let you cross-drill the cylinder. In this end-on orientation, drilling torque can rotate the tube; compliant padding for more traction may be in order.
The OpenSCAD source code as a GitHub Gist now includes a module that spits out the clamp:
I picked up a horsehair dust brush from eBay as a lightweight substitute for the Electrolux aluminum ball, discovered that an adapter I’d already made fit perfectly, did the happy dance, and printed one for the brush. That worked perfectly for half a year, whereupon:
It broke about where I expected, along the layer lines at the cross section where the snout joins the fitting. You can see the three perimeter shells I hoped would strengthen the part:
That has the usual 15% 3D Honeycomb infill, although there’s not a lot area for infill.
There’s obviously a stress concentration there and making the wall somewhat thicker (to get more plastic-to-plastic area) might suffice. I’m not convinced the layer bonding would be good enough, even with more wall area, to resist the stress; that’s pretty much a textbook example of how & where 3D printed parts fail.
That cross section should look like this:
Anyhow, I buttered the snout’s broken end with JB Kwik epoxy, aligned the parts, and clamped them overnight:
The source code now has a separate solid model for the dust brush featuring a slightly shorter snout;
if when the epoxy fails, we’ll see how that changes the results. I could add ribs and suchlike along the outside, none of which seem worth the effort right now. Fairing the joint between those two straight sections would achieve the same end, with even more effort, because OpenSCAD.
The OpenSCAD source code as a GitHub Gist:
It turns out that the dual-core Intel Atom Inside an old Dell Mini 10 isn’t up to the demands of rendering modern web design; disk I/O speed has nothing to do with the CPU’s (lack of) ability to chew through multiple layers of cruft adorning what used to be straightforward static HTML.
So, equipped with Linux Mint / XFCE, it’s now found a new purpose in life:
In truth, an Atom isn’t quite up to the demands of modern 3D printing, either, at least in terms of processing a huge G-Code file into a layer-by-layer path preview. Fortunately, Pronterface doesn’t generate the preview until you ask for it: arranging the UI to put the preview on a separate tab eliminates that problem.
The Mini 10 can dribble G-Code into the printer just fine and looks much cuter than the hulking laptop in the background.
Confronted with a puzzling failure, I decided to perform some long-delayed tweaking…
The folks at Makergear send me (and several others) a new filament drive gear for testing. It has smaller splines / teeth and produces a much finer mark on the filament:
The obvious stripped section on the right comes from finger-fumbling an absurdly large extrusion distance (something like, mmm, 1450 mm) with a high extrusion speed. Not the fault of the drive gear, that’s for sure!
I remeasured the actual filament length extruded to recompute Marlin’s
STEPSPERMM configuration constant. After rediscovering the awkward fact that, when you change that value with an
M92 command, Marlin doesn’t recompute the current extruder position, so the next manual extrusion will move a random amount of filament in a random direction, the value eventually converged to 476.9 steps/mm.
I intended to put the M92 in Slic3r’s startup G-Code, but the prospect of random extrusions suggested that now was a great time to update the firmware; again demonstrating that no good idea goes unpunished.
The most recent Marlin version, 1.1.0-RC5 (clearly labeled “Not for production use – use with caution!”), had been released a few hours earlier, so I fetched that and tweaked the configuration files as before.
The firmware now includes thermal runaway / thermistor failure protection for both the bed and hot end. Increasing the two
THERMAL_PROTECTION hysteresis values to 6 °C seems to work well.
It also includes a
CONTROLLERFAN output that can go active when any stepper is enabled, then off after predetermined time. Setting that to Pin 6 and 30 seconds means the whining fan (it’s a ball bearing replacement in an aerodynamically poor location) in the control box goes off when it’s not needed.
DEFAULT_STEPPER_DEACTIVE_TIME to 600 seconds means the motors don’t time out while waiting for the platform to reach operating temperature.
HOMING_FEEDRATE for the Z-axis to 60*60 mm/min causes it to whack the lever a bit harder and overtravel slightly more. The Z Offset ended up at -2.15 mm, based on the calibration cubes below.
Running a PID calibration on the V4 hot end produced slightly different values: P=17.41, I=1.02, D=74.44. Hardcoding those into the config file does not override the values already stored in EEPROM: you must manually set them with
M301, then use
M500 to program the EEPROM.
A few Calibration Box iterations settled settled the Extrusion Multiplier at a convenient 1.00 with the new drive gear:
All in all, that whole process went much more smoothly than I expected.
The config files as GitHub gists:
The first pass at the lip balm holders suffered from a grossly overstuffed first solid infill layer:
The skirt measured the usual scant 0.25 mm and was level all around, so the platform alignment and home position were just fine. That’s rarely a problem, but it’s good to verify before proceeding.
Previewing the G-Code didn’t show any problems; all the second-layer threads looked just fine. With that said, I did create an issue for gcode.ws pointing out that the profusion of thread colors wasn’t useful and suggesting some alternative methods.
The first layer requires 15-ish minutes to print, so I decided to reproduce the problem in a solid calibration box sliced with the same settings as the holder:
That still life represents these tests:
- Solid 3 mm tall box, 20 mm square
- 30 mm square
- 25 mm square, with text in Arial
- Again, because I can’t believe it hasn’t failed yet
- With rectilinear first layer
- Back to Hilbert with text in Zapf Chancery
All of those printed without trouble; every layer came out exactly as it should. In particular, the first solid infill layer atop the Hilbert Curve bottom layer had the precisely filled threads I’m used to seeing, each one butted against its neighbors without any excess plastic.
I modified the OpenSCAD source code to extract a 20x20x3 sample block from the lip balm holder model, including a snippet of the actual text. That worked fine.
Expanding the sample produced the irregular chunk in the front row, also 3 mm tall, including a section of the lilypads surrounding the tubes. Another successful print!
I’ll leave to your imagination a pile of half a dozen first layers topped with small sections of grossly overstuffed solid infill, printed in between the successful blocks and as a result of the variations mentioned below, with identical text and slicer settings. The test blocks work fine, but the actual holder and sections from it do not.
Having eliminated the obvious causes, it was time for more drastic measures.
I build OpenSCAD and Slic3r from the latest source files on GitHub. Nothing in this leads me to suspect the OpenSCAD models and using the most recent stable Slic3r version produced the same results.
Rebuilding the Slic3r configuration files from scratch produced the same results.
That’s where I gave up, set the 3D Honeycomb infill to start with Layer 2, and completed the mission.
Lacking any better ideas, I decided to throw all the balls in the air at once …