Author: Ed

Rounded Cable Clips

This isn’t quite the smoothly rounded clip I had in mind:

LED Cable Clip - rounded channel — LED Cable Clip – rounded channel

It seems somewhat better looking than the square design, though:

I ran off a few of both styles to have some on hand:

Cable clips - on platform — Cable clips – on platform

They’re in a bag until I install the new LED strips and needle light.

The OpenSCAD source code:

// LED Cable Clips
// Ed Nisley - KE4ZNU - October 2014

Layout = "Oval";			// Oval Square Build

//- Extrusion parameters must match reality!

ThreadThick = 0.20;
ThreadWidth = 0.40;

HoleWindage = 0.2;			// extra clearance

Protrusion = 0.1;			// make holes end cleanly

AlignPinOD = 1.70;			// assembly alignment pins: filament dia

function IntegerMultiple(Size,Unit) = Unit * ceil(Size / Unit);

//----------------------
// Dimensions

Base = [12.0,12.0,IntegerMultiple(2.0,ThreadThick)];	// base over sticky square

CableOD = 2.0;

BendRadius = 3.0;

Bollard = [BendRadius,(sqrt(2)*Base[0]/2 - CableOD - BendRadius),2*CableOD];
B_BOT = 0;
B_TOP = 1;
B_LEN = 2;

NumSides = (Shape == "Square") ? 5*4 : 6*3;

//----------------------
// Useful routines

module PolyCyl(Dia,Height,ForceSides=0) {			// based on nophead's polyholes

  Sides = (ForceSides != 0) ? ForceSides : (ceil(Dia) + 2);

  FixDia = Dia / cos(180/Sides);

  cylinder(r=(FixDia + HoleWindage)/2,
           h=Height,
           $fn=Sides);
}

module ShowPegGrid(Space = 10.0,Size = 1.0) {

  RangeX = floor(100 / Space);
  RangeY = floor(125 / Space);

	for (x=[-RangeX:RangeX])
	  for (y=[-RangeY:RangeY])
		translate([x*Space,y*Space,Size/2])
		  %cube(Size,center=true);

}

//-- Square clip with central bollard

module SquareBollard() {

	intersection() {
		translate([0,0,(Base[2] + Bollard[B_LEN])/2])			// overall XYZ outline
			cube(Base + [0,0,Bollard[2]],center=true);

		union() {
			translate([0,0,Base[2]/2])						// oversize mount base
				scale([2,2,1])
					cube(Base,center=true);

			for (i=[-1,1] , j=[-1,1]) {						// corner bollards
				translate([i*Base[0]/2,j*Base[1]/2,(Base[2] - Protrusion)])
					rotate(180/NumSides)
					cylinder(r=Bollard[B_BOT],h=(Bollard[B_LEN] + Protrusion),center=false,$fn=NumSides);

			translate([0,0,(Base[2] - Protrusion)])			// center tapered bollard
				cylinder(r1=Bollard[B_BOT],r2=Bollard[B_TOP],
						 h=(Bollard[B_LEN] + Protrusion),
						 center=false,$fn=NumSides);
			}
		}
	}

}

//-- Oval clip with central passage

module OvalPass() {

	intersection() {
		translate([0,0,(Base[2] + Bollard[B_LEN])/2])		// overall XYZ outline
			cube(Base + [0,0,2*CableOD],center=true);

		union() {
			translate([0,0,Base[2]/2])						// oversize mount base
				scale([2,2,1])
					cube(Base,center=true);

			for (j=[-1,1])									// bending ovals
				translate([0,j*Base[1]/2,(Base[2] - Protrusion)])
					resize([Base[0]/0.75,0,0])
						cylinder(d1=0.75*(Base[1]-CableOD),d2=(Base[1]-CableOD)/cos(180/NumSides),
								h=(Bollard[B_LEN] + Protrusion),
								center=false,$fn=NumSides);
		}
	}
/*
#	translate([0,0,6])
		rotate([0,90,0])
			cylinder(d=CableOD,h=10,center=true,$fn=48);
*/
}

//----------------------
// Build it

ShowPegGrid();

if (Layout == "Square")
	SquareBollard();

if (Layout == "Oval")
	OvalPass();

2015-01-08

DC-DC Boost Converter: Another QC FAIL
Each LED emitter in the Kenmore 158 endcap light contains six chips in series:

LED mount – lighting test

Even though the current has the usual exponential relationship to the terminal voltage, the slope at 200 mA (100 mA each, assuming they share & share alike) remains low enough that I (think I) can get away with just dialing in a voltage and leaving it at that; changes due to small temperature variations won’t cause meaningful differences in the current.

That’s easier than building an adjustable current regulator, anyway.

The heap disgorged two cheap DC-to-DC boost converters from halfway around the planet, with about the right specs:
- 10 to 32 V DC in
- 12 to 35 V out
- 10 A
- 150 W
They couldn’t produce their rated output, but a pair of LEDs shouldn’t pose much of a challenge.

So I wired one up to the bench supply, set it for 12 V, turned it on, and wham it maxed out the supply at 3 A with no load on the converter’s output.

Huh.

Adding a suitable load resistor brought the input current down, but the voltage adjustment trimpot didn’t have much effect and the bench supply would still wham hit 3 A with no provocation, so the load resistor didn’t actually make any difference. Eventually, I figured out that simply pressing my finger on the trimpot caused the output to vary wildly.

Given that fairly broad hint, this became obvious:

Boost Converter – trimpot pins

Evidently, I had used the other converter for the previous tests. Huh.

With that trimpot pin soldered in place, the converter worked fine. Eyeballometrically speaking, the LEDs seem bright enough at 100 mA total (50 mA each) for my purposes, which happens at 18-ish V. Dissipating only 2 W won’t require nearly as much heatsink as they’re presently mounted on, although I should wait for warmer weather before concluding that they’re doing OK while crammed inside the end cap.

Before declaring victory, I took a closer look at the board and found this mmm oversight:

Boost Converter – masked 78L09 tab

Notice the big pad under the 78L09 regulator, with six thermal vias to an expansive copper pour on the other side of the board, completely covered with red solder mask.

Removing the regulator show the regulator’s footprint didn’t include the tab:

Boost Converter – 78L09 footprint

Maybe they decided, after a careful analysis, that the regulator couldn’t possibly dissipate enough power to warrant the additional solder required for the entire thermal pad. Heck, pocket a fraction of a yuan on ten million boards and you’re livin’ large.

Scraping the mask off, fluxing everything in sight, and soldering the regulator down probably won’t make any difference:

Boost Converter – scraped and soldered

Yes, The Bigger The Blob, The Better The Job strikes again. It does make me feel better and that’s all that counts.
2015-01-07
Kenmore 158 LED Heatsink: Epoxy Sculpture

The LED mounting plate inside the sewing machine’s end cap sits 30° from the vertical axis of the needle. Even though the surface-mount LED emitters have a broad pattern, it seemed reasonable to aim them toward the needle to put the brightest spot where it’s needed.

The LEDs must have enough heatsinking to pull 2+ W out of the solder pads, so I figured I’d just epoxy them firmly to the mounting plate, rather than try to gimmick up a circuit board that would interpose a fiberglass slab in the thermal path.

Combine those two requirements and you (well, I) get a wire fixture that provides both power and alignment:

LED mount – wire fixture

The LED body is 5 mm square, sin(30°) = 0.5, and the rear wire raises contact end by 2.5 mm. This still isn’t an exact science; if the center of the beam lands in the right time zone, that’s close enough.

Testing the LED assembly at low current before entombing it shows the emitters have six chips in series (clicky for more dots):

LED mount – lighting test

The grotendous solder job follows my “The Bigger the Blob, the Better the Job” principle, modulated by the difficulty of getting a smooth finish on bare wires. Indeed, the first wires I painstakingly bent, set up, and soldered turned out to have an un-solderable surface, much like the header pins from a while ago. That hank of wire now resides in the copper cable recycling bucket; you’re looking at Version 1.1.

Two strips of Kapton tape under the ends of the wires hold them off the (scoured and wiped clean!) aluminum plate, with more tape forming a dam around the nearest edges:

LED mount – epoxy pour

Despite being steel-filled, JB Weld remains nonconductive, the epoxy-filled gap under the wires insulates them from the plate, the wires aren’t shorted together, and there’s a great thermal bond to the heatsink. Good stuff, that JB Weld!

A view from the back side shows the epoxy sagging over the wires before I added another blob:

LED mount – epoxy pour – rear

The LED assembly just sits there, without being anchored, until the epoxy cures. The epoxy remains thick enough (in the rather chilly Basement Laboratory) so that it doesn’t exactly pour, can be eased into place without too much muss & fuss, and stays pretty much where it’s put.

After the epoxy stiffened a bit, I gingerly positioned stranded wires not-quite-touching the LED wires and applied a dot of solder to each. Powering the LEDs from a bench supply at 500 mW each took the chill off the heatsink and encouraged proper curing:

LED mount – heated epoxy cure

Fast forward to the next day, return the heatsink to the Sherline, and drill a hole for the power cable. It’s centered between the wires in Y and between the fins in X, which is why I couldn’t drill before mounting the LEDs:

LED mount – drilling cable hole

It’s not like I’m building this from any specs…

Trim the wires, solder the cable in place, cover the wire ends & joints with JB KwikWeld epoxy, and it’s done:

LED mount – final epoxy

With the LEDs running their 230 mA rated current, the entire heatsink gets pleasantly warm and the mounting plate isn’t much warmer than that. I loves me a good JB Weld job…

However, I suspect they’ll shine too brightly at full throttle, which means an adjustable power supply looms on the horizon…

2015-01-06
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
Delicate Tire Tracks in the Snow

Seeing this early one wintry morning made me wonder if somebody had ridden away on our bikes in the dead of night:

Bike Tracks on Snowy Driveway – overview

A closer look, as seen from the garage door:

Bike Tracks on Snowy Driveway – detail

We’d gone for a ride two days earlier and, apparently, our tires deposited enough salt dust (?) on the driveway as we rolled them out of the garage to melt the light snowfall. I’m not sure I can believe that, as those same tires left no trace of our return from that same trip, when I’d expect them to carry more dust.

If it’s a thermal effect, it was produced by one brief contact with tires kept in an unheated garage and rolled over an asphalt driveway, after exposure to ambient conditions for two days.

Truly a puzzlement…

2015-01-04
The Windows Update That Replaces the Update That Prevented Further Updates

Category killer in the “You can’t make this stuff up” category:

Update to prevent update prevention error

I vaguely recall similar errors in Ubuntu’s updater and I suppose everybody gets it wrong occasionally.

2015-01-03
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