A PC-based scan tool, according to Fahrion, allows the technician to take advantage of the bigger screen and the user interface of the PC. "Say, if you're looking at an O2 sensor—a real common problem on any vehicle would be code that tells you the vehicle is either running too rich or too lean—the very first thing you want to do is decide whether it's a failed oxygen sensor that's giving you a bad message," he says. "All an oxygen sensor does is flip back and forth between a one and a zero, and it has to do that pretty quickly. If you try to look at that with a hand-held tool, you can't make anything of it, because there's no fixed voltage value you can look at. If you can graph it on your PC—you just click on a parameter and tell it to graph it—a sine wave comes up on your screen and you can see whether that's a good sensor. So that graphing capability is something you get on a PC-based tool.
"The other thing is the ability to embed a lot more help into the product," he explains. "We can put pages of help data right into the basic operations. How does this sensor work? What does this trouble code mean? Well, here's a paragraph instead of the line of text that you'd get on a hand-held.
"That's the whole direction we're going with our next generation AutoTap, which addresses some of what I believe your fleet guy is saying: they're overwhelmed with data," he says. "If they had a scan tool that walked them through a test, we can address that feeling of hopelessness, that you're overwhelmed with information and you don't know what to do with it."
FLOW OF INFORMATION
In his seminars, Menchu takes a systems approach. It's not enough to have a scan tool that can understand what the vehicle is reporting; the technician also needs to consider the variety of computers in the vehicle, and how those computers communicate and report information over the data bus.
"A common question I hear involves a car with four doors," Menchu says. "Each door has a computer in it that's connected to the bus. If one computer on one door goes out, it kills the signal, and it kills the bus. So you have to go check each one individually; you have to disconnect each one until the bus comes back up, and then you know which one's bad."
To Menchu, this scenario represents the ultimate problem in diagnostics, and it also points to the ultimate key: flow of information.
"You have to find out what's involved, who the players are, what are the conditions, and what's the flow of information?" he explains. "So you have to check all the players, see that they're operating under the right conditions, and trace the flow of information and find out where it's not correct. And then, on top of that, you need to have the skills and the tools to monitor it all and put it all together.
"Engineers often use a functional diagram to show a complex system. When you're diagnosing something and trying to figure out this complex problem, if you draw out your own functional diagram, based on your understanding, you can immediately tell where you are," Menchu says. "You're starting to visualize the flow of information and who the players are."
PUTTING IT ALL TOGETHER
According to Menchu, the confusion that some technicians might experience with OBD II codes is not the real issue.
"The real problem is the complexity," he insists. "It's massive amounts of complexity, and there's only one way to deal with it: that's to have lots of experience, and lots of information, and to have good tools that are meant for the job. If you have the wrong scan tool, there are certain things you can't do, and certain cars you can't fix.
"So the real question is, how do we teach technicians to deal with the complexity?" he says.
Menchu's recommendation to fleet maintenance managers is to get the technicians talking with the service manager, so they can learn from each others' perpectives. Together, he suggests, they must:
#1: Learn to identify the fundamental problems and issues;
#2: Once a week, get together with everybody in the shop and talk about it, 'Here's the problem I had, here's the information I gathered, here's how I found the answer,' whether it was going to the IETN, or calling up another technician, or they just stumbled onto it—and then analyze things together as a group.
"One of the things I see in the industry is that we get so caught up in the immediate need that we forget the big picture," says Menchu. "For a technican to be successful right now, he needs to fix the car. But you have to step back and look at the big picture of your career. You're always going to have that question mark of finding information and being able to absorb it. But at some point, you have to start focusing on yourself."
That's where experience comes in.
Dave Cappert examines the most important scan tool functions.
Not long ago, the scan tool was simply one of the tools you could use to help diagnose emissions problems. My, how times change.
OBD II changed maintenance forever--OBD III is set to do the same.
Technical Editor Dave Cappert answers your questions about scan tools.