EvoScan v0.97 supports for Innovate LC-1 / TurboXS / PLX
Oct 12, 2006, 05:53 PM
#137
Originally Posted by MalibuJack
You can wait for a software fix (from Evoscan) or you can get a different USB/Serial cable that doesnt also use an FTDI chip.
Its actually something that Evo4Mad can fix in his code, it has to do with how the com ports are reset and he can make a change to avoid resetting/conflicting with the Openport cable.
Its actually something that Evo4Mad can fix in his code, it has to do with how the com ports are reset and he can make a change to avoid resetting/conflicting with the Openport cable.
I am using multiple EvoScans with multiple FTDI cables, and none of them reset each other...
Last edited by evo4mad; Oct 12, 2006 at 05:57 PM.
Oct 12, 2006, 07:56 PM
#139
Originally Posted by evo4mad
Thats strange because Colbys cable doesn't use com ports, so how would it reset? it uses a direct usb driver. What driver setting are you talking about that gets reset? Is there some specific part of the ftdi driver code you can point me at?
I am using multiple EvoScans with multiple FTDI cables, and none of them reset each other...
I am using multiple EvoScans with multiple FTDI cables, and none of them reset each other...
Windows basically resets the com ports when you initialize a port. I have seen this on many of the ports. Anyway, what happens is all of the signal lines "glitch" and since the 12v/ground circuit for triggering reflash is switched through one of the signal lines, if the port is reset, it could trigger the ECU's bootstrap
This doesn't always happen, but I have spotted a few people describe this happening on rare occasions. And it definitely seems to have something to do with the order of the ports and the drivers. If disconnecting the white molex cable solves the problem, then that is what is happening.
I am assuming that you are enumerating the hardware for the Tactrix Cable, and of course identifying it as the right cable, which of course, means it will correctly identify the cable. But VB is notorious for resetting ports when you use the RS232 specific code.
I'm not really sure exactly how to fix it, but on my program, I used lower level RS232 calls instead of using the MSCOMM control, or the .NET RS232 assemblies.
HOWEVER, when I switched to the newer .NET 2.0, I found the ports don't reset when you open one port, you only fiddle with that one. Stay away from the MSComm ActiveX control though if your using it.
Oct 12, 2006, 08:00 PM
#140
I'm sorry about the confusing answer.. When I read it I realized I never distinguished why it happens when the the tactrix driver doesnt use an actual comm port..
But its because the driver is shared with an FTDI serial device, and if the driver goes through and does a port reset globally, it will enumerate through all of the instances and reset all of them, I think the VCP driver does this numerically, so if the device shows up as a higher order than the com port, it may not hit it, and therefore may not reset it.
But its because the driver is shared with an FTDI serial device, and if the driver goes through and does a port reset globally, it will enumerate through all of the instances and reset all of them, I think the VCP driver does this numerically, so if the device shows up as a higher order than the com port, it may not hit it, and therefore may not reset it.
Oct 12, 2006, 08:43 PM
#141
Evolved Member
iTrader: (17)
Join Date: Aug 2004
Location: In da streetz
Posts: 3,275
Likes: 0
Received 0 Likes
on
0 Posts
I was able to get my LM-1 to log along with EVOScan. I purchased a new USB-serial cable and unplugged the white connector as suggested by MailbuJack 
is there anyway to add the GM 3bar MAP sensor I'm logging threw my RPM converter (LMA-2) into EVO scan??
is there anyway to add the GM 3bar MAP sensor I'm logging threw my RPM converter (LMA-2) into EVO scan??
Oct 12, 2006, 11:30 PM
#142
Hi MJ, yeah nobody I know would ever use the MSComm library lol. I'm using low level kernel32 dll calls for efficiency and speed, as you can see from the EvoScan logging speed I got it down pact. And initilising with DCB and CreateFile commands, these are very specific routines and specify the exact com port. If there are any compatability problems, it will be the low budget third party device drivers. 
And the FTDI device is directly opened using FT_OpenByDescription and a direct FT_ResetDevice call which is standard practise. So I don't think its very fair to say that EvoScan needs fixing.
Try and make sure the openport usb plug is the first usb cable plugged in, this may make a difference.
And the FTDI device is directly opened using FT_OpenByDescription and a direct FT_ResetDevice call which is standard practise. So I don't think its very fair to say that EvoScan needs fixing.Try and make sure the openport usb plug is the first usb cable plugged in, this may make a difference.
Originally Posted by MalibuJack
You can wait for a software fix (from Evoscan) or you can get a different USB/Serial cable that doesnt also use an FTDI chip.
Its actually something that Evo4Mad can fix in his code, it has to do with how the com ports are reset and he can make a change to avoid resetting/conflicting with the Openport cable.
I'm sorry about the confusing answer.. When I read it I realized I never distinguished why it happens when the the tactrix driver doesnt use an actual comm port.
But its because the driver is shared with an FTDI serial device, and if the driver goes through and does a port reset globally, it will enumerate through all of the instances and reset all of them, I think the VCP driver does this numerically, so if the device shows up as a higher order than the com port, it may not hit it, and therefore may not reset it.
Its actually something that Evo4Mad can fix in his code, it has to do with how the com ports are reset and he can make a change to avoid resetting/conflicting with the Openport cable.
I'm sorry about the confusing answer.. When I read it I realized I never distinguished why it happens when the the tactrix driver doesnt use an actual comm port.
But its because the driver is shared with an FTDI serial device, and if the driver goes through and does a port reset globally, it will enumerate through all of the instances and reset all of them, I think the VCP driver does this numerically, so if the device shows up as a higher order than the com port, it may not hit it, and therefore may not reset it.
Last edited by evo4mad; Oct 12, 2006 at 11:51 PM.
Thread
Thread Starter
Forum
Replies
Last Post
mrfred
ECU Flash
496
Sep 14, 2022 07:08 PM
