Sorry guys I have kept my peace as long as I can. But I have read this time and time again on this and other forums so it's time for me to state the truth.
Engine diagnostic codes should never have been released to the public, they are dangerous in untrained hands. I know many feel that the computor diagnostics are better than sliced bread, well yeah they are if you in the parts sales business. I have read I don't know how many threads that someone has a problem and the first thing that is suggested is go get the codes read even if there isn't a CEL. Ok thats fine I guess to a point but one of the first things we were taught in Drivability diagnostics training was computors LIE. Over 60% of diagnostic trouble codes, the real problem has virtually nothing to do with the sensor that throws the code, and on oxygen sensors the number is closer to 90% (my biggest rant) So I will start with the oxygen sensor codes first. when getting an O2 sensor out of range code, changing the O2 sensor should be the LAST thing you do not the first. Oxygen sensor out of range high or rich is almost always a fuel related problem, IE high fuel preasure from a bad regulator, leaking or stuck injector etc so that stuff needs checked first, next check wiring making sure no shorts or grounds. same thing with lean condition usually caused by things like a vac leak or other bad sensor that isn't out of range yet.
Another one is when you get multiple codes, whats the first thing you should do? No it's not check the sensors that are throwing hte codes, it's go check your ground wires ALL OF THEM.
Basically when you find a trouble code, the first thing you should do, before ever touching the truck is sit back and think, what else besides that sensor could cause that to read like that? Then start a diagnostics on the situation. MAF sensor codes have been thrown for nothing more than a dirty air filter, yet the first thing people want to do is clean or replace the MAF sensor. MAP sensor have been replaced multiple times when all that was wrong was the hose was cracked
Guys I am not saying don't look at those codes, but use them as a tool not as the final diagnostics, they should direct you in the area to look at like mentioned above O2 sensors should get you looking why it thinks it's running rich, not automatically replacing the O2 sensor. I have heard that almost all O2 sensors that are replaced are not bad, infct there is very few things that can take them out. running certian aditives in your gas, and using things like Red RTV to seal intakes and exhaust manifolds are the 2 main culprits so lets sit back and think a little before automatically assume bad sensor.

 

You could have written this article yourself: AVOID THE AUTOZONE COMPLEX

 

Rob, very good points!! I'm very guilty of suggesting scanning for codes, making a bad assumption that people know how to interpret them

 

Yeah, I agree pretty strongly myself. I've been pottering around myself with this stuff. Currently trying to diagnose my own that just started throwing a few in the last 2 weeks. I've had a couple of cars that were simply "fixed" based on codes, only to find on my own it was something related the next day & replaced myself. Reputable garages, too. Got me just a bit steamed. Well now this truck is throwing TPS out of range and 2 TFI codes. A new co-worker suggested EGR, which I said I'd check (I should have remembered there aren't any exhaust passages anywhere back to engine). Still, I'd love to simply clean a main valve. At this point, I'm figuring I'm going to have to so some knuckle-busting checking on that belated TFI. I think a throttle bug of some sort could muck up the timing, too, though. My head's just a bit scrambled now, though. I don't think a bad TFI could mess with throttle bug, though. Truck runs fine on backup TFI mode. Checked air bypass with meter, MAP & O2 all fine. It won't idle without 'em at that. HEGO like new, too.

 

Actually, I did notice a potential vaccuum leak on my brake booster, but doesn't seem to yet. Possibly one of the most important neglected things to watch on these trucks. Mine rubber fitting starting to look cracked. That is the remaining sympton, however. Vaccuum stays at about 14-15 inches unless I rev it, which 0's it (fine) then bumps back to about 17 for a few seconds before idling back to 15. Seems more likely mechanical than electrical to me overall.

 

Monsterbaby: yup.

The codes do not replace a functioning brain.

All of the basics still apply, even if they are a little hidden.

tom

 

So many people get the code(s) and then start replacing stuff without running the pinpoint tests and using common sense to determine the REAL problem.

TTDCSB40

 

In defence of those poor helpless codes..

Before we get too far on the "them dagburn computers, never needed them on my Model T and Henry Ford knew how to build them good!" wagon I think you need to look at what their function is.

Sure, get code and replace what code points too, that's bad diagnostics in any book. That should be discouraged and unfortunately I believe we are ALL guilty of doing that from time to time. Not relying on the codes EXCLUSIVELY is a matter of experience.

The designers have all those sensors and wires in the engine compartment to help squeeze every last drop of HP out of that engine AND not destroy the Earth in the process. As a result the engine now needs a computer to perform calculations that before a carburator did as a bunch of pre-sets. Those sensors aren't there for you, they're there for the computer, it just so happens you can use them as well.

When the computer detects an abnormal signal in sensor A, it goes into fault mode. It's a computer, it can't find a work-around for the issue because it doesn't know what the issue is and isn't smart enough to problem solve even if it did. That's not the computer's job, it's job is to take those sensor inputs and calculate air-fuel mixtures and timing adjusts. So when the computer goes into fault mode it sends fault code based on the last faulty signal and tells the driver to check the engine. Just because sensor A sent a faulty code doesn't mean it's faulty - it just means it sent information that was out of its normal operating range - maybe it got bad input and passed it along, who can say (certainly not the computer)??

So you are correct, you shouldn't rely on those codes as the end-all answer to the problem, you should test first. Unfortunately the person designing that truck was also an Engineer and in the process of using sensors for the engine he/she/it also decided what a good idea it would be to put sensors on ALL the truck components. Those sensors aren't there for you, they're there for the engineer or the mechanic.

 

The release of ODB-II, 1.0 was the occasion for a BSOD. Chuckle.

The engineers had a job to do. They tried to do their job in the most cost effective method available. If that required measuring the gas cap being loose, they figured that they could find out of it was loose with some programming in the ECM. They did good. They figured if they had wheel rpm sensors on each wheel for ABS and anti-slip control they could use baseline rpm counts to determine low tire pressure (I think that is what they do), a very creative use of information that they already had. They know the rpm of the engine, and can calculate if the rpm 'contribution' by a given cylinder is not the same or close to the others, they can determine which cylinder is misfiring, but not the CAUSE.
These guys did a lot. They used the resources at hand and made some elegant product. Remember, the Apollo that went to the moon had a 4K computer, and look what they did with that. We should be taking our hats of to these women and men of the industry.
... stepping down from soapbox....
tom

 

And, if you recall, that computer kept "crashing" due to data input overload. A NASA engineer finally decided that the "crash code" could be safely ignored.

Steve

 

Then we have to assume that the NASA computers didn't freeze up and/or leave people staring at a blue screen of death when they "crashed".

(Which means it couldn't have been a Microsoft product ).

 

I'm just a sayin' that they went on a 500,000 mile trip with no spare, so to speak. And, tho the computer crashed from too much input, it took a human mind to interpret what was going on, both on the moon (driver) and in Texas, where some geek (no insult meant) just happened to know that code was a buffer over-run, basically. So the humans took computer codes ... and figured out what was wrong. The computer did not do all the figuring, and that was the point of the post, I think?
We still need humans. It has taken how many years to get 'self controlled' vehicles to run that desert 100+ mile route independently? My youngest nephew could do it in less time, and he's not in school yet. Point is, machine information has its place, and human interpretation is still a needed ingredament.

tom

 

All very good points, now, in defense of the auto parts aftermarket. I work for a parts
store that makes the code reader available, with a deposit, and will print out the
findings for the customer. The findings are in a 4 page format and the codes are not
given until the 4th page. That being said, let me point out the obvious, how many
actually read on the 1st page where it states exactly what you've all said, "just
because there's a code for a given part doesn't mean that part is bad!" Everyone
wants to fix the symptom, not cure the problem. And too, add in some less than
quality individuals doing the code retrieval, and we have the current situation. Believe
me, after working with the general public for auto parts, there are a few out there who
aren't ready to put gas in, let alone have keys.
I, too, will step down from the soapbox, now. Have a good one.