It seems like yesterday when you graduated with your Associate’s degree in Automotive Technology but it’s been three months, and you’ve successfully landed a job at ABC Auto Repair in your hometown. The boss, though, has been slow in cutting you loose; feeding you a stream of oil changes and tire repairs as you become accustomed to the workflow and your fellow technicians.
Then the day comes! The boss hands you your first diagnostic ticket — a customer concern that the “Check Engine light is on” — and he tells you he wants to see what you can do. You’re excited about the opportunity to show what you’ve learned over the last two (or more) years of study and you’ve handled more than a few Check Engine light complaints under your teacher’s guidance. This should be a piece of cake!
Four hours later and you still have no clue why the light is on or what to do about it. Now you’re feeling discouraged and you’re wondering if you’ve chosen the right career. Before you cry “Uncle” and throw in the towel, let’s talk about the process you’re using in your diagnostic method. That is, if you’re using one at all!
Don’t run before you walk
How should you proceed when you get a ticket with a Check Engine light concern? Often, that’s all the information you’re going to get and unless the car is totally running like — well, you know — so you may not know right away whether or not there are any drivability concerns to go along with it.
My first step after bringing the car into the shop is to connect a scan tool using the Global OBD II option. The standardized format makes navigating through the data I want easy, no matter the make, and all “live” data is actual data free from substitute values that you may see in a more manufacturer-specific mode. The first stop, of course, is to see what codes are stored or pending and you’ll find that in Modes $03 and $07. I’ll record all the code designators I find and then move over to the “Freeze Frame” records to learn a bit more about the conditions the car was being operated under at the time the code(s) set.
A word, though, on Freeze Frame data. If the code is part of a continuous monitor (Comprehensive Component, Misfire or Fuel Control), then the data I find there is relevant to my diagnostic approach. Looking for the cause of a misfire at idle is different than one that occurs only under load. However, if the code is part of a non-continuous monitor (pretty much all the others), I’m not going to be as concerned about the data. In these cases, it is only telling me about the test conditions required and not so much about the conditions leading to the fault.
To clear or not to clear
I’m guessing that many of you reading this follow a similar process up to this point. And I’m also guessing that most of you clear the codes right about now, too.
That, my friends, could be a mistake.
When you clear the codes, you remove all traces of the problem and you may want to go back later to check on data that no longer exists. Once you hit that “enter” key, you wipe out not only the codes and related freeze frame data, you also clear and reset the Mode $06 data and the monitors.
So wait until you’ve completed the repair before you clear the codes.
Another common mistake is to rely on the code description to provide your diagnostic direction. Most code descriptions are pretty good but they don’t tell you what failed or why, only what component and/or circuit is involved. Once you’ve retrieved the codes, your next stop is your service information system. Time to do a little reading.
Research before you wrench
Even the simplest services today require interaction with an onboard computer. Tire pressure monitoring systems and battery replacements come immediately to mind, and oil life monitor resets have been around for even longer. So thinking you can apply the same operational knowledge across the OEM lines is a serious mistake that will lead to frustration, comebacks and lots of lost effort.
To avoid all that, invest the time up front to learn all you can about the code(s) and the system(s) affected. Start by reading the code description, focusing on the criteria required before the ECM can record the fault. Often, multiple codes will set when only one code is the actual culprit. The reverse can also be true. If some codes are recorded, other tests may be suspended until the fault is corrected. And that means that you could have a new code pop up after you’ve made your repairs! If you’ve already sent the customer home, they’ll be back and they won’t be happy.
In addition to learning about the codes and systems, check the service information for any factory Technical Service Bulletins (TSBs) related to the code or problem. Forty percent or more of drivability problems are related to ECM programming and the only sure is to reflash and update the control module. If that’s the cause in your case, it’s something you’ll never figure out on your own, leaving you chasing your tail in a never-ending circle. In addition, TSBs are often a great source of tips that can speed up your diagnostic time.
Don’t overlook other resources either. Many service information systems now offer databases of known problems you can research and you’ve heard me mention iATN and Identifix more than once. Today, even Google can be a source of good information as long as you take the time to screen and verify the source.
After the homework is done
Once you’re armed with the data and knowledge you need, it’s time to decide on your next step. How do you proceed with your testing from here depends on the particulars of the fault you are chasing down. But, as our own Albin Moore likes to point out, the key to good troubleshooting is to use a testing method that brings the fault to you!
I like to start my testing by basing my tests on two factors; one, I have an idea of what I think is the most likely cause of the problem so I want my test to either prove or disprove that idea and two, I want to perform a test that is both easy and general in nature so that I can test for multiple causes at a time. An example of such a test is the relative compression test I perform on each and every drivability problem I tackle. With a second channel referenced to the ignition event, I can gauge the overall mechanical health of the engine as well as verify that ignition timing is correct (if not, it could indicate a cam timing or synch issue). And it beats doing a mechanical compression check!
Once I’ve used general tests to narrow the realm of possibilities, I’ll move in to more precise system tests to home in on the culprit. In many instances, the testing process takes very little time because I’ve already taken the effort to consider all the things the cause can’t be. Once the cause is identified, I make the repair and then verify that the repair is the only repair needed by retesting or rerunning the system monitors.
Stick to the plan
A good diagnostic approach is applicable to any troubleshooting situation you find yourself in. The key, for me anyway, is to follow the same approach regardless of the problem I’m faced with. Initial data first (including a visual inspection), research of the problem and the systems involved, general testing to narrow the field and then focused testing to home in on the cause. Last but certainly not least, verify the repair before it’s returned to the customer.
Follow your plan of attack and you’ll avoid wasted effort, duplication and missed information. And that means more successful repairs in less time!
