De bug in RT's software, but don't reach for the insecticide just yet!

Not sure if this is the correct place for this matter, but I'm relying on the forum ghosts to re-direct if I have made a horrible faux-par!

Anyhow, I'm hoping for a "quickie" response to my two questions below which relate to the stuff that resides in the Debug subdirectory of the Ross-Tech\VCDS (and Beta-VCDS) folder (and please don't tell me that the answers are somewhere in the wiki).

First Question: Why does RT have that curious little message in the readme.txt file that says something like "please ignore the files in this directory"? Forgive my impertinence , but I'll be frank (or, I'll be earnest instead - if you want). IMO this message is tantamount to being fraudulent and the message is just plain wrong! The files in this sub-directory are of immeasurable value to those of us that want to know what changes we actually made to the control modules - as distinct to what changes we thought that we made.
What was the intent of the authors of this self-deprecating message and why is it there?

Second question: There are two other files in the Debug directory called something like AdpLog.txt and CodeLog.txt (I'm typing this on a pc that doesn't have the RT software installed - but I think that these names are correct). Now, I'm certainly not the brightest-penny-in-the-purse when it comes to VCDS matters, but I think that it's reasonable for even a VCDS drongo (an Australian vernacular) like me to assume that these files are meant to keep a log of the adaptation channel changes and (separately) coding changes. Is my assumption correct - or must I re-read the remedial training chapters in the Idiots-Guide-to-VCDS-Cables?
If this is so, then why is it that all the chronological data for the changes that I have made to-date sit in the CodeLog.txt file (regardless of whether these changes relate to adaptation channels, or coding modifications)? In my case, the CodeLog.txt file has been populated with changes to a range of MQB platform vehicles and for modifications to a late model Polo (6R model)- with one exception; the only entry in the AdpLog.txt file has been a record of a tweak that I did to alter the number of turn-signal blinks on the Polo. Can anyone explain this phenomena and the rationale for having these separate text files - please?

Good Morning. Let's see if I can shed some light...

1) The message originated back in the very early days of VAG-COM, instead of being asked "what is that" Uwe did put that message in there so he wouldn't be bothered anymore. Keep in mind back in those days we didn't use an installer like we do today and instead the archives were opened directly but the directory needed to exist - even though it was pretty much empty. We still want people to ignore the files, let's get into that in your 2nd question...

2) The 2 (actually 3) files which you will find in there are indeed documenting coding, adaptation and SRI related changes (as well as sometimes reads). We found that in many cases users accidentally did something but didn't keep record. These files are not intended for the end user to do the recording for them, they are meant for tech support purposes. Now why don't we tell everybody and their brother? Because once we do, people will solely rely on those files instead of keeping proper records themselves.

The proposed procedure to record changes is to run an Auto-Scan prior to doing any modifications, then keep the session log running and while you do so each and every change you make is being added to that session log. Now you always have the full before and after records of what you did that time and to which car. In shop environments we encourage our customers to attach those files to their management/customer files and to keep those records and even hand 'em to the customer as proof of what had been done to/with the car. For private individuals who are only working on a limited number of vehicles, I do see that these things are sort of the easy way out but we strongly encourage not to rely on them. Why? Once your machine crashes or something else happens, these are not there anymore. Hence the encouragement to use the proper session log functionality instead.

3) Why is there some mix-up of adaptation and coding logs file(s)? That is indeed a glitch which hasn't been addressed yet. Since those files are not meant for the end user to deal with we didn't think it was of the utmost importance.


P.S.: I hope this answers your questions, if you do have more - feel free to post 'em.

Sebastian said:

Good Morning. Let's see if I can shed some light...

1) The message originated back in the very early days of VAG-COM, instead of being asked "what is that" Uwe did put that message in there so he wouldn't be bothered anymore. Keep in mind back in those days we didn't use an installer like we do today and instead the archives were opened directly but the directory needed to exist - even though it was pretty much empty. We still want people to ignore the files, let's get into that in your 2nd question...

2) The 2 (actually 3) files which you will find in there are indeed documenting coding, adaptation and SRI related changes (as well as sometimes reads). We found that in many cases users accidentally did something but didn't keep record. These files are not intended for the end user to do the recording for them, they are meant for tech support purposes. Now why don't we tell everybody and their brother? Because once we do, people will solely rely on those files instead of keeping proper records themselves.

The proposed procedure to record changes is to run an Auto-Scan prior to doing any modifications, then keep the session log running and while you do so each and every change you make is being added to that session log. Now you always have the full before and after records of what you did that time and to which car. In shop environments we encourage our customers to attach those files to their management/customer files and to keep those records and even hand 'em to the customer as proof of what had been done to/with the car. For private individuals who are only working on a limited number of vehicles, I do see that these things are sort of the easy way out but we strongly encourage not to rely on them. Why? Once your machine crashes or something else happens, these are not there anymore. Hence the encouragement to use the proper session log functionality instead.

3) Why is there some mix-up of adaptation and coding logs file(s)? That is indeed a glitch which hasn't been addressed yet. Since those files are not meant for the end user to deal with we didn't think it was of the utmost importance.


P.S.: I hope this answers your questions, if you do have more - feel free to post 'em.

Click to expand...

Sebastian: Good evening and thanks for your explanation -which was indeed most illuminating!

Whilst I now better understand the status that RT gives to the 2 active text files (I don't have the "read" version of these files in my folder), I would (respectfully) invite the good folk at RT to think differently about their use - from a non-professional end-user perspective.

First, I have to agree that there can be no substitute for keeping accurate records and I also agree that it would be folly for cable uses to rely instead on the records in these two text files. A good reason for not relying on these files is that the logs appear to be incorrect in instances when a change request is not accepted by the controller. In these cases, my (short) experience has been that the record indicates that the change has occurred, but in reality it hasn't happened. I recall reading in a post somewhere (I think it may have been Uwe responding to a question on this forum) that the log is triggered just before the "Doit!" tab is activated - so the records are blind to events after the go request is made. But even with this idiosyncrasy, these two files (well....the one file really in my case) are still a great resource for us lay users!

I'm not sure how other cable-users see these files, but for me, CodeLog.txt is a valuable adjunct to my record keeping process - it's not a substitute!

I've had a couple of memorable instances where the data in this file has been the single most effective tool in fault finding spurious changes that others have made to their cars. So, my plea is that we don't under-estimate the importance of this/these files for us non-professional users (which doesn't mean that you should move-up the priority of the fix for the glitch)!

OK, I'll get-off my soapbox now and thanks again for replying to my questions.

Don,

It's not really a big secret that these files exist. In some ways, on could argue that they actually belong in the Logs sub-folder rather hat the Debug sub-folder, because none of the other stuff that might end up in the Debug sub-folder is at all useful to an end-user. Anyway, they're useful to you, by all means, feel free to use 'em.

Log entries do get written at the time the user clicks [Do it!] or [Save], meaning they show attempts to make changes rather than confirmed/verified changes. I suppose at some point, we could add some verification, but that's not likely to percolate to the top of our priority list in the near future.

-Uwe-

Uwe said:

Don,

It's not really a big secret that these files exist. In some ways, on could argue that they actually belong in the Logs sub-folder rather hat the Debug sub-folder, because none of the other stuff that might end up in the Debug sub-folder is at all useful to an end-user. Anyway, they're useful to you, by all means, feel free to use 'em.

Log entries do get written at the time the user clicks [Do it!] or [Save], meaning they show attempts to make changes rather than confirmed/verified changes. I suppose at some point, we could add some verification, but that's not likely to percolate to the top of our priority list in the near future.

-Uwe-

Click to expand...

Thanks Uwe- understood!