How many times have you run into a situation like this? The vehicle that is in your bay has been to a couple of shops and still has problems. Maybe it has an issue that stubbornly hasn’t yet manifested itself. Or perhaps the system or vehicle you are working on you have very little firsthand knowledge of its operation and/or you have never had the “privilege” of working on one. I think if most of us are being honest, we would admit these situations are presenting themselves more and more frequently. So what do you do? How do you proceed at this point? Do you have a set plan of attack (POA) in place or a process that will help guide through these increasingly tough “diags”?
The diagnostic process has to start at the service desk. The questions of who, what, where, when and how need to be part of the original or triage process. The customer is often times the best source of information about the problems with his/her vehicle. They operate it numerous times a week in many different conditions and usually know its many quirks and where and when the problems arise. Our job
s as technicians is to be the diagnostic detective and put all the pieces together to come up with the “why.”
|This is the internal diagnostic flow chart I use to keep myself on track. It’ll work for you, too!|
So what’s your POA
Do you use Google or some internet "silver bullet" site? Will you use the results of that search to start replacing parts? Unfortunately there has been a trend in our industry to do just that! I get calls or emails from time to time seeking advice on diagnostics. When I ask questions like “what have you tested?” or “what do you know?” I usually get responses like, “we replaced this,” or “Google said to put this part in” I actually don’t have issues with Google searches or pay diagnostic sites — both have a place in the diagnostic process — but use the results to gain some direction and do some testing.
I always try to have a logical approach to diagnostics whenever I am working on something that I have very little firsthand knowledge or experience in working on. I am always harkened back to elementary school science class, when I was first introduced to the Scientific Method, a four-part process that involved the following steps with a focus on how we can apply them to our logical diagnostics:
- Form a hypothesis — Oftentimes we have an idea or silver bullet or TSB that we “think” may be the cause of our problem. For example, a 2002 Malibu with 200,000 on the odometer is towed in with a “crank-no start” condition. Based upon your experience, pattern failures and internet searches, you “think” or surmise that possibly the fuel pump may have died. This is your hypothesis.
- Design an experiment — Based upon your hypothesis, design an experiment to test or prove or disprove what you think is the cause. In the above example where we suspect a fuel delivery issue, maybe the experiment we design to test the fuel delivery system is to place a fuel pressure gauge on the fuel rail test port.
- Analyze the results of your experiment. Using the above vehicle, lets say I have fuel pressure that is in spec and yet the vehicle still doesn’t start. How do I know if the fuel is reaching the cylinders? Make note of the results and design another experiment as to how to test that.
- Modify your hypothesis based on the results. Design another “experiment” if needed. The above example may seem a little simple, but I believe it illustrates a logical plan that we as techs use regularly, possibly without necessarily realizing that we are employing a logical diagnostic method. I would implore you to use the same method to diagnose systems that you may not have “time in type” in. We test the no-start fuel delivery system in a logical path like muscle memory, yet if we are confronted with a network no-communication issue, we are often challenged on how to proceed.
Another method someone showed me a few years ago was to try to put ideas on paper and do some brainstorming. Try this sometime: take a piece of paper and divide it into 4 squares:
In the upper left corner, label it “things I know,” and list them. Maybe the vehicle is a No Start (NS), yet it has spark. Make a note of that.
In the upper right corner, label it “things I don’t know,” and list them. Do I have adequate fuel pressure? Does the injector and spark plug fire at the correct time?
In the lower left corner, label it “things I want to know,” and list them. So say I have fuel and spark yet the engine still doesn’t start. Is the fuel reaching the cylinders? Is the engine mechanically in time?
In the lower right corner, label it “design the experiment,” and list ways you could prove the “thing you want to know.”
This is kind of a “brainstorming” technique that I think makes techs critically think and put to paper a logical plan of attack. Another great piece of advice I picked up from a fellow Motor Age contributor that I call the “Manna Mantra” is to “do the extra test.” In other words, if you think you have proved or verified something, find an additional way to prove it to yourself. This will make you a better tech and is a great way to cross check your results.
The "flat rate" test drive
I believe that a logical POA should start simple and have the ability to garner the most amount information with the least amount of effort. This in my opinion
is to always start with a scan tool and test drive. Systematically leverage the information in the scan tool. Look at and record codes, both current and historical. Don’t necessarily limit yourself to the enhanced side; use the OBD II generic data to check for pending codes and take a look at the Mode $06 data, if applicable. Make note of the PCM calibration, too. There are times when calibration updates have been issued to correct drivability issues. It’s hard to tell if the module needs to be recalibrated if you don’t know what calibration is in the module. None of these tests are time consuming. It is merely using the scan tool to its fullest ability and having a logical progression or POA. After recording any codes and freeze frame data and comparing that to the customer’s “what, when and how” description, a systematic test drive while recording a snapshot or movie can usually give you a “go/no go” of the fuel system and the engine's ability to breathe. This is sometimes referred to as the “flat rate” test drive.