The Smell of Molten Projects in the Morning

Ed Nisley's Blog: Shop notes, electronics, firmware, machinery, 3D printing, laser cuttery, and curiosities. Contents: 100% human thinking, 0% AI slop.

Category: Machine Shop

Mechanical widgetry

Kenmore 158 LED Heatsink: Machinable Wax FTW!

In the quest for More Light around the Kenmore 158’s needle, I’m replacing the pair of 10 mm LEDs with a pair of 21 V / 115 mA = 2.5 W surface-mount emitters that require a good heatsink. Because the heatsink must mount inside the sewing machine’s end cap, there’s not much air circulation: when sizing the heatsink, I figure that nothing exceeds like excess.

There doesn’t seem to be any way to measure the available space inside the hinged end cap, so the plan is to fit the largest possible heatsink, run it for a while, and then build a smaller (and presumably less awkward) heatsink based on those measurements.

I sawed a slice off an aluminum heatsink harvested from a junked PC, wrapped masking tape around it, and filled it with machinable wax to prevent the fins from chattering:

Heatsink filled with machinable wax

Pouring the wax into a cold heatsink worked about as poorly as you’d expect, so I held the heatsink over the stove burner, slowly remelted the wax into the bottom of the fins, and topped it off with more wax from the pot. I’m almost certainly using too little fire; the stuff melts at a bit under 300 °F and doesn’t really get liquid at any temperature I was comfortable with. The double boiler we use for candle wax won’t get nearly hot enough.

Clamped into the Sherline’s vise, it’s obvious that the slitting saw won’t quite reach all the way through:

Heatsink – slitting saw setup

I figured the height by working backwards from the outside of the end cap and forward from the bulkhead at the end of the arm. As it turned out, the middle fins fit and the outer two didn’t, but it was surprisingly close. The length turned out to be spot on, which is the sort of coincidence that tells me I’m on the right track. This is not an exact science.

One cut along the front, another along the rear, and the fins popped right off:

Heatsink – cut detail

Those aren’t broken teeth on the blade, they’re just loaded with wax and aluminum dust.

I love the way Sherline’s little flycutter produces a nice finish with minimal effort:

Heatsink – flycut fins

My plan to secure the heatsink to the sewing machine by repurposing two convenient screws was foiled by the lower screw: it’s too short and sports a fine 6-40 thread. Not only does my heap lack 6-40 screws, Eks doesn’t have any, either; I would have lost big money on that bet.

Brownell’s has a fillister-head screw assortment including 6-40 threads, so that problem will Go Away in short order, but they’re out of stock at the moment. My other Brownell’s assortment (which they no longer carry) includes 5-40 screws, but …

This being a prototype, I simply milled a recess to accommodate the offending screw head:

Heatsink – screw head clearance slot

The upper screw originally held the incandescent lamp socket in place and will be long enough to hold the heatsink.

In there somewhere, the ragged bandsawed edge on the far side got itself milled smooth.

Some trial fitting showed the two outer fins must be 2 mm shorter to fit inside the end cap, so the finish on those isn’t nearly as nice:

Heatsink – removing machinable wax

That shows the machinable wax on its way out of the fins, urged along by whacking the ends with a wooden stick. The wax doesn’t adhere to the aluminum and leaves a clean surface, although I’m sure I should scrub it down with solvent to remove any residue.

A bit of paper-doll cutout work provided a shape for the plate that will hold the LEDs, then some bandsaw and hand-filing and milling trimmed it to fit. The heatsink has a slot along the edge, barely visible at the right end of the previous photo, so I hand-filed a rabbet in the plate to let it sit flat against the bottom of the slot and the end of the fins.

Steel-filled epoxy (good old JB Weld) secures the plate and provides good thermal transfer. The steel bar holds the plate against the fins while the epoxy cures:

Heatsink – epoxying LED mount

After some iterative abrasive adjustment on the belt sander, the assembly just barely fits inside the end cap. This view looks through the bobbin access hatch opening in the bed:

Heatsink – endcap trial fit

The two outer fins hit various mold sprues / vents / protrusions inside the cast (!) end cap. I think the next version will have three fins, as the cap rides right against the outer fin; the abrasive adjustment came into play on that fin and the end of the LED plate.

The plate could be a bit longer, but let’s see how this one works out.

The notch just barely clears the arm that moves the needle sideways during zig-zag stiches. The rectangular joint guides the arm left-to-right (vertically in this image), but doesn’t slide up-and-down. I think it’s as far out as it’ll ever get, but, again, this is a prototype.

Now, to mount LEDs on that plate…

2015-01-05
OpenSCAD: Quantized Vertices
Back when I started fiddling with 3D printed chain mail, the whole process from model to plastic worked wonderfully well. That continued with the larger sheets, but now, occasionally, the OpenSCAD model would produce weirdly sliced links. Depending on nothing repeatable, some links wouldn’t bridge correctly: the thread paths in the bottom layer across the gap would mysteriously stop just short of one pillar, return to the start, and leave an unsupported shelf that would, of course, fall into the gap.

Shortly before Christmas, I managed to get a consistent failure that manifested differently: upon loading the STL file, Slic3r would quietly perform dozens of automatic corrections that (sometimes!) produced bizarrely distorted results. Feeding a failing model into Meshlab showed an irregular assortment of “self intersecting faces”, highlighted in red:

Chain Mail Square Armor – open – 2×2 – Meshlab self-intersecting faces

Although all four outer links in that image come from the same OpenSCAD module with identical sizes, they don’t all exhibit the same problem in the (nominally identical) faces on each of their four corners. In fact, those faces come from the intersection of two square slabs, carefully sized and positioned to avoid creating coincident planes:

Chain Mail Link – Outer shape

The central opening comes from a similar, slightly smaller, intersected-squares shape, but all four interior corner faces in each link show that they’re self-intersecting.

The STL looked fine in Meshlab, except for the highlit self-intersecting faces, so the geometry seemed OK.

When Slic3r autocorrected the “problems”, it apparently removed one vertex on the bottom surface of each bar, deleted the triangles connected to that vertex, then repaired the mesh to produce a delightfully symmetric pattern:

Chain Mail Square Armor – open – 2×2 – Slic3r corrections

Although the links are resolutely symmetric, Slic3r seemed happy with the identical vertices at the other end of the bar.

Unfortunately, the resulting G-Code won’t produce good links:

Chain Mail Square Armor – open – 2×2 – first layer G-code visualization

So, shortly before Christmas, I filed an issue on OpenSCAD’s Github repository.

The ensuing discussion showed that Meshlab flags faces as “self intersecting” when they have different vertices, even if their values are numerically equal, as well as vertices that differ by teeny amounts. Slic3r applies slightly different criteria to vertices & faces when it automagically corrects “problems” in the STL file, so that Meshlab may:
- Highlight faces that don’t bother Slic3r
- Apply the same highlight to faces that cause horrible problems
I don’t profess to understand much of that and may have the details wrong, but, apparently, OpenSCAD formerly used quantized coordinates that ensured all vertices within a tiny volume would have the same numeric value. In particular, all three faces that meet at a common point would, in fact, have numerically equal coordinate values for that point. The STL file format consists of a list of separate triangles, each with three coordinates for each of the three axes, and (without quantization) it was entirely possible for each of the three triangles with a common point to have three very slightly different positions for that point.

In theoretic terms, quantized coordinates cause horrible problems during geometric manipulation, because numeric values that aren’t exact can make repeated transformations come out wrong; running an object through a transformation and it’s inverse might not yield an object identical to the original one.

In practical terms, it seems that slicers and STL repair algorithms can reach incorrect conclusions based on minute differences produced by floating-point operations and numeric-to-text conversions. Those differences depend on slight changes in position, rotation, and size, so doing anything to the model produces completely different results.

That notwithstanding, the day after Christmas brought a new OpenSCAD version that uses quantized coordinates. A bit of rummaging in the source shows that the 3D grid (defined in src/grid.h) isn’t all that coarse:
```
const double GRID_FINE   = 0.00000095367431640625;
```
STL files don’t carry units, so that could be in either millimeters (the Slic3r / RepRap convention) or inches (Sketchup, but we won’t go there). It’s exactly 1/1024², in case you were wondering, which produces a 5% speedup in the geometry engine compared to the more human-readable 1/1000².

With that commit in hand, all the chain mail links slice perfectly again.

A very nice Christmas present, indeed!

Thanks, Marius…
2015-01-02
Pilot InstaBoost: Product Cheapnification in Full Effect

After rebuilding the battery clamps on the Pilot Instaboost jump starter, something on the back of the package caught my eye:

Pilot InstaBoost – clamp picture

The un-modified joint on the as-delivered clamp has a plastic stud and nothing through the spring:

Battery Clamp – original joint

Compare the first picture with our modifications:

Battery Clamp – improved joint

Looks like Pilot applied some cost reduction between taking the picture and shipping what we have now.

I bet they cheapnified something else, too. Something that cost them a lot more and the absence of which can’t be verified by most consumers…

2014-12-31
Improved Pilot InstaBoost Jumpstarter Clamps

The Sienna now spends all its time sitting outdoors in an apartment parking lot and gets even less driving (hence, battery-charging) time than we used to give it. Fortunately, Santa being my kind of guy, our Larval Engineer received a Pilot InstaBoost jumpstarter, which is basically a 10 A·h / 40 W·h lithium battery with husky plug & socket connectors, a pair of 10 AWG wires, and big alligator clamps. The package claims a 400 A peak discharge rate, but the tiny inscription on the back of the case reports 200 A; either of those seems mmmm somewhat optimistic to me.

The customer reviews suggest that the plastic battery clamp handles feature a crappy hinge joint which disintegrates under moderate stress on a cold winter night, firing the spring into the nearest snowbank and rendering the clamp completely useless. The joint consists of a plastic post on each side of the inner handle that protrudes into a hole in the outer handle:

Battery Clamp – original joint

I assigned her some Mandatory Quality Shop Time to improve the joint. She found some brass tubing that fit the existing hole and cut two pieces to length:

Battery Clamp – cutting brass tube

A 1 inch stainless screw was just barely long enough (that’s Loctite Red in the nut), but the end result certainly looks durable enough:

Battery Clamp – improved joint

It’s along the same lines as the improvement I applied to my old Park Tool MTB-7 Rescue Tool.

Apart from that, the clamps look pretty good. There’s even a husky braid between the two jaw pads, ensuring at least one reasonably low resistance joint to the battery post:

Battery Clamp – jaw strap

With a bit of luck, we’ll never know how well it works as a jumpstarter. She can use the USB port to keep her phone charged, which may provide enough motivation to keep the thing topped up and ready for use…

[Update: two days after this post went live, someone found it by searching for:

how to repair clamps pilot instaboost 400

You have been warned!]

2014-12-28
Kenmore 158: Recalibrated Optoisolator Drive

Because the motor will draw more current during pulsed operation, the ET227 needs more base drive. The existing circuit topped out around 2.5 A, so I reduced the current sampling resistor by a bit:

Optoisolator Driver

If you care about the exact current, you’d use a 1% resistor, but if you care about the current, you’ll be doing closed-loop feedback to compensate for the transistor gain variations. Compared to those, the resistor doesn’t matter.

Running the MCP4725 DAC through its range produces a nice graph:

Current Calibrate – DAC – 270k Hall 2.7k opto

The X axis comes from the Tek Hall-effect current probe, so the numbers don’t depend on the ferrite toroid & differential amp calibration. They do, of course, require a bit of eyeballometric calibration to extract the flat top from the waveform, as shown by this old waveform:

Motor current – ADC sample timing

Ya gotta start somewhere.

The linear fit to those dots gives the DAC value required to produce the observed current, at least for these particular transistors at whatever temperature they’re at in a rather chilly Basement Laboratory.

Of course, the observed current tops out at 1.2 A: the motor’s peak current during normal linear operation. The line looks so pretty that I’ll assume it continues upward to the maximum 12-bit DAC value of 4095 and the corresponding ET227 current. Working backwards, that will be 3.1 A and should suffice for all but the highest peaks at high line voltage.

2014-12-26
Merry Christmas!

May you receive as many Things as you need and have a place to put them:

A Rack of Things

Merry Christmas to one and all: take the day off!

Spotted this at the Mini Maker Faire. My Things generally live in boxes, but there’s a time for every style…

2014-12-25
Kenmore 158: Recalibrated Hall Effect Sensor Amp

Reducing the differential amp gain fits a higher current into the Arduino’s fixed 5 V ADC range:

Hall Sensor Differential Amp

Those are 1% resistors, chosen from the heap for being pretty close to what I needed. Given that it’s an LM324 op amp, we’re not talking instrumentation grade results here.

The same calibration run that produced the DAC plot gave these values:

Current Calibrate – ADC – 270k Hall 2.7k opto

The linear fit gives the actual current, as seen by the Tek probe, for a given ADC reading.

The trimpot controls the offset voltage at zero current; working backwards, ADC = 0 corresponds to 140 mV, a bit higher than the actual 90 mV. Close enough, at least for a linear fit to eyeballed data, sez I.

Working forward, the maximum ADC value of 1023 corresponds to 4 A, which should suffice.

2014-12-24