Page 1 of 2 12 LastLast
Results 1 to 10 of 14

Thread: New functionality of VCDS?

  1. #1
    Verified VCDS User
    Join Date
    Mar 2014
    Location
    Poland
    Posts
    95
    Post Thanks / Like

    New functionality of VCDS?

    Uwe, are You going to increase the functionality of VCDS by including the direct coding in the memory cells in the CECM.
    I'm thinking about manual light configuration in cells 3073 - 3119 of the CECM. I think You know what I mean.
    I'm using other software to do it, but it's slowness is horrible.

    I've read your comment about VIM. I can see, there is no support for ABS coding.
    If You will go this path, the VCDS will remain tool for enthusiasts - not for professionals.
    Just keep the advantages of product - fast, perfect interface - and improve new functions.

  2. #2
    Verified VCDS User Al Bundy's Avatar
    Join Date
    Mar 2014
    Location
    Bucharest, Romania
    Posts
    20
    Post Thanks / Like
    Hi
    I support this functionality. With it you can set up easier byte 18.
    And there is a nice little program made ​​by the Russians, in explaining what each address.

  3. #3
    Benevolent Dictator Uwe's Avatar
    Join Date
    Jan 2014
    Location
    Earth
    Posts
    26,389
    Post Thanks / Like
    Blog Entries
    1
    Quote Originally Posted by Enriquez View Post
    Uwe, are You going to increase the functionality of VCDS by including the direct coding in the memory cells in the CECM.
    That's not coding. That's directly altering non-volatile memory, with no chance at all for the software control module to reject changes that make no sense or that could have very bad consequences. Historically, we've refused to do that, because we'd rather our customers don't brick their control modules.

    Does that mean we will never support changing those parameters? No it doesn't. It only means we won't do so until/unless we come up with a way that we think is reasonable safe for most users.

    -Uwe-

  4. Likes jyoung8607, jakematic, Enriquez liked this post
  5. #4
    Verified VCDS User
    Join Date
    Mar 2014
    Location
    Poland
    Posts
    95
    Post Thanks / Like
    Good point, I understand.
    However, the long coding in the LCode helper modifies as well the same memory, but adresses starting at 3136 in groups of 3 cells together.
    So if the coding is like mine 40190AB8E05BF1C040080080310089E443F900AE776987F05C 814000A040

    the value of cells 3136, 3137, 3138 is $40, next 3139, 3140, 3141 is $19 etc...
    So we can say it's a matter of coding

  6. #5
    Verified VCDS User Al Bundy's Avatar
    Join Date
    Mar 2014
    Location
    Bucharest, Romania
    Posts
    20
    Post Thanks / Like
    Uwe, If you remember me, I send you the same request 2 or 3 years ago, when I see that your VCDS interface work with vageeprom 1.18 or 1.19 to READ eeprom memory fron IC G4 or similary cars.
    When I modify byte 18, the modification is send in the memory. And if byte 18 is 00, we cannot UNDO this modification with VCDS. It can be do with VAS-PC acces memory direct.

    Or, you can give acces to a limited number of users, only them who ask directly you to give acces, based on pasword or something else.

  7. #6
    Ross-Tech Employee Sebastian's Avatar
    Join Date
    Feb 2014
    Location
    Magdeburg, Germany
    Posts
    1,948
    Post Thanks / Like
    Enriquez, you are correct when you state that the coding is finally written into memory locations as well but the process how it get's there is slightly different. We've pushed some of these ideas around in the past, reality is that this isn't entirely out of the question but there are currently more important things which require our attention. Direct memory access for end users is a very dangerous field, do we want to give each and every user that level of access? How do we decide if somebody is "intelligent" enough to use it properly and won't blame us for their mistakes? There are plenty of things to consider and there is a reason why that functionality isn't available in VCDS.
    Sebastian @ Ross-Tech.com // VCDS Rookie since 2003

    »Nichts erweitert das eigene Wissen mehr,
    als die Meinung eines Andersdenkenden.«

  8. Likes Zenerdiode liked this post
  9. #7
    Verified VCDS User
    Join Date
    Mar 2014
    Location
    Poland
    Posts
    95
    Post Thanks / Like
    Sebastian that is the problem which _YOU_ need to resolve. If You want to keep Your product safe for all it will not meet the requirements of more advanced users. Then we will have to go to the other products such as VCP or just use VAS to complete the work. VCDS is very comfortable and fast, but not all things can be done using it. This is why I'm raised this topic. The same story is when You buying an hammer. You cann smash Your finger as well.

    I don't ask for direct access to the memory cells, because there is a lot of other tools to do it. However if You can do a simple menu for byte 18 recoding as in VAG Helper it would be nice and save time. You cannot brick anything having access to this. I'm not offence, but I think that kind of discussions will help You to choose the direction You develop Your product.

  10. Likes Uwe, Zenerdiode, langers2k, Spacewalker liked this post
  11. #8
    Verified VCDS User Zenerdiode's Avatar
    Join Date
    Jun 2014
    Location
    Newcastle, England
    Posts
    989
    Post Thanks / Like
    I like the idea of EEPROM access being added as a 'non-documented feature' unlocked to people who specifically ask - also locked maybe to their account and/or interface. VCDS is very explicit for the novice user; with two clear sides: 'This is Safe' and 'Refer to Service Procedures'. EEPROM direct access should not be enabled en mass because as Sebastian states; one bit wrong and you can brick a module with no return.

    Yes, the VAS-PC tool does allow this functionality, but the dealerships (where the vast majority of these are used) are backed by the insurance that if something goes wrong and a module does get bricked - they will replace it. But my hunch is that most technicians will not know of the EEPROM facility unless directed by a 'Master Tech' or whoever at the technical centre.

    If anyone needs convincing of how easy it is to damage a module, here's a bit of my experience. I like to play about with these things but won't do it on a live car. I have a few bits and pieces of modules that I have collected over the years and build a virtual car on the bench. I've used the VAG EEPROM Programmer mentioned above and I trust it, in the same way I trust VCDS, that it is stable and does exactly what you ask of it. Other programs of the type have let me down. Even so, I had an Instrument Cluster and that has all sorts done to it, EEPROM copied, bytes adjusted, programmed back, what ifs, etc. I've programmed all 00s and all FFs just to see what happened. All fine, all reversible, original contents flashed back in and put back on the shelf. Tried the same with an Immobiliser I box, changed the PIN etc. then the what ifs again. This time I filled the EEPROM with FFs and that's it. Dead. You can connect to the module to read fault codes, you get 65535 memory error. But the module does not allow you to even read the EEPROM contents anymore - let alone write anything back. It's fine doing this in the back room, it's gone back on to the shelf until I can be bothered to de-solder and progam the chip to fix - but imagine I'd done this to a friends car - and it was their only means to get to work the next day?

    But still, Sebastian, please consider me 'intelligent' enough so I can help with this.

  12. Likes jakematic, jyoung8607, Uwe, langers2k liked this post
  13. #9
    Ross-Tech Employee
    Join Date
    Jan 2014
    Location
    Near Philadelphia, PA, USA
    Posts
    1,120
    Post Thanks / Like
    Blog Entries
    3
    Quote Originally Posted by Sebastian View Post
    ... Direct memory access for end users is a very dangerous field, do we want to give each and every user that level of access? How do we decide if somebody is "intelligent" enough to use it properly and won't blame us for their mistakes?
    This issue is not a matter of determining "Intelligence." It is a matter of legal liability. Who will be held responsible when a user defeats a safety system? Who will be responsible when the lack of that safety system results in a death?

    Ross-Tech has been very mindful of these issues. Sure, advanced users are limited by the lack of this ability but at the same time, RT has to protect it's derriere. In this litigious world in which we live, RT has to error on the side of caution. We have too much invested to have it ripped from our hands over a bit that was flipped!

    Unless someone can show us a legal means by which the responsibility for damages caused by this feature of modifying bits that were not intended to be modified by the OE be placed on the party making the change rather on the party enabling the ability to make the change, I think RT has to follow the route we are following - no EEPROM change for you.

    Quote Originally Posted by Enriquez
    Sebastian that is the problem which _YOU_ need to resolve. If You want to keep Your product safe for all it will not meet the requirements of more advanced users. Then we will have to go to the other products such as VCP or just use VAS to complete the work.
    As to RT not keeping up with the needs of the advanced users, we are not the OE. The OE can take the liability for changes their engineers tell a technician to make. But when a tool allows any user to make such changes, then the liability issue comes into play. We'll accept the criticism that our tool is not keeping up with the needs of the advance user. The advanced users may have to have other tools. VCP will allow users to defeat safety systems and I doubt the creators of VCP will care about the legal liability. Their business model is not the model of RT as they already do things that are dubious in the legal realm such as providing flashes that are the property of VAG (distributing Intellectual property of others). They obviously do not care about the legal ramifications. As users who want the capability to flip any bit, we understand your desire. But, the big picture says that Ross-Tech must consider all legal aspects of how it's product might be used.

    Uwe has a huge investment in this product. To risk it to meet the desire of a few users would be penny wise and pound foolish.

    Uwe, chime in if what I have written is incorrect.

  14. Likes jakematic, Eric, PanEuropean liked this post
  15. #10
    Verified VCDS User Spacewalker's Avatar
    Join Date
    Jun 2014
    Location
    Poland
    Posts
    787
    Post Thanks / Like
    I am with both of you guys, stay safe and professional.
    But - more advanced user need more options, basic user can do lot of damage with a simple coding and they will not roll back it if they did not keep genuine autiscan .
    You can add extra access windows and all you do after that is "on your own"
    Like a 2 levels of acces to this same VCDS software.
    Basic one - safe
    Advanced - you know for who.

    Or you can relist BASIC and ADVANCED vcds software.

    Hope you understand.
    HOT HOT HOT VW Touran 2005 with ACC HOT HOT HOT

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •