Changing diagnostic session

hadez16 · Apr 19, 2018

Hi all,

there exist already a thread about a special S12345 Login for 5F units in order to activate some channel in another diagnostic session.
http://forums.ross-tech.com/showthr...e-Access-on-MIB-units/page4&highlight=session

My link points directly to a non-answered question yet if S<LOGIN_CODE> is a generic syntax to change the diagnostic session so Developer or Engineer or whatever followed by the Login for that session.
Is that the case? Or is S12345 a speciel thing which just triggers some magic steps uniquely for 5F?

Why am I asking?

It seems that there exist another topic where success only can be reached by changing the diagnostic session: Retrofitting footwell lights in MQB cars like Golf MK7.5.
Several threads exist where the lights just won't light up after having them activated by coding like in other cars equipped by factory.

Then one thread came to my attention where someone had success by changing the diagnostic session prior to assigning the light function "Fussraumlicht" to the according "Leuchte" channel.
http://www.golfmk7.com/forums/showthread.php?t=29362
(Post #15)

So it seems that changing this does trigger some more stuff that requires beeing in a non-standard diagnostic session.

Do some magic login cheat codes for VCDS already exist to just change the session?
Or could this be some top priority feature request I'm filing at this second?

Cheers,
hadez16

TBAx · Apr 19, 2018

When I was allowed to make a wish, I would recommend VCDS to allow changing diagnostic mode using a drop down menu in the module overview or the like. This would remove the dependency on the label files (which to my knowledge have a small script associated to the "special" login S12345).

Also: Does VCDS allow alphanumeric logins? Those are required to perform i. e. End of Line (EOL) programming on MQB ESC/IPB controllers.

Uwe · Apr 19, 2018

You guys follow this forum right?

Do you really think it would be a good idea to give some of the unwashed masses here the ability to change diagnostic sessions at random via something as obvious as a menu item?

-Uwe-

jyoung8607 · Apr 19, 2018

Uwe said:
You guys follow this forum right?

Do you really think it would be a good idea to give some of the unwashed masses here the ability to change diagnostic sessions at random via something as obvious as a menu item?

... so if we take a shower first...?

hadez16 · Apr 19, 2018

Uwe said:
You guys follow this forum right?

-Uwe-

Yes - only professionals.

A skill system could also be introduced where such features get enabled after having 500 saved codings... (statistics in About dialog).

Well, I'm lacking arguments.

MasterTommy · Apr 19, 2018

Uwe said:
You guys follow this forum right?

Do you really think it would be a good idea to give some of the unwashed masses here the ability to change diagnostic sessions at random via something as obvious as a menu item?

-Uwe-

Well, seeing as there’s already a difference between interface versions (limited vs unlimited), I personally don’t really see a problem there. You could hide advanced stuff in enthousiast versions and only show them in professional versions. Lock them so only knowledgable people can use them. But to completely leave it out is, in my opinion, not really a great long term strategy. More and more recent models require a different approach to be able to do common stuff, and I don’t really see that getting anything but worse.

Changing diagnostic session is just one item in a small but essential list of ‘stuff you need to do your work’ in the latest MQB/MLB cars. I love VCDS for the way it presents its functionality and ease of use. But ease of use and functionality do not have to be mutually exclusive.

- There is no need to include all possible diagnostic modes. Engineer mode and EOL modes would be sufficient.

- Parameterization is as easy, if not easier than making coding changes. But without it there is more and more stuff you just cant do.

- Update SW (flashing) could be a different tab under applications. And again, restricted use is better than none. You could have it only flash based on a RT managed list with which flashfiles you can flash to selected control module. And have it refuse to even progress to anything without first having a Vbatt that is only achievable with a charger connected (>13.2V).

And I completely understand advocating against functionality that could cause big issues when used incorrectly. What seems to be odd then to me is that the only guided function VCDS has is an SRI reset. Different tools with much more functionality also have a ton of guided functions. In the interest of proctecting unknowledgeable people against their own actions, you’d think guided functionality is something that would fit VCDS like a glove.

I’m not trying to rant or anything, just providing constructive criticism.

MasterTommy · Apr 19, 2018

Typed on phone btw, will spellcheck later

Santos · Apr 19, 2018

MasterTommy said:
You could hide advanced stuff in enthousiast versions and only show them in professional versions.

Personally, I would consider you guys "Power users", a step above a professional user. We get calls/emails weekly of professional users running random adaptations/basic settings and screwing a lot of things up. Give them a little more power and i can see people blaming us for bricked modules ,etc.

Uwe · Apr 19, 2018

hadez16 said:
Yes - only professionals.

MasterTommy said:
Well, seeing as there’s already a difference between interface versions (limited vs unlimited), I personally don’t really see a problem there.

We get much of our feedback from individual enthusiasts rather than professional users. One of the problems with professional users is that they're working on customer's cars and the customers want those cars back ASAP. Often that means that by the time something is reported to us, and we say, "try this please", or "get us the following data from the car please so we can investigate", the car is gone. That's obviously not a problem for the individual enthusiast who is playing with his own car.

Then there's the fact that there's a goodly portion of "professional" users (i.e. actual workshops) who are in the "unwashed" category. I'll give you an example: Just this week we had a guy who owns a shop and who has been a customer for well over 10 years complain that VCDS "messed up" a 2016 Audi S6. The car wasn't sitting quite level, so his tech went into the J197 module and ran the Basic Setting called, "Resetting of all adaptations". Well guess what? The module now has "No End-of-Line Programming". :eek:

But somehow, this is our fault. :rolleyes:

Anyway, whether someone is a "professional" (who works on cars for a living and has bought an unlimited VIN interface) is not at all a good way to tell whether I would trust him not to mess up a car, nor would I want to block capabilities from our more knowledgeable enthusiast customers who don't need unlimited VINs.

-Uwe-

Sebastian · Apr 19, 2018

@hadez16, please get in touch with me directly and I'll take a look at the specific scenario. I am sure we can find a workaround for this.

TBAx said:
Does VCDS allow alphanumeric logins? Those are required to perform i. e. End of Line (EOL) programming on MQB ESC/IPB controllers.

Do you have a specific reference for that statement? The spec for the security access / login function does NOT allow anything else than numeric values.

MasterTommy · Apr 19, 2018

Uwe said:
We get much of our feedback from individual enthusiasts rather than professional users. One of the problems with professional users is that they're working on customer's cars and the customers want those cars back ASAP. Often that means that by the time something is reported to us, and we say, "try this please", or "get us the following data from the car please so we can investigate", the car is gone. That's obviously not a problem for the individual enthusiast who is playing with his own car.

Fair point!

Then there's the fact that there's a goodly portion of "professional" users (i.e. actual workshops) who are in the "unwashed" category. I'll give you an example: Just this week we had a guy who owns a shop and who has been a customer for well over 10 years complain that VCDS "messed up" a 2016 Audi S6. The car wasn't sitting quite level, so his tech went into the J197 module and ran the Basic Setting called, "Resetting of all adaptations". Well guess what? The module now has "No End-of-Line Programming". But somehow, this is our fault.

Well remind me to never apply for a helpdesk job at you guys.

That being said, that basic setting option, which is freely available in MQB/MLB controllers is a very fine example of something I'm not sure why it's there, and any of the above points I made earlier aren't. 'Resetting of all adaptations' would (and still does) sound to me like resetting something you can relearn. That VCDS is unable to relearn something that it does allow you to erase, is kind of asking for it. Also, no clarification is given regarding that option in the form of those handy text balloons or something else. Right now, without being able to switch diagnostic modes, VCDS makes it very easy to start a procedure you cannot finish, without providing any sort of warning. It cuts both ways.

Anyway, whether someone is a "professional" (who works on cars for a living and has bought an unlimited VIN interface) is not at all a good way to tell whether I would trust him not to mess up a car, nor would I want to block capabilities from our more knowledgeable enthusiast customers who don't need unlimited VINs.

-Uwe-

I agree. I just really think some of these missing functions are not really optional anymore but rather essential and could, with some guidance, be very effectively implemented in VCDS without doubling the amount of customer service employees you guys currently have. On the other side of things I don't get why other 'dangerous' options are freely accessible which, when activated, screw things up for the user. That kind of invalidates the point of wanting to protect the user (the point you made earlier).

Uwe · Apr 19, 2018

MasterTommy said:
That being said, that basic setting option, which is freely available in MQB/MLB controllers is a very fine example of something I'm not sure why it's there, and any of the above points I made earlier aren't. 'Resetting of all adaptations' would (and still does) sound to me like resetting something you can relearn.

It's in there because it's defined in the data for that module. It's called what it is because that's what they call it.

But in upcoming versions, it will get a warning like this:

MasterTommy said:
On the other side of things I don't get why other 'dangerous' options are freely accessible which, when activated, screw things up for the user.

Unfortunately, it's not always obvious what might be "dangerous", even to us. It's a bit different when we know in advance that something is definitely dangerous.

-Uwe-

hadez16 · Apr 20, 2018

Sebastian said:
@hadez16, please get in touch with me directly and I'll take a look at the specific scenario. I am sure we can find a workaround for this.

Thanks Sebastian, very kind. "Unfortunately" it is not my personal problem (car) with the footwell lights but I thought that piece of information regarding having the need of changing the session is just very interesting.
That's why I started this generel thread about that topic.

There exist that thread in our german forum called "Golf VII Fußraumbeleuchtung codieren" where I already quoted some parameter channels that need to be changed in addition I think.

Code:

IDE11477-ENG128539-Innenbeleuchtung Parameter-p_adaption_kundenwunsch_fussraum,00
IDE11477-ENG128548-Innenbeleuchtung Parameter-p_helligkeit_andereTuer_auf_zuendung_aus_fussraum,0 %
IDE11477-ENG128545-Innenbeleuchtung Parameter-p_helligkeit_andereTuer_auf_zuendung_ein_fussraum,0 %
IDE11477-ENG128547-Innenbeleuchtung Parameter-p_helligkeit_dieseTuer_auf_zuendung_aus_fussraum,0 %
IDE11477-ENG128544-Innenbeleuchtung Parameter-p_helligkeit_dieseTuer_auf_zuendung_ein_fussraum,0 %
IDE11477-ENG128549-Innenbeleuchtung Parameter-p_helligkeit_einausstieg_fussraum,0 %
IDE11477-ENG128540-Innenbeleuchtung Parameter-p_helligkeit_entriegelt_fussraum,0 %
IDE11477-ENG128541-Innenbeleuchtung Parameter-p_helligkeit_max_fussraum,0 %
...

I'd love to have a retrofitted car in access...sorry

Uwe said:
Well guess what? The module now has "No End-of-Line Programming". But somehow, this is our fault.
-Uwe-

Isn't there any safeguarding phrase in the fine print that keep special users away from claiming that it is your fault?
If you buy a car and hit it against a tree, you can't blame Audi. It's a tool that has to be handled correctly.

I don't want to sound presumptuous - I have no clue about that business and stuff.

PetrolDave · Apr 20, 2018

MasterTommy said:
You could hide advanced stuff in enthousiast versions and only show them in professional versions. Lock them so only knowledgable people can use them.

Some of us "enthusiasts" have been using VCDS for a lot longer than some professionals - I personally have been using VCDS for nearly 15 years - so the assumption that if one is an enthusiast you are not knowledgeable is IMHO not valid. I would not be happy with this suggestion.

TBAx · Apr 23, 2018

Sebastian said:
Do you have a specific reference for that statement? The spec for the security access / login function does NOT allow anything else than numeric values.

Not one I can publicly disclose unfortunately.

Ciamardo · Jun 8, 2018

Uwe said:
Do you really think it would be a good idea to give some of the unwashed masses here the ability to change diagnostic sessions at random via something as obvious as a menu item?
-Uwe-

hi
I have a solution

, enable this feature ONLY on specific Request , available only HEX-NET and activable by code sent from Ross-Tech using the Feat code Option

Little Disclaimer -use of the Feature is at your own full risk and Ross-tech LLC will not respond in any way :thumbs:

So, what do you think ??

Sebastian · Jun 9, 2018

Again, if you happen to have a specific use case I am sure we can accommodate your needs.

Changing diagnostic session

hadez16

Verified VCDS User

TBAx

Verified VCDS User

Uwe

Benevolent Dictator

jyoung8607

FoRT

hadez16

Verified VCDS User

MasterTommy

Verified VCDS User

MasterTommy

Verified VCDS User

Santos

Administrator

Uwe

Benevolent Dictator

Sebastian

Ross-Tech Employee

MasterTommy

Verified VCDS User

Uwe

Benevolent Dictator

hadez16

Verified VCDS User

PetrolDave

Verified VCDS User

TBAx

Verified VCDS User

Ciamardo

Verified VCDS User

Sebastian

Ross-Tech Employee