I found a pdf description from several years ago (2015) of the CodingLog file that describes the logging process. I am not sure how to attach a pdf, so I extracted the text:
A useful tool when the "brown stuff and the fan meet"
Introduction
It's a VCDS cable user's worst nightmare: You have diligently followed all the instructions, but the tweak has not been successful. Disappointed, you proceed to roll-back all the settings to their original value only to find that the car is now behaving in an unexplainable way. Something has gone seriously wrong and you're desperately searching for answers!
Well, whilst there can be no universal panacea in these instances, the following process may at least provide some insights as to where to start your fault finding investigations.
"De bug" in Ross Tech's software!
Within the Ross-Tech folders on your laptop is the "Debug" subdirectory. You will find this directory in both the Beta and non-Beta software versions. Most likely, there will be at least two files in the Debug subdirectory and maybe three. These files are: Readme.txt, CodingLog.txt and possibly, AdpLog.txt
The "Readme" file contains the following curious message "You can ignore the files in this folder". This message was placed in the directory by Uwe Ross as part of the software development but it would be wrong to ignore the contents of this folder as the information in the files can be a valuable tool in fault finding errors.
Every time that you make a change to an adaptation channel, or each time that you modify the coding value of a control module, RT's VCDS software makes a record of the event. When a change is made, the relevant text file in this folder is updated by writing a new record into the existing file (i.e. the old file is simply augmented with the new record, rather than a new file being created).
As originally intended, the change records were meant to be written into the AdpLog.txt file - for adaptation channel changes and separately into the CodingLog.txt file -for modifications to coding. However, as at the time of writing, because of a software glitch, almost all entries (with a few exceptions) are made into the CodingLog.txt files. So, it's not unusual for the Adpmap.txt file to be absent from the Debug directory. Ross-Tech has advised that whilst the software glitch has been identified, there are no immediate plans to implement a fix as the problem is seen as low-priority.
My understanding from discussion with Ross-Tech is that the files in this folder were intended for the development of the original VCDS software and as proof-of-work-done by professional cable users. However, an unintended benefit of these files is that they can be a valuable adjunct in fault finding errors of the type described in the opening paragraph.
Having been made aware of this facility, it's tempting to rely on these files as the record-of-source for tweaks that have been implemented (i.e. instead of the usual
Page | 1
practice of keeping separate records). A good reason why this should not be done is that the records in these files sometimes are not accurate. As Ross-Tech has explained, the information in these records is written into the files when "Do it!" tab , or "Save" tab is activated. This means that these records are blind to events that occur within the controller after the go-request is initiated. For example, if a change request is not accepted by the control module, the file will indicate that the change has been made when in reality the setting in the control module will remain unchanged. So, do not use these files as a substitute for manual record keeping. However, even with this idiosyncrasy, the CodingLog.txt file can be very useful as is illustrated in the following example.
How to use CodingLog.txt for fault finding - Example
For this example, it is assumed that a cable user has attempted to implement the Auto RainClosing tweak This tweak enables any open window, and/or an open sunroof to automatically close when the rain sensor on the windshield detects precipitation. For the purposes of this example, it's not important to understand the details of the tweak. Suffice to say that in broad terms the tweak requires that
1. The settings in the following three adaptation channels need to change:
a. Channel (15)
b. Channel (16)
c. Channel (28)
2. Coding changes need to be made to the rain sensor module (RLFS)
For the purpose of the example, assume that the cable user correctly makes the required changes to the three adaptation channels (above) and the correct coding modification to the RLFS was also made. Despite the fact that these instructions were correctly performed, the tweak still did not work (some forum members have reported that the Auto RainClosing tweak will not work on their cars).
Disappointed, the cable user decides to restore everything to its original value. However, in rolling back the settings, the cable user incorrectly changes channel (29), instead of channel (28). At the end of the roll back process and unbeknown to the cable user, two adaptation channels are incorrectly set and the car behaves in an unexplained manner. Even-though the user can recheck the steps in the tweak (this will likely identify that the setting for channel (28) has not been rolled-back), finding the error in the setting for channel (29) will be problematic.
To illustrate how CodingLog.txt can be used as a fault finding tool, a copy of the portion of this file that relates to the changes in the example above is shown below.
Note the structure of the file (I've included the red boxes and the red writing for illustrative purposes):
· The 3 x adaptation channel changes are shown in the first two blocks:
o The implementation of the tweak changes is shown in the first block
o Roll-back of the adaptation channel settings is shown in the second block
Page | 2
· The coding changes to the RLFS is shown in the last block
o The tweak coding change is shown in the first line (coding from - coding to)
o The rollback coding change is shown in the second line of this block
· The address of the control module is shown for each record as is the time and date of the change