|
|
Post by karstenes on Jun 18, 2024 2:48:12 GMT
Hello,
I have recently replaced almost all the modules in my headlights as they had died from what seemed to be age. I most recently replaced the AFS modules. Once writing the long coding to the 55 module, the headlights start adjusting and moving, but get stuck in the far left position and do not move right. They then move up and down but still remain stuck left. The AFS error then pops up on the dashboard. Here is the scan for my 55 headlight module:
55 Headlight Regulation
System description: AFS-ECU
Software number: 7P6907357D
Software version: 0090
Hardware number: 7P6907357A
Hardware version: H07
Serial number: --------------
ODX name: EV_HeadlRegulVWAFSMQB
ODX version: 001120
Faults:
U101400 - Control module incorrectly coded
static
Date: 2024-06-17 21:35:58
Mileage: 176402 km
Priority: 1
Malfunction frequency counter: 1
Unlearning counter: 74
C1081F1 - Left headlamp power output stage Incorrect coding
static
Date: 2024-06-17 21:35:58
Mileage: 176402 km
Priority: 2
Malfunction frequency counter: 1
Unlearning counter: 74
C1082F1 - Right headlamp power output stage Incorrect coding
static
Date: 2024-06-17 21:35:58
Mileage: 176402 km
Priority: 2
Malfunction frequency counter: 1
Unlearning counter: 74
C107E54 - Headlight No basic setting
static
Date: 2024-06-17 21:35:59
Mileage: 176402 km
Priority: 1
Malfunction frequency counter: 1
Unlearning counter: 74
C108B29 - Left swivel module position sensor Implausible signal
static
Date: 2024-06-17 21:36:04
Mileage: 176402 km
Priority: 2
Malfunction frequency counter: 1
Unlearning counter: 74
C108C29 - Right swivel module position sensor Implausible signal
static
Date: 2024-06-17 21:36:04
Mileage: 176402 km
Priority: 2
Malfunction frequency counter: 1
Unlearning counter: 74
C108907 - Left Swivel Module mechanical malfunction
static
Date: 2024-06-17 21:36:04
Mileage: 176402 km
Priority: 2
Malfunction frequency counter: 1
Unlearning counter: 74
C108A07 - Right Swivel Module mechanical malfunction
static
Date: 2024-06-17 21:36:04
Mileage: 176402 km
Priority: 2
Malfunction frequency counter: 1
Unlearning counter: 74
Fault
Control unit: 55 Headlight Regulation
Active faults: 4
Inactive faults: 0
System description: AFS-ECU
Software number: 7P6907357D
Software version: 0090
Hardware number: 7P6907357A
Hardware version: H07
Serial number: --------------
ODX name: EV_HeadlRegulVWAFSMQB
ODX version: 001120
Faults:
U101400 - Control module incorrectly coded
static
C1081F1 - Left headlamp power output stage Incorrect coding
static
C1082F1 - Right headlamp power output stage Incorrect coding
static
C107E54 - Headlight No basic setting
static
Mileage: 176402 km
Date: 2024-06-17 21:36
The only persistent errors are the incorrect coding errors though. Any ideas for how to fix this?
Thanks!
|
|
|
|
Post by dv52 (Australia) on Jun 18, 2024 5:06:57 GMT
karstenes :hmm.......first, posting-up a snippet of a SCAN report is very limiting because it fails to identify how the car was built and what other lighting related modules are in this car (like the central electrics module and possibly Light Control Modules if this car is a mk7.5 FL) If you intend to pursue this matter, I suggest that you include a full UNEDITED (meaning no changes) copy of the SCAN report - add the SCAN as an attachment rather than dumping the contents into the post proper OK -there could be a vast array of reasons for the errors in your scan report. More information is needed to understand what has happened to this car - without this data, any rely is just an uniformed guess!!
When you say "I have recently replaced almost all the modules in my headlights" - what exactly do you mean? Which modules were replace and which were not?
Also, for those modules that were replaced -were they EXACTLY like-for-like, meaning were both the part number and software number identical for the old and new modules in each case?
And, how did you deal with dataset versioning in those new modules that have datasets? Where did you source the new modules - were they brand-new, or did you use 2nd-hand modules? If the latter, were the modules from your exact model car?
Plus, the normal process before replacing new modules is to make a SCAN of the car with the old modules in-situ so that you have a record of the existing coding values that will need to be re-entered into the new modules. Did you do this? If so, also post-up an UNEDITED copy of the SCAN report using the old modules -please (again as an attachment)
OK again!! A quick look at the error codes suggest that there are likely multiple problems with this car. I'm not sure if you understand how coding happens in these CAN sub-networks. When new output modules are installed into headlight fittings, they will be automatically coded by the primary module (usually the hex55 module) - but auto-coding ONLY happens if the CAN sub-network is otherwise error free.
With multiple errors in the swivel modules in your SCAN snippet, the left/right output modules will NEVER be auto-coded, So I suggest that you prioritize the task of fault finding the swivel module errors first! After these faults are fixed- clear ALL errors and hopefully the output modules will be auto-coded. I suspect the remaining task with be the completion of basic settings.
Don
|
|
|
|
Post by karstenes on Jun 18, 2024 16:33:45 GMT
First off, I had no way to extract the sub module coding as the control modules on the headlight assemblies were dead, so the old scan shows no submodules, but I do have that scan The modules are 2nd hand from ebay, but both came from the same seller and have the same software version as each other. (Links is 008, rechts is 008). I have replaced the right xenon ballast and both DRL modules. The swivel error does not appear when I am in the scan on the app, only missing coding and missing basic setting. Any more info I should look into?
Thanks again, Karsten
|
|
|
|
Post by dv52 (Australia) on Jun 19, 2024 0:49:05 GMT
First off, I had no way to extract the sub module coding as the control modules on the headlight assemblies were dead, so the old scan shows no submodules, but I do have that scan OK-bummer!! But I assume that you still have the original physical factory modules - which will have equipment details written on the housing stickers! The modules are 2nd hand from ebay, but both came from the same seller and have the same software version as each other. (Links is 008, rechts is 008). Yes, having the same "software version" on the new left/right-side modules is a good start - but are the part/software numbers of the new modules EXACTLY the same as on the original factory modules (as I suggest above - look at the physical old modules and compare with new modules)? I have replaced the right xenon ballast and both DRL modules. hmm... why replace the DRL modules - the old SCAN doesn't indicate that the DRL modules were problematic? The swivel error does not appear when I am in the scan on the app, only missing coding and missing basic setting. Any more info I should look into?[/ I don't understand!! The swivel errors appear on the SCAN attachment. Are you saying that a fresh SCAN of this car no longer reports swivel errors?
Clearly there are lots of errors on this car - so we need to identify which errors are initiating other errors and deal with these first (hence my interest with the swivel errors)
I suspect that U101400 - Control module incorrectly coded might be an "initiating error" As you can see, the error-code has "Priority 1" (which is the highest priority error) and the date/time stamp is 2024-06-17 21:35:58.
Unless I misunderstand your words, if you just replaced the modules listed in your previous reply above - NO coding changes should have been made to the 55 Headlight Regulation module!
However, this error-code is telling you that from the date/time indicated and for some unknown reason - the coding values in the 55 Headlight Regulation module are no longer appropriate! Most likely, the coding values of interest are in the long-code string for this module albeit this could extend to channel values in the module!
How is this error possible if you didn't change the 55 module - let me suggest 2 x possible answers to this question (please provide other reasons, if you want)?
Option 1 -As I said, the hex55 module will auto-code the power output modules if it is happy that everything is OK. The coding in the hex55 module tells it what type of equipment is installed in the headlight fittings and this information manages how the headlight modules are controlled. So, maybe the new modules in the headlight fittings are functionally different to the original factory modules and they need different coding in the hex55 module to operate correctly?
Option 2 - Coding changes were actually made to the hex55 module after the new modules were installed. Of course I'm guessing - but maybe look in History for any change records on the hex55 module - around the date/time stamp for this error. If you find any change records, revert the settings back to the old value.
|
|
|
|
Post by karstenes on Jun 19, 2024 1:32:51 GMT
When I look in the app, the errors do not appear oddly, though I do see them in the scan output now. The replacement modules are not the exact same software version, which on the label is either 0004 or 0001. The label is in the picture below.
The DRL lights were out and there was an error. Maybe this scan was after I replaced them? I am not sure.
I took an original backup of the car, and the current 55 module long coding is the same as the original backup which I loaded. I did try flipping and unflipping a bit in the long coding to attempt to reprogram the submodules, as I had seen in a thread you replied to a while ago. So you think this may be a compound error with the wrong version control modules and fault swivel sensors? Or possibly just the current leimo modules are nonfunctional with my car?
The current errors were there when I got the car (I decided no AFS was worth a good discount from the seller, not realizing the mess I was getting myself into).
Is there a possibility these modules could be used with coding changes? I have access to a VAG-COM as well if that is helpful. (I know you're not a wizard so if you don't know thanks anyway  )
|
|
|
|
Post by dv52 (Australia) on Jun 19, 2024 3:31:26 GMT
When I look in the app, the errors do not appear oddly, though I do see them in the scan output now. The replacement modules are not the exact same software version, which on the label is either 0004 or 0001. The label is in the picture below. OK - at least we might have a possible reason for the errors!! I took an original backup of the car, and the current 55 module long coding is the same as the original backup which I loaded. I did try flipping and unflipping a bit in the long coding to attempt to reprogram the submodules, as I had seen in a thread you replied to a while ago. So you think this may be a compound error with the wrong version control modules and fault swivel sensors? Or possibly just the current leimo modules are nonfunctional with my car? I very much doubt that "flipping and unflipping a bit in the long coding" had any impact on your current error codes!!
And I don't know if the 2nd hand modules are faulty.
However, these headlight modules are interchangeable - a trick that I have used in the past is to swap modules from left and right side headlight fittings (where the same error-code doesn't appear in both modules). Then SCAN the car again - if the new error-code chases the changed car-side, the problem is in the module. The other option here (I assume) is to re-fit the old modules - then SCAN the car again - do you get the same error codes as before the 2nd hand modules were installed? This tells you if a problem other than the original reason for the changes has occurred!
The current errors were there when I got the car (I decided no AFS was worth a good discount from the seller, not realizing the mess I was getting myself into). hmm....... I don't understand!! There was just ONE error-code on the 55 module in the full_old_scan.txt file that you posted earlier! Definitely NOT the same!! Is there a possibility these modules could be used with coding changes? I have access to a VAG-COM as well if that is helpful. (I know you're not a wizard so if you don't know thanks anyway ) Alas you are correct - I am far from being "a wizard"!! I don't know the specific differences for the two software versions on 5N0-941-329 modules! If by "VAG-COM" you mean VCDS, then the device can NOT be used to change the software version. You need access to either ODIS (dealer tool), or VCP to flash these modules. And then of course you need to get a copy of the correct software file!! |
|
|
|
Post by karstenes on Jun 19, 2024 23:23:45 GMT
Back again!
I have attempted switching modules and manually rotating the lights inside the casings in case they were stuck but no luck.
I have narrowed it down to two possible issues. While researching, I stumbled upon a post on golfmk7.com (OP there gives shoutouts to you!) about retrofitting AFS bi xenons to a golf. DIY: OEM Lighting Package (AFS Xenon) Retrofit
The OP there documented his process and I found one line from the post: " NOTE: I tried workarounds of tying into diagnostic canbus (pins 9 and 19) and although I could get AFS recognition and programming, would do up/down shimmy shake at startup, and make pitch corrections, I could not get the yaw movement or cornering lights to work as I had communication errors. I had to replace CAN Gateway to resolve. " which is exactly what I am experiencing. I am guessing this is due to the CAN Gateway not liking my modules? That or the actual main headlight regulation module doesn't like the AFS modules. Either way CAN Gateway or the AFS modules would need to be replaced. (I am guessing your recommendation here would be to buy some modules with the same software version as my old ones).
The other possibility is incorrect coding on that Gateway or the AFS module. I have tried changing some of the AFS long coding, but that has not worked, though I have only flipped individual settings and not changed large parts of the long coding. (Everything is back to original now). I don't have the knowledge of the Gateway module coding, and due to the high possibility of me pulling some other parts of my car offline, I left that be.
Do you see any paths forward or get any ideas from this info? I am slowly leaning towards the expensive option of getting matching AFS modules, but if coding changes would work that would save me a lot of money!
Thanks again for the help, Karsten
|
|
|
|
Post by dv52 (Australia) on Jun 20, 2024 0:30:20 GMT
I have attempted switching modules and manually rotating the lights inside the casings in case they were stuck but no luck. Not sure what this means? My suggestion to swap modules was NEVER going to fix anything. Module-swapping is a very nuanced diagnostic technique which works by carefully comparing before/after error reports and deducing cause-and-effect! I have narrowed it down to two possible issues. While researching, I stumbled upon a post on golfmk7.com (OP there gives shoutouts to you!) about retrofitting AFS bi xenons to a golf. DIY: OEM Lighting Package (AFS Xenon) RetrofitThe OP there documented his process and I found one line from the post: " NOTE: I tried workarounds of tying into diagnostic canbus (pins 9 and 19) and although I could get AFS recognition and programming, would do up/down shimmy shake at startup, and make pitch corrections, I could not get the yaw movement or cornering lights to work as I had communication errors. I had to replace CAN Gateway to resolve. " which is exactly what I am experiencing. I am guessing this is due to the CAN Gateway not liking my modules? That or the actual main headlight regulation module doesn't like the AFS modules. Either way CAN Gateway or the AFS modules would need to be replaced. (I am guessing your recommendation here would be to buy some modules with the same software version as my old ones).
Yes, your link is about mk7 headlight fittings - but OP's project is very different to your case! Don't get me wrong - I'm not saying that the link isn't useful, rather I'm suggesting that any parallel with your problem is marginal at best!! The other possibility is incorrect coding on that Gateway or the AFS module. I have tried changing some of the AFS long coding, but that has not worked, though I have only flipped individual settings and not changed large parts of the long coding. (Everything is back to original now). I don't have the knowledge of the Gateway module coding, and due to the high possibility of me pulling some other parts of my car offline, I left that be. Hmm...... I don't think that the Gateway module is implicated in your problems because you have NOT replaced any modules in this car that have full registration on the primary CAN spine. The modules that were replaced are part of a CAN sub-network - which means that they are insulated from the CAN network that the Gateway module controls by another module (in this case, the hex55 module).
As i've said before, the first task in solving these problems is to fix the hex55 module "incorrectly coded" error !
Do you see any paths forward or get any ideas from this info? I am slowly leaning towards the expensive option of getting matching AFS modules, but if coding changes would work that would save me a lot of money! Alas, I suspect that fixing this problem with simple coding changes is a very, very long-shot! And please understand that the option of buying "matching AFS modules" is NOT a guaranteed fix. The observations in my replies are NOT absolutes - they are only a suggestion that are prone to the uncertainty of remote diagnostics on forums like this! |
|
)