So this arrangement pulled in, maneuvered about, and backed up to the building I was standing in the shade of:

As Zappa once said: “Apparently, there was no law against that …”
Ed Nisley's Blog: shop notes, electronics, firmware, machinery, 3D printing, and curiosities
So this arrangement pulled in, maneuvered about, and backed up to the building I was standing in the shade of:
As Zappa once said: “Apparently, there was no law against that …”
Just to see what happens, I laid some smashed glass in puddles of epoxy:
Backlighting with the LED light pad reveals more detail:
The chunk on the left is the proof-of-concept shot glass coaster with a form-fit black acrylic mask atop a clear epoxy layer on a clear acrylic base. The chunk at the top is raw shattered glass fresh from the pile. The two chunks on teardrop acrylic scraps are bedded in transparent black and opaque black tinted epoxy.
A look through the microscope at all four, laid out in that order, with the contrast blown out to emphasize the grain boundaries:
You may want to open the image in a new tab for more detail.
The raw chunk has air between all its cuboids, so it’s nicely glittery. All the others have much of their air replaced by epoxy.
Clear epoxy produces an essentially transparent layer where it fills the gaps, because its refractive index comes close enough to the glass. The stretched contrast makes the gaps visible again, but the backlit image shows the unassisted eyeball view.
Transparent black dye sounds like an oxymoron, but it fills the gaps with enough contrast to remain visible. The overall chunk is not particularly glittery, but it’s OK.
Opaque black dye produces a much darker tint; the slightly tapered thin layer between the glass and acrylic (the small white circles are air bubbles) cuts down on the transmitted light. The gaps remain nearly as prominent as in the air-filled chunk, although with very little glitter.
Bedding the glass in epoxy against an acrylic sheet should reduce its tendency to fall apart at the slightest provocation, although the proof-of-concept poured coaster showed the epoxy must cover the entire edge of the glass sheet to bond all the slivers in place.
Now that vape “pen” refill cartridges are (mostly) dead, roadside debris has gotten chunkier:
It’s a Hyde Edge Recharge vape pen or it could be a counterfeit. You (definitely not me) get “up to” 3300 puffs from the 10 ml container, with 50 mg of nicotine ensuring you can’t get enough and will come back for more. Although I don’t follow the market, “disposable” vape pens can still contain the fruity flavors prohibited in refillable pens, with the added decadence of throwing the whole thing away when the tank runs dry:
My admittedly inexperienced eye says the “tank”, which is really just a fiber cylinder soaked in fruity juice + nicotine, still has plenty of hits remaining.
The Basement Shop may never smell the same again.
Of more interest, the silvery lump wrapped in a white felt strip is a 600 mA·hr lithium cell that slurped 406 mA·hr through its USB Micro-B jack when I recharged it. Perhaps the user victim sucker tossed it when the battery “died”, being unable / unwilling / ignorant-of-how to recharge it? The yellow aluminum case seems faded on the mouthpiece end, but that might be a stylin’ thing.
A closer look at the electronics payload:
The two red wires over on the right went to the coil in the draw tube to the right of the “tank”. Not being interested enough to care, I wrecked the coil while extracting the rest of the contents. Comfortingly, the red and black wires from the PCB go to the positive and negative battery tabs.
A closer look at both sides of the PCB:
The SOT23 IC sports an LTH7 topmark corresponding to an LTC4054-4.2 Standalone Charge Controller (Analog Devices absorbed Linear in 2017). The two LEDs to its right glow red during charge and white during each puff.
The black felt disk covers an anonymous pressure sensor activating the coil during each puff. With four pins, the sensor must be far more complex than just a switch, but nowadays puff sensing could require an entire ARM microcontroller.
Speaking of microcontrollers, there’s always this fate:
I fought down an almost uncontrollable urge to amputate my arms at the elbows and cauterize the stumps …
Setting up a piece of MDF and hitting the Frame button produced a lightly scorched line around the part perimeter, plus a slightly diagonal track leading from / to the Home position in the far right corner:
Doing another pass with LightBurn’s rubber-band frame produced the faint dotted circle.
Huh. Didn’t useda do that.
The laser should not fire while framing and, having just installed LightBurn’s 1.2.01 update, suspicion instantly fell on the most recently changed thing.
Which turned out not to be the case, as LightBurn’s tech support pointed out:
This is generally an indication of a failed high-voltage power supply, not a software issue.
OMTech’s support requested a video of the equipment bay, which didn’t seem like a useful way to convey the situation. Instead, I sent pix.
This picture shows the status of the 60 W laser power supply while the laser is incorrectly firing:
The power supply has two LEDs on what looks like, but is not, an Ethernet jack near the bottom:
The LASER orange LED near the top turns on when the HV output is active and the laser should be firing.
In this case, L LED is off and the LCD shows “Laser signal OFF”, but the LASER LED is on and the LCD shows 2 mA beam current: the laser beam is ON, even though the controller has not activated the PWM signal.
Not only that, but I discovered the laser would fire while framing even with the lid up and the “safety interlock” sensor active.
Totally did not expect that.
For comparison, the power supply status during a manual pulse at 49% power:
In that case, the L LED shows the PWM signal is active, the LASER LED is on, and the LCD shows 14 mA of current to the tube. That’s how it should work.
Although the function of the TEST button seems very lightly documented, pressing it did not turn on the output (the LASER LED is off), despite lighting the L LED:
OMTech confirmed my suspicion:
We are afraid that the laser power supply is defective
A replacement should arrive in a few days.
Protip: always practice laser eye safety.
A note from Alan adds more data about troubleshooting problems with the classic Kensington Expert Mouse trackball scroll ring:
I have two comments and a question: first I made the mistake of purchasing 4 used expert mice on ebay etc and each had a different problem but 3 of 4 also had faulty scroll rings. 2nd: one of them was dated 2020 (a wireless version). so they definitely haven’t fixed this issue and it’s very wide spread (or maybe why shady sellers decide to part ways with their trackballs).
question: from reading across your quotes it’s not clear but it seems like there is no real consistent fix to this issue nor a really strong conclusion as to what causes it? My futzing with a couple of these does seem to suggest that alignment of the ring makes a difference but not a lasting one.
As far as the alignment non-fix goes, tweaking the detector position just changes the amount of light passing through the wrong side of the reversed IC, without solving the problem. That’s what we’ve all done, with essentially the same results: feels good, doesn’t last.
Kensington (whoever they are these days) may have fixed the problem with a different quadrature detector oriented in the proper direction, but that’s not something we civilians can accomplish.
It should be possible to unsolder the reversed detector (if, indeed, it is), aim the lens (if that’s what it is) at the emitter, then somehow resolder the leads to the same pads. Perhaps flip it to put the leads on the top, away from the PCB, secure it with a generous blob of hot-melt glue, and connect jumpers from pads to leads?
So far, the two new-ish units on my desks continue to work well, depriving me of sufficient motivation to dig into my junkers.
If anybody is willing to hack their defunct trackball, please let us all know what happened!
Because you may be reading this in our future, comments on this particular post will probably have been disabled to reduce the attack surface for spammers. Send me an email / use the comment form (linky over on the right), or comment on the post of the day and I’ll sort it out. Thanks!
Making a coaster with petals from the NBC peacock turned out to be trickier than I expected:
Protracted doodling showed that I cannot math hard enough to get a closed-form solution gluing a circular section onto the end of those diverging lines:
However, I can write code to recognize a solution when it comes around on the guitar.
Point P3
at the center of the end cap circle will be one radius away from both P2
at the sash between the petals and P4
at the sash around the perimeter, because the circle will be tangent at those points. The solution starts by sticking an absurdly small circle around P3 out at P4
, then expanding its radius and relocating its center until the circle just kisses the sash, thus revealing the location of P2
:
t1 = tan(PetalHA);
sc = (Sash/2) / cos(PetalHA);
<< snippage >>
P3 = P4; // initial guess
r = 1.0mm; // ditto
delta = 0.0mm;
do {
r += sin(PetalHA) * delta;
P3.x = P4.x - r;
dist = abs(P3.x * t1 - sc) / sqrt(pow(t1,2) + 1);
delta = dist - r;
message("r: ",r," delta: ",delta);
} while (abs(delta) > 0.001mm);
P2 = [P3.x - r*sin(PetalHA),r*cos(PetalHA)];
The dist
variable is the perpendicular distance from the sash line to P3, which will be different than the test radius r
between P3
and P4
until it’s equal at the kissing point. The radius update is (pretty close to) the X-axis difference between the two, which is (pretty close to) how wrong the radius is.
As far as I can tell, this will eventually converge on the right answer:
r: 1.0000mm delta: 13.3381mm r: 6.1043mm delta: 6.2805mm r: 8.5077mm delta: 2.9573mm r: 9.6394mm delta: 1.3925mm r: 10.1723mm delta: 0.6557mm r: 10.4232mm delta: 0.3087mm r: 10.5414mm delta: 0.1454mm r: 10.5970mm delta: 0.0685mm r: 10.6232mm delta: 0.0322mm r: 10.6355mm delta: 0.0152mm r: 10.6413mm delta: 0.0071mm r: 10.6441mm delta: 0.0034mm r: 10.6454mm delta: 0.0016mm r: 10.6460mm delta: 0.0007mm
Obviously, efficiency isn’t a big concern here.
Having found the center point of the end cap, all the other points fall out easily enough and generating the paths follows the same process as with the simple petals. The program performs no error checking and fails in amusing ways.
As before, laser cutting the chipboard deposits some soot along both sides of the kerf. It’s noticeable on brown chipboard and painfully obvious on white-surface chipboard, particularly where all those cuts converge toward the middle. I applied low-tack blue masking tape as a (wait for it) mask:
Whereupon I discovered the white surface has the consistency of tissue paper and removing the tape pretty much peels it right off:
Putting the chipboard up on spikes and cutting it from the back side, with tabs holding the pieces in place (so they don’t fall out and get torched while cutting the next piece), should solve that problem.
In the meantime, a black frame conceals many issues:
I must up my coloring game; those fat-tip markers just ain’t getting it done.
The GCMC and Bash source code as a GitHub Gist:
// Round Petals Test Piece | |
// Ed Nisley KE4ZNU | |
// 2022-07-17 Coasters with round-end petals | |
layerstack("Frame","Petals","Rim","Base","Center","Tool1"); // SVG layers map to LightBurn colors | |
//----- | |
// Library routines | |
include("tracepath.inc.gcmc"); | |
include("tracepath_comp.inc.gcmc"); | |
include("varcs.inc.gcmc"); | |
include("engrave.inc.gcmc"); | |
FALSE = 0; | |
TRUE = !FALSE; | |
//----- | |
// Command line parameters | |
// -D various useful tidbits | |
// add unit to speeds and depths: 2000mm / -3.00mm / etc | |
if (!isdefined("OuterDia")) { | |
OuterDia = 100.0mm; | |
} | |
if (!isdefined("CenterDia")) { | |
CenterDia = 0.0mm; | |
} | |
if (!isdefined("NumPetals")) { | |
NumPetals = 6; | |
} | |
if (!isdefined("Sash")) { | |
Sash = 5.0mm; | |
} | |
// Petal values | |
PetalAngle = 360.0deg/NumPetals; // subtended by inner sides | |
PetalHA = PetalAngle/2; | |
PetalOD = OuterDia - 2*Sash; | |
PetalID = CenterDia + 2*Sash; | |
PetalOAL = OuterDia/2 - Sash - (Sash/2)/sin(PetalHA); | |
//message("petalOAL: ",PetalOAL); | |
P4 = [PetalOD/2,0.0mm]; | |
// Find petal vertices | |
P0 = [(Sash/2) / sin(PetalHA),0.0mm]; | |
t1 = tan(PetalHA); | |
sc = (Sash/2) / cos(PetalHA); | |
if (P0.x < PetalID/2) { | |
a = 1 + pow(t1,2); | |
b = -2 * t1 * sc; | |
c = pow(sc,2) - pow(PetalID/2,2); | |
xp = (-b + sqrt(pow(b,2) - 4*a*c))/(2*a); | |
xn = (-b - sqrt(pow(b,2) - 4*a*c))/(2*a); | |
y = xp*t1 - sc; | |
if (FALSE) { | |
message("a: ",a); | |
message("b: ",b); | |
message("c: ",c); | |
message("p: ",xp," n: ",xn," y: ",y); | |
} | |
P1 = [xp,y]; | |
} | |
else { | |
P1 = P0; | |
} | |
P3 = P4; // initial guess | |
r = 1.0mm; // ditto | |
delta = 0.0mm; | |
do { | |
r += sin(PetalHA) * delta; | |
P3.x = P4.x - r; | |
dist = abs(P3.x * t1 - sc) / sqrt(pow(t1,2) + 1); | |
delta = dist - r; | |
message("r: ",r," delta: ",delta); | |
} while (abs(delta) > 0.001mm); | |
P2 = [P3.x - r*sin(PetalHA),r*cos(PetalHA)]; | |
PetalWidth = 2*r; | |
if (FALSE) { | |
message("P0: ",P0); | |
message("P1: ",P1); | |
message("P2: ",P2); | |
message("P3: ",P3); | |
message("P4: ",P4); | |
} | |
// Construct paths | |
PetalPoints = {P1,P2}; | |
OutArc = varc_cw([P2.x,-P2.y] - P2,-r); | |
OutArc += P2; | |
PetalPoints += OutArc; | |
if (P0 != P1) { | |
PetalPoints += {[P1.x,-P1.y]}; | |
InArc = varc_ccw(P1 - [P1.x,-P1.y],PetalID/2); | |
InArc += [P1.x,-P1.y]; | |
PetalPoints += InArc; | |
} | |
else { | |
PetalPoints += {P0}; | |
} | |
//--- Lay out the frame | |
linecolor(0xff0000); | |
layer("Frame"); | |
if (CenterDia) { | |
goto([CenterDia/2,0mm]); | |
circle_cw([0mm,0mm]); | |
} | |
repeat(NumPetals;i) { | |
a = (i-1)*PetalAngle; | |
tracepath(rotate_xy(PetalPoints,a)); | |
} | |
goto([OuterDia/2,0]); | |
circle_cw([0mm,0mm]); | |
//--- Lay out internal pieces for oriented cutting | |
// baseplate | |
layer("Base"); | |
relocate([OuterDia + 2*Sash,0]); | |
goto([OuterDia/2,0]); | |
circle_cw([0mm,0mm]); | |
// central circle | |
if (CenterDia) { | |
layer("Center"); | |
relocate([OuterDia/2 + Sash,-(OuterDia - CenterDia)/2]); | |
goto([CenterDia/2,0mm]); | |
circle_cw([0mm,0mm]); | |
} | |
// petals | |
layer("Petals"); | |
repeat(NumPetals;i) { | |
org = [PetalWidth/2 - OuterDia/2,-(OuterDia + Sash)]; | |
relocate([(i-1)*(PetalWidth + Sash) + org.x,org.y]); | |
tracepath(rotate_xy(PetalPoints,90deg)); | |
} | |
// Debugging by printf() | |
if (FALSE) { | |
layer("Tool1"); | |
linecolor(0xff1f00); | |
goto([Sash/2,0mm]); | |
circle_cw([0mm,0mm]); | |
goto(P0); | |
circle_cw([0mm,0mm]); | |
goto([0,0]); | |
move([OuterDia/2,0]); | |
goto([0,0]); | |
move(OuterDia/2 * [cos(PetalHA),sin(PetalHA)]); | |
goto(P2); | |
move_r([0,-PetalWidth/2]); | |
} |
#!/bin/bash | |
# Round petals test piece | |
# Ed Nisley KE4ZNU - 2022-07-17 | |
Flags='-P 4 --pedantic' # quote to avoid leading hyphen gotcha | |
SVGFlags='-P 4 --pedantic --svg --svg-no-movelayer --svg-opacity=1.0 --svg-toolwidth=0.2' | |
# Set these to match your file layout | |
ProjPath='/mnt/bulkdata/Project Files/Laser Cutter/Coasters/Source Code' | |
LibPath='/opt/gcmc/library' | |
ScriptPath=$ProjPath | |
Script='Round Petals.gcmc' | |
[ -z "$1" ] && petals="6" || petals="$1" | |
fn=RoundPetals-$petals.svg | |
echo Output: $fn | |
gcmc $SVGFlags \ | |
-D "NumPetals=$petals" \ | |
--include "$LibPath" \ | |
"$ScriptPath"/"$Script" > "$fn" | |
First you mix the epoxy, then you blend in the dye, then you dispense it into the thing you are making. If you’re using many colors, this is obviously not the right way to go about it:
A bit of pondering converted some scrap MDF into a rack holding the little cups and dispensing pipettes:
The bar magnet holds the backplate against a bench block to keep it at right angles to the base while the adhesive cures. The base is three layers of MDF with no, small, and large holes fitting the cups. I expect many epoxy spills; scrap MDF reduces deep emotional bonding to the result.
The LightBurn project has the sign outline as a tool layer to simplify aligning the victims with the laser path, plus one layer defining the cuts for the three plates. I exported it as an SVG image with the same information as colored vectors for use in whatever laser control program you might use.
The SVG image as a GitHub Gist: