Tips for maximizing your scan tool use

Second, is what is known as loop-speed or the speed in which the scan tool has the ability, to refresh. When we select to view a set of PIDs, we are making an inquiry to the ECU for each PID we select. The ECU will have to process the request from the scan tool and then reference the inputs it's processing from the vehicle. It will then report the data to the scan tool, where is it processed and delivered to us for viewing. All of this takes time so, the more inquiries we make, the slower the scan tool performs… Choose wisely!

Next, is dependent upon the system you are addressing. Some systems (like power windows, for example) are simple and may involve one or two ECUs to carry out the processes of opening and closing them. Other systems are very inter-dependent upon one another (like ADAS, Traction Control or even HVAC) and require communication between several ECUs and many times over multiple communication networks (Figure 2). My point here is, I'm always looking for the scan tool to tell the entire story. I should be able to capture the inputs to the ECU as well as the outputs to reflect what the ECU sees and “IF” the ECU is trying to generate an output. The data should be collected in a fashion that a fellow tech could analyze the capture and make a diagnostic decision (more on this below).

Now, last but certainly not least, is a thorough understanding of the system and components that are being addressed. The ability to analyze scan data is just that. Without the understanding of system-configuration (all the players involved in carrying out a specific goal or output) there would be no idea about which data PIDs were necessary to view. The decision about which of the PIDs to display will be derived from the information found by referencing a wiring diagram as well as the description and operation of the system. These PIDs will represent the:

Inputs — Information about individual components’ physical state, (amount of pressure, temperature,   angle or position) and the intent of the ECU or person operating the system.

Decision making/processed data — This information is reflected by the ECU PIDs, which indicates a state of operation (a “thumbs-up or thumbs-down,” if you will). They will typically be displayed as “on/off”, “yes/no”, “permitted/not-permitted,” etcetera. This gives us, as technicians, a valuable insight that will be explained a bit below

Shared data — As you are all probably aware, many systems exist on a virtual platform, meaning, their functionality requires a communication bus (or several) with integrity. If data that is being processed in a specific node is then reflected in the PID list of another node, this is a good indicator that the data is being shared over the network. This provides for a means to split the system into sections in which to troubleshoot. With a little bit of common-sense and knowledge of the previously researched system, a lot of unnecessary testing will be avoided.

Outputs — This is the result. Thinking in terms of a true "system", any break-down in the above-mentioned will not allow for an output to occur. Seeing the entire story reflected in the scan tool list will show your intent to operate a system, the data required for an ECU to make a decision, and of course, the final decision to operate or not-operate a component (and the reason why). Ask yourself, would you be thinking about testing a switched input (like a window switch) if the scan tool reflected a PID that showed the intent to lower the window?

Considering all, of this data is gathered right from the driver's seat. I can’t think of a more efficient way to begin a diagnostic approach. To demonstrate the value of scan tool analysis and how it plays a role in accurate and efficient decision-making, a series of preliminary captures on a few different systems is displayed below.

It gave us the slip
This vehicle has made it to the shop with the complaint of what is described as a "slip in the transmission." We know that a slip can occur internal to the gearbox or within the torque converter itself. It's important to distinguish which. Begin by first determining when the fault presents itself and then by educating yourself on how this transmission functions at, that point in time. This will offer you some anticipation of what should be occurring, and will also allow you to see the fault reflected on the scan tool. I typically like to view the following PIDs:

Engine RPM — This provides the input speed to the transmission's main shaft.

Main Shaft RPM — This, in combination with the above, will allow us to determine the amount of torque converter clutch slip occurring (if applied).

Command Gear — If a slip occurs, we can determine if it’s within a particular-clutch assemble or more global. This gives insight as to which components may be at fault.

Countershaft Shaft Speed — This indicates true vehicle speed. It will give us a point of reference to compare the main shaft speed in, order to determine if the slip is in the box or in the torque converter (or both!). Many PID lists offer this data after processing in “mph” so there is no math needs to calculate input to output ratios.

Referencing the capture (Figure 3), we can see that as vehicle speed increases, the PCM is commanding a shift in the transmission’s gear ranges. This is indicated by the step-up characteristics each time a shift is commanded. We can then see that the RPM suddenly “flares” after a shift to 2^nd gear. It's visible in the RPM trace but the main shaft speed maintains a steady indicated speed. This means that the slip is occurring at, this point in time. By researching the operation of the transmission, we would realize that the torque converter isn’t even commanded at, this point in time. This means we can conclude that the fault is internal to the transmission. More importantly, if further testing were to be conducted, it's likely not going to be focused around something like "main-line pressure". Logic would tell you other faults under different trans operating conditions would also be present if, that were the case. We could then limit our testing to the components and circuits necessary to correctly apply that 2^nd gear clutch pack. The best part is, we haven’t even left the driver’s seat!

A window of opportunity
This next case is of a right-front power window that isn't functional from the master window switch or, from the RF door switch. A quick visual and functionality test reveals all the other windows respond correctly, under all functions. Referencing the wiring diagram and description (if not familiar) will help us decide how to monitor the system with the scan tool. The master switch/ECU are both contained within one unit. With the master RF-window switch set to lower the window, the request can be seen on the PID list. This should tell you there is no need to test for a faulty switched input because the ECU saw the request. We see (Figures 4, 5) by the blue circuit that the master window switch communicates on a UART network, with the passenger door window switch. Accessing the PID list on this passenger door switch assembly also demonstrates the same request, to lower the window. So, with two simple tests from the driver's seat, we've avoided disassembling any door panels unnecessarily. Equally as important, we've narrowed down the area of focus. While operating the power window master as well as the RF door switch, the micro-relay can be heard operating within the switch. With the verification of proper B+ and ground supply to the switch, we can focus our effort on the circuitry feeding the window motor. The ability to manually drive the motor in either direction (from the passenger switch connector, with the door panel still affixed) proves the fault is internal to the micro-relay contact of the RF door switch. Again, all without removal of any door panel assemblies.

Feed me
One of the most valuable times to employ the scan tool is during drivability analyses. Just think of how many ways a “low-power” complaint can be derived from. This is nothing different than what we’ve been speaking about all along. Inputs/processing/outputs…it’s the same for drivability. We typically reference the fuel trim values to reflect how well the engine is being fueled. This is the end-result or feedback. When a vehicle fails to produce power, it’s because the engine can’t breathe properly, the air/fuel ratio is incorrect or, the ignition timing is not as it should be (or inadequate). With a properly set up PID list (In a graphed format) and running the engine under different operating conditions, it’s easy to determine the cause of the low-power complaint, right from the driver’s seat.

On the PID list being referenced (Figure 6), the MAF sensor could be identified as the primary input to determine how much fuel to deliver. It's responsible for weighing the air. Getting the fuel to the cylinder is the easy part. Properly weighing the air to determine the proper A/F ratio is the real challenge. Knowing the engine's displacement and the RPM, a simple math calculation can be carried out to determine an expected MAF value with the throttle wide-open.  The fuel trim will indicate just how hard the PCM is working to correct for a miscalculation. As can be seen in the graph, the engine was operated first, at idle/no-load and was then taken up to WOT/full load. The trend indicated that there was very little fuel trim at idle but a severe amount of positive correction (Totaling 66%) during high-load conditions. This indicates the engine was severely under-fueled, equally on both banks.  The fact that the MAF sensor reported 147gps indicates both, that it is not misreporting nor is the engine struggling to breathe. If it was misreporting, we would expect to see it do so by about 66% (to match the fuel trim correction). If the engine had a true breathing fault, the MAF would correctly report that and the fuel trim wouldn’t deviate away from zero, due to the accurate measurement.  The fact that it affects both banks states that the fault is common to both banks. The results of this one full-throttle pull conclusively point, to a fuel delivery issue and will have to be followed up with a pressure/volume test to prove the pump is under-delivering.  A test for fuel pump amperage and voltage drop will then determine if the fuel pump has everything it needs to perform properly.

So, as can be seen in just these few examples demonstrated above, the scan tool can open your eyes to how all the players function together to carry out a goal. You get to see the entire story play out for you so diagnostic direction can be gained before investing time in a specific- area. Begin employing these capturing/analysis techniques on known-good vehicles and get comfortable with the functionality of your specific scan tool(s). Learn the INS and OUTS of it and what makes it special. You do that and watch how quickly you become the cleverest tech in the shop…not to mention the increase in productivity and confidence.