Nearly everyone's had some important piece of plastic trim or other part break in their car at one time or another. In the past you pretty much had to ignore it or shell out a mad amount of money at the dealer for a new piece (unless your luck enough to find it at a salvage yard in decent shape). Glue either refuses to work for the most part or fails very quickly on abs. These days you can pick up a 'plastic welding' kit at any number of online stores that does a much better job. They use hot air to fuse the plastic together and give you a bond as strong as the original. I didn't have one of these handy when the a/c vent broke off the door of my beater but, with a little improvisation, I managed to rebuild the plastic screw posts on it and drill/tap out some new threads. It's actually stronger than the original, though it looks like crap (where no one will ever see it). An old high wattage soldering iron with a flat tip was put between the remnants of the old post and a piece of matching scrap. Once they were nice and molten, the iron could be pulled out and the parts held firmly together for a moment, just until they solidified. Since there weren't any nice posts lying around and the originals had long since disintegrated, I had to settle for irregular pieces that could, after adhering to the original part, be shaped with the hot soldering iron. The new posts are approximately twice the thickness of the old ones. I would prefer to use the kits in the future because, while it worked rather better than expected, this process was rather time consuming.
Friday, May 09, 2008
Improvised Plastic Repair
Posted by Ironlizard at 7:09 PM 0 comments Links to this post
| Hotlinks: DiggIt! Del.icio.us
Sunday, January 06, 2008
Faulty ECM or Just an Oily Distributor? (Nissan Sentra/Pulsar)
Who the hell came up with the idea of a sideways mounted distributor stuck right into the oil gallery of a cylinder head?
To be fair, I knew this particular bit was in need of replacement. It already leaked oil onto the transmission bellhousing just below due to a worn distributor shaft, I just wasn't in any particular hurry to get a new one since I rarely drive. What I didn't expect was what the distributor/crank position sensor would do, besides getting the cap and rotor a bit wet. It started with a fuel problem that would alternately produce flooding and low pressure from the pump, killing the car either immediately or shortly after movement. This seemed like an obvious fix. A new regulator and the pump was now producing consistently low numbers on the fuel pressure gauge while refusing to prime at all on some occasions. I was suspicious, so before dropping upwards of 200$ on a new unit, I took a trip junkyard for a cheap pump I could try for confirmation . (I broke it and cannibalized the two, but that's another story.) Right about that time the power to the fuel pump stopped working altogether. This led to the obvious checks of wiring, relays, fuses and fusible links for a few hours until life interrupted and the car sat a while longer. Nothing. Looking over the wiring diagram for this car, I noticed that the fuel pump relay was actuated by the ECM, the only part I hadn't checked before. $#!@.
Out from under the seat came the control module. With the key turned to 'Run', the two LED's in the ECM remained unlit. This was a bad sign, but not fatal since there were several possibilities besides a fried EPROM/power transistor/Other-Very-Important-Part. A few more power circuits, ignition signals, fuses and fusible links later and, fearing the worst, I swapped in the old PCM from before the manual transmission swap. The same blank stare from the LED's stared back at me accusingly.
Going back to the diagram, I noticed that the ignition coil and it's accompanying power transistor were linked directly to the same power circuit as the ECM, so of course I began poking multi-meter probes into it's guts. At this point I found something shorted (not sure exactly which wires) that disappeared soon afterwards (this is going to haunt me later). I don't remember what prompted me to unplug the crank position sensor and turn the key one last time but when I did, I was greeted with the Christmas themed ECM lights blinking cheerfully at me. Maybe I should have thought of this sooner.
Now, I had known that a bad crank angle sensor could cause stalls, no start and some very rough running but it's the first time I've heard of one behaving in this peculiar way (cutting off power to the ECM in an indirect sort of way). In hindsight (now with highlighting!), it should have been more obvious.
1/19 Note: Leaving the key in the ignition and wiggling the harness/disconnecting parts until relays kick on or the ECM lights up is a good way to troubleshoot something like this.
Posted by Ironlizard at 5:45 AM 0 comments Links to this post
Labels: sentra pulsar nissan distributor electrical | Hotlinks: DiggIt! Del.icio.us
Monday, December 31, 2007
Vista, Virtual Drives and the Blue Screen of Death
They started sporadically at first, gradually increasing in frequency until my beleaguered machine restarted with every visit to the Vista login screen, with it's pretty Aurora Borealis-like facade and ridiculous login icons. The faulty memory had been replaced. The ATI video drivers had been rolled back, rolled forward and unrolled with great vigor. USB devices had met their doom while being propelled at high velocity by their frustrated god. Various treks through the list of other installed drivers and arcane registry entries brought no relief lasting more than an hour. Maybe three. On the verge of installing a badly compromised alternative until a replacement could be found, it was agreed to reinstall the entire bloated, yet strangely appealing in some inexplicable way that can only be compared to the allure of poisonous seafood to some, mass that is Windows Vista for one last attempt. This heroic effort at slash and burn technical support lasted many minutes. When it was done, there was once again the veneer of a stable operating system residing deep within the dust and nicotine tar choked bowels of The Computer.
And for a time, everything was well. The gnomes of the screen did their work with tiny colored candles and the invisible hamsters spun their fan shaped wheels day and night while strange groaning things within did what strange groaning creatures do within whatever they're in. * This time more care was taken and interloping Windows Updates were stopped at the gates, thoroughly searched by the Google before allowed entry to the inner sanctum. Aging drivers were left unmolested by younger, more aggressive versions seeking to gain their positions. The Comodo firewall had it's teeth filed down to nubs and its corpse left within an MSI file to rot, lest it's corrupt touch once again bring about the dreaded Blue Plague... err Screen. Right then. Blue Screen of Death it is. The horses and coconuts lived in harmony for another blissful stretch of time.
To make a long story short: Virtual Clonedrive (Latest version last month, whatever that was) caused a STOP error immediately this time. Same symptomatic lack of any error code, just a plain, blank BSOD. This only after turning off the automatic restart function in VIsta (retained from XP, apparently).
*Whatever it was, at least they did it well out of sight.
Posted by Ironlizard at 3:48 AM 0 comments Links to this post
Labels: Bluescreen, BSOD, OS, STOP, Vista, Windows | Hotlinks: DiggIt! Del.icio.us
Tuesday, November 20, 2007
Automated Form Submission Using axWebBrowser With No Id Tags
It's fairly simple to manipulate the DOM of a web page in the Internet Explorer ActiveX control when the tags are nicely formatted with Id tags. You can just stuff the element into IHTMLElement and do Document->getElementById("Id"). You can then diddle with the button, field or whatever other HTML element you like to your heart's content. But what about those fields and buttons the page creator has neglected to give a unique identifier? The only answer is to put the the element, or group of elements if there are others that match this criteria, into an IHTMLElementCollection. This makes it rather more difficult to access the individual form element you need. There are a few examples of how this is done, but the only ones I found easily weren't in C++. I took the logic from a Visual Basic example and translated it to this:
void FormSubmit(){
// This gets all of the html input elements on the page. Buttons and textboxes.
// Must be HTMLDocument3 or it fails
IHTMLDocument3^ doc=(IHTMLDocument3^)axWebBrowser1->Document;
IHTMLElementCollection^ docelems=doc->getElementsByTagName("input");
// This is for a textarea control that doesn't fall under the input category
IHTMLDocument3^ doc2=(IHTMLDocument3^)axWebBrowser1->Document;
IHTMLElementCollection^ docelems2=doc2->getElementsByTagName("textarea");
// This runs through each element in the collection to see if it contains a particular string that
// you've identified as unique to the set of input or textarea elements gathered by each
// collection.
for each (IHTMLElement^ inputElement in docelems){
// This part is of particular interest as it activates or checks a checkbox by changing the entire
// element. Other ways are more difficult to implement with this particular type for some
// reason.
if (inputElement->outerHTML->Contains("Checkbox1")){
inputElement->outerHTML="<input type=\"checkbox\" name=\"Checkbox1\" checked/>";
}
else if (inputElement->outerHTML->Contains("recipient")){
inputElement->innerText=windowsTextbox->Text;
}
else if (inputElement->outerHTML->Contains("sender")){
inputElement->innerText="Anonymous";
}
}
for each (IHTMLElement^ inputElement in docelems2){
if (inputElement->outerHTML->Contains("text")){
inputElement->innerText="This is not a test."; }
}
for each (IHTMLElement^ inputElement in docelems){
if (inputElement->outerHTML->Contains("SendButton")){
inputElement->click();
}
}
}
This could be implemented with only one collection instance by using
IHTMLElementCollection->All instead of the getelementsbytagname method. Using this method, however, can reduce the number of items in each collection and minimizes the chance of false positives when dealing with multiple element types.
Posted by Ironlizard at 3:22 AM 0 comments Links to this post
Labels: axwebbrowser, c++, CPlusPlus, getelementbyid, getelementbyname, getelementbytagname, ihtmlelement, ihtmlelementcollection, iteration, programming, VisualStudio | Hotlinks: DiggIt! Del.icio.us
Thursday, September 20, 2007
Arachnophobia
Posted by Ironlizard at 1:58 PM 0 comments Links to this post
Labels: arachnid, Spider, web | Hotlinks: DiggIt! Del.icio.us
Wednesday, August 22, 2007
Rolling Your Own Gaskets
There are times when you can't find a particular gasket locally, or it's just unobtanium. You could always use silicone gasket maker but there are certain applications that are just too much for it to handle. That's if you trust silicone gaskets not to eventually lose chunks and do things like clog your oil pickup screen. I don't and, as a result, avoid the stuff whenever I possibly can. So what do I do when I can't find the gasket I need? I cut my own, of course. Sometimes you can even make a better gasket than what the local parts store is pushing as OEM. All of these reasons apply when it comes to the gasket I'll be doing today.
First of all, it's important to get the appropriate gasket material. You can't use just anything. Use the wrong material and you'll be sprouting leaks, or worse, very quickly. I picked up this roll of composite paper/rubber gasket material (suitable for most applications, with the exclusion of oil pans) from the clearance shelf of a local parts store for about two dollars some time ago. Let's put it to good use.
Here you can see the reason a store bought gasket isn't optimal for this particular application. The odd bulge on this intake port isn't accounted for on stock offerings and, as a result, the amount of gasket preventing a leak here is tiny. (Just about 1mm! You can see the imprint left on the second to last intake port below, the clean areas are what the oem gasket covered.) With a custom made gasket, there will be a good deal more space between you and a huge vacuum leak.
The first step is to simply make a pencil outline of the part by putting it down on the sheet of gasket material and running around the perimeter with your pencil. There's really no need to be careful, because we'll trim any excess later.
Now, it's a pretty simple matter to cut along the line to make our basic shape. Again, no need to worry about perfection. Leaving too much is just fine. Remember, it's easier to trim than it is to add material.
We have our basic shape. It's time to cut out the bolt holes. This is accomplished by placing the form on the intake as closely to it's final position as possible and punching through one of the bolt holes with an x-acto knife or something similar. No need to make the hole very large as some friction is important to hold the thing in place. Repeat for the remainder of the holes, keeping in mind that the gasket must lie perfectly flat. No waves or bumps at all or your new gasket will leak.
Now is a good time to begin cutting out the port holes and cooling passages. This should be fairly self explanatory. Try to start in the center of each hole to minimize the chances of poking a hole where a hole should not be.
Once that's all done, you can trim the outside to a perfect fit with your sharp blade and finally enlarge the bolt holes to ensure an easy assembly. Slop on the gasket sealer, assemble the parts and call it a night.
Posted by Ironlizard at 11:27 PM 0 comments Links to this post
Labels: automotive, diy, gasket, Intake, nissan | Hotlinks: DiggIt! Del.icio.us
Saturday, August 18, 2007
HP Netraid and Modern Linux Kernels
They just don't play well together.
I recently acquired an aging HP Netserver (for free!) and wanted to load up a LAMP server on it for testing. It seemed like a very straightforward proposition until I attempted to put it into practice. Not one modern distribution would would detect the RAID controller. Redhat 7.3 on some old disks would, however, and this gave me a bit of hope. The problem with using such an old version was that it wouldn't support some of the more modern packages I needed. PHP5, for example. I would need to upgrade somehow. This I did, going through the upgrade path all the way to RH9. Going any further, however, was nearly impossible due to some odd restructuring that had occurred at RedHat sometime after this version. Besides, what I really wanted was some flavor of debian, with it's delicious apt-get.
Researching a bit, it turns out that the 2.6 and above kernel has lost the ability to detect these hardware RAID adapters for some reason (the PCI ID's are missing from the newer drivers for HP Netraid 1M and Netraid 2M, even though the legacy driver itself is otherwise the same). There is, luckily, a useable patch to the 2.6 and above kernel that takes care of this problem by adding the two ID's to the source code of the megaraid files (megaraid.h and megaraid.c must both be patched or it won't work). The 2.6+ kernel patch, by Kevin Carson, can be found here.
This is the essence of it, in case the old archive disappears:
+++ kernel-source-2.6.11.works/drivers/scsi/megaraid.h 2005-07-05 10:05:44.000000000 -0700 @@ -84,6 +84,10 @@ #define LSI_SUBSYS_VID 0x1000 #define INTEL_SUBSYS_VID 0x8086 +/* Sub-System Device IDs */ +#define HP_NETRAID1M_SUBSYS_DID 0x60E7 +#define HP_NETRAID2M_SUBSYS_DID 0x60E8 + #define HBA_SIGNATURE 0x3344 #define HBA_SIGNATURE_471 0xCCCC #define HBA_SIGNATURE_64BIT 0x029 --- kernel-source-2.6.11/drivers/scsi/megaraid.c 2005-06-16 08:06:21.000000000 -0700 +++ kernel-source-2.6.11.works/drivers/scsi/megaraid.c 2005-07-05 10:06:39.000000000 -0700 @@ -5037,6 +5037,10 @@ PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0}, {PCI_VENDOR_ID_AMI, PCI_DEVICE_ID_AMI_MEGARAID2, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0}, + {PCI_VENDOR_ID_AMI, PCI_DEVICE_ID_AMI_MEGARAID3, + HP_SUBSYS_VID, HP_NETRAID1M_SUBSYS_DID, 0, 0, 0}, + {PCI_VENDOR_ID_AMI, PCI_DEVICE_ID_AMI_MEGARAID3, + HP_SUBSYS_VID, HP_NETRAID2M_SUBSYS_DID, 0, 0, 0}, {0,} }; MODULE_DEVICE_TABLE(pci, megaraid_pci_tbl); I find it rather odd that the fix, distributed two years ago, still hasn't made it into the official source. It's not as if it were some huge change and would add support to these servers, which are rather old but still quite useful. For anyone not familiar with the patch format displayed above, the lines preceded by a plus(+) are the additions to the existing code which is shown around the new lines for reference. The @@ -84,6 +84,10 @@ line tells you around which line numbers the changes will be made. In this case, we're looking at line 84 of the header (.h) file. The changes are made directly to the files of the kernel source before compiling. (I've been so spoiled with automated patches and such that I actually had to look this up.)
I cobbled together this procedure from four different places:
http://www.falkotimme.com/howtos/debian_kernel2.6_compile/
http://www.suseblog.com/?p=156
http://www.edseek.com/archives/2004/03/22/creating-an-initrd-image-on-debian-gnulinux/
http://www.linuxquestions.org/questions/showthread.php?t=335214
While it may be better to compile the source on another machine and create an install disk, this just seems easier and doesn't require compiling an entire distro from scratch.
1) Download Sarge 3.1 (it's out there, though you might have to hunt) minimal install, change sources.list, run apt-get update then dist-upgrade. This didn't upgrade my kernel, but changed everything else to etch. This can break things, but should be just good enough for the next step.
2) Get some needed utilities and the source:
apt-get install kernel-package ncurses-dev fakeroot wget bzip2
cd /usr/src
wget http://www.kernel.org/pub/linux/kernel/v2.6/linux-2.6.18.tar.bz2
3) Unpack the sources:
tar xjf linux-2.6.18.tar.bz2
cd linux-2.6.18
4) Edit both megaraid.c and .h with patch code. The only things you'll be adding are:
#define HP_NETRAID1M_SUBSYS_DID 0x60E7
#define HP_NETRAID2M_SUBSYS_DID 0x60E8
In megaraid.h. and:
{PCI_VENDOR_ID_AMI, PCI_DEVICE_ID_AMI_MEGARAID3,
HP_SUBSYS_VID, HP_NETRAID1M_SUBSYS_DID, 0, 0, 0},
{PCI_VENDOR_ID_AMI, PCI_DEVICE_ID_AMI_MEGARAID3,
HP_SUBSYS_VID, HP_NETRAID2M_SUBSYS_DID, 0, 0, 0}, {0,}
In megaraid.c
5) Make sure you're in the /usr/src/linux-2.6.18 directory and type:
make menuconfig
This will bring up a nice menu driven way to configure your new kernel's options. There are a few hundred esoteric options in here. I suggest checking them carefully because some things aren't included by default that I consider a necessity. IPTables and Netfilter, for example.
In the SCSI drivers section: select *only* the legacy driver remember to compile it with the driver as a <m>odule, this is very important. I also selected RAID transport class and a few dozen other things in the kernel cinfiguration that seemed interesting or useful. This may or may not be a good idea, see your favorite linux expert for details.
Once this is done, save and exit. Then type the following:
make-kpkg clean
fakeroot make-kpkg --revision=myKernel.1.0 kernel_image
6) After a few dozen hours install your shiny new kernel:
dpkg -i kernel-image-2.6.8.1_myKernel.1.0_i386.deb
7) Do not reboot. Well, you can if you really want to but the new kernel won't work just yet, so you'll need to boot into the previous version to finish up.
8) Now edit the intramfs file in /etc/intramfs-tools/modules (memory fails me here, but that's about where it should be) and add 'megaraid' on a line by itself. If it doesn't exist you'll need to apt-get intramfs or whatever the heck the package is called.
9) Type: update-intramfs -c -k 2.6.18 (or your kernel version)at the command prompt
10) edit the grub menu.lst in /boot/grub and add:
initrd /boot/initrd.img-2.6.20
To the boot image of your new kernel. The old kernel's boot parameters should guide you if you're not sure where to put this.
That should do it, if it doesn't work for you, see my disclaimer. One good thing about GRUB is that it keeps my old (2.4) kernel handy in case I screw up and need to do this over again. I can now use more up to date packages on my old Netserver. Unfortunately, this has to be done every time I upgrade the kernel from now on.
Posted by Ironlizard at 10:11 PM 3 comments Links to this post
Labels: custom, debian, drivers, HP, kernel, Linux, megaraid, netraid, raid | Hotlinks: DiggIt! Del.icio.us







