@NJG876: Hi.
Hmm....... maybe another opinion might be of value in your considerations?
There is absolutely no doubt that OBD11 is a very powerful tool and in IMO it's better than VCDS in some respects (albeit both have their advantages and deficiencies).
One of the differentiators between the 2 x diagnostic devices is One Click Apps (OCAs) - which are marketed particularly to those users that want a quick and easy method to make coding changes. This market sector is entirely ignored by VCDS - which is sold as the device of choice for more serious users (not sure that this marketing is correct!)
Anyhow, OCAs do have a legitimate value and they are used by many OBD11 owners! Incidentally, there is NO need to buy a PRO license, or pay an annual subscription fee if you ONLY want to use OCAs and it's a good way to avoid the additional cost until a user is more familiar with the device.
However, many (ALL?) new OBD11 users blissfully buy OCAs without understanding their dangers!!. Don't get me wrong, I'm NOT saying that OCAs are bad - I'm simply suggesting that before going down the OCA route, a OBD11 user needs to make an informed risk-based decision.
So, there has been lots of discussion about the many advantages of OCAs - but not much has been said about the risks . Fact is that there are basically two problems that OBD11 users should be aware-of when using OCAs:
First: When the code-cutters on the OBD11 mother-ship write the programs for OCAs, they make certain assumptions about the current way the the modules are coded in the car. To a degree, these assumptions can be tested by sub-routines in the OCA before actual coding changes are made. If these tests fail, the OCA doesn't implement a coding change and a confirming message of this outcome is displayed on the screen. However, it's not possible to test every scenario and only the obvious pre-condition tests are used.
As a frequent example of this problem - consider a user that has successfully implemented a OCA (let's call this the "original OCA") but later decides to "undo" the change. In the intervening period, this user has implemented other OCAs - some of which have affected the coding changes in the "original OCA". When the users applies the "undo" facility in the original OCA, the coding change that reverts to the original settings upsets the subsequent OCAs and an error results!!This is a common scenario because OCA users generally tend to use lots of OCAs!
Second: One of the fundamental facilities in a good diagnostic device is the History function. This is the facility in OBD11 that records details of all the changes that a user makes. It's a very valuable facility for experienced users - but it's even more precious for new-bees - because it allows users to revert coding changes back to their original values (because the History record contains the value of the original factory setting which is otherwise lost)! Alas OCAs do NOT leave any records of the coding changes that they make in the History facility!
I'm not sure what percentage of OBD11 users successfully implement OCAs without ever encountering these problem - but both of the cases above happen with regular repetition and there are lots of bewildered/anxious users on the OBD11 forum as examples. In some instances, fellow forum members are able to make useful suggestions to fix the problem - but often, the only recourse is to seek advice from the OBD11 mother-ship (particularly when the "Second" case is the cause).
Again, I'm NOT advocating that OCAs are bad, I just want to stress that OCAs ain't all upside - they do have their risks!
So, my suggestion: use OCAs sparingly and understand the risks - a far better approach IMO is for new-bees to learn manual coding as quickly as possible (take early control of your new diagnostic device - it WILL pay dividends!!
Don
Bookmarks