|
|
Post by stevie1969 on Jan 14, 2023 11:09:45 GMT
I'm looking for advice about the errors thrown up after some damage by mice. There has been three wires repaired in different locations and no other noticeable broken wires, although as yet, I haven't been able to get under the car for a look. One of the faults is "lost communication with four wheel drive clutch control module" When I do the scan the CU 22 does not light up, ie not green or red. I have checked the fuse that i believe to be the correct fuse - fuse 44 in the glove box and it is ok. Anyone have any further advice going forward? Cheers Stevie Attachments:OBDeleven_Log.txt (5.08 KB)
|
|
|
|
Post by dv52 (Australia) on Jan 14, 2023 21:50:55 GMT
stevie1969 : hmm........... pesky little beasties!!  So, a couple of observations (suggestions) that you might consider- maybe? Here's how the Haldex module is wired :
There are probably 2 x basic reasons why the hex22 module is absent from your SCAN report - Power supply problem - if the fuse is OK, check volts on pin#3 @ the module connector and confirm earth continuity (pin #7)
- CAN wire problem - the wire colors are Orange/Blue (CAN high - pin #4) and Orange/Brown (CAN low - pin #2) @ the module connector.
Checking CAN continuity really needs an oscilloscope - but you can use a multi-meter. There are lots of videos on the net regarding this test method
Don
PS: In my picture, J533 is what OBD11 calls "19 Gateway" and J519 is "09 Central Electrics"
|
|
|
|
Post by stevie1969 on Jan 16, 2023 11:27:25 GMT
Thanks for the info Don. I've not been able to get access to under the car yet. Can you tell me where the J533 and J519 are located? The wires I have repaired are in the engine bay   |
|
|
|
Post by dv52 (Australia) on Jan 16, 2023 23:42:06 GMT
Stevie. Both J519 and J533 are physically inside the cabin. So, from your words - I suspect that your first priority is NOT accessing these modules. As I said, your first priority is getting J492 to successfully communicate with the CAN network. The comms-link for this purpose is the 2 x wires between J533 and J492 - which I have labelled "Convenience CAN Bus". And, of course - the module needs power to operate! My suggestion is that you start with the fuse, then test volts/earth at the 8 x pin connector on J492. Here's the physical layout for this task:
Don
|
|
|
|
Post by stevie1969 on Jan 26, 2023 16:47:33 GMT
Hi Don, thanks for the help. I had someone look at it in a garage - they said no other wiring damage, but they never checked to see if there was power at the plug, as suggested to him.  I am borrowing a set of ramps to check everything myself tomorrow. I've checked all fuses in both engine compartment and inside the car and all are ok. I've tried online searching for relay wiring diagrams to no avail. Do you have any idea which relays control what? Cheers Stevie |
|
|
|
Post by dv52 (Australia) on Jan 26, 2023 23:52:12 GMT
Stevie: Arrhhh.....you are back - hi again!! hmmm.......I intend no offense, but why are you ignoring the valuable information that you already have? An Audi S3 has a very convenient feature in instances like yours; it has been designed to undertake it's own diagnostics and OBD11 has been designed to provide a print-out of this health report (which OBD11 calls a "SCAN"). If your car had a fully operational AWD module, the SCAN in your first post would report something like this:
---------------------------------------------------------------
22 All Wheel Control
System description: Haldex4Motion
Software number: 0CQ907554D
Software version: 7076
Hardware number: 0CQ907554D
Hardware version: H52
Serial number: HA1-00011.12.1300010423
ODX name: EV_AllWheelContrHA1VW37X
ODX version: 002001
Long coding: 0001
Trouble codes:
No trouble codes found
---------------------------------------------------------------
Now, I'm not sure which exact hex22 module is installed in your car- but I have thieved the SCAN extract above from a vehicle that has a CJXC engine (i.e. same as in your SCAN). So, it's likely that your car has a similar type AWD module
So, what additional intelligence has become evident since our last discussion to suggest that the problem may be related to the "relay wiring"? I ask because whilst I can't eliminate the possibility that this isn't a problem - it ain't immediately obvious from your SCAN that there is an issue with this equipment (I think)
If this was my car and based ONLY on the words in your posts - I would do the following: - Clear ALL the faults in your SCAN report
- Make a fresh, new SCAN
- Look at the Priority number of the faults that appear in the new SCAN (low number means highest importance). Post-up a copy - please
- Tackle fault finding based on highest Priority faults
Don:
PS: maybe you have a copy of a "pre-rodent" SCAN in your History data. If so, it might be instructive to compare this with the current SCAN report
|
|
|
|
Post by stevie1969 on Jan 27, 2023 9:55:09 GMT
Hi Don, No offence taken. I was only trying to discount any other possible problems before getting under the car - if the broken wires had been intermittently making/breaking then this could in turn cause a relay to make/break constantly causing the the relay to malfunction. (If the unit it is indeed powered through a relay) I have cleared the faults, but they keep returning. I have attached the scans - one from last year and one from yesterday. There does seem to have been some kind of reading problem last year - there is no readable info for the Haldex: 22 All Wheel Drive System description: Haldex4Motion Software number: ô UÂG(ÃQ Software version: ô Hardware number: ô UÂG(ÃQ Hardware version: ô Faults: No trouble codes found Log+5 is after clearing and rescanning, Cheers Stevie I should add that log4 was done with no ignition key. |
|
|
|
Post by dv52 (Australia) on Jan 27, 2023 23:19:55 GMT
hmm......... OK - clearly some weird sh#t happening on this car - which according to your latest SCAN data is extending beyond just the hex22 module.
Given the new faults in your latest SCAN, I now understand (and I agree with) your concerns about the "relay wiring". So, if I look at your Log #5 and if I assume that this SCAN was taken with the ignition switched-ON, then I note the following: The header says "Full scan: Control Units: 1" - which of course is complete nonsense because NO car has only ONE control unit (read "module").
The reason why OBD11 has reported the Gateway module at all is because the Gateway module is the master module for the diagnostic function. This means that whenever an OBD11 user selects the SCAN facility on the OBD11 screen, the OBD11 dongle talks directly to the Gateway module in the first instance - all request/response commands are then relayed to/from the other modules via the Gateway module. But why aren't the other modules present in your Log #5 SCAN? Real strange! I'm guessing (again), but there's an interesting inconsistency on the Terminal 15 (T15) volts in the freeze-frame data for the various faults in your log #5 report. Notice that in ALL fault instances, the reading is Terminal 15 - Off.
Now, with my apology if you already know this stuff - when the ignition is turned to the ON position (regardless of engine-ON/OFF), the car sends a message to central electrics module (@ address hex09) to switch-ON battery volt to the Terminal 15 rail. This T15 rail is a pivotal power supply and an important signal to lots of the car's equipment
Here's how the T15 rail is energized by the hex09 module on a MQB platform car like your Audi: J329 is an electro-mechanical relay and as you can see, when its coil is energized from J519 (which is the central electrics module) - the "hard" battery +ve voltage (which is called "Terminal 30", or T30) is applied to the T15 rail. The signal to energize J329 from J519 is activated whenever the ignition is switched-ON.
So, assuming that the ignition was switched-ON when Log #5 SCAN was taken, T15 should have been energized.
When you switch-ON ignition, you should be able to hear J329 "click" to the energized state. If this doesn't happen - maybe try pulling J329 from its socket and measure these voltages with ignition ON:
86 = +12V (signal from J519) 85 = earth 30 = +12V (T30, "hard" Battery Volts) 85 = no volts when relay unplugged/+12V when relay plugged into socket (this is the wire to T15 rail)
Here's the relay panel lay-out diagram:
Don |
|
|
|
Post by stevie1969 on Jan 28, 2023 10:48:30 GMT
Hi Don, Thanks for taking time to help me with this. I had no understanding at all of car electrical systems until I started investigating this. I have checked the relay and it performing as it should be - my thought was that there was maybe multiple contacts being driven directly by the relay - it appears it is only for the full Terminal 15 system on one contact. Reading back on the scans I provided yesterday and doing the same scans today as yesterday - the log with only 1 CU is the IGN off scan. Apologies for my mistake. However, there is still an anomaly with this - the ignition is off, but the scan states: U011400 - Lost Communication With Four-Wheel Drive Clutch Control Module static Priority - 2 Malfunction frequency counter - 1 Unlearning counter - 248 km-Mileage - 98176 km Supply voltage, terminal 30 - 14.7 V Terminal 15 - On Unknown ambient data - date - 2023-01-17 11:02:58 How is it possible it reads that the ignition circuit is on when it is not? Todays scan only shows this Error and none of the others. Some gremlins at work here. With regards to the inability for the scanner to read the software and hardware info in last years scan, does this point to there being a long standing problem that was showing no errors? IGN ON.txt (4.33 KB) IGN OFF.txt (797 B) |
|
|
|
Post by dv52 (Australia) on Jan 28, 2023 23:02:02 GMT
I have checked the relay and it performing as it should be - my thought was that there was maybe multiple contacts being driven directly by the relay - it appears it is only for the full Terminal 15 system on one contact. Yes. However, that "one contact" energizes the vast majority of car's fuses and therefore nearly ALL of the car's equipment! So if T15 ain't working properly, it's bad!!!
Reading back on the scans I provided yesterday and doing the same scans today as yesterday - the log with only 1 CU is the IGN off scan. Apologies for my mistake. However, there is still an anomaly with this - the ignition is off, but the scan states: U011400 - Lost Communication With Four-Wheel Drive Clutch Control Module static Priority - 2 Malfunction frequency counter - 1 Unlearning counter - 248 km-Mileage - 98176 km Supply voltage, terminal 30 - 14.7 V Terminal 15 - On Unknown ambient data - date - 2023-01-17 11:02:58 How is it possible it reads that the ignition circuit is on when it is not? Stevie: hmm....... OK. As a general statement - there really isn't much point in a SCAN report with ignition OFF. As I have said, without T15 energized, nearly ALL the equipment in the car is not energized. And importantly from a diagnostic perspective, no T15 voltage rail means that the major part of the car's CAN network and nearly ALL of the modules in the car are sleeping. These CAN components were put into a sleep state on the previous ignition cycle to minimize the quantity of electrical current draw from the battery - and they will remain asleep until the T15 rail is re-energized
The reason why you ONLY see one module with ignition OFF and why it's the Gateway module is because the hex19 module is the master diagnostic module. In this role, the Gateway module becomes the principal controller for the SCAN function. When you plug-in the OBD11 dongle and start the SCAN function, the OBD11 software wakes-up this module and it talks directly to this module. The Gateway module then acts as an intermediator and it subsequently relays OBD11's messages over the CAN network.
So, with ignition OFF, the Gateway module is woken-up - but the rest of the CAN network is still asleep! Hence, the ONLY module in the SCAN report is the Gateway module!!!
As for your specific question - there is no contradiction in the "ignition circuit" values! When reading the Freeze-Frame data in these error reports, it is necessary to understand that the "reading values" (i.e. mileage, supply voltage, terminal 15) represent a snap-shot of the car conditions when the error was first registered in the module's fault memory:
Therefore - whilst the date/time of the SCAN for the extract above was 2023-01-28 09:25:21, the readings in the extract above relates to the car conditions on 2023-01-17 11:02:58 (this being the date/time of error registration into module fault memory)
Don
|
|
