Archive for January, 2011
- What’s new and different?
Father Vaughn always posed that deceptively simple question when asked for help with a new problem.
What he knew, and what we eventually discovered, was that the most recent Thing-That-Changed generally had something to do with what was now broken. Even if the difference didn’t seem related in any way, tracking down its effects was always a highly productive use of your time.
His question applies to non-technical problems, too… especially when you think nothing has changed.
Now, I’m a big fan of continuous ink supply systems for desktop printers and buy ink by the pint, but these folks put me to shame…
It’s delivering ink to the Southern Dutchess News plant in Wappingers Falls.
While printing up handouts for my talk at Cabin Fever, I finally tracked down why Adobe Reader was producing such crappy colors.
The left is before and the right is after the fix, scanned at the same time with the same image adjustments:
All of the print settings appeared correct (plain paper, 720 dpi, normal contrast, etc, etc), but Adobe Reader (and only Adobe Reader) looked like it was trying to print on vastly higher quality paper than I was using. Too much ink, too much contrast, generally useless results.
The solution was, as always, trivial, after far too much fiddling around.
In Reader’s Print dialog, there’s a button in the lower-left corner labeled Advanced. Clicky, then put a checkmark in the box that says Let printer determine colors.
And then It Just Works.
Equally puzzling: ask for 25 copies of a two-page document, check the Collate box, and you get 25 page 1, 25 page 2, then more page 1 starts coming out. I bet I’d get 25 x 25 sheets of paper by the time it gave up.
I have no idea what’s going on, either.
Memo to Self: verify that the box stays checked after updates.
After we rearranged the living room, we had a few floor lights in different locations that called for more X10 Appliance Controllers. I’m not a big fan of automated housing, because X10 communication is unreliable with a bullet, but it’s convenient to turn off all the lamps from the bedroom.
Anyhow, the old RCA HC25 X10 Appliance Modules I pulled out of the Big Box o’ X10 Stuff suffered from the usual conflict between compact fluorescent lamps and the “local control” misfeature that’s supposed to let you turn the appliance on by simply flipping the switch. The problem is that a CFL ballast draws a nonlinear trickle of current that the module misinterprets as a switch flip, thus occasionally turning the lamp on shortly after you turn it off.
This has been true since the first compact fluorescent bulbs appeared. The circuitry inside X10 modules hasn’t changed much, at least up until I bought the last round of switches quite some time ago. That’s either a Bad Thing (still a problem) or a Good Thing (everybody knows about it).
The solution (everybody knows about it, just use the obvious keywords) is to cut a jumper on the module’s circuit board that’s obviously placed there for this very reason. In this view, it’s just below the lower-right corner of the fat blue capacitor. If you need confirmation, it’s connected to pin 7 of the only IC on the board.
Snip the wire, move the cut end a little bit, and button the module up again.
Oh, yeah. No user serviceable parts inside is a challenge around here…
The Thing-O-Matic instructions suggest crushing the knob heads onto socket-head cap screws using pliers. That’s a desperation move for when you have no alternative.
Instead, if you have a drill press (and you should!), do it this way: lightly grab the cap screw threads in the chuck and squash it into the head.
The same trick works for pressing pulleys and drive splines onto motor shafts.
You shouldn’t use your drill press as a heavy-duty arbor press, but for pressing small circular things onto shafts, it’s hard to beat.
This was more tedious than it ought to be, but OpenSCAD now runs on my desktop box and uses OpenGL 2.2, courtesy of a not too obsolete nVidia GeForce 9400 dual-head card.
OpenSCAD has a slew of pre-reqs, most of which were already installed. However, the openscad and cgal non-packages live in the Arch AUR collection, so they required manual twiddling to install.
- cgal, which in turn requires cmake via pacman
The recommended PKGBUILD patch is easy enough to do by hand.
The final build step takes ten minutes using both cores, but the final result uses OpenCSG the way it should.
Oddly, the OpenSCAD rendering process for the few objects I’ve checked takes longer than on the laptop. Weird.
This does not get the most recent build from the developers, but it’s close enough for my simple needs right now. The mailing list archive is invaluable.
Then there was the laptop saga. Maybe the reason the laptop is faster is that it’s not actually using OpenCSG at all.
I wondered if the Thing-O-Matic would benefit from having its two high-current heaters on a separate +12 V supply than the DC Extruder, after finding that the heaters dragged the +12 V output down by nearly half a volt.
A bit of rummaging turned up a suitable ATX supply with a data plate that might justifiably lead one to believe that the supply provides separate +12 V outputs:
There’s no indication which of the four connectors might use +12V1 and +12V2, but, being that sort of guy, I applied an ohmmeter to the various yellow wires and found they were all exactly 0.0 Ω apart.
So I opened the Warranty Void If Seal Removed top cover and found this situation:
- All the yellow wires terminate in the same solder blob below the PCB
- Two incoming wires got neatly spliced together in mid-air, despite having free holes in the PCB
This may not come as much of a shock: they lie…
Perhaps if you spend more money on your supply, it’ll actually live up to the data plate specs. Then, again, perhaps you’ll just be spending more money.
And, if you swap in a fancy supply for the MBI-stock one, it might not make much difference at all. I suspect the various power levels and current capacities have pretty much the same degree of integrity…