Ooog. Rusty.

Sunday, 05 July 2015

The matter of the garage-sink drain having risen in priority of late, I decided it was time to Deal With It. It had been draining quite slowly for some time, and snaking it out couldn't be that much trouble, could it?

It could.

Disconnect wobbly plastic sink's wobbly plastic flexi-drain from the rigid plumbing. Poke rigid plumbing with cheapie household snake. Seems to be OK up to the point the snake doesn't want to go further around the bend. Hm.

Unscrew cleanout plug* between bend and wall. Poke snake at bend from that side. Same thing, and between the two attempts, I'm pretty well convinced that the bend is clear, so it's not an accumulation of sand and gravel causing the problem**.

Next: poke the snake the other way, on beyond the wall. It goes in a fair way easily, then hits some kind of squidgy obstruction. Eureka? Pull it back out with a glob of ick. Repeat, with various wiggling and turning. Stop getting ick, but the snake now hits a hard obstruction.

Oh, well. Obstruction could be junction, no? Put the plug back in and run some water.

Nope. Drainage has now gone from slow to virtually nonexistent, apparently dominated by a slow leak into the bucket under the drain.

Guess I need to call a real plumber, perhaps Monday afternoon, in among all the other Stuff I Gotta Do (Monday through Wednesday have cluttered schedules already).

Plumbers are expensive, though. Maybe I'll make a hardware-store run in search of a shorter, better-configured snake? Don't need more'n 4 feet, and having a decent handle for turning it, and less of a tail getting underfoot, might just make enough of a difference.

Update: Off to Home Despot; look at snakes; end up with a Kwik-Spin. Good thing I got something fairly long; after several more probulization cycles, I stopped getting wads of ick 10 feet or so down the pipe. Actually being able to turn the thing was a big help (the auto-feed feature, not so much in this particular case).

Put the plug back in: it drains properly now! Good as new!

I didn't try very hard to identify the fibrous component of the ick, but feathers from cage-cleaning over the years would seem the obvious suspect.

One cool shower later, I'm feeling almost human again. Almost.

And I haven't managed to get the smell off my hands yet. Maybe baking soda will help. Or bleach. Or nitric acid. Or maybe I should use the time machine and tell myself to have broken out the nitrile gloves.

But, hey: $30 for a snake beats $300*** for a Silicon Valley plumber.

* Maybe not intended as such; it could have been the place a washing-machine drain would have connected, had any inhabitant of this house ever owned a washing machine.

** Come to think of it, I believe I'd removed the bend sometime last year and removed such dense crud as had accumulated: dirt, sand, brass, swarf, and whatnot. So it should have been obvious that the current blockage was downstream.

*** Or however much the neighbors spent having their drain pipes totally re-done, including reaming out the crawlspace to accommodate modern American plumbers. I think bringing in a team of Cambodian plumbers on H-1B visas might have been cheaper.

Wednesday, 24 June 2015

Reminds me I haven't checked for updates in quite a while, what with it being a manual install.

And, look! I go to Adobe's site, and not only has the Acrobat reader (or whatever they're calling it these days) for Linux not been updated since version 9.5.something, but it's no longer available through the regular download path. (Version 9.5.5-1 still exists, but only if you know where to look.)

Yes, there are open-source programs for reading PDF files. They mostly work. In some cases, they work better than the Adobe product... especially when it comes to printing to a Postscript printer. (Adobe Acrobat has long been notorious for emitting output that Just Won't Work on a printer that uses Adobe Postscript. This isn't just a Linux thing; I first noticed it during my time in Corporateland when using a company-issued Windows NT system, back when NT was a thing.)

But... it seems none of them support all the funny features of the "Portable" (ha!) Document Format.

Not that I use any of the fancy unsupported features, but it's a potential work-compatibility issue.

And: none of them support having a gazillion files open in a single window, with a tab bar running along the bottom to select among them. This is how I use it. I tend to have quite an assortment of datasheets, manuals, client specs, and other assorted documents sitting open, all in a single window on virtual desktop #11, sandwiched between the web browser (desktop #10, typically several browser windows each with multiple tabs open) and the text editor (jEdit on desktop #12, with, at the moment, 474 files open, and a buffer-list sidebar to manage them).

So, do I need to grab the source code for one of the better open-source viewers, and write a more Adobe-like wrapper for navigation and open-document management? Office software really isn't my thing; I'm more of a bit-basher, and find GUIs rather baffling.

Actually, that might be a good idea anyway. Adobe's product has some weird bugs that show up when it's used the way I use it; after a while, the UI becomes horribly and inexplicably sluggish (like taking a minute or so to open a file or print dialog, while not using significant CPU time, so what's it doing?); I don't know if this is a function of time or of the number of files that have been open, but it's highly annoying.

Monday, 22 June 2015

Back to arguing with the open-source RTOS/TCP-IP hodgepodge, plus another third-party component which was taken proprietary a couple of years ago (I'm dealing with the last open-source release).

This particular combination is, well, ugh. Serious case of integration being out of phase, important things not quite working right, and the inter-package interface documentation being pretty much nonexistent. Also, all available demos are way out of date.

I'll muddle through, I guess.

I was about ready to hang up the AGROS project apart from ongoing support for existing clients, but, seeing the state of certain popular products, I'm having a rethink.

I still need to look at another branch of the open-source RTOS world, for futures, but if that turns out to be anything like what I've been dealing with, I'll consider it worthwhile to give AGROS its long-overdue makeover (much assorted cleanup, port to Cortex M architecture, re-do the configuration program using Qt and possibly a different scripting language, write some device drivers for different MCU families, and document everything - then try to recruit a user group to deal with more device drivers, porting to MIPS and whatnot, and stuff like that).

Because stuff that's dead easy under AGROS - as long as it's on an LPC2xxx platform - is a royal PITA in this other environment.

One of the hangups (other than getting out of the ARM7 world) has been UDP, but I actually did a partial implementation of UDP last summer, it looks like a full implementation will be needed for an existing client this summer, and the main sticky aspect had been the API, which, thanks to the current adventure, I can now see how to do better than what I'm dealing with. Once UDP is there, DHCP is reasonably easy, and a useful subset of mDNS shouldn't be a big deal apart from wading through all the RFCs that define parts of it.

Update: Just to make my life more and more wonderful, Eclipse and gdbserver sometimes get somehow out of sync, resulting in breakpoints happening in places entirely other than where I set them. So, as I try to sort through the out-of-phase components of this mess, I start regularly hitting breakpoints on frell.c line 434, when the only breakpoint I have set in frell.c is supposed to be on line 399, in the preceding function. Growf! And, no, shutting down Eclipse, gdbserver, the target hardware, and the pod, and then restarting everything, doesn't solve the problem.

Update 2: Optimizing linker can be confusing when debugging. That breakpoint at line 399? I'd commented out, for the moment, the only call to that function, in another module, so the code for it disappeared, and what would have been its start address had become that of the following function. Maybe I need to figure out how to turn that off for debugging purposes.

Saturday, 07 March 2015

Early on this fine Saturday morning, I went to print a few pages of info on connectors for a project....

The first page printed fine.

The second one was halfway out of the printer when the printer abruptly stopped and turned on an error light.

"Drum".

?

Normally, that light blinks for quite a while before things get really bad. And the print quality gradually deteriorates. It doesn't just shut down in the middle of a page!

So I jiggle things, and cycle power, and... as the printer runs through its startup process, it stops with a klunk and turns the light back on.

So I guess the drum unit is jammed.

Have to chase the cats out of here (later), put down paper or something, pull the drum, and see if it's something I can unwedge.

And then, presumably, it'll be Amazon Prime to the rescue. Because even if I could find a replacement drum locally, it'd likely cost almost twice as much as ordering from Amazon. That's the trouble with living in the hinterlandsthe middle of Silicon Valley.

Update: Braving the cramped space under my desk (muscles in lower back and groinal region still being troublesome), I pulled the drum & toner stack out, unstacked them, rotated the drum manually, blew dust off the corona wire (and wiggled the corona-wire cleaner back & forth), removed sundry detritus from the drum with a Kleenex® brand kleenex, reassembled it, re-inserted in printer, turned power on, held my breath, and... no frowny light! Seems to work OK now.

Say, you don't think the sudden error was the result of cat dander on the corona wire shorting out the HV, do you...?

Looking in my office closet, I find various used toner cartridges that I'm not really going to refill, some of which are for the previous printer of blessed memory, for which I also have a couple of used-up drum units. Well, off to e-waste with 'em. Had I found a used-up but not totally-defunct drum unit for this model, I might have used it temporarily while ordering a replacement, had the take-it-out-and-clean-it action failed.

Wednesday, 17 September 2014

Sometimes, things get set in stone too early, for the wrong reasons... and then, despite the proliferation of libraries-that-do-similar-things in the UN*X world, the old way remains the only way.

My personal peeve here is setting the Baud rate on a serial port. The UN*X way, formalized in the POSIX standard, involves passing the choice of rate as a small integer selected from a list in a header file.

This makes sense in the context of a PDP-11, with a serial-port card that takes a 3-bit number (or whatever it was) to select one output from a Baud-rate generator that does 110 and a few multiples of 300. It's completely outdated in the modern era of UARTs with Baud-rate generators that divide 60 MHz by an arbitrary factor.

And, most of the time, that's OK. But, when you need to talk to an embedded-device UART that runs at 1000 Baud because that's the standard in Upper Whatchacallistan? Having to use Windows just to do that sucks almost as much as writing a special-purpose Linux device driver just to get a custom Baud rate.

(OK, so there is a way of mucking about with the Baud rate using the standard driver. Ugly! Seriously, the API should have been fixed decades ago to take the actual requested Baud rate, with the legacy rate #defines redefined to the actual number, e.g., B9600 would be 9600.)

Sunday, 10 August 2014

The living-room projector didn't wake up last night. (Come to think of it, it was working Thursday night, so it's not a sitting-idle issue.) Presumably the lamp has gone bad. It's an expensive item, but, as it happens, I'd already bought the replacement, quite some time ago, for an impending failure that turned out to be a false alarm. So, as long as it's just the lamp, all's well, apart from my needing to find a couple of hours and a flat surface to deal with the changing-a-light-bulb process.

Then, today: I tried to turn the lab Linux box on. The disk-activity light flickers (once per turn-on attempt), but there's no other sign of life. Various green lights on the motherboard are lit up, though, whether I push the button or not. Grrrr!

Ah, well. Tomorrow, the Prius goes in for diagnosis. On consideration, I don't really think it's the known failure mode involving the differential; it sounds more like an electric-motor issue. Which currently isn't getting any warning lights. Curious.

And I can spend some portion of tomorrow fixing computers and projectors. Today went to laundry and watering-system manifolds.

Update: Well, the computer looks to be a cheaper & easier fix than the Prius. (Has to be; I could replace the whole computer for the cost of having the Prius diagnosed, never mind having any work done.) More detailed observation of symptoms: when the disk-activity light flashes briefly on button press, the internal green lights blink off momentarily, as the fans twitch. Connecting a voltmeter across the input to the internal power supply shows a big dip in the 12V at that moment. So... the external power brick (12V, 5A) has maybe gone bad, and can't handle the startup current? Substitute a 12V, 3A supply that's lying around: it seems to work. So, off to Halted in search of a replacement 12V, 5A unit, 'cause I suspect the 3A one might just be a little bit light for running that PC, long-term.

Update 2: Drop-in replacement, $13.95 plus tax and travel. Seems to be working, but Linux is running a long filesystem check. Something about having gone 384 days without a check. I presume it'll come up OK, having gotten to this point.

Update 3: One out of three today... I just changed the light bulb in the projector, and It Still Doesn't Work. I'm guessing the high-voltage supply, maybe the starter circuit, is out of order. Not something I'm likely to fix, especially in the absence of a schematic, and at this point a replacement projector is not at all in the budget, so we'll be without big-screen TV for the foreseeable future.

Oh, well. Paying work resumes tomorrow. Meanwhile, I've got a few hours to work on the project for which I'd turned the lab Linux box back on in the first place....

Friday, 11 July 2014

Once again, I attempted to set forth on a voyage of discovery, whereof details after it happens. 'Twas originally planned for last September, then this April, then June, and finally Today. All the previous attempts were derailed by work and/or family events which cropped up and kept me at home.

Well, today was the day... and we got as far as Lodi* before the Prius (NHW11, 2002, a bit over 200K miles) lit up its check-engine light.

OK, so first thing in such a situation (given that it still seemed to be running fine, and that I'd fed it just a few hours earlier): pull into a parking lot, re-seat the gas cap, and try restarting the engine several times. Nope; still get Check Engine, Master Caution, and Red Car With Exclamation Mark**.

Look up the nearest Toyota dealership: a bit under 2 miles. Drive there. No technicians available, but a helpful service manager (whose name I managed to forget, or I'd mention it here) grabbed his personal (non-Toyota) OBDII dongle and pulled the codes: P3125 and, if I recall correctly, P3130. The generic tester couldn't provide any further information, so he went and looked at his computer, and I asked my Magic Elf Box, and we both came to the conclusion that It Was Bad, that the car was at least temporarily drivable (with some prospect of making it home), and that making a run for home and risking having to call AAA was a better bet than staying in Lodi until a technician was available and the car could be diagnosed and parts could be ordered and installed, i.e., Tuesday-or-so.

And thus it comes to pass that I'm writing this at my own desk; whatever was wrong didn't fail catastrophically in the hour and a half it took to get home from Lodi.

So now I'm looking at P3125, and there are many subcodes, some of which are well over $4K to fix, while some are much cheaper... and P3130 is an inverter cooling system malfunction (I did check, back in Lodi, and the inverter coolant reservoir is full).

The usual dealership has a most uninformative website, but offered me a next-available-appointment of Wednesday. No.

The nearest dealership (not that much nearer, actually) has a live person answering the phone, longer service-department hours, and the possibility of getting it looked at Monday if I bring it in at 0700, so I guess that's the plan.

And, just in case it needs a new $4400 inverter module... I'm looking at the DIY instructions, and maybe I'll call around to some junkyards. If there still are any in this area that haven't been bulldozed for high-density development. I don't think eBay is an option, given my schedule constraints.

It does appear, though, that the expensive P3125 subcodes tend to be accompanied by obvious symptoms, such as rough running. I didn't observe any such things.

It's at times like this I wish the Prius had a decent set of steam gauges - even virtual ones - instead of an ID10T light.

And it reminds me why my toaster*** controllers keep a fair amount of detail in the event log... and why I get frustrated when end-users (who commonly define the communication protocol) don't give me enough status bits to return important diagnostic information.

Update, Monday morning: Took the car to the nearest specialist. Had some communication difficulties, of the form "phone number ended up off by one on the work order, so I didn't get a call." Called in when I noticed this. Problem is the inverter coolant pump, which is expensive to replace but nowhere near as expensive as the inverter itself. Also getting the oil changed early, so it doesn't come due while on the road.

Meanwhile I have this Cool Idea for a comprehensive virtual steam gauge panel that would listen to the CANbus and present interesting parameters (in particular, any that were out of whack). But... gotta pay big bucks to the CANbus Buyers' Club for the list of standard codes, and then negotiate with each car manufacturer for access to the secret list of vendor-specific codes and their associated data (and the normal range for each item). So, not something I'll be doing anytime soon.

Update 2, Monday afternoon: Just to make times even more interesting, the garbage scow (being my '89 Jeep Cherokee, which is currently Joy's transportation) developed a cute new problem: apparently there had been issues with the ignition lock for some time, and suddenly it started jamming in the RUN position. It'd turn forward, toward START, but not back toward OFF. Turning it forward until the starter ground its teeth and then quickly back would, however, get to OFF. Ugh. I just spent a while poking at it, after administering a dose of cleaner & dry lube... and discovered that the problem had gotten worse, and also that it had worn all the teeth off Joy's key (which was still accepted as a starting token). My key, when I tried it, wasn't letting go no matter what, nor would the lock allow OFF as an option.

Well, turns out that the way to stop the engine is to disconnect the negative lead from the battery and then try to crank the starter (the headlights aren't enough of a load, though I didn't try the high beams).

With electricity absent, I wiggled my key forth & back several times, and nothing jammed... though it's not clear what caused the jamming, really.

We'll be needing to run an errand or two in the Jeep this afternoon, so I'll be leaving the tools for disconnecting the battery in the back. Just in case....

I guess the old beast will be needing a new lock cylinder Real Soon Now, but today isn't the day.

So, head for nearest dealership. Can't even get the codes looked at until tomorrow at the earliest. Ponder, discuss. Joy heads for Cameron Park with her daughter; I call AAA and use my 100-mile long-range tow plus 8 miles to get the Prius back in front of my house. (By this time, the fault seems to have cleared (no lights, and the car behaves normally at parking-lot speeds), but driving it a long way seems inadvisable, especially as I don't know that the fault codes were. What's that "Multi-Function Display" for, anyway?)

Anyway: tow truck ride goes smoothly; the return trip will suck. Driver's a nice guy. Tip him some cash and a bag of backyard avocados.

Then call Hertz. Got a Corolla or similar lined up for tomorrow morning, and a lift to go pick it up. Prius fixery can wait until later; this trip is kinda now-or-never.

It's almost like the Prius has a phobia about leaving California. I try to explain to it that there are Prii in hillbilly country, too, and that outside California it'll get Real Gas, not the oxygenated junk, and it'll be able to get 54 MPG again, but it just isn't believing me.

And, looking at the after-hours activity? I'm glad I didn't hedge my bets by cutting another leg off the pig ahead of Intel's quarterly earnings statement. The recent gain was based on optimism about earnings, but it seems to have outperformed even the optimism. Up almost a buck and a half after hours, forsooth!

* Not an old Norse god.** Not an Eastasian delicacy.*** If plutonium is copper, I work on toasters.

Tuesday, 10 June 2014

Grumble grumble finally got rid of the mystery error message through a simple but arcane maneuver that has no perceptible connection to the message. Now I can duplicate the problem, under the development environment. Except that this manifestation of the problem causes the development environment to get wedged. And, owing to the nature of the LabVIEW "programming language", I can't bloody find the place to set a breakpoint, nor see what the connections are. Not even with grep.

I'm reminded of why, or rather when, Linux users hate Windows. I, for one, don't hate Windows when I'm using Linux. It's when I'm forced to use, or interoperate with, Windows that I hate Windows. (When I'm using Linux, I have occasional grumbles, but if I get really annoyed about something, I have the option of fixing it myself, because Open Source.)

Up until a couple of weeks ago, I was perfectly happy to ignore LabVIEW, and even to have it on my "gotta learn someday because it's what everybody uses" list. Now that I have to deal with it, personally? EXTERMINATE! EXTERMINATE!

Update: Hey, guys? Most software that deals with drawing boxes and connecting dots has this thing called "View→Zoom" to allow getting an overview in a limited space... or getting a close-up view of what yer pokin' at, so's ya can see where things connect. Might be worth a thought for, say, the 1996 release. 'Cause when I delete a malfunctioning and useless module, and try to re-connect its inputs and outputs? The handles are bigger'n the lines I'm trying to manipulate. Makes it real hard to see what I'm doing.

Boopdate: Well, after I gutted the useless module what's supposed to beep or boop following user input, according as how the input was OK or not, the UI seems to be working. Some lower-level module involved in playing the beeps and boops was throwing an error, which was causing all manner of non-obvious bogosity. So now I can build an executable that seems to work, though it says "Student Edition" all over the place. Back to the client site, tomorrow or the day after, where we left the Official Development System, build a fresh boopless binary (maybe even correcting for the absurd screen layout the dear departed baked into the original!), and see if it runs on the client's shiny new PC....

Still bashing my head against the horrid LabVIEW software for the Nightmare Project.

LabVIEW's uninformative error messages don't make it any easier, of course. And telling me that a VI claims to be part of library, and that I need to disconnect it and re-add it might be more useful if (1) there were some way of learning which library it claimed to belong to, and (2) the library-adder didn't refuse to add the VI on grounds of it already being part of the project.

And this whole mess is taking on a Winchester Mystery House quality; the code was adapted from an earlier project, which was adapted from one before that, which... and a lot of outdated stuff never got removed, and there are countless dead ends, and there appear to be a couple of non-Euclidean rooms. And it appears that, somewhere along the line, a couple of VIs were copied out of a now-long-obsolete standard library, and modified.

Almost time to dig out the Yellow Pages and have a look under "Necromancers." (No, not "spiritualists"; I need someone who can raise the dead. Or at least plague them in the afterlife.)

Friday, 30 May 2014

The past week having been largely eaten by the problem of getting a simple test-automation program to run on a second machine, I feel some cursing is in order. I'm about ready to consult a necromancer, if not to summon the author of this program then at least to disturb his rest.

We did find the source code... so far as LabVIEW can be said to use "source code". It's all Ancient Egyptian to me*. But! I successfully defanged the apparent copy protection. Only the code still doesn't run right on any but the original PC. The failure mode has changed, but it doesn't work.

Now I'm trying to poke at it using student edition LabVIEW (don't worry, we'll compile for delivery using the fully-licensed version). And: I can poke at the blocks, and kinda-sorta see what's going on, after a fashion... but I can't run the sucker, because the library topology has gone non-Euclidean or something. Totally obscure error message, to which the solution might be either "keep all the source files in exactly their original locations, and don't even think about working on a copy of the project" or "re-install LabVIEW and try again."