Working with Logs - Bugs and other issues VCDS v16.8.4.2

   #1  

Moni

Verified VCDS User
Verified
Joined
Oct 26, 2016
Messages
24
Reaction score
9
Location
USA
VCDS Serial number
C?ID=288542
VCDS Version: 16.8.4.2

BUGS
When scanning module “44 Steering Assist”, at the save-log step, the field for the VIN is picking up 00000000000003547
This results in an error “Unlikely VIN”.
If there was a new release that fixes this – never mind.
After one hour battle with the software I was in no mood to check for updates and go back down to test again.

Unworkable:
To get the detailed log for a module this needs to happen:
1. Select module
2. Advanced ID - 1A
3. Save
4. Browse
5. Switch to *.txt
6. Rename to 09 Cent Electric.txt (read below why I need to rename)
7. Save
8. OK
9. Done/Close
10. Are you sure - Yes
11. Go Back
12. Close Controller, Go Back – 06

Repeat 14 times!
~ 35 min.
If done via glide pad on a laptop and in the driver’s seat … be ready for false clicks and more Go-back.
I love your software but after 45 minutes I hated it. I still love it but I did hate it a lot at the time!

Even bigger problem:
The output is ADDED to the selected log file!
This makes the records come sequentially. It is a nightmare to scroll down and compare values like:
VCID: 3A38FAD6BD1A5492C7-806E vs. VCID: 3A38FAD6BD1A5492B2-806E
That value maybe a bad example (see my question below).
Never the less - This has to absolutely change!

The default mode should be OVERWRITE the selected log NOT append!
In the code this is a one letter change in the save function.

Each module-specific log has to be saved with a separate name.
It can be something like 02-Transmission-#######-2016-12-18.txt
Where ## is the mileage.
The VIN should be a folder name. This will split nicely the logs.
The VIN is already inside the logs so no danger of mixing files.
It is absolutely silly to overburden the names with the VIN.

Huge problem:
At the save-log step the default name comes with the VIN and the mileage text-box is empty.
You already know the miles – this value has to be prepopulated.

Not a huge problem:
… but when multiplied by 14 it becomes a huge one:
The headers are not consistent – that is not cool for side-by-side comparison:

Latest:
Sunday,18,December,2016,15:04:18:17869
VCDS -- Windows Based VAG/VAS Emulator Running on Windows 10 x64
VCDS Version: 16.8.4.2 (x64) HEX-NET CB: 0.4323.4
Data version: 20161129 DS267.0
www.Ross-Tech.com
Dealer/Shop Name: xxxxxxxx
VIN: 3VWC…… License Plate:

Previous
Saturday,19,November,2016,14:38:47:17869
VCDS Version: Release 16.8.3 (x64)

The new version is great! It is an improvement, I get that. Just try to keep it consistent as much as you can.

Naturally most of these problems are gone if you implement a one-click export to a single file of all “Advanced ID - 1A” for all available modules (I suggested this in a separate thread).
It goes without saying – please create a NEW file (overwrite if there). Do not append. Overwriting is perfectly fine if you keep the naming convention as mentioned above.

Question:
Is this value a VCDS software value or is it a vehicle settings/coding value:
Looks like VCDS related info, rather than info on, say, actual coding of the transmission module itself.
For example:
02-Transmission module:
November:
VCDS Info:
VCID: 3A38FAD6BD1A5492B2-806E
Labels: 09G-927-749.clb

December:
VCDS Info:
VCID: 3A38FAD6BD1A5492C7-806E
Labels: 09G-927-749-V2.CLB
 
   #2  

jyoung8607

FoRT
Verified
Joined
Feb 25, 2014
Messages
2,511
Reaction score
4,092
Location
Cincinnati, OH
VCDS Serial number
C?ID=25607
I'm curious, what is it you're trying to discover or save from the Advanced ID box? I don't think there's much in there you'll need. Most of the contortions you're going through seem to be related to saving that particular data. The important data gets preserved in an Auto-Scan.

That's not to say batch-saving that data is a bad suggestion, I'm just trying to discover what it would do for you.

It goes without saying – please create a NEW file (overwrite if there). Do not append. Overwriting is perfectly fine if you keep the naming convention as mentioned above.
The idea of deliberately destroying historical information the user has already saved... I think you'll find that opinion to be in the minority.

Is this value a VCDS software value or is it a vehicle settings/coding value:
Looks like VCDS related info, rather than info on, say, actual coding of the transmission module itself.
For example:
02-Transmission module:
November:
VCDS Info:
VCID: 3A38FAD6BD1A5492B2-806E
Labels: 09G-927-749.clb
VCID carries VCDS-internal data for Ross-Tech support needs. It's not from the car or module. I'm afraid the format is proprietary; I know little and can say less. I can say there's no real use in preserving and comparing VCID values across historical scans. Everything else is game though.

Jason
 
   #3  

Uwe

Benevolent Dictator
Staff member
Joined
Jan 29, 2014
Messages
29,938
Reaction score
21,379
Location
USA
VCDS Serial number
HC100001
BUGS
When scanning module “44 Steering Assist”, at the save-log step, the field for the VIN is picking up 00000000000003547
This results in an error “Unlikely VIN”.
That one is a bit puzzling. Is this repeatable? 16.8.4.2 is the latest.

The default mode should be OVERWRITE the selected log NOT append!
Let's agree to disagree. Initially (way back when), it was overwrite and users constantly complained about losing data as a result.

It is absolutely silly to overburden the names with the VIN.
Many of our customers are shops that work on a zillion different cars with this software. They absolutely want the VIN as part of the filename.

Question:
Is this value a VCDS software value or is it a vehicle settings/coding value:
Looks like VCDS related info, rather than info on, say, actual coding of the transmission module itself.
For example:
02-Transmission module:
November:
VCDS Info:
VCID: 3A38FAD6BD1A5492B2-806E
Labels: 09G-927-749.clb

December:
VCDS Info:
VCID: 3A38FAD6BD1A5492C7-806E
Labels: 09G-927-749-V2.CLB
Correct VCID is something calculated by VCDS, useful to us for support purposes. It does not come directly from the module, so changes in it should not be taken to mean that something about the module has changed. However, in this case, the TCM did get a new label file.

-Uwe-
 
   #4  

Moni

Verified VCDS User
Verified
Joined
Oct 26, 2016
Messages
24
Reaction score
9
Location
USA
VCDS Serial number
C?ID=288542
About the "44 Steering assist" issue. I can send screenshots to support. Will try to do today.

About the "destruction" of history. :)
I guess you guys did not read carefully - nothing is destroyed but rather preserved and ordered in a way nicer way than what you currently have.
I maybe an enthusiast with engines but am professional in programming and organizing data.

A professional mechanic who is dealing with many cars will have a clearly observable top folder structure where the VIN is the folder name (add in owner initials or make or something else)

These are long names due to the VIN and should not repeat hundreds of times per file - especially when you work on zillions of cars.
Each client should have their data in a separate folder - way easier to manage.

Under each of these folder you will have many files with all of your history.
##-Module-Mileage (for example)
07-Module-A-8020
07-Module-A-8022
07-Module-A-10035
In this example you have three files:
At 8,020 miles you baselined the car (new client), made some repairs and tested after a 2 mile test-drive (8,022)
Then the client visited once more at ~10K miles.
All clean to read and kept separate for each owner.

The overwrite is ONLY for the same miles count and module (if a person wants to back it up they can make the name change). In any event overwriting the same log in the same session is OK as nothing changed between two scans a minute apart.

Granted, there are two types of logs. Static and running data. OBVIOUSLY we are talking about static data.

All of that will be way more streamlined if all modules are in the same file, no.

Why is this better. Because even without Notepad++ you can just pop two consecutive readings in simple Notepad next to one another and compare visually. Scrolling up and down is just silly. The more visits the client has - the worst it will get.

About what I am trying to achieve:
In the log file from the auto-scan you do not have this info:
- Advanced Identification/FAZIT
- Flash Status
- Misc.

For the ones who intend to comment on whether or not this is useful to have:

There are two points of view: A professional mechanic and an enthusiast (one or two cars). I am the latter.
I DO UNDERSTAND the different point of view each group has re what is useful and what is not.
I do not dispute the more streamlined needs of professional mechanics.
The same way a professional mechanic should understand the POV of an enthusiast who spends $500 on a toy and is willing to keep spending on that hobby.
I say "toy" not to discount the power of this software but to just say "not really needed for most". Like in - at the end of the day a motorbike is a toy for most.

So, from my POV I do need it. I want to see in 5 seconds if any reprogramming took place while the car was being repaired.
At least I can ask the right questions.

Bottom line - at the end the product gets better from exchanges like this.
 
   #5  

PetrolDave

Verified VCDS User
Verified
Joined
Dec 16, 2014
Messages
3,780
Reaction score
3,781
Location
South Molton, UK
VCDS Serial number
C?ID=1423
A professional mechanic who is dealing with many cars will have a clearly observable top folder structure where the VIN is the folder name (add in owner initials or make or something else)

These are long names due to the VIN and should not repeat hundreds of times per file - especially when you work on zillions of cars.
Each client should have their data in a separate folder - way easier to manage.
Programming professionals, like you and I'd like to think I, organise data in the manner you describe with a well ordered folder structure.

But, and it's a big but, the population at large do not organise data in such an easy to find and well structured manner - the vast majority of people use a flat structure of a single folder with zillions of files in it.

So for people like you and I, your suggestion is valid; but for "Joe Public" it would be a disaster IMHO.

Just my $0.02...
 
   #6  

Santos

Administrator
Staff member
Joined
Jan 29, 2014
Messages
236
Reaction score
2,768
Location
Lansdale, PA, USA
But, and it's a big but, the population at large do not organise data in such an easy to find and well structured manner - the vast majority of people use a flat structure of a single folder with zillions of files in it.
who needs folders when you can save everything to desktop.
 
   #8  

Moni

Verified VCDS User
Verified
Joined
Oct 26, 2016
Messages
24
Reaction score
9
Location
USA
VCDS Serial number
C?ID=288542
Fully and unconditionally agree.

One angle though - and you will agree as well.
"Joe Public" is not doing this on purpose. He just does not give a damn and THAT'S OK. No, seriously, this is really fine.
I actually like users who do not give a damn as they force me to re-think my coding.

Users not giving a damn is kind of a blessing as you are free to channel the behavior into "best practices" and the user will just go with it.
There is absolutely no question that the proposed naming and folder convention is better than a big "paella" of files.

Now one more thing you will agree with.
There is a huge number of current customers who will throw something at the screen if you bring "best practices" in your next release.
Asking them to rename their files-paella is also a non-starter.

There is only one way to go about it and it is not a technical problem but a management decision.
When and if such improvement comes it should look like that:
1. Default behavior of saving is not changed.
2. There is a selectable option to go for a new naming convention.
3. There is a separate conversion tool that would take a current files-paella and split it to folders and separate files.
#3 in itself is about one-person one-week cost.

Again - users will get an absolutely better product but most will not care - hence the effort/cost is entirely up to management.

So - to close this issue - will it be possible to do this in the mean time for the next version:

1. When you append info to a current log - please insert at least a new line in front of each new addition (or a divider of some sort) (5 min change).
2. Add a check-box to your Auto-Scan function (default = OFF) that would loop through all modules and extract all info incl.
- Advanced Identification/FAZIT
- Flash Status
- Misc.
Something like "Add extended info".
It could be just an hour or a day of coding and testing (depending on how your code is structured).

Is this doable?
Note - this is really a very small coding effort and will not change anything in the current default behavior.

The above #3 could be bundled in a completely new major version where you also offer the log-comparison functionality I suggested in a separate thread.
For this to happen you absolutely must have the logs separately. (yeah ... doable in a single file too but it will look like .... put a choice-word here ...)
Something to think about - cause you will be releasing future upgrades and improvements and what not anyway.
 
   #9  

PetrolDave

Verified VCDS User
Verified
Joined
Dec 16, 2014
Messages
3,780
Reaction score
3,781
Location
South Molton, UK
VCDS Serial number
C?ID=1423
There is only one way to go about it and it is not a technical problem but a management decision.
When and if such improvement comes it should look like that:
1. Default behavior of saving is not changed.
2. There is a selectable option to go for a new naming convention.
3. There is a separate conversion tool that would take a current files-paella and split it to folders and separate files.
#3 in itself is about one-person one-week cost.

Again - users will get an absolutely better product but most will not care - hence the effort/cost is entirely up to management.
From what relatives who have worked in independent car repair shops tell me, the management of the many independent repair shops that use VCDS are unwilling to accept anything that takes more time to do a repair - and creating a folder per vehicle will do that (and creates the chance of error in creating the folder name incorrectly).

OK I hear you say but it will make retrieving data from a previous service on a vehicle easier, but retrieving data from a previous service is very much an outlying use case so the extra convenience/speed in that tiny minority of uses will not compensate for the extra time taken in the majority of cases.

Bottom line - repair shops probably won't see adding a feature that they don't want and which they perceive will cost them time & money (even if it's a selectable feature that they don't use as per option #2) as making a better product.

As a former Chief Engineer I've learnt that successful products work with with users behavior and don't try to change their behavior - even if that means the product is, in the view of the development team, sub-optimal.

The customer is always right ..... even if he/she is a complete fool, because they pay our salaries.

Having said all that, I 100% agree that an "Add extended info" feature could be really useful, and would be far quicker than manually getting the data from each module.
 
  • Like
Reactions: Uwe
   #10  

Moni

Verified VCDS User
Verified
Joined
Oct 26, 2016
Messages
24
Reaction score
9
Location
USA
VCDS Serial number
C?ID=288542
Fully agree on all counts.

Hope the feature "Add extended info" gets added.

Thanks for the insights. Good to be on the same page.
 
Top