Hot melt glue gun timer

I use hot melt glue a lot, but the warmup time is a problem.  I turn the gun on, go away to do something else while it warms up, and may or may not remember the pending glue job.  I’ve found the gun on 2 days later.  Not good.

I solved the main safety problem a couple of years ago with a mechanical timer.  Now the switch on the gun is always on, but it turns off after 10 minutes or so whether I remember to come back and use it or not.  Of course when I run across the incomplete glue job an hour later, I have to start all over.  An “it’s hot” notification would be very helpful.

While there isn’t easy feedback from the gun when it’s hot (yeah, a current sensor would work), open loop timing is good enough for the task.  Sitting around and observing when the gun was up to temp gave the critical info: a little under 4.5 minutes.

Fifteen lines of Arduino code (plus a couple of #defines) on one of my general purpose ATtiny85s and a little piezo buzzer gave me a timer that beeped once when the gun was hot, twice one minute later, 3 times another minute later, etc.  The dollar 5V wall wart from Goodwill that powers it is plugged into the same outlet as the gun, so the mechanical timer turns them both on at the same time.  OK, wrapping it all in blue painter’s tape is pretty crude packaging, but it works.

Putting the buzzer near the basement door increases the chances I’ll hear it even if I’ve left the basement.  It was put in place 11/14, and works absolutely great.

When I upgraded recently from my drooling old Dremel 1200 glue gun to a Tec 805-12, warmup time dropped to just about 2 minutes.  The old Arduino code was still safely in my sketchbook, so changing one #define and adding a couple of comments, and it was good to go again.  I discovered with pleasure that power to the Tiny was plugged into the unmodified ICSP header, so reprogramming it was trivial.  It works great again, and the reduced time ’til that first beep is icing on the cake.

Posted in Tiny 85 stuff | Tagged , , , | Leave a comment

Repair attempt of Grohe Quick Coupling

While in the middle of repairing the kitchen sink drain plumbing, I noticed a fairly significant leak under the sink.  OK, I’d failed to tighten one of the new plastic drain couplings in between repair sessions.  Fine.

But that didn’t fix most of it.  More observation found that it was coming from the source end of the flexible hose going to the faucet’s pull-out spray head.  Our Grohe LadyLux Plus faucet features a quick-connect (“Quick Coupling”) between the valve assembly and the hose to the spray.  This is a standard Grohe part, and for $30-40 I can get a replacement of the plastic end of the connection.  We have the yellow one (46 318000).  Installation is trivial.  And the leak is still small enough for a tray under the sink to catch it all.

I’m cheap, but not that cheap.  Send in a little money, get the part on the doorstep, 5 minutes work and Done.  I don’t have much problem with that.  Of course as several reviewers have commented, it’s pretty expensive for a plastic part.  And the part’s not damaged, and might be fixable.  It’s worth a try.  (So to be clear:  The motivation is maybe 20% cheap, and 80% “I can probably fix this.”)

The actual seal is an O-ring inside the plastic part.  It’s barely visible in the picture; feeling it with a probe was what convinced me of its existence.  (Just a guess, but that 25 cent part is probably all that’s needed in 90% of the repairs.)  It fits against the smooth outer surface of the male end coming from the valve.  A leak in a seal like that is often due to the crud and lime of the ages.  I’m a little surprised that no one mentions crud on the surface of the male part in discussions of repair by replacing the plastic part.

The repair plan

So the plan is to swab out the inside of the plastic part with Lime Away to get rid of the calcium deposits on the O-ring, clean the outside of the male part, and put ’em all back together with waterproof silicone grease.  Here we go.

Looking inside the plastic part, there was clearly some sort of device, but several commenters said the yellow (and green) versions don’t have a flow restrictor (though other colors do).  I vaguely recall that I might have removed a flow restrictor from the spray head end when it was all new, but I’m not sure.  And I could blow thru the plastic part both ways, so it obviously wasn’t a check valve.  But as I poked around with a Lime Away soaked Q-tip, that inside part seemed to move – and be spring loaded.  After some cleaning, it went from brown and crud-encrusted to pretty blue and white plastic parts.  And once cleaned out, it turned out to actually be a check valve!  A sensible (high end) feature – so the water in the hose doesn’t drain out when you disconnect the hose.  I rinsed it all out well, and called that done.

I scrubbed down the metal male part with a very well worn green scrubbie (couldn’t find a white one) soaked with Lime Away.  I tried to twist around the pipe rather than rubbing along its length, in case I introduced any scratches.  Unlikely, but…  It certainly looks cleaner, but the green ring of crud seems to remain.  I wonder where that hits with respect to the O-ring.

A significant part of the hope of helping it seal is a nice slathering of silicone grease.  Another Q-tip with that (on both surfaces), and it was ready to reassemble.  Done.

Fingers crossed – let’s see how it fares!  A couple of hours and a round of dish washing, and it’s still dry.  An update will follow.

Update 9/13/17: It’s been over a month, and no leaks.  I’m going to call this one a success and Done!

Update 12/13/17:  Well, not done.  It leaked some more. 🙁   I ordered the Grohe part ($34/free on eBay) and installed it 11/28/17.  I did do one more round of cleaning of the male fitting, put silicone grease on again, and the whole replacement was the 5 minute job I expected.

I put a shiny black plastic tray under it with grains of table salt in the low places.  It’s been in place for a couple of weeks now, and the salt says there have been no leaks.  I think it’s really Done this time.  (Of course I thought that before…)

About the only explanation I can come up with for why the new part worked is that the rubber in the new O-ring is newer/more live.  If that’s the case, replacing just that ring should have worked.  I probably could have gotten the old one out, if destructively.  And I could probably have managed to force a new one into place.  But I didn’t want to have to try to spec and source the part.  And with mud on my face from the first failed attempt, the 5 minutes and $34 was an acceptable cost for being Done.

Posted in Home Repair | Tagged , , , , , , , | Leave a comment

Resurrecting Pogo HA server (and replacing a BGA chip!)

I got a watchdog email shortly before we left for the April Adventure weekend (email: 4/20 6:45P) about datafile and camera pic being older than the 1260 sec threshold.  I couldn’t get it running the morning before we left, so didn’t start real recovery efforts until 4/24.


I couldn’t ping or ssh to the box, so I power cycled it.  (Yeah, that’s a little harsh for a Linux system – but I didn’t have many choices.)  Nothing.  I looked around for backups, and found one – from 6 years ago!

I uncabled the box (power, 485 net, ethernet) and brought it out so I could plug into the 3.3V serial console pigtail I’d installed early on.  It didn’t boot as expected, so I tried to look at the system thumb drive.  The main Win10 PC, jimsdellmini (Ubuntu) and Gparted on the red kitchen laptop all did not detect that there was a thumb drive plugged in.  They did see the USB device (like with lsusb), but no storage drive.

I found a very similar 4GB Microcenter drive (with silver laptop Clonezilla on it) and in desperation decided to try to swap the flash chips to try to recover the files, hoping it was the board or controller chip rather than the flash chip that was bad.

Here are the boards, and the back sides with the flash chips.  Oh no – they’re BGA!  Looks like the boards were set up both to take a second flash chip and to take either BGA or leaded (TSSOP?) chips.  Thanks for these using BGAs, Murphy.  Not.


All work below was with air:3 and heater:8 and a smallish (0.198″OD) tip on the AUYOE Int 906.  I worked with the chips and boards on a firebrick.

First I unsoldered the good chip from its card with hot air.  Took a couple of minutes, but seemed successful, and gave me a little hands on practice with the hot air.

Then with vague hopes that the bad drive might just have a bad solder joint, I reheated that board, hoping to reflow the bad chip in place on its original card.  When I tried that in jimsdellmini, it still did not show up as a memory device (though it did show up in lsusb).  Nice try.

Then I unsoldered the bad chip from its card.  I put the good chip on the bad card – no prep, no reballing, no cleanup.  I reheated it, purely guessing at the time.  I watched closely, but never saw it move or recenter.

When I plugged the bad card with the good flash into jimsdellmini, the OS found the device and I could see the files from the flash (old clonezilla files).  Plugging it into the Win10 PC, that could see it and its files as well.  Wow – I just successfully resoldered a BGA chip!

Encouraged, I cleaned off the bad chip with flux and solder wick, and ran a ball of (leaded) solder across it, providing what looked (to eyes that had never seen one) like an appropriate reballing.  I cleaned the previously good card with flux/wick, put the reballed bad chip on it, then heated it to reflow.  Watched, but never saw it move.  Did wiggle the board a little a couple of times to try to help it find home.  After I let it cool, the chip seemed well adhered, so presumably at least some solder melted, though I can’t be at all certain all the balls did.  But I’m hoping the extra prep increased the chances of good soldering compared to the first (good chip, bad board) try – which worked with no extra prep.

When I put the good board/bad flash in jimsdellmini, lsusb could see it, but it didn’t appear as a file system.  The Win10 PC could see the device, but no file system as well.  Nice try.  🙁

Despite efforts to take good notes, either I screwed up multiple times or the USB ID moved with the flash chip (which is very unlikely).  Boo on me.  But I eventually did enough retries comparing lsusb output to convince myself I had done what I intended (like not putting the bad chip back on the bad board), and that it really didn’t work.

In any event, I’ve done all the due diligence I know how to do, and so can completely give up on trying to resurrect the files from the old working drive.  Bummer, but with closure.


OK – I’m now confident I’ll never get the files back from the original thumb drive.  Time to move on.  I had a backup tar from 10/6/11 (!), and with the notes here untarred it to a random 8GB drive from the thumb drive box.  It booted, and thanks to the serial console, I got it sort of running.  I think the ftp password to the Godaddy host had changed, and the IP of the AT&T first router had changed, and probably some other stuff.

But its (6 year!) old talked to the existing HA nodes, got data from them, and pushed it to the Godaddy host.  We’re back on the air!

Well, sort of.  All the camera stuff was implemented after that backup, so had no hope of working.  And the graphs didn’t update like they used to.  I feared the data format had been updated somehow, and the parser on the web host was looking for something that wasn’t there any more/yet (and that I had zero recollection of).

Several weeks later (6/20/17), I dug around trying to figure out why the graphs didn’t update.  Between looking at the code and finding and reading the note on “Home Page Speedup”  I slowly realized the poll perl script on the Pogo not only ftp’d update data, but invoked (with wget) the graphs.php script on the host that actually updates the graphs.  After a few stumbles I put that into a new and got it working.  Now the graphs update automatically again – yay!


First on the agenda is a workable backup method.  I don’t remember whether I had a backup script on the old drive, but at least there’s a good start in the project notes from the last painful rebuild.

I copied and touched up that script so just running “gobackup” in perl/backup will (presumably) make a backup tar file and put it on the main PC as F:\pogobackup.MMDDYYYY.tar.  If I can just remember to run that when I make a change (or maybe put it in a cron job)!  To that end, I put a banner in the motd saying “IF YOU TOUCH ANYTHING HERE, UPDATE THE BACKUP!”  And after was actually running graphs.php, I kicked off a backup. 🙂  A backup file appeared on the main PC, but I haven’t tried to put it on a new thumb drive.

Maybe make a watchdog that checks sums on some main files and sends an email backup reminder if they’ve changed?  What files?  Main perl files, hosts, rc stuff?  Should all data like credentials be hosted in a single file and read by the scripts?  Here’s a first crack at a list:

in /perl:
in /etc:

Update 7/15/17:  Woo hoo!  I think I got a first hack of the camera working again!  A first problem was that the main disk on jimsdellmini – which hosts reading from the camera – was completely full (and I couldn’t figure out what it was full of).  I dug some more and removed several old kernels and the associated stuff in /lib/modules.  Now I can at least work on the machine.  Hmm – that machine’s not backed up at all.  But it’s still running, and the old scripts are still there.  I plugged in an external hard disk, but it didn’t seem to see it.  I plugged in an old 1GB thumb drive and got it mounting to /media/CameraDrive.  Steps 0,1.

Looks like ~/perl/gosnaps reads from the camera, gets snapshots and puts them in /media/CameraDrive, then calls putpic to send latest to the Pogo.  Putpic ftps the latest to <ftproot>/pics with its timestamped file name, removes old latest.jpg, and copies the latest also to that filename.  Of course it needs an ftpd running on the rebuilt Pogo – which it wasn’t.  Got that running, but putpic doesn’t supply any credentials.  Added user jim to the Pogo, and some flag somewhere allowed auto logging-in of ftp.  I made a symbolic link in /srv/http to /srv/ftp/pics/latest.jpg, and I could see it in a browser looking at the Pogo.  It works!  Steps 2,3 done.

The main script already has stuff to implement regular (5 min) ftps to the GoDaddy host, so I copied one of those blocks of code, and after way more playing with the it uses than I cared to do, got that set up to push the latest pic to the real host.  And that seems to work, too!  Of course, the nice go485 script that used to pkill the old 485poll and restart it somehow stopped working, presumably with one of those kernel updates.  I can’t yet see how to pkill it, so must manually kill 2 processes and then manually restart it.  But at least go485 now prints out instructions on what to do.  And I even kicked off a backup with the new in it!  Oh, but /etc/rc.local still started  Rats.  But at least now doing the additional backup to capture that was easy.  I suppose I should untar it to a new flash drive and test it.  One more thing on the list.  But now I get pictures!  Steps 4,5,6A,6B done.

And the terrible displays recently on the home page turned out to be 2 instances of running.  (The old go485 script hadn’t killed the old one.)  Fixed that.  Wanted to clean out the data in datafile.csv, but decided to just let good data accumulate and fix itself in 5 days.  Cleaning the intermixed data was harder than I hoped. 🙁

But I did hack in an init in the power outage section of graphs.php that should stop the long-standing problem of displaying one phantom outage every time I’d trim datafile.csv.  Seems to work now.

Update 7/19/17:  Looks like the woo hoo on getting the camera stuff working was premature.  Yeah, it worked, but several hours later it stopped, with error messages on jimsdellmini about no space on device.  Yeah, the thumb drive is only 1 Gig – but c’mon, it it can’t be full yet!  And df showed only 4% used!  Tried touch abc – no space on device.  Same, as root – no space on device.  Deleted the 171 pics, and it all started working again.

Turns out there’s a limitation on FAT 16 (with which the 1GB thumb drive was formatted) on number of files in the root directory, and if the file names are long the limit is hit much more quickly.  I guess “snap07-19-23-59.jpg” qualifies as a long name.

I suppose I could have tweaked a couple of scripts and stashed the image files in a subdirectory, but I just reformatted the thumb drive ext2 with fdisk.  Works fine days later.  There’s also a daily cron job that clears out files older than 24 hours, so it should work for plenty long enough.  (Turned out to be older than 30 days.)

Update 8/18/17: The random 8GB thumb drive I rebuilt as a Pogo system disk failed.  This time I schlepped the new HP laptop over with a 3.3V USB-serial cable and plugged it in before I did anything else.  Nothing.  I power cycled it and got a shell from flash – no USB boot.

Put the thumb drive in the main Win10 PC, and with ext2explore.exe copied the very latest, which hadn’t been saved to a backup tar yet.  Yay!  Everything else should be OK in the latest tar file.  I hope it works – I’ve still never actually tested it.

Tried fsck on the thumb drive in jimsdellmini, and it gave a zillion errors.  Let it run – twice – but couldn’t read the drive when remounted.  Took 2 tries, but deleted partition table and recreated with fdisk, then put new ext2 fs on with mkfs.  Copied latest tar over, but oopsed and untarred the 2011 tar instead.  Took a LONG time.  Discovered what happened when I tried to replace – and it wasn’t there.  Carefully did rm -rf on the thumb drive (another LONG time), then started to untar the right file.  SLOW.  Gave up with ctrl-C.  Jimsdellmini wasn’t happy with that, and never really unmounted the drive.

Put in a brand new 16GB red Microcenter USB3 drive, fdisk‘d a new partition table, new mkfs, and untarred the right file.  Much faster, as expected.  Plugged it into the Pogo, and with laptop still connected, watched it boot.  Success!

No house pic, tho.  Finally killed a days old ftp process on jimsdellmini.  A few minutes later, a good pic had propagated all the way to the Godaddy host.  Yay!  Looks like all the scripts on the Pogo do in fact start on boot – and the backup tar works!

I hope the brand new thumb drive lasts longer than the 8GB fold-flat credit-card drive from some patent law freebie I used last time.  And why do these things always happen the night before I have a long drive to a weekend?

Update 8/30/17:  I’ve been fighting on and off with being out of storage on the “camera drive” on jimsdell mini.  It’s been running that 1GB thumb drive for a while, and just failed again.  Thankfully the “house picture old” watchdog fired and sent email.  Turns out once again the drive was full (but really, this time).  There’s a cron job purging files matching a find -mtime +30 (days), but that wasn’t aggressive enough for this tiny drive.  After I manually deleted several days’ worth of pics, it started working again.  How many days’ worth will the drive hold?  It looks like nite pics (B/W) are ~26KB, while day pics are more like 110KB.  Doing an ls |wc  on /media/CameraDrive gave 10586 files, while df showed 658048K used.  So that averages about 62KB/pic.  At 24*30 pics/day, we burn about 45MB/day, so the 1GB drive should hold around 22 days of pics.  I changed the cron job to -mtime +15, so it should take care of itself now, and run around 30% free.  We’ll see.


  • I’d really like to move the camera stuff to the Pogo, if I can.  The old (and newly current)  system uses jimsdellmini to get images from the camera and push them to the Pogo, which eventually pushes them to the host.  I think the two reasons I originally used another machine instead of hosting all that on the Pogo were a) a concern that the somewhat compute-intensive image processing burst might interfere with the serial polling of the HA nodes, and b) not wanting to have the HA system bouncing while I tried to get it all working.  But if I integrated the camera stuff into the main poll script rather than as a separate process, I could avoid interfering with the serial polls.  And I’d get jimsdellmini out of the critical path and more usable for other stuff.
  • And of course implementing a more rational database – like RRD? – has been on the list for a long time, but that’s a pretty big deal.
  • It would often be helpful to have an easy way to add annotations to any of the graphs/data sets to comment on special things that happened.  That will probably wait until a more final database is implemented, but who knows?   Update:  I could make each power outage line a link to a (password protected) page that would prompt for a comment.  Prepending exactly the posted outage line (timestamp and duration) to the comment, maybe with ‘;’ delimiter, the comment line would be appended to a comments file.  When printing the outage lines, I could grep out any matching lines from the comments file.  Maybe.
  • And I’d really like the water meter reader to work again.  I even looked at it a few weeks ago and could see that the optics could still be aligned on the red spinning arrow, providing enough brightness variation that I’m surprised the phototran couldn’t see it.  Maybe it’s just a drift/reset the bias thing.  Update: Looks like the city’s going to replace all the water meters, so the clever-but-not-clever-enough-to-keep-working optical telescope will soon be completely obsolete.  More here.
Posted in Home Automation | Tagged , , , , | Leave a comment

IR comms considerations (for penlift for the Drawbot)


I was planning to hold this to be part of a much larger writeup of the Drawbot, but while it started as part of that project, it sort of took on a life of its own as an IR comms optimizing exercise.  I blew a huge amount of time on this, sticking my head in the sand and ignoring other things I really should have been working on.  I kept thinking “just one more test” – but that wasn’t how it worked.

The first version of the pen lift for the Drawbot included a nice servo mechanism driven by a Tiny85, but time forced the major ugliness of a light pair of wires from the main Arduino to carry control info to the gondola.  It worked fine, but those wires were never supposed to be there.  IR communication was the plan.

Finally, using a (20 year?) old 3 pin 38KHz IR receiver still in its Radio Shack bubble pack, I made up a PCB with a Tiny85 listening to the receiver module, driving the servo to lift the gondola and red and green status LEDs (for pen down/up).  I defined a simple pulse position protocol (in DrawbotStuff/DrawbotTinyServo4_IR.ino) on top of the required 38KHz pulses to deliver the 1 bit (up/down) messages, made up a test sender with an Arduino and an IR LED sending alternate state messages every half second and got it working.

A little aluminum bracket glued to the back of the PCB clips it to the gondola.  Servo and power wires were both perfect length to go to the board.  Sometimes we just get lucky. 🙂

Unfortunately, I wondered whether a useful improvement in range could be made by increasing LED current, along with a corresponding decrease in pulse width.  Now, the plan is to use 3 IR LEDs spread across the width of the Drawbot base, shining up at the gondola so even when it’s at the bottom corners of its movement, it will still have a transmitter LED more or less under it (ended up with 6).  And with one LED at 50% duty cycle and 20mA – completely within the LED’s specs – I can get range much greater than to the top of the Drawbot.  So it really doesn’t need any range improvement.  But I just had to go and ask the question.  Bad decision.

Rick S suggested a 50% duty cycle would contain the most energy at the fundamental, thus providing max signal after the receiver’s bandpass filter.  Sounded like a reasonable argument against a range increase.  I tested at the space with 5.5 mA/50% DC pulses and got range (go/no go, with the actual receiver and protocol) of 50″.  Dropping to 25% DC but still 5.5mA, range dropped to 40″.  I can believe that.  Keeping 25% and increasing current to 11mA range went up to 167″!  WTH?

Christine suggested maybe the LED output was nonlinear and at the lower current wasn’t putting out as much as expected.  I tested with a very small 8 cell Si solar panel directly into my bench meter in current mode (~100 ohms), which I think is a good way to test for light energy in.  (I crudely covered the panel to keep out ambient light.)  Results of output current v LED drive current were VERY linear, 1-30 mA.  So I think doubling the current does indeed double the light output.

(A vaguely plausible explanation for the wild range increase  (sorry for no pics 🙁 ):  The test was done with the LED near the end of one of the gray tables at the space, maybe 5″ above its surface, and aimed horizontally.  *Maybe* – energy off axis, which should never have come into play, hit the table top and reflected/diffused off toward the 167″ away receiver over another table.  That effect could be eliminated by mounting the LED out in space, not over a possibly reflective surface.  A subsequent test with similar currents but without the problem table did not show the wild range increase.)

Of course while testing using the actual intended receiver and message protocol provides great “real world” chops, it violates my “No boolean failure indications!” rule.  I should really structure a better test indicator.  Hmm – if I can’t get inside the receiver module to get an analog indication of how close we are to max range threshold, what if I can control the stimulus – LED current – and use that to sneak up on the indicator?  (Interesting idea, cost me lots of time digging into how to get an analog handle on LED current with a bench supply, but never got used.  All I did was suffer along with the go/no go indications of the IR receivers. 🙁 )

A good next test would be another doubling (or more) of LED current (with corresponding decrease in duty cycle to keep from blowing the LED) and testing range.  Maybe simplify the pulse train to eliminate any funnies created by my protocol, and maybe use a newer (and just different) IR receiver module.

Range test approach

Ugh.  The first tests (at W88) were with 2 known resistors that measured a factor of 2 difference in LED current: 5.5mA and 11 mA.  I kept the current low so the range would be manageable.  But the results were just unreasonable.

For the next round, I wanted to compare the range with a known LED current at 50% duty cycle (of the 38KHz pulses) with the range with a considerably higher current and correspondingly lower duty cycle (to not smoke the LED) – for nominally the same energy per pulse.  How hard can that be?

The lowest duty cycle I could easily arrange on the Arduino at 38KHz was 20%:


That gave me a 2.5:1 change from the 50% D.C. (duty cycle) I took as reference.  That should be enough to see whatever effects there are by increasing LED current by a factor of 2.5.

To provide known current pulses, I set the IR LED up with a fixed resistor and an adjustable bench power supply.  Pulse current was gated by a logic level MOSFET driven by an Arduino (or sometimes a bench pulse generator).  I mounted the FDS6670 MOSFET (in its odd SOIC 8 package) with power, logic in, and load connections so it might be reused some time.

By measuring the voltage pulses across the known resistor (with my nice new scope), I made a table of supply voltage v LED current so I could easily produce any desired LED current.  That approach was chosen so changes in the forward voltage of the LED would not affect the results.  The first 2 columns below show the results.

I, mA   Vsupply   Vsup, computed
  2       1.55     1.53
  5       2.16     2.26
 10       3.27     3.36
 20       5.57     5.56
 40      10.6      9.88
 50      11.6     11.9
 80      18.5     18.6
100      22.8     23.0

(In hindsight, the limited accuracy of reading the pulse amplitude on the scope introduced more error than the LED.  Better would have been to measure the LED’s forward voltage at a couple of currents, measure whatever drop there was across the MOSFET (if any), interpolate the LED voltage and compute the supply voltage.  Working backwards and subtracting the drop across the resistor at each current from the required supply voltage in the table above, I computed LED voltages between 0.6 and 1.17V, with no particular correlation with current – awful.  Still close enough to be useful – just not very ideal.  Measured DC LED Vf=1.19V @10mA.  Later I computed the Vsupply based on known Vf (third column above); that’s what I used for subsequent tests.)

Knowing I’d need a long straight shot, I mounted the LED (with Arduino dangling) on a stick hanging out in space so it could see past various obstructions, “up” a small staircase, and along the floor on the next level.  At 50% duty cycle and 50 mA, it worked for the full 44′ shot.  (11′ down the computer bench, 6′ to the stairs, 7 ft “up” the stairs, and 20′ across the kitchen.  View from the LED is on the left.)

Unfortunately, I never got very crisp results.  The go/no go indication of the pen lift receiver was too capricious.  Once again, I could see some decrease at constant current going from 50% to 20% duty cycle.  But when I tried to change current, results were unclear.  (Note that the observation of range decrease going from 50% to 20% DC has no relevance to the tradeoff we’re investigating.  But it’s a very easy test, and can at least give some warm fuzzies when it behaves as expected.)  Hmm – might there have been reflections from the kitchen floor – very analogous to the table in the tests at W88 – confounding the measurements?

Trying to get better results, I made up another simpler receiver, using a different IR module and just an LED.  After verifying that this one was indeed open collector (the RS one wasn’t), and getting past some dumb mistake, I second guessed myself and made it and remade it so the LED would be on, then off, then on when pulses were sensed to make the most usable tool.  (Is it easier to see it stutter off or on at the ragged edge of range?)  Here it is as used, with some random little LiPo cell.

But it’s not that simple.  In reading the datasheet for the common Vishay TSOP devices, I found you can’t just send continuous 38KHz pulses – something about AGC.  It’s designed only for messages, and messages have a maximum length, and dead time is required between messages.  That meant I would have to rewrite my test sender, honoring the gaps, but still giving a ‘mostly continuous’ indication on the receiver.  Yeah, it’s just datasheets and code and design decisions, and yes, I can do it all, but boo.  So I did it.  Boo.

Trying to decrease the range (to make measurement easier) while staying pretty linear, I made a little diffuser/attenuator out of a bit of plastic tube that (when split) fits over the (5mm) IR LED and has a Kleenex cover taped over the emitting end as the diffuser.  I can’t imagine its effects could be brightness dependent.  It might, however, act as much more of a point source, changing the parts of the range behavior related to the narrow beam divergence created by the LED’s lens.  Ugh.

Real test results (finally!)

Using the new supply voltage values, new code on the penlift board, new code on the test driver Arduino, the 3d version of the independent receiver, and clamping the LED on the edge of the bench looking out so  there wouldn’t be any possibility of unintended reflections, I did some tests.  Finally.  To keep from further frying the LED’s resistor (oops), I quit the 50% DC tests early.  (I really need to remember to consider power more consistently in electronics hacks.  As well as thermal  effects in chemical hacks.)

The new sensor (with new “as continuous as I dared” pulse stream) worked, but not great.  Its LED was constant brightness (and blinking at ~10Hz), but gently started to dim as it reached max range.  Then it went out.  I tried to gauge where it just started to dim (what a terrible indication!) and moved just a little closer for the official range.  Uncertainty was a couple of inches.  Ugh.

The penlift receiver exhibited some kind of hysteresis.  I’d move away until it stopped responding, then go closer again so it restarted.  But then if I went away very slowly, I could get an extra inch or five.  This was over the course of several seconds.  Parts of the AGC seem to be very slow.  Again, I moved a little closer than the very furthest I could finesse for the official measurement.  For both the penlift and the alternate receiver, I moved around in space to make sure I was fairly centered on the beam.

The new receiver, tested with the diffuser shows the expected (and unimportant) behavior of somewhat shorter range (~72%) when DC is reduced from 50% to 20%.  For the payoff test of decreasing DC and increasing current by like ratios:  Using the 20mA->50mA points nets a 15% range gain.  Using 10mA->(interpolated) 25mA gives a 32% gain.  That’s probably statistically significant, though hardly a “Hallelujah!”.

Data from the penlift – including its protocols – with the diffuser provides similar range decrease (66%) in the irrelevant dropping DC test.  The payoff tests – two pairs of direct data and one interpolated – gives an average range gain of 8%.  Big whoop.

The penlift with naked, lensed LED – the configuration I had expected to use all along – again gives similar range drop (70%) with reduced DC.  But the payoff tests – real data for 2->5mA and extrapolated for 5->12.5mA (ran out of room to go any farther!) average 62% gain.  But there’s a partial explanation:  Graphs of both data sets covering several points (the ones with diffuser) show a clear curve – with greater slope at low currents.  Since the scant data points we have are at the bottom, steepest part of the curve, one could argue that current increases have more effect there.  But (in a fit of sensibility!) I haven’t done any curve fitting to see if that’s justified.

The bottom line

Results were mixed, but it does look like increasing current and decreasing duty cycle, here both by a factor of 2.5, increased range by 10% – 30%, possibly more in some cases.  Interesting.

But putting my adult hat on for a moment, this was all unnecessary for the case at hand:  At just 5mA and 50% DC, the penlift worked out to 16 feet.  The farthest the gondola can ever get from the LEDs is a little over 3 feet.  But once some dumb question insinuates itself into my head, rational behavior is out the window.  Ugh.

Update some months later:  The actual drawbot pen lift works perfectly with this overengineered comms mechanism.

 Notes on IR receiver modules

For at least my future reference, here are some random bits I learned diving down the IR receiver rabbit hole:

  • The receiver modules are cheap and wonderfully effective.  Just use one!
  • They come with center frequencies from 30-56KHz.  It doesn’t matter which you use, but do be sure your transmitter matches it.
  • There are several quite well documented control protocols used by commercial remotes.  The IR receiver docs often include nice info on them.
  • These things are expressly designed for delivering small (a few bytes max) asynchronous messages, and REQUIRE gaps between them.  They’re NOT designed as general purpose comms links.
  • They will (usually?) detect the beginning of a pulse stream in well under a millisecond.  But their AGC/other internal timing is very much not designed for DC carrier.  Don’t try to use them for a (normally on) beam break application!
  • There are multiple versions of modules tuned for different use cases.  I ran across families supporting “AGC 2” and “AGC 4”.  Presumably there are at least two other AGC classes.  There are versions for “short” and “long” data packets, and something called “continuous”, though it might need gaps as well.  I’d guess they would all work for simple hobby applications.
  • If you can’t get a datasheet for a junkbox/surplus IR receiver and don’t know the pinout, the following is alleged to have worked well and never fried any parts:  With a 1K resistor between the power supply and the device (for safety), just try all the possible pinouts of power/ground/signal out while shining a TV remote at it until you find the one that works.
Posted in Drawbot, Tiny 85 stuff | Tagged , , , | 1 Comment

Chinese nail blocks not a fraud

Well, that was informative.  As Ziggy taught me to say back at Reuters, “The test is the test.”

cheapieblock4703When Scott told me about keeping a nail buffer block on the bench to provide 4 grits of sandpaper in one convenient, easily replaced tool, I thought I’d try it.  But after the 4-for-a-dollar Chinese cheapies arrived, they didn’t seem to do anything!  Even the coarse side didn’t begin to do what even the fine side of an emery board did.  I was convinced they’d just glued 4 colored pieces of paper to a nice foam block.  OK, I could glue some real sandpaper to the nice block, but that’s not what I was trying to buy.

But just because my fingers couldn’t feel any grit (at all!) didn’t mean the blocks were a fraud.  How could I test it?  How about “sanding” a piece of polished acrylic with them?  What about controls?  Name-brand commercial products exist – and surely those aren’t frauds.

The test

products4675Armed with products from Revlon and Trim for comparison, I set up the test.  Knowing I was going in with a strong bias, I tried to basictestsetup4664make it as objective as I could.  I put a 22 oz anvil on the pad (with a bit of sticky waffle rubber between to reduce slipping), and tried hard to not apply any force normal to the plastic as I scrubbed.  I revlonsetup4665arbitrarily chose 16 strokes back and forth for each sample as a nice round number.  Of course while the anvil provided constant force, it certainly didn’t provide the presumably more important constant pressure on the various sandpapertapedtoblock4667width and stiffness blocks.  Oh, well.  (Oops.)

I included some 1200 and some 2000 wet/dry sandpaper as well.  I just taped some bits of those around a block for a comparable test.


depthgauge0827To take closeup pics of the scratches, I mounted some little short FL positive lens in a bottle cap that just lightly press fit over the lens on my usual camera.  A bit of wire made a distance jig.  A black background and camerasetup0832side lighting seemed to give about the best results.  Unfortunately, auto-exposure can’t be turned off, so that tends to normalize the appearance of the pictures.

Being chinzy with the plastic cost a bit:  Some of the Revlon scratches impinged on some of the foam block tests.  Fortunately, they went a different direction, so when I took pictures I could try to exclude them.


Short answer:  I was completely wrong.  The 4 sides of the cheapie blocks clearly scratched the plastic, and in 4 graded ways.  And within the eyeball-quality results, their gradations were about the same as the 4 sides of the comparable Trim product.  The Revlon board included a side (black) that actually felt like an emery board (plus another medium grit white side), so those were in a different league from the Chinese (and Trim) “polishing” blocks.  In all cases, the #1 side was most coarse, #4 smoothest.

testacrylic4697Here’s the whole piece of plastic after the tests, marked for the blocks/sides used.  Overall fairly successful, though in hindsight I could have reduced the number of scrubs to 10 or 8.

Hmm – there’s a strong and repeatable artifact that grits 1 and 3 scratch more than 2 and 4, for both the Chinese and the Trim blocks.  Both 1s/3s are on the narrower sides of the blocks.  I’d have to guess we were seeing an effect of higher force/unit area on those smaller sides.  The Revlon block is more square in cross section, and doesn’t show that effect.  Interesting.  Yeah, I could retest and mask the surfaces to fix that – but I got the results I was after, so I’m done.
Here are the closeups, including a steel ruler for scale.  Identical contrast post processing was done to each.  Top to bottom, we have the cheapie, the Trim block, the 4 numbered sides of the Revlon board, and finally the white and black surfaces of the Revlon along with 1200 and 2000 actual sandpaper.

chineseblocktrimblocksrevlonblocksrevlonsandpaperThe closeups aren’t as definitive as I’d hoped.  But the result that the cheapie does in fact have 4 different (if fine!) abrasives is clear.

The test is the test.

Posted in Miscellaneous | Tagged , , , , , | Leave a comment

Hot melt strain reliefs – next phase

old4657I’ve used hot melt glue for strain reliefs on connectors – typically 0.1″ headers abused as connectors – for a long time.  Insulation is a secondary plus, but the primary goal was physical strengthening/protection of the quite small (and therefore weak) solder joints.    Yeah, the technique is good – no cold joints – but they’re still pretty small.  Cheap, works great.

I’m happy with a new, slightly more sophisticated application.  I’ve been soldering ribbon cable to cheap USB-TTL adapters for a long time.  They’re fine for the first couple of years, but after having to repair several broken wires, I’ve started taking a longer view.

The common failure mode is due to solder wicking into the stranded wire.  With a nicely soldered joint, there’s reasonable mechanical strength right where the wire goes thru the hole.  The next millimeter of wire is strengthened by the wicked-in solder, so all of that is OK.  But then comes the junction of the stiff, solder impregnated wire and the plain wire (typically slightly inside the insulation).  That’s where the flexing happens, and that’s where the fatigue failure occurs.

newtop4658The new application of hot melt strain relief is to go far enough up the wire that the solder/no solder junction is protected.  Yeah, there’s still additional flex at the very end of the hot melt, but I think that’s better than flexing at the junction.  I’ll bet these don’t fail the way the unrelieved ones do.

Maybe I’ll remember to come back here in a couple of years and report back. 🙂

Posted in Miscellaneous | Tagged , , | Leave a comment

Prius footrest

On road trips in the (new, 2015) blue Prius, my left foot is frequently unhappy.  It would like a comfy  place to rest – the way IT wants to sit.  While there is a nice left foot rest, it’s not what my foot wants.  I’ve finally hacked in at least a first pass at what my foot has wanted for a long time.

footwell4358The existing foot rest assumes the drivers left foot wants to rest pointing straight forward.  Mine doesn’t – it wants to point to the left by maybe 30 degrees.  And the foot rest assumes the bottom of the foot wants to be flat (though toes raised).  Mine doesn’t – it rolls outward (is that supination?).  Making a new rest with angular correction in 2 dimensions was “interesting”.

I considered a sock full of quick set concrete, smushed into place then with its top shaped by resting my foot on it.  That might have worked.

A physical prototype/strawman usually helps me visualize what I have to make. I put a thin flat piece of wood maybe 3″x6″ on the foot rest and rotated it CCW about how my foot wanted.  OK – I’ll need to trim the bottom at an angle to meet the floor nicely.  Good start.  Now for the wedginess.

makingwedges4367I tried to block it up on the right side ’til it felt good, but couldn’t find a trivial way to do it.  So I rocked my foot back and forth (flat-supinated) to get a very seat of the pants idea what angle it wanted.  I guessed about 20 degrees, and sliced a slightly narrowed piece of 2×4 at that angle on the table saw.  While I was right there I hacked freehand the angle on the bottom, and plopped it on the rest to see how if felt.

thewedge4375Oops – that 20 degrees was too much.  Back to the saw.  After turning the wood lots of ways and scratching my head some, I used the nice blade angle scale to slice 7 degrees off, for about 13 degrees of wedge.  Felt good!  Let’s attach it – at least as version 0.1.

I was going to drill it and put a couple of self tapping screws thru whatever the original footrest was made of, but got spooked at the thought of wires (or brake lines or worse) being routed right behind it.  Very unlikely, but inposition4383high stakes.  Bummer.  Let’s just go with Liquid Nails.  It’ll be a mess if I ever have to take it off, but c’mon – it’s on the floor.

The tube of Liquid Nails has been sitting in the caulk gun for a liquidnailstipsealer4391couple of years now (though to my surprise, I hadn’t put a date on it).  I keep a 1/4-20 bolt “screwed” into the tip to try to keep it from drying out.  Pulled the bolt, squirted some out and sure enough – it was still good!

A lead block on a piece of wood to gluedup4388hold it down and some scrap to keep the bottom of the new footrest up so the floor mats will still slide out, and it’s done for now.

clamped4390It’s cold out – low in the 30s tonight, highs only in the 40s.  Recommended application temp range is 40-100, so it’s a little out of spec.  The good news is that the wood and carpet are both porous, so that should help.  (Well, except for the rubber tread on the original.)  I left the car door open (and clamped the light switch “off”) hoping it won’t smell too bad tomorrow.  We’ll see.

Foot is very anxious to try it out.

Update 1/8/17:

fail4417Well, fail.  Probably due to not letting the glue set up long enough, the wedge fell off the next morning.  Bummer.  And a mess.

itsfoam4418Second try:  I peeled the carpet back to see what I had to work with underneath.  Wow – a big block of nice closed cell foam!  Guess the worrying about puncturing brake lines was unnecessary.  (Well, no.  It was appropriately erring on the side of caution.  Just turned out to be wrong.  No regrets.)  I should be able to hack that foam into submission.

reshaping4422It was a challenge to hold the odd-shaped piece of foam to work on, and a sort of seat of the pants guess for the angle, but I chopped a big piece off.  I removed the most in the mainchunkremoved4427lower left corner to accommodate my heel.  But the upper right needed to be raised a bit more.

gluingonshim4438I cut a shim out of the cut off piece, and glued it on.  There are NO parallel sides or right angles on this sucker.  But I got it stuck on, probably with Gorilla Glue.

foaminplace4482It went back in pretty easily.  You can see some of the glue outline of the upper right shim.  The carpet went back on fine, and I got all the clips and other bits in.  The carpet didn’t seem fazed by upper right shim, but I had to wedge a block of something in below the side molding to hold it down into the heel depression.

cleanedupwell4483Now I had to face the dumb Liquid Nails.  It had had several days to cure by now.  But with a little scraping, it came off very well – even from the carpet.  Yay!  (Hmm – did the glue in the sealed, but aged tube lose some of its sticking power?)

done4494The final result is hard to tell from stock.  You can see the bit of dark stuff I wedged in to push the carpet into the heel hole.

I’ve been driving with it for a month now.  It’s definitely better than it used to be, but not perfect.  I think I was too conservative when I cut out the heel hole.  And in order to gain the maximum outward roll comfort, my heel needs to be way over to the deepest place on the left.  Unfortunately, that compromises the toe’s desire to point out to the left.  I’m not likely to go back and do it again, but my foot appreciates the improvement, tradeoffs and all.

Posted in Miscellaneous | Tagged , , | Leave a comment

Mantis tiller

Mantis+Toys3976After many years of dithering, I finally decided to get a Mantis.  I found a used one for $80? $100? on Craigslist and bought it.  It’s great!  I found edger and dethatcher parts for it and it’s ready to rock and roll.  This note will hold some details about it and its history.

Last summer (2015) I edged all the sidewalks with it and tilled up the big mess where the tree in the inside front lawn was removed and the stump ground out.  Despite its size, the thing is a beast!  I drained the tank and ran out what fuel was left in the carb and put it away for the winter.

When I tried it this spring, it wouldn’t start.  Not even a pop.  Yeah, the fuel was a little old (whatever was in the snowblower/lawnmower can – of course with Stabil, which is great), mixed fresh with oil to 50:1, but I doubted that that fuel was an issue.  I choked it and pulled a lot, but when I pulled the plug, it was completely dry.  Looks like a carb issue.  C’mon – I even ran it dry, which is a lot more than I ever do for any of my other small engines!  I drained the tank and put it away for a couple of weeks.

When I got back to it I’d decided to disassemble and clean the carb.  I had a tuneup kit (almost the right one) with fuel lines, plug, and air filters on the shelf, but no rebuild kit.  If I got in trouble, I figured I could probably find a kit at some local lawnmower place.  And I’d watched a couple of rebuild videos on YouTube.  That’s a pretty amazing resource.

The carb came apart easily, and looked pretty clean inside.  I sprayed carb cleaner kind of randomly thru holes, but didn’t know where it should come out.  The first glitch was when I went to reassemble the machine.  Since I had new fuel lines (and fuel filter and check valve and tank grommet), I figured I’d install them.  But the hoses PartsIboughtMyFuelFittingswere way longer than the originals, and the 3-hole grommet was too big for the hole in the tank.  The parts in the kit I got are on the left, but the originals look like the pic on the right.  The old grommet was still OK, so I cut the other hoses down and put it together.

You’re supposed to pump the primer bulb on top until you see gas in the return (clear) line.  I’d replaced the quite dark (but still flexible) bulb with a new clear one, but it didn’t seem to do much.  I did finally see some fuel in the clear line (a red herring:  it was coming from the tank, not the carb!), but the bulb wouldn’t flex back to normal after pressing on it.  Grumble, cheap chinese parts, grumble, put old bulb back.  Same behavior.  Choked it and pulled a lot – but still not even a pop and the plug was still dry.  Rats.

I took the carb off and apart again, sprayed some more carb cleaner at it, and pondered the primer bulb and its plastic environment.  Sucking and blowing on the (top) fuel return nipple, there was very little flow, but it seemed like a check valve (flowing out of the carb).  The brass insert apparently at the other end of the return fuel passage could be there to hold a check valve in.  But I could barely suck any air thru it.  I worked a bit of wire insulation into the hole and could hear/feel what could be a sticky flap valve.

After working it a bit more, I blew carb cleaner in to the brass fitting and it sprayed out the return nipple!  I’d done that before, but nothing came out.  (A tech doc I found later confirmed that the primer bulb blows fuel/air out the return line thru the check valve, and then sucks fuel thru the carb passages, thru an inbound check valve and into the primer bulb.)

Encouraged, I put it back together again and pumped the (new, clear) bulb.  It filled with fuel!  So that’s how it’s supposed to work!  Some normal steps later, it started and ran.  A couple of tweaks to the low and high speed needles, and it was running well.  I tilled the little flower plot next to the garage (just in time for Lauren to plant the flats of impatiens she’d just bought) and the little Mantis did a terrific job.  I should be able to do the edging the next nice day.  Oh yeah – this was all with the same old fuel I’d tried in the beginning.  Stabil is great stuff.

Label3981Handles-Age3979For the record, here are some pics.  Looks like it’s pretty old, based in part on the white handle grips, and in part on the C1U-K17 carb.  I’m guessing the newer tanks take the larger 3 hole grommet.  The air filters in the tune up kit were the right shape, but a little too large – SerialNum3985presumably another later update.  I was able to poke them into place with a screwdriver.  The SV-4B engine ID is old, too.

The machine ran fine when I got it, and this carb cleanout is the only work I’ve done on it (so far).  I really should check the gear case grease, and I sort of think there’s something about the muffler that should be checked.  I haven’t done anything to the plug since I got it (except pulling it to look for gas).

The used dethatcher I found on Ebay seems to be in good shape, but doesn’t have the sheet metal cowling.  I found a video of a guy (Jim Barry) doing dethatching with a Mantis.  He pulled the cowling off briefly as a demo.  It threw the thatch everywhere without it.  Thanks, Jim!  I should be able to make something pretty functional from the 22 ga sheet steel from the animal cages Ed S tore out.


Posted in House and garden/snow | Tagged , , , , , | Leave a comment

Laser etched rubber stamp

AdafruitPassportEver since Mitch Altman presented the idea, I’ve thought hackerspace passports were pretty cool, if geeky.  (Thanks to Adafruit for the pic.)  I’ve also felt that Workshop 88 should be able to participate with a good stamp.  Of course we couldn’t just buy a stamp – we had to make it.  Thanks to the laser cutter, we can now do that.

GreenFlameA block of rubber stamp rubber from Carlson Art in Glen Ellyn failed the Beilstein test, the green flame showing it contained the dreaded Chlorine.  I then ordered some sheets of 0.09″ by A4 “laser engravable” gray rubber stamp material from China, poised to give negative feedback if that failed Beilstein.  But it didn’t (yay!), so I did some calibration raster etches.  The stuff etched beautifully.  I ended up at 250 DPI 100% power, 2% speed, and did a second etch at 6% speed just for a little extra depth.  It looks like it’s about 0.025″ deep.  I StampF+B3787also etched a non-mirrored (and non-inverted) copy of almost exactly the same artwork fairly deep into a little block of scrap wood to serve as a mount/handle.

Epoxy now holds the roughed up back side of the rubber to the block.  It seems to give quite nice impressions.  One improvement:  There’s a line at the bottom for a date/signature/whatever that’s too thin.  That line should have been considerably bolder.  But it mostly worksPageWstamp3788.

As I got ready to post about it on the W88 blog, excited that we could now produce rubber stamps, I realized that rubber stamps are a thing of those quaint old paper-based days.  Aside from this one, I doubt if any W88 folks will ever have need for a rubber stamp.  But it was an interesting project…

Update 4/1/16: Raster engraving speed depends on the base resolution in Retina Engrave.  It takes twice as long at 500 DPI as at 250 DPI.  For most applications, 250 DPI is fine; many of the raster data entries in the settings Dropbox Paper doc are at 250, including for the rubber stamp.

250v500DPI3801I was  slightly curious about whether etching the rubber at 500 DPI would make a visible improvement, but was even more interested in seeing whether the engraved depth would change.  At higher DPI values, more laser energy is deposited per unit area, so it should engrave more aggressively.  Sure enough, with the same raster power and speed, it etched noticeably deeper at 500 DPI.  I think it looks very slightly smoother and better detailed, but I might be seeing things.  The deeper engraving, however, is completely clear, and needs to be part of our understanding of the raster engraving process.

Posted in Laser Cutter | Tagged , , , , , , , | 2 Comments

W88 Laser Exhaust Fan Replacement

When we first got the W88 laser cutter up and running, we scavenged the ancient circulation blower from the old, gutted in-wall furnace, took advantage of the 8″ flue/fresh air hole in the wall, and hacked a mounting to provide the exhaust for the laser.  That (admittedly overkill) blower died around 3/14/16, about 6 months after we put it in.  After an urgent discussion on Slack Fan3224about flow rates (FSE recommended 60-100 CFM), pressure drop, 8″ and 6″ duct booster fans, a marine ventilation blower, a big honker 110VAC muffin fan from American Science & Surplus, and other possibilities we decided on the sciplus fan.  Daniil picked it up on the 15th, and we hacked it in that night.  (Some upgrades are visible since the original picture:  The vent pipe now runs thru the side of the furnace shell, the water cooling tank has moved inside the furnace, and there’s a power switch up where you can reach it!)

That fan (spec’d at 198 CFM, presumably in free air) (after removing a plastic mount for the electrical connection) fit inside the 8″ pipe perfectly.  There’s maybe 1/8″ clearance around the edge.  By installing it inside the pipe, we gained clearance for the 4″ flex pipe to bend to horizontal.  In the original installation, it fed vertically into the blower. Tom M suggests that mounting the blower with its shaft vertical probably speeded its demise.  It died of a bearing failure, and the bearings weren’t designed for that load.  But it served us well getting the laser running – and it was free!

Fan+MountPlate0237We reused the 4″ flange Daniil had hacked together as the inlet at the bottom of the old blower, screwing it to a plywood plate to mount it and to cover the hole to the 8″ pipe.  We’d planned to mount the muffin fan directly to the back of that same plate, but the motor hub almost completely obscured the air flow from the 4″ inlet.  We found some 1/4-20 threaded rod and tapped holes in the fan for it.  (Thanks for bringing in the tap set, Daniil!)  Setting the fan deep in the pipe provided what seemed like reasonable air path.  A standard IEC power cord lost its C13 end and provided the power connection.  The green wire is even connected to a threaded hole in the fan body!

BeingInserted0238Here’s Daniil about to put it in place.  We left the original wood plate that fit the 8″ pipe.  The new plate mounts over it (with the foam gasket from the old blower still there) with the same long screws ReadyToConnect0239into anchors in the concrete block wall.  It’s all quite solid, and we think it should serve for quite a while.

The only remaining work is to plug/cover up the holes resulting from the flats on the top and bottom of the fan.  Expanding foam is a possibility, as is removing the fan, laser cutting a circular plate and screwing it to the exit surface of the fan.

Done0242With it all buttoned up, the only clue that there’s actually a fan there is the power cord going into the plywood plate.  It also runs MUCH more quietly than the old blower.  While your can hear the whine of the fan spinning up if you listen, the reduced noise is an excellent reason to continue with plans to put an air vane flow sensor in the exhaust port of the laser cabinet.

All in all, it was a fun emergency repair project/hack, and very satisfying to get the laser back up within hours of deciding what parts to use!

FanRing0246Update 3/18/16: Daniil and I stayed late after the meeting Thursday and made a ring to reduce the backflow/leakage around those two non-round areas of the fan.  We pulled the fan, measured, did some quick artwork in inkscape, put the fan back in temporarily, and cut the ring from 3mm plywood without incident.  Well – one incident:  My artwork, on the laser PC, looked perfect in inkscape, but didn’t export as vector to RE.  The design showed up – reversed B/W – in the raster view, but not in vector.  Daniil did the same thing on his laptop and it worked fine.  Troubling.

We feared that drilling the ring for screws would weaken it a lot, as half the width of the skinny ring material would be lost to the holes.  He was for some mysterious and unvoiced reason uncomfortable with using zip ties to hold it on, so we decided to glue it on with some HF 5 minute epoxy.  RingWeightedDown0247We found a very appropriately shaped weight to hold it while the epoxy cured.  It’s all back in place now, looking from the outside exactly like it did before.  But we know we picked up maybe 5% better airflow from the patched up leakage path.

Unrelated to the fan ring, I worked a lot that Thursday putting in NewOutletsA0249better AC power wiring for the whole laser setup.  I scrounged some of the Greenfield apparently ripped out of the media room initial electrical rough in, and put 2 duplex NewOutletsB0254outlets outside and one inside the furnace shell, all powered from the original BX-connected box.  I cut a hole in the side of the shell at a comfortable height NewSwitch0258and put a in switch that controls all 6 outlets.  It’s a little close to the edge for a normal switch plate, so I made a narrow one from fluorescent acrylic.  The possibility of some UV LEDs has not been ruled out.  The sign above it was vector engraved, as the artwork I made up in inkscape for that one imported as vector but not as raster.  That remains troubling.  But I’m delighted and relieved to have much more civilized power control for the laser.  That was one of the last big punch list items to get the laser “production ready”.  Maybe now I can go back and do some work on the Shapeoko 2!

InkscapeOpacityUpdate 4/29/16: I discovered the problem that caused my inkscape prints to Retina Engrave to work wrong:  I had the “Opacity” set to less than 100%.  Apparently RE doesn’t like that.  It had become a default value, and all docs created since that happened were so corrupted.  Changing the opacity back to 100% (and making sure it stuck as the default!) completely fixed the problem.  Who knew?

Posted in Laser Cutter | Tagged , , , , | Leave a comment