# "Headlight Range Control" warning message - need some advice



## PanEuropean (Nov 3, 2001)

Hello All:
I'm posting this question for a friend of mine who owns a Touareg. It is a fairly new vehicle, SN 42xxx. It has two problems, which _might_ be inter-related, both of which have defied all the repair attempts of a very competent and concerned dealership.
First problem: The warning message "Headlight Range Control" keeps on appearing. Much work has been done to try and fix this: Alignment of lights checked, suspension level sensors checked, vehicle inspected for damaged wires, etc. Later on in the process, both headlight assemblies and the instrument cluster were replaced. The message still appears.
Second problem: This is really minor, I only mention it because it might be related to the first problem. The instrument cluster trip computer (MFA) will not store accumulated mileage over a series of trips. In other words, if the car is stopped and started a few times, the trip computer will zero out.
Has anyone here encountered a similar headlight problem, and found a fix for it? Does anyone have any thoughts or suggestions on the matter?
Michael
Phaeton Forum Moderator


----------



## shervinf (Sep 17, 2003)

*Re: "Headlight Range Control" warning message - need some advice (PanEuropean)*

The last time I got the Headlight Range Control Error my battery died. Have they checked your battery? It would explain why the memory gets erased!!!


----------



## spockcat (Jun 5, 2003)

*Re: "Headlight Range Control" warning message - need some advice (shervinf)*


_Quote, originally posted by *shervinf* »_The last time I got the Headlight Range Control Error my battery died. Have they checked your battery? It would explain why the memory gets erased!!!

Good tip. Could be. And the battery may be getting weak because of a failing alternator to battery harness.


----------



## hotdaymnitzbao (Oct 26, 2003)

*Re: "Headlight Range Control" warning message - need some advice (PanEuropean)*


_Quote, originally posted by *PanEuropean* »_
First problem: The warning message "Headlight Range Control" keeps on appearing. Much work has been done to try and fix this: Alignment of lights checked, suspension level sensors checked, vehicle inspected for damaged wires, etc. Later on in the process, both headlight assemblies and the instrument cluster were replaced. The message still appears.


i HAD this problem a few days ago... haven't gotten it fixed as one of my headlight is out.


----------



## jim.bresee (Nov 25, 2003)

*Re: "Headlight Range Control" warning message - need some advice (PanEuropean)*

We have this issue on our Treg.
In our case, the issues is a sensor that measures incline used to level the headlights has crapped out.
This sensor is on backorder without an expected delivery date.
The good news is that the Treg has an acceptable failure mode when this sensor dies. It sets the lights slightly lower then normal, but other then the orange warning indicator, it does not impact operation.
Good luck with yours!
Jim


----------



## nogood911 (Feb 7, 2004)

*Re: "Headlight Range Control" warning message - need some advice (jim.bresee)*

Hi All
Yes there have been some "issues" with the suspention level sensors-most of the time replacement of the failed sensor is the fix


----------



## STL VWguy (Jan 9, 2005)

*Re: "Headlight Range Control" warning message - need some advice (jim.bresee)*

My car has said this a few times. Seems to only come up when the car is parked on an extreme angle, then when started, the headlights try to self level and I guess can't. Only comes on at start in that situation then goes away. Hmm..


----------



## j.colind (Oct 11, 2003)

*Re: "Headlight Range Control" warning message - need some advice (STL VWguy)*

I'm getting this too ... and have steel springs. In my case, it's strictly temperature related. When it's cold outside, (ie below 5c) this message pops up. I rather suspect it's a voltage issue as I've also had the dreaded running gear workshop crop up when it's REALLY cold... I'm bringing the 'egg in on monday for this and a whole host of other minor gliltches. Will advise if the dealer is able to fix it...
C.


----------



## paul harden (Feb 4, 2004)

*Re: "Headlight Range Control" warning message - need some advice (j.colind)*

I had the same problem It turned out to be the left front suspension sensor was bad. The part had to be back-ordered. The dealer is scheduled to installed it on Monday. Only took the dealer and VW two weeks to find the problem.


----------



## PanEuropean (Nov 3, 2001)

*Re: "Headlight Range Control" warning message - need some advice (paul harden)*

Many thanks to everyone who offered their suggestions and advice.
Michael


----------



## PanEuropean (Nov 3, 2001)

*Re: "Headlight Range Control" warning message - need some advice (PanEuropean)*

This problem was finally resolved. It proved to be very difficult to troubleshoot.
The faulty component was the J519 central electrical controller, part number 7L6 937 049 M with internal software status 3001 (photo below). What made the troubleshooting very difficult is that this controller experienced a 'soft' failure, meaning, it did not generate a fault code.
In brief (please appreciate that this is VERY brief), the truck would constantly display a "headlight range control malfunction" message in the display between the speedometer and the tachometer. The written message would appear at start-up, and a yellow coloured alert message displaying an icon of a headlight would persist at the top of the instrument cluster.
An enormous amount of troubleshooting was done - both headlights were replaced, the instrument cluster was replaced, a new wiring harness was overlaid on top of the existing one, all sorts of coding was changed, yada, yada, yada - no results. The fault codes that would be returned consistently appeared in addresses 29 and 39 (the left and right gas discharge headlight units, J343 and J344). These fault codes were typically as follows: _"01539 - Headlights Not Adjusted 005 - No or Incorrect Basic Setting / Adaptation."_ No matter what efforts were made, it was not possible to either clear the fault message from the instrument cluster display (although the fault codes could be cleared from the controllers), nor was it possible to perform basic settings of the J343 and J344 controllers.
To make a long story short - a few very talented VW techs decided to put their heads together and work "outside the box" - meaning, ignoring the Guided Fault Finding system - and troubleshoot this problem the old fashioned way, using Principles of Troubleshooting such as data collection, analysis, and process of elimination of paths of influence. This eventually led to swapping the J519 Central Electrical Controller with a 'known good' controller borrowed from a different Touareg that belonged to one of the technicians. Even though the donor controller was an earlier model - a revision L suffix at software revision level 2703 - once that controller was coded to the appropriate configuration for the problem Touareg, it then became possible to complete the 'basic settings' adaptation of the two headlight control units successfully, and the problem went away.
I was invited to be involved in this process as a strategy planner. It was a fascinating project, and we were all really delighted to get this Touareg fixed - I have been driving it around for the last day, no problems of any kind. The only disappointing thing is that it took quite a while to fix it, and the GFF software was of no value. My personal guess is that there is a problem with the software of J519 controllers PN 7L6 937 049 M at internal software status 3001. If there are any VW Certified Techs on the board who encounter a similar problem, please feel free to email me (click on my user name for my email) and I will be happy to explain the whole process of fixing it to you.
It is very notable that at no time in the whole repair process - which spanned almost 6 weeks - did this J519 controller ever return a fault code. This is why I suspect a 'soft' failure of the controller, and from that, possibly a problem with the 3001 software in this controller.
Michael
Phaeton Forum Moderator
*The Culprit - note PN and software revision number*



_Modified by PanEuropean at 6:29 PM 1-24-2008_


----------



## sciencegeek (Oct 26, 2003)

*Re: "Headlight Range Control" warning message - need some advice (PanEuropean)*

Good story.
Was the old controller ever put into another egg to show that it was the cause of the problem? While I believe that you've fixed the problem, I don't believe that you've conclusively demonstrated that the old controller was the cause of the problem. (Standards of proof are high in science.







)
And what happened to the resetting problem of the trip computer?
This whole thing still smells like a battery problem; maybe the thing is fixed now because you guys have had it on a charger while doing all that work.


----------



## PanEuropean (Nov 3, 2001)

*Re: "Headlight Range Control" warning message - need some advice (sciencegeek)*

Arend:
That is an excellent question, and I thank you for asking it. But, you are going to have to help me out a bit with the logic of proving the argument as you propose it should be done. Not being a scientist (I am an aircraft pilot / engineer / safety manager by profession), I don't fully understand how putting the suspect controller in a 'known good' Touareg would strengthen the proof. It appears to me that if replacing a specific component solved the problem (we tested and proved that the problem still existed immediately prior to replacing the suspect controller, to control against any other action as a possible fix), then that is sufficient proof. But, I suspect you are correct, I just need you to explain the rationale, the logic of your statement to me so I can fully comprehend it.
We can't put the suspect controller back into the Touareg that donated the replacement controller, because the 'doner' Touareg unfortunately suffered a sudden death while we were troubleshooting the problem Touareg - this is how we got the 'donation' (photo here: VAG-COM 504.0 Not Detection Obvious Flat Tire on TPMS - Could this be a software bug? . The employee who owns the doner Touareg was not injured in any way - this is an amazing testament to the strength and careful design of the Touareg.
As for the problem with the resetting trip computer - that required recoding of the *OWNER* of the Touareg, using the special 'RTFM' programming code. This can be found in the Touareg owners manual, in the section that describes how the Touareg has three different trip computers - one for long term, one since last fill-up, and one since terminal 15 (ignition circuit) power was switched on plus 120 minutes after that, before it automatically resets to zero. The driver of the Touareg can choose which of the three displays he or she wants to appear on the MFI using the thumbwheel control on the steering wheel.







I didn't know about this before, because I had never driven a Touareg until last night, when I took the "problem" Touareg home, just to test it further and make sure the headlight fault did not come back. I found a neat little book in the glove compartment that explains how to operate the truck. I don't think the owner was aware of the presence of that book.
Michael


----------



## Corradodrvrfnd (Feb 15, 2002)

*Re: "Headlight Range Control" warning message - need some advice (PanEuropean)*


_Quote, originally posted by *PanEuropean* »_
I found a neat little book in the glove compartment that explains how to operate the truck. I don't think the owner was aware of the presence of that book.
Michael

Do we have a "best of" because I just spit coffee all over the monitor with that one.
I'm going to go clean it up now. http://****************.com/smile/emthup.gif


----------



## ksand (May 17, 2004)

*Re: "Headlight Range Control" warning message - need some advice (PanEuropean)*


_Quote, originally posted by *PanEuropean* »_As for the problem with the resetting trip computer - that required recoding of the *OWNER* of the Touareg, using the special 'RTFM' programming code.

Ha, ha, ha - that's classic!


----------



## matthewsjl (Mar 23, 2004)

*Re: "Headlight Range Control" warning message - need some advice (PanEuropean)*


_Quote, originally posted by *PanEuropean* »_
That is an excellent question, and I thank you for asking it. But, you are going to have to help me out a bit with the logic of proving the argument as you propose it should be done. Not being a scientist (I am an aircraft pilot / engineer / safety manager by profession), I don't fully understand how putting the suspect controller in a 'known good' Touareg would strengthen the proof. It appears to me that if replacing a specific component solved the problem (we tested and proved that the problem still existed immediately prior to replacing the suspect controller, to control against any other action as a possible fix), then that is sufficient proof. But, I suspect you are correct, I just need you to explain the rationale, the logic of your statement to me so I can fully comprehend it.


The absolute proof that the controller is at fault is that the fault experienced moves with the controller when placed in a known good environment.
John.


----------



## sciencegeek (Oct 26, 2003)

*Re: "Headlight Range Control" warning message - need some advice (matthewsjl)*


_Quote, originally posted by *matthewsjl* »_The absolute proof that the controller is at fault is that the fault experienced moves with the controller when placed in a known good environment.

You beat me to it. Yes, that's right.

_Quote, originally posted by *PanEuropean* »_It appears to me that if replacing a specific component solved the problem (we tested and proved that the problem still existed immediately prior to replacing the suspect controller, to control against any other action as a possible fix), then that is sufficient proof.

This is not proof; it's good circumstantial evidence. For example, it's quite possible that the process of taking out and putting back the controller resets another component in the system, and voila, it works again. Or that the connection was bad, and the process of replacement restored it. Many scenarios are possible. I would of course not dispute that the controller being at fault is the likeliest explanation; but, given your experiments, you do not have proof that it was.


----------



## spockcat (Jun 5, 2003)

*Re: "Headlight Range Control" warning message - need some advice (PanEuropean)*

One less V10 on the road. http://****************.com/smile/emthdown.gif


----------



## sciencegeek (Oct 26, 2003)

*Re: "Headlight Range Control" warning message - need some advice (spockcat)*

you don't think they'll be able to buff that out?


----------



## spockcat (Jun 5, 2003)

*Re: "Headlight Range Control" warning message - need some advice (sciencegeek)*

I think they need some duct tape too.


----------



## matthewsjl (Mar 23, 2004)

*Re: "Headlight Range Control" warning message - need some advice (spockcat)*

It's interesting - as an aside from the buffing and duct tape issue, is the car pictured a write off?
The V10 is at the higher end of the price range - I was always led to believe that a car would be repaired by insurance companies up to approx 50% of the value of the car (general United Kingdom rule rather than a US guideline).
Plenty of front end and side damage. The chassis is probably twisted too....
John.


----------



## PanEuropean (Nov 3, 2001)

*Re: "Headlight Range Control" warning message - need some advice (sciencegeek)*


_Quote, originally posted by *sciencegeek* »_This is not proof; it's good circumstantial evidence. For example, it's quite possible that the process of taking out and putting back the controller resets another component in the system, and voila, it works again. Or that the connection was bad, and the process of replacement restored it. Many scenarios are possible. I would of course not dispute that the controller being at fault is the likeliest explanation; but, given your experiments, you do not have proof that it was.









Thank you very much, that was exactly the education I was seeking. Can you recommend a source where I can learn more about this particular epistemology - by this I mean the critical thinking that you applied when you originally challenged the process I followed to justify my conclusion? It does not have to be automobile related - a good website would be great, or if you could recommend a book, that would also be great. I want to learn how I can be more rigorous in the future when I attempt to prove a similar conclusion that arises from a diagnostic and troubleshooting process that is largely based on Boolean strategy.
As I explained in the original post, my role in the repair of this Touareg was not that of a subject matter expert - heck, I had never even driven a Touareg until last night - I was just the strategy planner for the group of subject matter experts (the VW technicians). Hence my desire to learn more about how to better prove (or challenge) conclusions, in an abstract sense.
Michael


----------



## sciencegeek (Oct 26, 2003)

*Re: "Headlight Range Control" warning message - need some advice (PanEuropean)*


_Quote, originally posted by *PanEuropean* »_Can you recommend a source where I can learn more about this particular epistemology ... ?

That's a good question, and I wish I had a simple answer. Surely there must be textbooks that address general scientific reasoning, but I wouldn't know what they are or how good they are. Science is extremely fragmented and rigorous scientific reasoning is usually learned when you're a senior undergraduate or a graduate student, when you've already specialized ... thus, rigorous reasoning is almost always learned in the context of the specific field you work in. I think it wouldn't help if I pointed you to a paper in a molecular biology journal that I teach in a seminar course where this type of reasoning is illustrated well.
I think in the example at hand, many (if not most) scientists would agree with me (or matthewsjl) ... but there are tougher scenarios where even rigorous scientists may disagree on what constitutes proof. And then, there's the whole issue of the definition of "proof". In mathematics, it's clear. In the experimental sciences, it's much less clear and (believe it or not) is closer to the legal definition, which requires the elimination of "reasonable doubt." This is abused in science as much as in law, believe it or not, and there are a lot of crappy papers in the journals that do not actually show (a lesser synonym for 'prove') what they claim.


----------



## matthewsjl (Mar 23, 2004)

*Re: "Headlight Range Control" warning message - need some advice (sciencegeek)*

I don't seem to remember being taught logical fault finding at University in the UK... maybe it was too long ago now. I saw the previous request for guidence on learing more about the fault-finding process and couldn't come up with a good answer. Maybe I can add a few things from experience:
1. The human brain deals better with simple problems
- Reducing the number of variables often helps in fault finding.
- Splitting complex systems up into smaller subsystems and proving that these work correctly often helps.
2. Sometimes the aim isn't to prove that a component is at fault rather than to prove eyerything else isn't at fault! Elimiate all other possibilities.
3. Think through the system and try to find the lowest common point of failure. Start here and work through the system logically.
In your Touareg troubleshooting it sounds like you started option three after GFF and swapping a few components didn't work.
Sorry I can't be more specific.
John.


----------



## PanEuropean (Nov 3, 2001)

*Re: "Headlight Range Control" warning message - need some advice (matthewsjl)*


_Quote, originally posted by *matthewsjl* »_3. Think through the system and try to find the lowest common point of failure. Start here and work through the system logically.
In your Touareg troubleshooting it sounds like you started option three after GFF and swapping a few components didn't work.

Hi John:
Yes, you are correct in your observation. I was invited into the process as a strategy planner, and I started from item 3. That process is known as identification and analysis of "paths of influence".
I have taught Principles of Troubleshooting for many years to aircraft engineers. This short, 3 day course focuses on troubleshooting problems from a perspective of logic and analysis, rather than from the perspective of a subject matter expert. The gist of it is that the troubleshooter starts with a gross overview of the system, then identifies what components have influence on the symptom, then uses Boolean logic to develop a diagnostic plan. It is not an entirely rigid approach, because in some circumstances, it is less expensive to make an occasional out of sequence inquiry than it is to strictly follow the decision making model.
The total cost of a repair encompasses not only technician time and parts cost, it also includes the value of the time that the vehicle (aircraft, in my case) is out of service, and the often very substantial costs of iatrogenic problems that can arise as a result of system disassembly.
What caught my interest when ScienceGeek criticized my 'proof'- and I thought it was excellent criticism - was how a more rigorous approach to establishing proof could possibly contribute to greater reductions in the total cost of a diagnostic and troubleshooting operation. In other words, great, we got the problem fixed, and we got it fixed quite economically (our only costs were labour time and the temporary loan of a part), but is it now appropriate for us to conclude that more careful consideration of this particular component should be part of a future diagnostic plan if we ever encounter a truck that displays the same problem symptoms? One's gut reaction would be 'yes, for sure' - but is that a valid conclusion, and can it be 'proven'?
Michael


----------



## Holger_Dansker (Dec 30, 2004)

*Re: "Headlight Range Control" warning message - need some advice (matthewsjl)*

Incredibly interesting development in this thread....

_Quote, originally posted by *matthewsjl* »_
1. The human brain deals better with simple problems
- Reducing the number of variables often helps in fault finding.
- Splitting complex systems up into smaller subsystems and proving that these work correctly often helps.
2. Sometimes the aim isn't to prove that a component is at fault rather than to prove eyerything else isn't at fault! Elimiate all other possibilities.
3. Think through the system and try to find the lowest common point of failure. Start here and work through the system logically.


This matches perfectly with my experience in troubleshooting complex electronic aircraft systems (11 years with RC-135 aircraft electronics in the USAF). We used to teach to to place everything in "a line" from beginning to end. And then keep cutting in half, throwing out the wrong guessed half, and start again with a new, shorter line.
Also, I can very much attest to the fact that simply plugging in and unplugging a controller unit about 50% of the time can fix a problem like the one in this thread. Shame you could not have tried the old controller in a new treg or simply put it back in the treg after replacing it solved the problem to see if it was still broken.
We used to call that "threatening the part with replacement" in order to get it to work.








Finally, we also learned that most troubleshooting skill starts with a knack for it. The ones that did not have the knack could really never be taught well enough to be any good. Others got it first time, every time and could even improve on what was taught to them.


----------



## PanEuropean (Nov 3, 2001)

*Re: "Headlight Range Control" warning message - need some advice (Nusser)*

Hi Bret:
Thanks for adding your thoughts. My background is also aircraft maintenance. The strategy you propose - placing everything in a line and then repeatedly cutting the line in half - is a good one, and can be used quite effectively. But, you can refine your technique a bit further, and thus cut your total cost of repair (labour + ground-time + risk of further problems from excessive disassembly) down even more if you apply the "Paths of Influence" diagnostic technique on top of that.
For example, let's say you have a position light that is inoperative, and it happens to be way up high, so you can't easily get to it to check the bulb. Putting everything in a line results in the following: main DC bus power present, power available to switch, switch in position, trace wiring to lamp, check lamp. (I'm putting the lamp up way out of reach to make it impractical to check the bulb first, which is what most of us would want to do).
If you apply your 'line-halving' technique to that scenario, you would probably start by checking switch position, or checking for power at the switch. But, if you use the 'paths of influence' strategy, you will note that the same switch controls 3 position lights, so your first step will be to turn the switch on and see if the other 2 lights work. If they do, you have just eliminated the first 75% of the line as a possible cause of the problem. You now know that the problem exists after the last branching splice junction that feeds the 3 lights.
Now, you have to decide how to approach the problem light. If it will cost you an hour of setup time to rig a scaffold to reach a position light fixture that is on the top of the rudder, you might instead choose to check the last point on the supply wire to the rudder position light that you can reach from inside the fuselage. But, if you have a motorized scaffold available, it would be cheaper to just go directly to the lamp module and check the bulb.
The two techniques are complimentary, and I am not by any means saying one is better than the other. What I am getting at is that the more we, as technicians, can apply effective models to diagnosis and troubleshooting, the faster and more economically we will get the job done. Personally, I don't think this is one of those 'born with it' skills that you either have a knack for or not. When I was teaching this subject, I would often invite a receptionist or secretary to join the 3 day class if I had an extra seat available. These 'non-technician' employees always found the course to be easy to understand, and I often heard later on that if the coffee machine was broken or the phone system didn't work, the rest of the staff would always call Suzie to troubleshoot it, even though Suzie didn't know which end of a screwdriver went into the fastener, and which end went in her hand. But, she sure had principles of troubleshooting and diagnosis strategy down pat.








Michael


----------



## PanEuropean (Nov 3, 2001)

*Re: "Headlight Range Control" warning message - need some advice (Nusser)*


_Quote, originally posted by *Nusser* »_ Shame you could not have tried the old controller in a new treg or simply put it back in the treg after replacing it solved the problem to see if it was still broken.

That's a darn good point, thank you for telling me about it. You just reminded me of a very useful technique - 'remove and reseat'.
Michael


----------



## matthewsjl (Mar 23, 2004)

*Re: "Headlight Range Control" warning message - need some advice (PanEuropean)*

I'm presently on a management and leadership course with my company. Part of it focusses on learning styles that individuals possess.
In my relatively short career to date, I have found that we can have good engineers and really good engineers:
The good engineers can take a procedure and execute on it 100% every time, time after time. Process and procedure is key. 
The really good engineers can take the procedure and execute on it 100% every time, again time after time. However, the separating factor is the ability to work outside the procedure to problem solve (experiment, learn, apply) when things don't go to plan.
The GFF process is programmed and falls under category 1. Category 2 doesn't seem to exist in the USA unless the VW techs take it on themselves to work outside the encouraged path.
As a second point, usually more people will cope with hardware problems better than software problems (although the borders are getting more cloudy as everything becomes software driven). Some people react well to lights to indicate problems and don't react well to 'computer speak' (as the Treg produces - which has to be interpreted). Mechanical faults (that can be seen) are easier than electricals.
To keep the aircraft theme going - I'm a pilot (but only light aircraft)








Very interesting thread...
John.


----------



## Holger_Dansker (Dec 30, 2004)

*Re: "Headlight Range Control" warning message - need some advice (PanEuropean)*


_Quote, originally posted by *PanEuropean* »_
That's a darn good point, thank you for telling me about it. You just reminded me of a very useful technique - 'remove and reseat'.
Michael

My most famous "war story" about inflight TS & Repair was to take a inoperative comm/crypto box and instead of trying to hunt through which of the 30 seated cards I should start with -- I just held it 3 feet off the aircraft floor and dropped it. Cabled it back up and it worked perfectly. It weighed about 25-30 pounds and the noise scared the crap out of the people in the back half of the aircraft, but it got the job done very quickly.
We always had to be rather inventive during inflight maintenance, as time was always against it.
hmmm.... memories or years gone by..... 
I can already visualize the dropping of various Treg parts now....


----------



## PanEuropean (Nov 3, 2001)

*Re: "Headlight Range Control" warning message - need some advice (matthewsjl)*


_Quote, originally posted by *matthewsjl* »_...The GFF process is programmed and falls under category 1. Category 2 doesn't seem to exist in the USA unless the VW techs take it on themselves to work outside the encouraged path.

Wow - you just made a really, really sharp observation. 
One very experienced service department manager I spoke to said" "96% of the problems we have today are easier and faster to fix than ever before, thanks to GFF. The other 4% are 20 times more difficult than they ever were before." Now that I think of it, I bet he had identified the need for the 'category 1' and 'category 2' approaches that you described - category 1 is great for 96% of the problems, but no good for the other 4%.
I think the challenge that VW now faces is to provide the technicians with more education about how to troubleshoot by use of critical thinking, while at the same time maintaining the benefits provided by GFF. This might be the key to some of the image problems that VW is having with product reliability. Let's say I am driving my W12 Phaeton down the street one day, and the engine falls out and I coast to a stop in front of the dealership. The service writer comes out, apologizes for the product failure, and tells me to come back in 2 days and pick up the car. I do that, and the car is fully repaired and running great. Chances are I will be telling my friends about how good VW after-sale service is, not about the fact that the engine fell out.
On the other hand - some poor Touareg owner makes 4 service visits in a row because the rear seat cigarette lighter doesn't work, and after the 4 visits, the cigarette lighter still doesn't work - hey, they are going to be really P.O.'ed, probably burned off the VW brand for good, and looking for a buy-back.
The fix is to be found in technician training at the dealership level, not back at the manufacturing plant.
Michael


----------



## 12johnny (Oct 28, 2003)

Very, very interesting thread... Thank you!


----------



## Curjo (Nov 21, 2003)

*Re: "Headlight Range Control" warning message - need some advice (PanEuropean)*

I think you're correct in that the training program for techs is a little lacking.

_Quote, originally posted by *PanEuropean* »_
One very experienced service department manager I spoke to said" "96% of the problems we have today are easier and faster to fix than ever before, thanks to GFF. Michael

But... VW makes it easy for dealers to be reimbursed for the fixes done IAW the GFF. VWOA needs to make it easier for a dealer to pay a technician for the time he spends troubleshooting problems that are NOT fixed via GFF.


----------



## PanEuropean (Nov 3, 2001)

*Re: "Headlight Range Control" warning message - need some advice (Curjo)*

You are correct. It would be naive of us to expect that any large corporation such as VW that relies on a network of independent, franchised dealers will suddenly say "Sure, do what you think is best and just send us the bill". I do comprehend that VW has to impose some discipline on the process, and GFF does that. GFF also provides immense protection for the customer as well, by ensuring that unnecessary repairs are not carried out, either due to incompetence or for other reasons.
The challenge that VW faces is how to use GFF to its best advantage 96% of the time, but still leave slack for that 4% that cannot be easily fitted into a predetermined 'slot'. It's a bit like the challenge that any company faces when they implement an automated attendant telephone system - it works great for the vast majority of the callers, but if your need is not on the pre-defined menu, and you don't have the option of pressing 0 to speak with an operator, you will hit a blank wall.
Perhaps the answer might lie in recognizing certain highly experienced and highly trained technicians as "Master Technicians", and granting them a budget of labour hours - maybe, for example, 4% of what the dealership bills in warranty labour each month - to use at their own discretion when these oddball problems pop up. That's just a shot in the dark - heck, I'm just a customer, not a tech or a VW employee - but it might provide a starting point for discussion of other ideas about how to address this critical issue.
Michael


----------



## chessmck (Dec 22, 2003)

*Re: "Headlight Range Control" warning message - need some advice (PanEuropean)*

Thanks to all for their comments on this thread. It is great!!!
GGF solutions - now here I go out on a limb, but only for my 2 cents...
I believe this GGF solution process was started when it became an issue to have a tech learn the entire process of how something worked. When I first started in audio then automation, I had to fully understand how everything worked and completed repairs at the component level. Later this moved to card level as it became cheaper. Now I think we are training to module replacement because companies can not afford the "entire system" training time. Also they now have expensive equipment back at the factory to tell someone which component to change instead of the old ways of using a logic probe or oscilloscope to trace the signal and find the bad component. Again removing the detailed training and have a process someone with less training can follow.
I agree with having time for a tech to work outside the GFF process.
Back to the problem of the distance the key fob would open (or not open) the door. Unless you understood how RF works, you would never understand why you could not unlock the hatch from the rear - with the antenna hidden under the metal hood and through the metal firewall. Yet in the metal walled service bay, it would work well - because the RF bounced off the walls and back into the front and to the antenna. If you went outside, it would not work....


----------



## matthewsjl (Mar 23, 2004)

*Re: "Headlight Range Control" warning message - need some advice (chessmck)*

GFF is a two part component:
1. The various parts/modules sending the correct signals to allow diagnosis.
2. The GFF being programmed *correctly* to pick up on the signals and use them correctly.
I write small bits of software on a very ad-hoc basis. Everything works fine when all the pieces fit together how I think they should fit (and have programmed accordingly). What causes me problems is unexpected behaviour.
The unexpected behaviour part is the bit that's difficult to predict (if you see what I mean). This is why we have testing - unfortunately, nothing tests like having a product in the field.
I'm sure that VW will update the GFF based on 'unexpected behaviour' that they find. Problem is, they can only update after the problem has occurred!
John.


_Modified by matthewsjl at 1:07 AM 4-9-2005_


----------



## fauvaydoc (Apr 2, 2003)

*Re: "Headlight Range Control" warning message - need some advice (PanEuropean)*

I disagree with the 96% GFF repair success, at least in the US. As a Technician, I've seen many complex faults without test plans, a test plan that leads nowhere, or an incorrect diagnosis from the test plan (one was on a Phaeton climatronic/infotainment malfunction!). Most of the time, I just use the wiring diagrams and information in VESIS when GFF is of no use. I believe in training a technician as much as possible so he/she is able to diagnose these problems without aid of GFF, although you must train people who are willing/capable of learning. GFF usage for warranty repairs has only been mandatory since model year 2004 in the US and it's success very much relies on the technician and the input/measurements that are supplied to the 5051/5052. This also comes from experience, it's not a completely idiot-proof procedure every time. Many times there are too many variables to determine the problem with an advanced Touareg/Phaeton system-such as temperature, outside influence, fuel quality, etc. All of these variables can't possibly be programmed into the software, but I'll admit it is getting better with every update. As far as the issue of fixing vehicles correctly the first time, I believe there needs to be more quality control at the dealership level. Some dealerships use a shop foreman/master technician to ensure the repairs were done right (especially oddball problems and repairs to higher-end vehicles). Some dealers do not have any method of quality control. There needs to be more intervention by VW in dealership service processes and every shop should be operating the same way to avoid confusion and mistakes.


_Modified by fauvaydoc at 12:25 AM 4-9-2005_


----------



## PanEuropean (Nov 3, 2001)

*Re: "Headlight Range Control" warning message - need some advice (fauvaydoc)*

Fauvaydoc:
I agree with much of what you have said. As an owner, I am pretty skeptical about GFF. I think it is great for simple stuff, but not sufficiently developed yet to address the more complex problems that can arise in the Touareg / Phaeton class of vehicles.
There are a few threads going on in the Phaeton forum that touch on some of the problems associated with GFF. If you are interested in the 'conventional troubleshooting vs. GFF' issue, these may be of interest to you: Report on first 3000 mile trip, and a preceding post addressing a similar problem in my own car, Two bad batteries.
Michael


----------



## echofan (Jan 22, 2013)

PanEuropean, 
I too have this message on my 2007 Touareg. In my case, the warning came on around the time I noticed the brightness on my headlights was uneven. One side appeared to be at least 50% off brighter than the other. 

they replaced: 
- both bulbs (twice) 
- replaced left side headlight control module 
- left side level sensor 
- repair wiring 

My dealer appeared to fix the warning problem after my 4th visit but one of my headlights was still 50% brighter than the other. A week later the warning light came back on and it's been on ever since (nearly a year). I moved to another province since and their work is no longer under warranty. 

I don't know if replacing the central electrical controller is worth a shot but at this point I will try anything so if you don't mind, could you send detail information so I could share it with my new dealer? 
any other advice is appreciated 
thank you


----------

