EvoScan J2534 Read Error - 16
Jun 10, 2014, 10:57 PM
#76
Evolved Member
iTrader: (10)
Join Date: Mar 2013
Location: Chicago
Posts: 890
Likes: 0
Received 0 Likes
on
0 Posts
The driver itself isn't the issue. It's the firmware upgrade that the 2.0 uses now. He explained it 4-5 posts back and explained it doesn't matter what version of ecuflash you're using. Why are you still talking? If you open your c: drive you will notice that evoscan and ecuflash have their own driver packs for both devices. I don't know how to make this any more clear to you. I'm sorry.
Jun 10, 2014, 11:01 PM
#77
Evolved Member
iTrader: (10)
Join Date: Mar 2013
Location: Chicago
Posts: 890
Likes: 0
Received 0 Likes
on
0 Posts
Here ill tell you what, since you do this for a living apparently then for your theory to be correct then all you should have to do is copy the driver from your openecu folder and paste it into the evoscan driver folder. Why don't you go ahead and do that and let us know how that works out for you 
Jun 10, 2014, 11:11 PM
#78
Did you read what I wrote? Here I bolded the key part for you:
I read what he wrote. I was explaining to you that had the hypothesis been correct based on the results that is how you fix it. Also it is clear from your last statement that you have no idea on how pathing and drivers work. Depending on how the program has been setup to use the drivers if you switch those it may work, it may not it all depends on how the link between the two has been done. In fact here's a fun exercise for you delete the local version of that dll from that directory and go and put that same driver under driverstore or system32 in windows and depending on how that linking has been done the program loads just fine. Why? Because if you ask for a driver from the system there is a specific ordering of paths it goes through to pull the correct driver or library if you put the driver/library with the correct name and version (once again depending on how it has been setup to be called) in any higher priority path it actually can and will load that driver/library regardless of where the correct driver/library is.
This is a common problem that occurs with programs with shared libraries. Like I said based on what Hamish said above this is not the particular problem but for you to sweep it away without understanding how it could have been the problem is interesting to say the least.
Actually had that been the issue that is exactly how you solve the problem. You would adjust the program itself to be able to handle differing versions of the driver and even now knowing what the problem a correct fix is still going to need to be able to work with those differing versions so you don't only have it work with the newer version. But you're right I just talk about this stuff on the internet I don't do it for a living or anything.
This is a common problem that occurs with programs with shared libraries. Like I said based on what Hamish said above this is not the particular problem but for you to sweep it away without understanding how it could have been the problem is interesting to say the least.
Last edited by codgi; Jun 10, 2014 at 11:48 PM.
Jun 11, 2014, 12:04 AM
#79
Evolved Member
iTrader: (10)
Join Date: Mar 2013
Location: Chicago
Posts: 890
Likes: 0
Received 0 Likes
on
0 Posts
Evoscan doesn't recognize the 2.0's new firmware. The driver and location is irrelevant at this point as you SAID YOURSELF THAT'S NOT THE PROBLEM, that's why I told you to swap the drivers from the different programs, although it would have locked up your pc if you tried to do that so I was kinda hoping you would try that. He said it himself that an older version wouldn't make a difference because when you plug in the 2.0 it automatically connects the device to that new firmware. If you know so much about computers and you're such an expert then why don't you stop trolling on here and go fix the problem with evoscan and the 2.0's firmware update Bill Gates.
Last edited by jrainwater; Jun 11, 2014 at 12:08 AM.
Jun 11, 2014, 02:50 PM
#80
Evolving Member
Join Date: Sep 2012
Location: Ottawa, Ontario, Canada
Posts: 181
Likes: 0
Received 0 Likes
on
0 Posts
This has been a problem for more than a year...and is only 'allegedly' getting fixed now.
I'm sorry, but again, I'll believe it when I see it. There's no excuse for leaving this issue this long on COMMERCIAL software.
I'm sorry, but again, I'll believe it when I see it. There's no excuse for leaving this issue this long on COMMERCIAL software.
Last edited by Broke4speed; Jun 11, 2014 at 02:53 PM.
Jun 15, 2014, 02:03 PM
#81
Alright, after working on this all weekend day and night. it finally turned out that yes indeed the error message means error 16 (ERR_TIME_OUT no response from vehicle). This problem was also effecting OBDII communications with openport 2.0. so now you will be able to also do some OBDII logging with Openport 2.0 and EvoScan v2.9.0090 for ALL 1996-2006 OBDII vehicles.
Last edited by evoscan; Jun 16, 2014 at 12:58 PM.
Jun 15, 2014, 07:25 PM
#83
Newbie
iTrader: (3)
Join Date: Dec 2005
Location: Seattle, WA
Posts: 87
Likes: 0
Received 0 Likes
on
0 Posts
Could you send me some specific details of what response is being eaten in response to what request on what ECU so I can check it out and fix it?
Colby
Colby
Alright, after working on this all weekend day and night. it finally turned out that yes indeed the error message means error 16 (ERR_TIME_OUT no response from vehicle). The OpenPort 2.0 is eating some response data that the dtc spec needs, but I have added a work around for the openport2 and just feed some dummy data to the dtc program after initialization. This problem was also effecting OBDII communications with openport 2.0. so now you will be able to also do some OBDII logging with Openport 2.0 and EvoScan v2.9.0090 for ALL 1996-2006 OBDII vehicles. This problem does not effect 1.3D 1.3R 1.3U cables they are returning all data correctly.
Jun 16, 2014, 05:25 AM
#84
@Colby, yeah sure thing mate, I had to look really hard to find the differences between 1.3U and op2.0 cable on this because the signals were both the same down to the microsecond between them amazingly.
oh I just had a thought, I wonder if the op2 firmware needs to allow for all the trailing edge zeros if using bit bang for slow_init sequences. that could explain why init returns no keywords, and 2 extra bytes are left on the queue.
EvoScan v2.9.0090 now works great, and relies on the firmware the way it is now.. haha. as confusing as that sounds. which is fine.. as long as it works really
I will email you the details.
Cheers,
Hamish.
oh I just had a thought, I wonder if the op2 firmware needs to allow for all the trailing edge zeros if using bit bang for slow_init sequences. that could explain why init returns no keywords, and 2 extra bytes are left on the queue.
EvoScan v2.9.0090 now works great, and relies on the firmware the way it is now.. haha. as confusing as that sounds. which is fine.. as long as it works really
I will email you the details.
Cheers,
Hamish.
Last edited by evoscan; Jun 16, 2014 at 01:01 PM.
Jun 16, 2014, 08:06 AM
#85
Evolved Member
iTrader: (10)
Join Date: Mar 2013
Location: Chicago
Posts: 890
Likes: 0
Received 0 Likes
on
0 Posts
Is Colby, the Colby from Tactrix? If so, thanks for the warranty replacement and your buddy Mike is a really really great guy. But you probably know that already
Jun 16, 2014, 08:08 AM
#86
Evolved Member
iTrader: (10)
Join Date: Mar 2013
Location: Chicago
Posts: 890
Likes: 0
Received 0 Likes
on
0 Posts
This is great. Everyone working together to make this happen finally!!! Woo hoo lol
@Broke4speed, keep the faith man!! We have Colby AND Hamish working on this now
Good things are coming.
@Broke4speed, keep the faith man!! We have Colby AND Hamish working on this now
Good things are coming.
Jun 21, 2014, 12:18 PM
#89
Evolving Member
excuse me for having to ask, but I can't find v2.9.0090 to download off your website. v2.9.0023 is the latest I'm finding, from July 2013.
http://www.evoscan.com/evoscan-updates
Thanks