VCDS freezes up

[LN-TAL]

Hi,

sometimes VCDS freezes up when you try to connect to a control module. All of the buttons (e.g. reading fault codes, coding, adaption etc) are greyed out (can not push them), and when you hit «close controller» (or, if you are running an auto scan, hit «ESC - to cancel auto scan» (or whatever the button says), the software freezes up, and you get the message «not responding» on the title line.

This has ONLY happened when I connect to my HEX-NET interface by wifi (AP mode). I have never experienced this bug when I use the USB cable (but, I have not used the USB nearly as much as I have used the wifi).

Today I was trying to do an autoscan, and it failed twice (I have never had two fails after each other before). The first time it was stuck on module 09. The second it was module 46. The third time I used the USB cable But as I said, I have also experienced this bug when I am trying to connect to one module (e.g. 01-engine). I then hit "close controller". The software freezes up (the message "not responding" is shown on the title line, corresponding to the norwegian "Svarer ikke" which you can see on the picture), and after 10-15 sec (my guess) you get back to the «select module» screen.

Is this a known bug ? If you need me to do some «debugging» stuff with my equipment, please let me know. I will be more than happy to assist.

 

[Uwe]

I don't think that's a known bug. What version are you using? Is your HEX-NET completely up-to-date?

You say this only happens when you connect in AP mode? What's the distance between the HEX-NET and your computer when this happens?

Are there any other WiFi signals around? If you have an Android phone or tablet, Wifi Analyzer is a really nice little tool to have.

-Uwe-

 

[LN-TAL]

I forgot to say: it happens with both 14.10.2 and beta 15.2.0. The reason I say it only happens in AP mode is because that is the only WiFi mode I have tried (I have only briefly tested the infrastructure mode)

I think my hex-net is updated (CB: 0.4123,4 FW: 0,214 WiFi: 310C). The distance seems to be irrelevant. Today I had the tablet inside the house (about 3 meters from the car). But it also happens when I sit in the car, only about 50 cm from the HEX-NET interface. There is some wifi networks around. But not very many.

Android ? Phøf

 

[Uwe]

OK, what kind of tablet is it? Please give us as much detail as possible.

-Uwe-

 

[LN-TAL]

This tablet is a Microsoft surface PRO 10,6", with windows 8.1 PRO. But I also had the same problem with my Lenovo thinkpad 8" tablet.

The surface tablet have 4GB ram, 128GB flash disc.

edit: hmm, there is a picture in the first post. But somehow it does not show up ? The link to the picture is: http://imgur.com/yUt93pt

As you can see from this picture, VCDS connects to the module in question (in this particular case: module 09). But there is some kind of bug, communication failure or something, because all the buttons are greyed out, like "the system is not completely ready"). And I THINK the reason why VCDS does not move on is because the connection to the module is not completed, or something.

 

[Uwe]

Hmm... Take a look at all the scans posted by "roth" in this forum in the last few days. I'm not saying what you're experiencing is not a bug, but I'm sure it's not universal, i.e. it doesn't affect everyone.

Remind us, what kind of car are you trying to scan?

-Uwe-

 

[LN-TAL]

Audi A6, 2012 3.0TDi quattro. 4G5.

edit: And again, this does NOT happen every time. I have never ever experienced that an autoscan failed twice before.

 

[Sebastian]

In cases where it freezes, what happens if you just wait (let's say a minute or two)?

 

[LN-TAL]

Ok, I have done some more testing, and here is my observations:

It definitely seems to be a problem with communication with module 09 and 46 on MY car. Well, I don't think it is a problem with MY car, but probably something «special» with the communication with module 09 and 46 in this TYPE of car.

I have used about 1 hour now with testing. I have opened and closed most of the modules MANY times. First a question: is it ok to open and close modules many times a row for testing purposes ? (without doing anything, as soon as the communication with the module is ok, you just hit «close Controller, Go Back - 06». And then open the module again asap. Or can this destroy some modules ?

In this hour, I have experienced:

1. This bug ONLY happen when using WiFi (AP). I have NOT experienced this bug by using USB.

2. This bug ONLY happens with module 09 and 46. It did NOT happen on ANY other module.

3. It seems the bug is MUCH more frequent on module 09 than on module 46. My (un)qualified guess is that the bug shows up more than 50% of the connection attempts to module 09. Less than 50% of the connection attempts to module 46.

You can tell from experience when the bug is showing up. The bug shows up when NOT all the information is loaded into the «extra field» in VCDS.
SOMETIMES, if you wait a long time (20 sec +) the «missing information» in the extra field(s) is loaded correctly, and all the fields (like «fault codes - 02») is activated. This is probably because VCDS wont «activate» the buttons before the communication with the module in question is established in a correct manner ?

Sebastian: actually, VCDS wont normally freeze up until I do not want to wait anymore, and hit the «close controller, go back - 06» button. And I really do not think the freeze is a bug. I think this is more of VCDS telling me «Hey stupid, I am not finished with setting up the communication with this module, and now you want me to to back again ? I better freeze and think about this».

SO, to sum it up. I think this is a problem with setting up the communication with some «few» modules. And, due some strange reason, this bug only appears when I use the WiFi, and not usb. Well, I cant guarantee that it does not affect VCDS when I use USB between the tablet and the HEX-NET. But at least I have not, to this date, experienced this fault when I have used USB connection.

I also have not come to the conclusion before this evening that it only affected module 09 and 46. But I think that is because I have not paid to much attention to this.

Hope this can shine some light on the problem ?

 

[Sebastian]

I have seen the same issue a few times, so have other customers. It seems to happen mostly on modules with a lot of slaves, or when a slave doesn't seem to answer in time. As you mentioned, if you wait a while - things usually catch up - yet if you don't wait and try to click things randomly VCDS may freeze forever. The reason why you're not seeing this via USB is because VCDS queries things differently.

P.S.: Uwe, see FS#896.

 

[jyoung8607]

3. It seems the bug is MUCH more frequent on module 09 than on module 46. My (un)qualified guess is that the bug shows up more than 50% of the connection attempts to module 09. Less than 50% of the connection attempts to module 46.

You can tell from experience when the bug is showing up. The bug shows up when NOT all the information is loaded into the «extra field» in VCDS.
SOMETIMES, if you wait a long time (20 sec +) the «missing information» in the extra field(s) is loaded correctly, and all the fields (like «fault codes - 02») is activated. This is probably because VCDS wont «activate» the buttons before the communication with the module in question is established in a correct manner ?

May I ask how long you're waiting before giving up? 09-Central Electronics can have a ton of slaves on modern cars. I used VCDS with a remarkably bare-bones Jetta and VCDS needed something like 40 seconds to enumerate all the slave controllers.

For historical reasons, the VCDS GUI thread may not be serviced during those inquiries to the car, so if you click on/around the window, Windows (I think Vista and beyond? maybe 7?) will tell you that VCDS isn't responding. VCDS isn't actually hung, it's just not accepting and processing GUI inputs at the moment. It's a cosmetic issue only. So, I'm curious to know if you still have trouble if you start the Auto-Scan and then don't touch the computer at all while the scan is running, and wait a few minutes to see if the scan finishes.

Jason

 

[LN-TAL]

I have waited about 10 minutes in the autoscan before I canceled. (10 minutes AFTER it stopped to do something usefull)

 

[Uwe]

That's certainly more patience than I would have.

-Uwe-

 

[jyoung8607]

I have waited about 10 minutes in the autoscan before I canceled. (10 minutes AFTER it stopped to do something usefull)

Yeah, that's much too long. It's hung, and that's worth looking into.

Are you familiar with taking debug-1024 logs from VCDS? That's the next step here, to log a working scan and then a not-working scan so that Ross-Tech support can see where they diverge. If not, we can talk you through it. It's not difficult. Even if it turns out to be a known issue that Ross-Tech is already addressing, it would be nice to confirm that.

Jason