The Smell of Molten Projects in the Morning

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

Month: April 2015

  • MakerGear M2: Platform Z-axis Switch Repeatability

    Having run off four quick prints with identical settings, I measured the thickness of the skirt threads around each object:

    Skirt Thread Consistency
    Skirt Thread Consistency

    They’re all slightly thicker than the nominal 0.25 mm layer thickness, but centered within ±0.02 mm of the average 0.27 mm. Tweaking the G92 offset in the startup G-Code by 0.02 would fix that.

    The 0.29 mm skirt surrounded the first object, which had a truly cold start: 14 °C ambient in the Basement Laboratory. After that, they’re pretty much identical.

    Some informal measurements over a few days suggests the actual repeatability might be  ±0.05 mm, which is Good Enough for layers around 0.20 to 0.25 mm.

    The larger skirt suggests that the platform has a slight tilt, but the caliper resolution is only 0.01 mm.

    When I realigned everything after installing the V4 hot end, the last set of thinwall boxes looked like this:

    Thinwall Calibration Cubes - 5 copies
    Thinwall Calibration Cubes – 5 copies

    Their heights were:

    4.96 5.01
    4.98
    4.91 4.92

    Not enough to worry about, in any event, sez I…

  • RPi: Time-lapse Photos

    The Raspberry Pi doc provides a recipe for the simplest possible time-lapse webcam: fire fswebcam once a minute from a cron job.

    The crontab entry looks much like their example:

    * * * * * /home/ed/bin/grabimg.sh 2>&1
    

    I put all the camera details in the ~/.config/fswebcam.conf config file:

    # Logitech C130 / C510 camera
    device v4l2:/dev/video0
    input 0
    resolution 1280x720
    set sharpness=128
    jpeg 95
    set "power line frequency"="60 hz"
    #no-banner
    

    That simplifies the ~/bin/grabimg.sh script:

    #!/bin/bash
    DATE=$(date +"%Y-%m-%d_%H.%M.%S")
    fswebcam -c /home/ed/.config/fswebcam.conf /mnt/samba/webcam/$DATE.jpg
    

    The output directory lives on a Samba-shared USB stick jammed in the back of the Asus router, so I need not putz with a Samba server on the RPi.

    Manually mounting the share, which for the moment is the /testfolder/webcam directory on the USB stick:

    sudo mount -t cifs -o user=ed //gateway/testfolder/webcam /mnt/samba
    

    I’m pretty sure automagically mounting the share will require the same workarounds as on my desktop box, but this fstab entry is a start:

    #-- ASUS router Samba share
    //gateway/testfolder/webcam	/mnt/samba	cifs	auto,uid=ed,credentials=/root/.gateway-id 0 0
    

    That requires a corresponding credentials file with all the secret info:

    domain=WHATSMYNET
    username=ed
    password=pick-your-own
    

    This is mostly a test to see how long it takes before something on the RPi goes toes-up enough to require a manual reboot. Disabling the WiFi link’s power saving mode seems to keep the RPi on the air all the time, which is a start.

  • Lurid Filament Colors vs. Monochrome Images

    An experiment with images of an object made with translucent magenta PETG…

    The Slic3r preview of the object looks like this, just so you know what you should be seeing:

    Necklace Heart - Slic3r Preview
    Necklace Heart – Slic3r Preview

    It’s pretty much a saturated red blob with the Canon SX230HS in full color mode:

    Necklace Heart - Slic3r Preview
    Necklace Heart – Slic3r Preview

    Unleashing The GIMP and desaturating the image based on luminosity helps a lot:

    Necklace Heart - magenta PETG - desaturate luminosity
    Necklace Heart – magenta PETG – desaturate luminosity

    Desaturating based on either lightness or average, whatever that is, produced similar results.

    Auto level adjustment plus manual value tweaking brings out more detail from that image:

    Necklace Heart - magenta PETG - desaturated - adjusted
    Necklace Heart – magenta PETG – desaturated – adjusted

    I also tried using the camera in its B&W mode to discard the color information up front:

    Necklace Heart - circle detail
    Necklace Heart – circle detail

    It’s taken through the macro adapter with the LEDs turned off and obviously benefits from better lighting, with an LED flashlight at grazing incidence. You can even see the Hilbert Curve top infill.

    The object of the exercise was to see if those tiny dots would print properly, which they did:

    Necklace Heart - dots detail
    Necklace Heart – dots detail

    Now, admittedly, PETG still produces fine hairs, but those dots consist of two layers and two thread widths, so it’s a harsh retraction test.

    A look at the other side:

    Necklace Heart - detail
    Necklace Heart – detail

    All in all, both the object and the pix worked out much better than I expected.

    Leaving the camera in full color mode and processing the images in The GIMP means less fiddling with the camera settings, which seems like a net win.

  • RPi: Logitech QuickCam for Notebook vs. fswebcam

    Combining the camera data I collected a while ago with a few hours of screwing around with this old Logitech camera:

    Logitech QuickCam for Notebook Plus - front
    Logitech QuickCam for Notebook Plus – front

    I’m convinced it’s the worst camera I’d be willing to use in any practical application.

    The camera offers these controls:

    fswebcam --list-controls
    --- Opening /dev/video0...
    Trying source module v4l2...
    /dev/video0 opened.
    No input was specified, using the first.
    Available Controls Current Value Range
    ------------------ ------------- -----
    Brightness 128 (50%) 0 - 255
    Contrast 128 (50%) 0 - 255
    Gamma 4 1 - 6
    Exposure 2343 (8%) 781 - 18750
    Gain, Automatic True True | False
    Power Line Frequency Disabled Disabled | 50 Hz | 60 Hz
    Sharpness 2 0 - 3
    Adjusting resolution from 384x288 to 320x240.
    

    Putting the non-changing setup data into a fswebcam configuration file:

    cat ~/.config/fswebcam.conf
    # Logitech QuickCam for Notebook Plus -- 046d:08d8
    device v4l2:/dev/video0
    input gspca_zc3xx
    resolution 320x240
    scale 640x480
    set sharpness=1
    #jpeg 95
    set "power line frequency"="60 hz"
    

    Trying to use 640×480 generally produces a Corrupt JPEG data: premature end of data segment error, which looks no better than this and generally much worse:

    Logtech 08d8 - 640x480
    Logtech 08d8 – 640×480

    The top of the picture looks pretty good, with great detail on those dust particles, but at some point the data transfer coughs and wrecks the rest of the image. I could crop the top half to the hipster 16:9 format of 640×360, but the transfer doesn’t always fail that far down the image.

    The -R flag that specifies using direct reads instead of mmap, whatever that means, doesn’t help. In fact, the camera generally crashes hard enough to require a power cycle.

    Delaying a second with -D1 and / or skipping a frame with -S1 don’t help, either.

    The camera works perfectly at 640×480 using fswebcam under Xubuntu 14.04 on a Dell Latitude E6410 laptop, so I’m pretty sure this is a case of the Raspberry Pi being a bit underpowered for the job / the ARM driver taking too long / something totally obscure. A random comment somewhere observed that switching from Raspbian to Arch Linux (the ARM version) solved a similar video camera problem, so there’s surely room for improvement.

    Dragorn of Kismet reports that the Raspberry Pi USB hardware doesn’t actually support USB 2.0 data rates, which also produces problems with Ethernet throughput. The comments in that slashdot thread provide enough details: the boat has many holes and it’s not a software problem.

    For lack of anything more adventurous, the config file takes a 320×240 image and scales it up to 640×480, which looks about as crappy as you’d expect:

    Logtech 08d8 - 320x240 scaled
    Logtech 08d8 – 320×240 scaled

    Even that low resolution will occasionally drop a few bytes along the way, but much less often.

    The picture seems a bit blown out, so set the exposure to the absolute minimum:

    fswebcam -c ~/.config/fswebcam.conf --set exposure=781 "Logitech 08d8 - expose 781.jpg"
    

    Which looks like this:

    Logitech 08d8 - expose 781
    Logitech 08d8 – expose 781

    Given that’s happening a foot under a desk lamp aimed well away from the scene, the other end of the exposure scale around 18000 produces a uselessly burned out image. I think a husky neutral-density filter would be in order for use with my M2’s under-gantry LED panels. The camera seems to be an early design targeting the poorly illuminated Youtube / video chat market segment (I love it when I can talk like that).

    There’s probably a quick-and-dirty Imagemagick color correction technique, although Fred’s full-blown autocorrection scripts seem much too heavy-handed for a Raspberry Pi…

  • It Wasn’t Quite Touching, So Ship It

    Picked up a Prime Switched Outlet to help tame the U2711 monitor’s DisplayPort incompatibility and, being that type of guy, had to open it up to see what’s inside.

    Good thing I did:

    Prime Switched Outlet - stray wire strand
    Prime Switched Outlet – stray wire strand

    Admittedly, white is neutral, so that stray wire would should just pop the GFI, but, still …

    You can wind up with events like this:

    Burnt outlet expander
    Burnt outlet expander
  • Red-Bellied Woodpecker

    Woodpeckers generally perch with their tummies against a tree, so it took me a long time to understand why Red-bellied Woodpeckers have that name:

    Red-bellied Woodpecker - suet feeder
    Red-bellied Woodpecker – suet feeder

    The bright red nape and head seemed entirely sufficient to me, but another woodpecker claimed that name first…

  • Epson S5 Projector Foot Repair

    First up: it’s not our projector, which means the usual Rules of Engagement do not apply.

    A few small black plastic fragments fell out of the Epson S5 projector’s carry bag, the front foot wouldn’t remain extended, and, as one might expect, the two incidents were related. Mary needed it for the gardening class she was teaching the next evening, sooooo

    A pair of plastic snaps release the entire foot assembly from the front of the projector:

    Epson S5 Projector Foot - assembled
    Epson S5 Projector Foot – assembled

    It became obvious that we didn’t have all the fragments, but it was also obvious that, even if we had the pieces, a glued assembly wouldn’t last very long.

    The threaded plastic stem surrounds a steel pin that’s visible when you remove the rubber foot pad. That pin holds the latch on the end of the stem outward, so that the stem can’t fall out. Drive out the pin with a (wait for it) pin punch inserted from the foot pad end, which reveals the broken plastic doodad:

     

    Epson S5 Projector Foot - stem removed
    Epson S5 Projector Foot – stem removed

    Release the latches on the gray handle and the intricate half-nut that engages the threaded stem slides out:

    Epson S5 Projector Foot - disassembled
    Epson S5 Projector Foot – disassembled

    A plastic spring in the boxy shell pushes the gray handle and half-nut against the stem, holding the stem in place. Pushing the gray handle upward (on the projector, downward in the picture, yes, your fingertip can feel those ribs just fine) pulls the half-nut away from the stem and lets the stem slide freely. With the stem extended, the projector leans on the stem, pushes it against the half-nut, and you can fine-tune the angle by turning the stem; the splines around the rubber foot encourage that. You can pull the stem outward without activating the latch, which probably broke the fragile plastic plate.

    A doodle showing the estimated measurements, plus three 3D printed prototypes required to get a good fit:

    Epson S5 Projector Foot - measurements and versions
    Epson S5 Projector Foot – measurements and versions

    The solid model looks about like you’d expect:

    Epson S5 Projector foot latch - solid model
    Epson S5 Projector foot latch – solid model

    The first version (leftmost of the three sitting on the doodle, above) had angled ends on the tabs that I intended to match up with the stubs remaining on the OEM latch. The part fit better with shorter tabs and the angles vanished on third version; the statements remain in the OpenSCAD source, but the short tabs render them moot.

    Apparently I got the cooling & fan & minimum layer time pretty close to right for PETG, as each of those three towers printed singly with no slumping:

    Epson S5 Projector Foot - V1 on platform
    Epson S5 Projector Foot – V1 on platform

    The third version snapped into place, with a square of tapeless sticky on the back to help keep it there. The obligatory Kapton tape helps retain it, but I have no illusions about the permanence of this repair:

    Epson S5 Projector Foot - repair installed
    Epson S5 Projector Foot – repair installed

    Because I know the problem will happen again, I called for backup:

    Epson S5 Projector Foot - 5 copies
    Epson S5 Projector Foot – 5 copies

    That’s with Hilbert Curve top / bottom fill, three top / bottom layers, 20% rectilinear infill, and two perimeters. Extruder at 250 °C, platform at 90 °C, hairspray for adhesion.

    Note, however, the hair-fine strings connecting the towers. Retraction must be just about right, as shown by the overall quality of the objects, but PETG comes out really stringy. Choosing an infill pattern to minimize retraction seems like a big win; relatively sparse 3D Honeycomb works well on larger objects, but these were so small that straight line fill fit better. The flat plates on the bottom consist of five completely solid layers of PETG.

    Reports from the field indicate complete success: whew!

    One could, of course, just buy a replacement from the usual eBay supplier, if one were so inclined.

    The OpenSCAD source code:

    // Epson S5 projector foot latch repair
    // Ed Nisley KE4ZNU - March 2015
    
    Layout = "Build";
    
    //- Extrusion parameters must match reality!
    
    ThreadThick = 0.25;
    ThreadWidth = 0.40;
    
    HoleWindage = 0.2;
    
    Protrusion = 0.1;			// make holes end cleanly
    
    function IntegerMultiple(Size,Unit) = Unit * ceil(Size / Unit);
    
    //----------------------
    // Dimensions
    
    Plate = [16.7,9.0,1.25];
    
    Block = [12.5,2.5,10.0];
    
    HoleDia = 7.7;
    HoleRadius = HoleDia/2;
    
    HoleOffset = 3.5 + HoleDia/2;					// +Y edge to hole center
    HoleSides = 8;
    
    StubLeft= 9.5;
    StubLeftAngle = asin((StubLeft - HoleOffset) / (HoleRadius));
    
    StubRight = 9.1;
    StubRightAngle = asin((StubRight - HoleOffset) / (HoleRadius));
    
    //----------------------
    // 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) {
    
      Range = floor(50 / Space);
    
    	for (x=[-Range:Range])
    	  for (y=[-Range:Range])
    		translate([x*Space,y*Space,Size/2])
    		  %cube(Size,center=true);
    
    }
    
    module RodSupport() {
    	difference() {
    		union() {
    			translate([0,(HoleOffset-Plate[1]/2),Plate[2]/2])
    				cube(Plate,center=true);
    			translate([0,HoleOffset-Block[1]/2,-(Block[2] - Protrusion)/2])
    				cube(Block + [0,0,Protrusion],center=true);
    		}
    		translate([0,0,-2*Block[2]])
    			rotate(180/HoleSides)
    				PolyCyl(HoleDia,4*Block[2],HoleSides);
    		rotate(StubLeftAngle)
    			translate([-2*HoleDia,-HoleDia,-Protrusion])
    			cube([2*HoleDia,HoleDia,Plate[2] + 2*Protrusion],center=false);
    		rotate(-StubRightAngle)
    			translate([0,-HoleDia,-Protrusion])
    				cube([2*HoleDia,HoleDia,Plate[2] + 2*Protrusion],center=false);
    
    	}
    }
    
    //----------------------
    // Build it
    
    //ShowPegGrid();
    
    if (Layout == "Show")
    	RodSupport();
    
    if (Layout == "Build")
    	translate([0,0,Plate[2]])
    		rotate([0,180,0])
    			RodSupport();