I am having problem with evoscan too, I can log, but logs seems odd, I don't get enought rpm foot prints.

I hope Mitsulogger will work for me, so I don't have to deal with evoscan anymore.

 

hey MJ i tried the bug fix version and got the same error. when i press continue and try to reconnect it is gives an error with the cable. when i press redetect and try to start the logger again it says failure to open device. i then have to unplug the cable from the laptop and plug it back in. when i try redetect and then start logger the initial error comes back.

 

Thanks for the update, I was going to try it this afternoon when I go out, I guess I don't have to now.

did you get the same error msg like the one I posted above?

 

this the error i got:

See the end of this message for details on invoking
just-in-time (JIT) debugging instead of this dialog box.

************** Exception Text **************
System.InvalidCastException: Conversion from string "&h" to type 'Double' is not valid. ---> System.FormatException: Input string was not in a correct format.
at Microsoft.VisualBasic.CompilerServices.Conversions .ParseDouble(String Value, NumberFormatInfo NumberFormat)
at Microsoft.VisualBasic.CompilerServices.Conversions .ToDouble(String Value, NumberFormatInfo NumberFormat)
--- End of inner exception stack trace ---
at Microsoft.VisualBasic.CompilerServices.Conversions .ToDouble(String Value, NumberFormatInfo NumberFormat)
at Microsoft.VisualBasic.Conversion.Int(Object Number)
at MitsuLogger.Mitsulogger.LogMUT()
at MitsuLogger.Mitsulogger.StartLogger()
at MitsuLogger.Mitsulogger.Button1_Click(Object sender, EventArgs e)
at System.Windows.Forms.Control.OnClick(EventArgs e)
at System.Windows.Forms.Button.OnMouseUp(MouseEventAr gs mevent)
at System.Windows.Forms.Control.WmMouseUp(Message& m, MouseButtons button, Int32 clicks)
at System.Windows.Forms.Control.WndProc(Message& m)
at System.Windows.Forms.ButtonBase.WndProc(Message& m)
at System.Windows.Forms.Button.WndProc(Message& m)
at System.Windows.Forms.Control.ControlNativeWindow.W ndProc(Message& m)
at System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)


************** Loaded Assemblies **************
mscorlib
Assembly Version: 2.0.0.0
Win32 Version: 2.0.50727.3074 (QFE.050727-3000)
CodeBase: file:///C:/Windows/Microsoft.NET/Framework64/v2.0.50727/mscorlib.dll
----------------------------------------
MitsuLogger
Assembly Version: 2.0.3438.36509
Win32 Version: 2.0.3438.36509
CodeBase: file:///C:/Users/Dell1/Desktop/Mitsulogger%202.0%20Release/MitsuLogger.exe
----------------------------------------
System.Windows.Forms
Assembly Version: 2.0.0.0
Win32 Version: 2.0.50727.3053 (netfxsp.050727-3000)
CodeBase: file:///C:/Windows/assembly/GAC_MSIL/System.Windows.Forms/2.0.0.0__b77a5c561934e089/System.Windows.Forms.dll
----------------------------------------
System
Assembly Version: 2.0.0.0
Win32 Version: 2.0.50727.3053 (netfxsp.050727-3000)
CodeBase: file:///C:/Windows/assembly/GAC_MSIL/System/2.0.0.0__b77a5c561934e089/System.dll
----------------------------------------
System.Drawing
Assembly Version: 2.0.0.0
Win32 Version: 2.0.50727.3053 (netfxsp.050727-3000)
CodeBase: file:///C:/Windows/assembly/GAC_MSIL/System.Drawing/2.0.0.0__b03f5f7f11d50a3a/System.Drawing.dll
----------------------------------------
Microsoft.VisualBasic
Assembly Version: 8.0.0.0
Win32 Version: 8.0.50727.3053 (netfxsp.050727-3000)
CodeBase: file:///C:/Windows/assembly/GAC_MSIL/Microsoft.VisualBasic/8.0.0.0__b03f5f7f11d50a3a/Microsoft.VisualBasic.dll
----------------------------------------
UtecTunerLogger
Assembly Version: 1.5.0.0
Win32 Version: 1.5.0.0
CodeBase: file:///C:/Users/Dell1/Desktop/Mitsulogger%202.0%20Release/UtecTunerLogger.EXE
----------------------------------------
ZeitronixZT2Logger
Assembly Version: 1.5.0.0
Win32 Version: 1.5.0.0
CodeBase: file:///C:/Users/Dell1/Desktop/Mitsulogger%202.0%20Release/ZeitronixZT2Logger.EXE
----------------------------------------
AEMLogger
Assembly Version: 1.6.0.0
Win32 Version: 1.6.0.0
CodeBase: file:///C:/Users/Dell1/Desktop/Mitsulogger%202.0%20Release/AEMLogger.EXE
----------------------------------------
System.Configuration
Assembly Version: 2.0.0.0
Win32 Version: 2.0.50727.3053 (netfxsp.050727-3000)
CodeBase: file:///C:/Windows/assembly/GAC_MSIL/System.Configuration/2.0.0.0__b03f5f7f11d50a3a/System.Configuration.dll
----------------------------------------
System.Xml
Assembly Version: 2.0.0.0
Win32 Version: 2.0.50727.3074 (QFE.050727-3000)
CodeBase: file:///C:/Windows/assembly/GAC_MSIL/System.Xml/2.0.0.0__b77a5c561934e089/System.Xml.dll
----------------------------------------

************** JIT Debugging **************
To enable just-in-time (JIT) debugging, the .config file for this
application or computer (machine.config) must have the
jitDebugging value set in the system.windows.forms section.
The application must also be compiled with debugging
enabled.

For example:

<configuration>
<system.windows.forms jitDebugging="true" />
</configuration>

When JIT debugging is enabled, any unhandled exception
will be sent to the JIT debugger registered on the computer
rather than be handled by this dialog box.

 

it's the same error!

 

by the way MJ the aem logger works, even though the error comes up the aem logger still streams data.

 

well, I'm not sure why you guys are getting this error, the code you guys are having an issue with has been the same for 5 years. But make sure you guys get the most current version that is available.

The big problem is the only feedback I ever get is when things don't work. So I have no information on what it does work with.

The only thing I know for certain is I've run the application on about a dozen computers and can not reproduce the error. The best I can do is to set up a little better error checking on the areas that are prone to throwing errors.

What you are describing is what happens when the cable returns absolutely no data and it tries to convert a non numeric value (the blank)

 

the wideband modules are basically unchanged from earlier versions, so I'm glad to know that its working. I just cannot figure out why the application works fine for me on numerous machines (Including a 64 bit Vista Home desktop, that I have never tested on before) and is giving 3 people problems, and I cannot be certain if its working at all because nobody else has posted that it works fine for them.

 

Please be more specific on what do you mean by the most current version that is available?

We are telling you the logger doesn't work, and we copy and paste the error detail we saw on the computer screen to show you, this is all we can do, we are not programmer, what other info do you need?

 

My point is there have been over 50 copies downloaded, and I cannot reproduce the issue, and need to figure out what you guys have in common compared to others, assuming it works at all.

I will fix the errors that cause the application to crash like the debug messages you sent over, but that doesn't mean the logging is going to work properly for you, and my goal is to figure out what is actually going on, I have gone out to my car, with 6 different laptops with different OS's, and it just works.. I have connected my ECU bench harness to several different machines, including my wife's laptop running windows 7, and her Lenovo Desktop which runs Vista Home Premium, and a brand new Lenovo Laptop from work with Vista Home 64 bit (before they re-image it to XP)

You'll have to periodically check the Aktivematrix thread to see if there is a new beta posted with additional fixes, as the only way to fix it will be getting copies out to you guys to test that are having problems.

 

Okay, so the V2.0 works for your Lenovo w/ Vista home edtion 64 bit, but it doesn't work for us. Does it matter what service pack was installed?

And, does the debug message give you any clue?

 

why can't I see Mitsulogger under the program files directory? how come I don't see Mitsulogger in add/remove programs directory? maybe this has to do why the logger doesn't work.

 

The program isn't INSTALLED, its just compressed, there is no need to "add/remove" because just deleting the directory perminently removes it. There is no installer.

Now, I've made some headway with the error, for whatever reason, data being returned from your cable is not framed properly, and is padded with non numeric data (space, null or whatnot) I wasn't watching for unexpected data like that and it would throw an error whenever it experienced it. It has never happened in the past and never required trapping the error before. I also reformatted the conversion a little better so it will just assume the value is zero instead of bad data, so it should never get to the point of trapping an error, but if it does, it just handles it and places the error into the message log window (bottom status window)

This does not address in any way your logging problem though, as I have not been able to reproduce the error (other than forcing it to happen by breaking the code)

However if there is just bad data in the buffer, then it should allow the program to continue on until it can clear it out without crashing.

Here's what I've discovered in the process of troubleshooting this..

1) The Openport 1.3 drivers are not signed, some versions of Vista 64 bit will "disable" a driver that is not signed. The one thing all of my machines have in common is I changed this behavior, or bypass signing restrictions on boot. Now, honestly, I installed the driver, and rebooted several times, and moved the cable around to different ports, and ultimately it still worked for me, but if Vista x64 (non Ultimate versions) decides to handle driver signing issues differently, then it may be the reason for the problem.

2) The only time I was able to generate any sort of timeout or bad data error, was to shut off my bench harness and ECU in the middle of logging (interrupting its communication) I was able to generate a similar error on one occasion by doing that.

Okay so what does this ultimately mean? Well, I have handled how Mitsulogger handles bad data better, but I suspect your problem has nothing to do with the logger, and is perhaps the driver or some other configuration setting.

Hopefully this version of mitsulogger will tolerate bad data a bit better and get "past" the issue and logging will be normal after the few bad bytes.

I would recommend downloading the new version regardless, but the key bit of information I was getting from you throughout all of this was Evoscan also has a problem logging, if thats the case, then its unlikely the logging software, but it could be driver related, or even a bad cable (assuming you have already used this cable on other cars, or it worked perfectly fine on another operating system)

Troubleshooting anything other than a problem with mitsulogger is a bit outside the scope of what I have the time to help with, but I'll try to help you work through it.


Mitsulogger is contained within a zip archive, the Mitsulogger folder inside of the archive has 9 files, the entire folder can be dragged and dropped onto your desktop and it will just work (assuming there's a proper FTDI/Openport cable driver installed)

It works in Windows 7 64 bit (as does ECUFlash)

I also have to really emphasize that Mitsulogger was designed as a tuner tool, no frills and not really intended for those who aren't fairly computer Savvy. But I wrote the tool for myself, It may frustrate some people who have problems, but its such a simple application, with very few dependencies, that its rare that it just "won't work" if ECU flash and Openport drivers are installed and working properly.

 

The debug message helped alot, the string shown only occurs in a few places in the code and made it easy to find (I originally fixed the most likely one, but I gambled wrong so I fixed all of them)

The lenovo I borrowed was a fresh booted machine, it had all current updates and everything that WIndows Update offered to it over the past 2 days.. However I don't recall if it had a service pack on it.

The machine I develop and the others I regular test with run the gamut of patches and service packs, and they all worked fine when tested, so I'm fairly confident that the application doesn't care about anything but having a proper driver installed, and .NET 2.0 (newer versions of .NET 3.0 and 3.5, "Should" have 2.0 as part of it, but it can be installed seperately if necessary)

I really don't understand what the issue is other than "garbage data" in the buffer, so hopefully the app will handle that garbage more gracefully and get past it.

 

My cable works fine with evoscan in window XP, not the vista 64 bit.

I will d/l the bug fix 2 and report back, thanks for the detail explaination.