Fault codes: Cracking the nut
A recent job undertaken by Neil backs up the importance of knowing what a fault code means, and what that information can tell you
Published: 19 October, 2020
A fault code can tell you a lot, if you understand what it is telling you. Then again, it can also leave you questioning what it means and what is causing it to be set if you don’t know why it has logged in the first place.
A recent job I had backs up the importance of knowing what the information is telling you.
Turbo boost pressure
The vehicle was a 2008 Vauxhall Antara 2.0 Diesel, which belonged to my neighbour Gordon. One evening, having a chat over the fence, he said he had been having running issues. After his local garage plugged into it, they changed some parts based on fault codes they found, but it was no better. The vehicle logged turbo boost pressure fault codes under load, and had slowly got worse and worse to the point it was now as flat as a pancake and had no power at all. I offered to bring some tools home and plug it in and have a quick look one night, and then offer some advice on where to go next as a favour. After all, on several occasions he had helped me out with one thing or another.
Plugging in my Snap-On Zeus, the one that was part of my prize when I won Top Technician 2019, I was presented with the a number of fault codes (see Fig.1). Upon asking some questions, he told me that the vehicle repeatedly logged faults for turbo boost pressure, so the boost pressure sensor (MAP) had been replaced but the vehicle still had the same symptoms. The EGR valve vacuum control solenoid had also been replaced as it had fallen apart, and on removal the old one had signs it had been broken and repaired.
Reviewing the situation, we have six faults stored on initial inspection. What I like to do here is split the faults into groups of what could be related to the customer’s complaint and what can be left for now and diagnosed/repaired further down the line.
Grouping faults
My groups, based on my findings, were that the P0101, P0045, P0069 and P0299 faults were directly related to the lack of power complaint. I also surmised that the fuel level fault and glow plug fault were secondary faults which required attention after the initial four faults had been rectified. After a quick visual inspection under the bonnet, this vehicle was equipped with a DPF so the glow plug fault would require attention sooner rather than later. I decided to leave the fuel fault, as in my experience this wouldn’t cause the customer complaint. However, like everything, there will be cases with certain manufacturers where a similar fault code could cause a running fault. This means it’s always a good idea not to ignore every fault code stored.
With the faults, I wanted to focus so now I broke them down one by one by what they meant and what could cause them to set. This was done with a mix of technical information and my own personal knowledge. My list was as follows;
P0101 – Intake air system leak detected: This fault is logged in relation to the mass air flow sensor and it is because the engine control unit detects that the measured MAF is not within range of the calculated model in the software that is derived from the boost pressure sensor, which remember is new. For this fault I would compare live data from the MAF and MAP to see if either were incorrect.
P0045 – Boost pressure valve low voltage: This fault is logged either by a short to ground in the circuit or an internal fault in the control valve itself. As I wasn’t familiar with the engine, I had a visual inspection to see whether the turbo actuator was electric or was controlled by vacuum, on this engine the control actuator was an electric unit so the fault could indicate an issue with the unit itself internally. I decided again for this fault to use live data as a starting point to see if any data was available for the control unit.
P0069 – Barometric pressure not plausible with boost pressure: This fault is logged when the ECU compares values from both sensors for plausibility and if either are out of spec the code will set. Once again live data to view both sensors reading was to be my first check to see if some direction could be gained.
P0299 – Boost pressure low pressure: This fault is exactly as it states, the ECU isn’t seeing the correct pressure from the MAP sensor it should be. Using multiple inputs from other sensors the ECU knows how much pressure the turbocharger should be creating via the electric actuator and as it is not seeing what it should be the code is set. This code could be caused by the turbocharger itself being faulty, the electric actuator not working correctly or the MAP sensor not reporting the correct pressure back to the ECU. Again, live data would be my first port of call as I could look at possible causes of all four faults codes and there may be a common link causing all four.
Live data
With my list done and my plan ready to execute, I then went into live data to see what the ECU was seeing and gain information to plan my next step. I set up a custom list view and brought up my sensors in question. All MAF, MAP, BARO and Turbo actuator command data PIDs were displayed and reviewed to see if anything stood out. As in my previous articles, knowing what the numbers displayed mean is crucial as if you don’t know, how can you make an accurate diagnosis? So, to keep it very simple for the sake of the length of this article, for MAF I want to see 0 air flow ignition on, engine off which I will refer to as KOEO (key on, engine off) steady flow at idle and increasing flow in relation to engine speed and load. I won’t list numbers as every scan tool lists different air flow measurements but common ones you will see are grams per second (g/s) and kilogram per hour (kg/h).
For BARO I want to see a steady 1 bar under all conditions, KOEO, engine running etc. The main reasons this sensor is fitted is so that the ECU knows the current atmospheric pressure for correct air/fuel mixture for emissions and for plausibility to make sure other sensors are operating correctly. As in the UK we live at near enough to 1 bar atmospheric pressure this sensor should be as close as possible.
For MAP I want to see 1 bar KOEO (plausibility check), then a pressure rise along with engine speed and load. Again, this is where the ECU compares BARO and MAP to each other. If one isn’t correct, it will know and log the P0069 code. This is required as if one drifted out of calibration and read differently but still operated within tolerance, the ECU would determine it to be ok which could cause running issues but no faults to be stored.
For turbo actuator command, I want to see some form of change in command to the turbo again under engine speed and load to make sure something is happening as if there is no movement the turbo will not create any boost pressure.
Observing data, I found the MAF to be reading what I expected under all conditions, and the BARO was correct. However, the turbo actuator control was a fixed value, which is clearly wrong. Was this a turbo issue or something else? The final piece of the puzzle was the MAP reading and KOEO. I had 0 pressure, and knowing we should see 1 bar, I have direction on where to go. Increasing engine speed and load, the pressure did rise slightly but we clearly have an issue. Remember, there is also no turbo control but we have to consider that if the ECU cannot see boost pressure, as a failsafe it won’t actuate the turbo in case it over boosts and causes some form of damage. Again, this reinforces the importance of knowing system operation.
MAP sensor test
With all this data gathered, my next step was to test the MAP sensor. This sensor was new, and through questioning Gordon I learned it was a genuine part, so why didn’t it read correctly? Testing power supply and ground to the sensor, both were ok so onto testing the signal wire. The signal voltage in live data was available and was compared to actual data gently back probing the wire, after checking both they matched exactly. Using my sensor simulator, I applied a varying voltage down the signal wire which matched in live data, so what next? We have a genuine new sensor, good wiring and correct ECU operation it seems? At this point with limited tooling and having had a quick look, bearing in mind it has taken me longer to write the article thus far than actually carry out my testing, I asked permission to arrange to take the vehicle to the workshop to carry out further testing.
With permission from Gordon, a few days later I nursed the poorly vehicle up to the workshop to continue fault finding his vehicle. Out of curiosity I had asked if the old MAP sensor had been kept, which it had, so I brought it with me to test to see if anything could be found. On measuring the new sensor, the signal voltage KOEO was 1.07 volts. As a quick check, I plugged in the old sensor and it read 1.64v so 0.5 volts difference. Bear in mind, for this sensor, this will make a massive difference in pressure conversion by the ECU. Checking live data, I now had my 1 bar pressure I was looking for so the new sensor appeared to be faulty as the voltage for static engine off pressure was too low and the ECU was looking for 1.6v. Starting the engine, the boost pressure barely rose, so I had fixed one fault but we still had another issue and more than likely the initial complaint. Noting faults and clearing them only left p0045 boost pressure valve low voltage. Remember from before when I had no change in position from the control actuator? Well, now I had change, but it was very slight and far less than I expected to see.
Turbo and actuator movement
So where to next? I decided to visually inspect the turbo and its actuator movement with someone increasing engine speed to see what happened. Upon inspection, I found the actuator arm was remaining still but showing signs the actuator was attempting to move, but wasn’t able to. I then decided to check movement of the linkage arm that the actuator moves. On some turbo assemblies, this can be done fully assembled or activated via a scan tool special function, but on this unit the motor was locked and attempting activation didn’t work, possibly due to there being a stored fault code.
This meant the linkage had to be removed from the actuator, Upon removal, the linkage arm and pivot were tight and it took considerable force to move through its full travel so we had found the cause of the fault. The low voltage fault was being logged as the position of the arm wasn’t where the ECU was commanding it to be, and as it stayed where it was (low) a corresponding fault code was set.
After cleaning and lubricating the arm and pivot I managed to get everything free and greased up to prevent a reoccurrence. Once reassembled, I then checked MAP pressure in live data now seen a nice increase in pressure in line with engine speed and could now hear an audible whistle from the turbo indicating it was creating pressure. A long road test monitoring data confirmed correct operation and the vehicle was returned to its owner.
Understanding
This article highlights the importance of understanding what a fault code is telling you, and also why it pays to spend time learning to understand to make an accurate diagnosis. Like everyone, I don’t know the meaning of all fault codes and this is where technical data comes in and plays an important part in diagnosing faults. As for the faulty new map sensor? Well, after some digging it was actually the wrong sensor supplied, even though it fit and plugged in. It was actually for the 2.2 engine which uses a different intake/turbo layout.
- Don’t follow the fault code – follow the smoke signals
When this 2010 Vauxhall Insignia arrived at our workshop recently, we were asked the common question: “How much to clean my DPF?” As always, we informed the customer the first thing we needed to do was to undertake an assessment, so we could determine why the car was having DPF problems and what was required to fix it. This assessment is much more than a fault code read, often perceived as a ‘diagnostic check’ and this highlights the difference. The fault codes present on the car were ‘P2453 DPF Pressure Sensor A Circuit Range Performance’ and ‘P2458 Mass Air Flow Sensor Performance’.
Opening the bonnet, we were not surprised to see a new MAF sensor and a new DPF pressure sensor. This is frustrating as the owner has paid for these unnecessary parts to be fitted on the basis that ‘the computer said they were faulty’.
Looking at the DPF pressure sensor fault first, the ECU was reporting a circuit range fault. This may look like a faulty sensor but is in fact caused by excessive DPF pressure. The pressure is measured by the sensor. The signal is sent back to the ECU as a voltage so the excess pressure causes an excess voltage signal and in turn the ECU reports what it can see. The DPF back pressure was in excess of 150MB at idle indicating we must clean the DPF after addressing the cause of the problem.
Moving on to the MAF performance fault. Again, the ECU only reports what it sees as incorrect; in this case incorrect air flow. This is obvious when analysing live serial data so our next step was testing the intake system for leaks to confirm our suspicions. As you can see there was a significant leak from an intercooler pipe. We found a cause for both issues. The split pipe would have initially caused the MAF fault but in turn would lead to the DPF pressure sensor fault due to the excessive soot being produced with the major boost leak.
After consulting the customer, we repaired the car, replacing the intercooler pipe. Root cause now taken care of we had the easy part – cleaning the DPF. Our weapon of choice for DPF cleaning is always the JLM Lubricants’ Clean & Flush. With the step one chemical we left it to soak for a few minutes. After running the engine for a few minutes, we flushed the DPF out with the step two JLM DPF flush.
After the clean we had a healthy 6MB of back pressure in the DPF and the pressure sensor fault was cleared. An extended road test confirmed the fix.
- No code; No problem?
By Darren Darling
The challenge: A 2009 VW Golf 2.0 TDI with recurring DPF problems and no fault codes stored.
This low mileage Golf was presented to us after an unsuccessful trip to the main dealer where the customer was told there was nothing wrong with the car. The customer’s complaint was that the DPF warning light would illuminate every 100 miles; MPG was poor and the car was smoking excessively during regeneration (white smoke). As always, we carried out a thorough assessment of the vehicle to find out why the car was having these issues.
I suspected that the lack of any fault codes was the reason the owner was told that the car was fault-free but clearly we had an issue as the car should not be in regeneration so frequently. We quickly determined this was not caused by a blocked DPF as the DPF was very clean and there were no mechanical issues with the car.
Extended road test
Our next step was to carry out an extended road test while recording live serial data. If the customer had predicted correctly then we would see the DPF symbol illuminate in the next 20 miles or so. Sure enough, the light came on during the road test and the vehicle initiated DPF regeneration. This now gave us an opportunity to monitor the car during regeneration to see what was going on. We noticed that our temperatures during regeneration were too low and that the car did indeed smoke very badly.
Because of the low temperature, the duration of the regeneration was also excessive, taking over 40 minutes to complete. This is not uncommon and we have seen this caused by a software issue on many occasions. We then consulted our database and could see this exact problem with the software version so our next step was to carry out a software update and repeat the extended road test.
The car was noticeably smoother and quieter following the update but it did not initiate regeneration. Although a good sign, we had not seen any evidence yet that it had improved. So, we headed back to the workshop to carry out a forced regeneration so that we could monitor temperature, smoke and regen duration.
We were now happy with the temperatures; the excessive smoke had gone and the regen duration was back to normal. We were confident that the software update had fixed the car.
This job highlights the need for the independent workshop to invest in the correct tooling to carry out software updates because they are becoming more common. No unnecessary DPF cleaning was required to sort this DPF problem out and no parts were fitted to the car.
Another job done and another happy customer.
- Issues of rotation
I received a phone call from another garage: 'We've seen you in the Top Technician magazine and are wondering if you would be interested in looking at an ABS fault for us?' The call went along the usual lines, can the symptoms be recreated? What is the repair history? The vehicle was booked in for me to take a look.
The car in question was a 2011 Honda
CR-V, which had been taken as a trade in at a local garage, the fault only occurred after around 50-70 miles of driving, at which point the dash lights up with various warning lights. The vehicle had been prepped and sold to its new owner unaware a fault was present.
Fault-finding
After only a few days the fault occurred and the vehicle returned to the garage. They had scan checked the vehicle and the fault code ‘14-1- Left Front Wheel Speed Sensor Failure’ was retrieved. On their visual inspection, it was obvious a new ABS sensor had already been fitted to the N/S/F and clearly not fixed the fault. Was this the reason the vehicle had been traded in? They fitted another ABS sensor to the N/S/F and an extended road test was carried out. The fault reoccurred. This is when I received the phone call; the garage was now suspecting a control unit fault.
My first job was to carry out a visual inspection for anything that was obviously wrong and had possibly been over looked: correct tyre sizes, tyre pressures, tyre tread and excessive wheel bearing play. All appeared ok. The ABS sensors fitted to this vehicle are termed 'Active' meaning they have integrated electronic and are supplied with a voltage from the ABS control unit to operate. The pulse wheel is integrated into the wheel bearing, which on this vehicle makes it not possible to carry out a visual inspection without stripping the hub.
Endurance testing
With the vehicle scan checked, all codes recorded and cleared, it was time for the road test. Viewing the live data from all the sensors, they were showing the correct wheel speed readings with no error visible on the N/S/F. The road test was always going to be a long one, fortunately at around 30 miles, the dash lit up with the ABS light and lights for other associated systems; the fault had occurred. On returning to the workshop, the vehicle was rescanned, fault code '14-4 - Left Front Wheel Speed Sensor Failure’ was again present. Again using the live data the sensor was still showing the wheel speed the same as the other three, so whatever was causing the fault was either occurring intermittently or there was not enough detail in the scan tool live data graph display to see the fault. It was time to test the wiring and the sensor output signal for any clues.
Using the oscilloscope, the voltage supply and the ground wire were tested and were good at the time of test. I connected the test lead to the power supply wire and using the AC voltage set to 1V revealed the sensors square wave signal. Then rotating the wheel by hand and comparing the sensors output to one of the other ABS Sensors, again all appeared to be fine. A closer look at the signal was required, zooming in on the signal capture to reveal more detail; it became easier to see something was not quite right with the signal generated by the sensor when the wheel was rotated. With the voltage of the signal remaining constant, a good earth wire and the wheel rotated at a constant speed the signal width became smaller, effectively reporting a faster speed at that instant, not consistent with the actual rotational speed of the wheel. It was difficult to see the error, zooming out of the capture to show more time across the screen it could be seen that this appeared in the signal at regular intervals, although not visible all the time because it was such a slight difference. Using the cursors to measure between the irregular output and counting the oscillations, it was clear that it occurred at exactly the same interval every time. It had to be a physical fault on the pulse wheel.
This meant a new wheel bearing was required. The vehicle was returned to the garage as they wanted to complete the repair, a new wheel bearing was fitted and extended road testing confirmed the vehicle was now fixed.
- Put the pedal to the metal
I have spent most of my life repairing things that are broken and the rest of it trying to prevent it happening in the first place. This year, June to be precise, will be my 50th year in the automotive industry; I have witnesses and have embraced incredible advances in technology.
This article may appear somewhat negative, perhaps even misinformed and out of touch. Have I lost the plot? Before judging my motives let me explain how I think and react to change. I think I have already proved my ability to embrace technical evolution. Fixing a problem for me should be a well thought out long term positive step forward; Understanding the immediate challenges whilst focusing on the cause and not reacting to the symptoms. I would like to think of myself as a thinking engineer.
Developments
I am referring to current automotive developments, specifically autonomous and battery powered vehicles. We have just witnessed the first death by an automonous vehicle, the litigation should be interesting. Who is responsible? The driver? He was in full autonomous mode! The vehicle manufacturer? How about Microsoft? and we have all just witnessed how software companies respond to problems! Back to the driver then.
If you genuinely believe this is a step forward ask your self this question; would you take your family on holiday with no pilot in the cockpit? After all, aircraft have some of the most comprehensive and competent automonous systems.
Second on my list are battery powered vehicles. Let me present facts that support my position. The problem- pollution of the atmosphere. The cause- hydrocarbon fuelled vehicles. Battery powered vehicles will drastically increase the requirement on electricity generation, with most countries using hydrocarbon fuelled power stations! Limited distance and the uncertainty of charging port availability, notwithstanding the unwelcomed journey delays, is in my opinion
not a sensible answer to flexible mass transport.
The UK has marginal spare capacity in power generation, imagine if 25% or more of the UK car parc plugged in at 6pm. The national grid does have strategies for sudden increases in demand. These include bringing old standby stations online and increasing imported supplies. I accept these considerations are partly personal
and emotional. However, look at a more interesting set of problems facing the vehicle manufacturers,
such as lithium reserves and the geo-physical locations.
Currently the average energy consumption of battery vehicles is 65kw/hr. This requires 10kg of lithium per battery. Tesla expects to produce 500,000 vehicles by 2020. This would require 5,000,000 kg or 5,000 metric tons, per year, of refined lithium. Discussions are under way for production of reduced performance vehicles requiring less lithium.
Research estimates global reserves of 365 years assuming the current 37,000 metric tons production per year. Current lithium demands are split 30/30% with battery and ceramic production. However, it is also predicted that around 100 mega capacity battery plants, like Tesla will be required to meet demand globally. Global EV estimates of 100,000,000 vehicles by 2040 would require 800,000 metric tons of lithium per year. Divide this by the estimated 40,000,000 metric tons global reserves leaves a timeline of 18 years.
Demand
Demand is a variable that cannot be accurately predicted. For example, China’s population of 1.3. billion, already has 50% of the vehicle ownership of the USA. With India and other emerging economies coming on-stream, vehicle growth could exceed all predictive estimates.
Where is the electricity going to come from? Greece for example has a EU emission get-out clause as all its energy production comes from vast open cast coal mines.
Recycling cost is around five times that of new production cost, with around a 20:1 lithium recovery ratio.
The lithium atomic symbol Li is the third lightest solid in the periodic tables. Highly flammable, it is also used as solid fuel rocket boosters and torpedoes. It is also used as an initiator for triggering nuclear weapons. With more down to earth requirements, lithium is used in heat resistant glass, grease, ceramics, and iron steel production. These requirements exclude all other uses of lithium, from your mobile phone battery to those nice kitchen tiles your wife has chosen. So back to my proposition, dealing with the problem and not the symptoms! Batteries are not the answer. I’m no physicist, but I see the hydrogen cell as the only current hope on the horizon for flexible mass transport.
A much-improved public transport infrastructure, a more realistic vehicle operating tax structure will all play a part in vehicle ownership within the developed economies. We cannot expect emerging nations such as China and India, with around two billion people, to follow suit any time soon.
As a keen cyclist from the age of 15, with a mild asthmatic condition I’m as focused as anyone on reducing global emissions. Judging by the way so many motorists still drive their vehicles, the reality shock of what’s coming cannot be far away.
- Part two The good and THE GREAT
In part one, we looked at the start of the ‘diagnostic process.’ The first steps were customer questioning, confirming the fault and knowing the system and its function. These help the technician to build the ‘big picture’ necessary to repair the vehicle correctly.
In this article we will look at the next four steps.
Step 4: Gather evidence
It is easy to overlook this step as many technicians think of it as the overall ‘diagnosis.’ However, once the technician understands the system, gathering evidence will provide key information. This step is normally best carried out with the use of test equipment that does not mean the dismantling of systems and components.
Many technicians have their own favourite tools and equipment but this list can include (but not limited to)
the following:
Scan tool – It is always best practice to record the fault codes present, erase the codes, and then recheck. This means codes which reappear are still current. Remember that a fault code will only indicate a fault with a circuit or its function. It is not always the component listed in the fault code that is at fault
Oscilloscope – An oscilloscope can be used for a multitude of testing/initial measuring without being intrusive. Some oscilloscope equipment suppliers are looking at systems within high voltages hybrid/electric vehicle technology. The waveforms produced by the test equipment can be used when analysing the evidence and may indicate that a fault exists within a system. An understanding of the system being tested will be necessary to understand the information. This may even include performing sums so all those missed maths lessons at school may come back to haunt you. It may take time to become confident analysing the waveforms, so be patient
Temperature measuring equipment – This can include the use of thermal imaging cameras. Most systems that produce energy/work will also produce some heat. The temperatures produced vary from system to system. Examples include everything from engine misfires to electrical components, as well as air conditioning system components and mechanical components such as brake and hub assemblies. The possibilities are endless and results can be thought provoking.
Emission equipment – By measuring the end result, an exhaust gas analyser can show you if the engine is functioning correctly. The incorrect emissions emitted from the exhaust help indicate a system fault or a mechanical fault with the engine
Technical service bulletins – Many vehicle manufacturers produce technical service bulletins (TSBs) that are generated by a central point (usually a technical department) from the information that is gathered from their network of dealers. Some of these may be available to the independent sector either through the VM or through a third party – It’s always worth checking if these exist. They may indicate a common fault that has been reported similar to that the technician is facing. Some test equipment suppliers may provide TSBs as part of a diagnostic tool package
Software updates – Many vehicle systems are controlled by a ECU. Most vehicle manufacturers are constantly updating system software to overcome various faults/ customer concerns. Simply by updating the software can fix the vehicles problem without any other intervention of repairing a possible fault. This is where having a link to a vehicle manufacturer is vital in repairing the vehicle
Hints & tips – Most technicians will have a link or access to a vehicle repair forum where they can ask various questions on vehicle faults and may get some indication of which system components are likely to cause a vehicle fault
Functional checks – Vehicle systems are interlinked and typically share information using a vehicle network. The fault may cause another system to function incorrectly, so it is vitally important that the technician carries out a functional check to see if the reported fault has an effect on another system. By carrying out this check the technician again is building the big picture
Actuator checks – Most systems today are capable of performing actuator tests. The technician can perform various checks to components to check its operation and if the system ECU can control the component, often reducing the time to the diagnosis, by performing this task the technician can identify whether it is the control signal, wiring or component or it is sensor wiring. This function can be used in conjunction with serial data to see how the system reacts as the component functions
Serial (live) data – The technician can typically review a vehicle system serial data through a scan tool. Having live data readings to refer to can help you review the data captured. Using actuator checks and viewing the serial data can also help the technician to identify a system fault
Remember to record all the evidence gathered so it can be analysed during the next step in the diagnosis. We can’t remember everything. If the technician needs to contact a technical helpline they will ask for the actual readings obtained recoding the data gathered will help.
Step 5: Analyse the evidence
Analysing evidence gathered during the previous steps can take time. The technician needs to build the big picture from all the evidence gathered during the first few steps. You need to analyse the information gathered, and decide on what information is right and wrong.
This step may rely on experience as well as knowledge on the product. You should take your time – don’t be hurried. Time spent in the thinking stages of the diagnosis can save time later. Putting pressure on the technician can lead to errors being made. It may be necessary to ask the opinion of other technicians. If the evidence is documented it may be easier to analyse or share between others.
Step 6: Plan the test routine
After analysing the evidence gathered it’s now time to start to ‘plan’ the best way to approach to the task or tasks in hand.
The technician should plan their test routine, decide on what test equipment should they use, what results are they expecting, if the result is good or bad and which component should they test next.
Document the plan – this enables you to review decisions made at this stage in the next step. The technician may not always get it right as there may be various routes to test systems/components. The test routine may have to be revisited depending on the results gathered during testing. Documenting the test routine will provide a map. Also, don’t forget to list the stages, as this is something that could be incorporated into an invoicing structure later.
The technician should indicate on the routine what readings they expect when they carry out the system testing. This can be generated by their own knowledge/skill or the expected readings may come from vehicle information which they have already sourced. If the information is not known at the time the test routine is planned, then the test routine may highlight what information is required and what test equipment is needed. You shouldn’t be afraid to revisit the plan at any time and ask further questions on which direction the tests should take. If the plan is well documented and the technician becomes stuck at any point, they can pause the process and revisit later. Also the information can then be shared with various helplines that support workshop networks.
Step 7: System testing
The technician then follows their pre-determined plan, if it is documented they can record the results of the test(s) as they follow the routine.
Many technicians tend to go a little off-piste when they get frustrated. Having the routine documented can keep the technician on track and focused on the result. If the routine is followed and the fault cannot be found the technician may have to go back to the analysing the evidence or planning the test routine. The technician shouldn’t be scared of going back a few steps, as I said previously analysing the evidence takes practice and can be time consuming, not to be rushed.
Summing up
Remember to follow the process. It is easy to be led off track by various distractions but don’t try to short circuit the process. Some steps may take longer than first thought to accomplish than others. Some distractions may be outside of your control, and it may be necessary to educate others. Practice, practice, practice. Refine the process to fit in with your business and its practices, the business could align its estimating/cost modelling to the process, being able to charge effectively and keeping the customer informed at each stage of the process.
Coming up...
In the next article I will be looking at the next four steps which are; Step 8: Conclusion (the root cause), Step 9: Rectify the fault and Step 10: Recheck the system(s). The last article in this series will indicate the final three steps and how to fit them all together in order to become a great technician and perhaps succeed in Top Technician or Top Garage in 2018.
