Scan Tools and Techniques

A Scan Tool is any device which can check and retrieve fault codes. They will often come in varying degrees of technology, from a test lamp in a large official looking case to complete interfaces supplied to Authorised Service Stations which can communicate with all electronic components. Let's start by dividing these into Categories.

  • OBD Flash code readers - The simplest type will active a diagnosis communication mode, which will cause a light to flash. This light can be inside the ECU, be part of the code reader, or maybe the MIL. Two flashes and a pause would indicate 2, 6 flashes and a pause would indicate 6. When this code numbers are collected, they are cross referenced in a handbook to reveal the cause of the error, which can then be rectified. As these are ECU based, these codes will relate directly to the engine only, and what the engine ECU can detect. These types of devices are often very specific, not only to Manufacturer or Model, but sometimes down to individual groups within a Model type.
  • OBD II and ELM Devices - With the introduction of various OBD II diagnostic standards, Scan tool manufacturers were able to produce one device which will be able to connect to OBD II compliant vehicles and rear standardised codes. As mentioned on our Diagnostics page, OBD II did have various protocols, such as VPW, ISO and PWM but multi-protocol devices are available to cover them all. The most famous of these are the ELM series of devices, using the ELM chipsets in a variety of devices, from complete units to Development kits. The latest version is the ELM327 chip, which, when implemented correctly, will allow OBD diagnostics on ISO, VPW, PWM, KWP and CAN standards. Details on the OBD Codes can be found at OBD Codes.
  • Manufacturer Specific Code Readers - These Devices work on far deeper level compared to OBD II devices. The Manufacturer Specific tools are able to carry out full diagnostics on many models, and provide a coverage second only to the manufacturer. Examples of these are Vag-Com and, pictured above, Peake. As well as the OBD II DTCs, these will also be able to interpret Manufacturer specific codes generated in OBD diagnostics, and often communicate with all other diagnostic enabled devices such as ABS systems and Body electronic modules. They are usually the most powerful class of diagnostic devices, second only to OEM Tools, but are held back by Single Brand usage.
  • Multi Platform Diagnostics - Multi Platform diagnostic tools act like a collection of the above-mentioned Manufacturer Specific Tools. These are made available to Service stations to provide powerful diagnostics to many different Manufacturer's vehicles. Depth of coverage can vary significantly between supported Manufacturers, with a few reaching Manufacturer Specific levels on some brands, but only OBD II level on others. These tools are often more expensive, but overall, can represent a saving compared to the cost of numerous Specific Hi-Level devices. Examples of 3rd party Multi-Platform devices are Launch, and Autodiagnos, and OEM manufacturers such as Bosch producing the Bosch KTS range.
  • OEM Scan Tools - The Highest level of communication is naturally the OEM equipment. Able to interface with new vehicles as they are released, and to carry out tasks such as coding and programming of replacement modules. Examples of OEM tools are BMW's Group Tester 1 (GT1), Porsche's PIWIS (Based on a Bosch KTS platform), and Mercedes Benz' Compact STAR
  • Diagnostic Techniques

    So now you know how dedicated Diagnostic tools work, but that isn't the complete solution. Code readers are not a magic bullet that will find and fix all problems, and true Fault finding techniques are used. It is best to always follow a plan, and gather as much information on the components to either locate yourself, or even if you ask on a technical forum. An example of a routine to carry out is-

  • Identify the symptoms - Gather as much information of all problems, What happened, under what conditions, is the fault recent, intermittent, continuous? Seemingly unconnected information such as the time of the faults, or the days could hold vital clues. Imagine if a vehicle would cut out only on a Tuesday morning. After discussing what happens on Tuesdays you discover the owner always visits one shop that day, which happens to be 6am via country lanes. It later turns out that Main beams used for long periods on this day only produce an earthing fault that affects other components. After completing and finding a fault with a vehicle, always look back, you will sometimes find overlooked or assumed information cost a lot more time than asking the right questions!
  • Clear all assumptions - If a vehicle refuses to start, and the fuel gauge shows full, don't assume it is! One short circuited wire could send you on a long journey looking in the wrong area.
  • Read the fault codes - Always remember when trying to find a fault with a car, to ask it! Many people use diagnostics incorrectly, and sometimes even the diagnostic systems are to blame reporting miss-named faults. Start by performing a full scan, noting down all the recorded errors, then erasing them. Fault codes are held on Non Volatile EEPROMS which will not clear themselves unless instructed to do so. Some codes might be the remnants of long since cured problems. Now re-scan the vehicle and see if any codes have returned. This will point to a current active fault. Next, take the vehicle on a Drive cycle, a relatively quick test drive that will cover most aspects and driving conditions. This may trigger a condition based fault. Some diagnostic systems are able to record Freeze Frame data, which may help pinpoint the conditions that caused a fault. If it is an intermittent fault, and not currently present, it can sometimes be better to wait until the fault re-occurs, and re-check for codes. Obviously, in some cases this may not be possible (think intermittent loss of power in an aircraft, asking the owner to call you next time it falls out of the sky isn't an option!)
  • Understand the codes! - A fault reported by a device is not the same as a fault with the device. One of the most common examples of this is receiving a Lambda-high code, and the first thing done is a new lambda sensor. This is a modern equivalent of shooting the messenger! Always try to verify a sensor is faulty before replacing it. This does sound very basic, but if I sold all Lambda sensors that were changed as a result of an airleak in a different area, I'd be a very rich man!
  • Back to Basics - Never get too caught up with the high tech world. Remember to check the simple things, fuses, wiring plugs etc. For a petrol engine for example, check the Holy Trinity; Fuel, Air and Ignition, and not just the presence, but the timing of this. You may need to start checking all sensors manually with a Multimeter or Oscilloscope. Signal generators can produce artificial readings but remember, a good signal needs a good sensor AND good conditions.