Scribd
Upload
90 views

Codinglog - TXT File A Useful Tool When The "Brown Stuff and The Fan Meet"

The document discusses a CodingLog.txt file that can be found in the Debug subdirectory of Ross-Tech's VCDS software. This file records any time a user makes changes to control module coding or adaptations channels. While not entirely accurate, reviewing the log after issues arise can help identify what settings were changed and provide insights for troubleshooting. The document provides an example where reviewing the log helped uncover that the wrong adaptation channel was modified during an attempted rollback.

Uploaded by

Alin Daniel
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
90 views

Codinglog - TXT File A Useful Tool When The "Brown Stuff and The Fan Meet"

The document discusses a CodingLog.txt file that can be found in the Debug subdirectory of Ross-Tech's VCDS software. This file records any time a user makes changes to control module coding or adaptations channels. While not entirely accurate, reviewing the log after issues arise can help identify what settings were changed and provide insights for troubleshooting. The document provides an example where reviewing the log helped uncover that the wrong adaptation channel was modified during an attempted rollback.

Uploaded by

Alin Daniel
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 3

CodingLog.

txt file
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

A quick scan of this file by the cable user will confirm the following in this example:
1. The settings for adaptation channel (15) and (16) have been restored to their
original value
2. The Coding for the RLFS has been restored to its original value (i.e. 00A800)
3. Adaptation channel (29) setting has been altered in the roll-back process -
instead of channel (28))

DV52 (Sept 2014)

Page | 3

You might also like