I assume you're referring to EvoScan, if so you've got a PM.

 

+1.

 

Any news on whether this has been fixed or will be fixed?

 

Not a word. Kinda blows

 

I'm back to 2.1, personally. 2.2 was stillborn for me because of the loss of LC-1 logging functionality, and 2.3 is completely unusable because of the logging jitters. Plus, it's amazing how much bloat has set in; 2.1 worked fine on my win2k tablet with 256MB of memory, but 2.3 is absolutely choking if I have the poor luck of having anything else open at the same time (like, say, ecuflash).

If logging with LogWorks didn't feel like such a hack, I'd be there in a heartbeat. I need to finish writing my own damn logger already.

 

He emailed me back saying that he will get done with V 2.4 asap.

 

Thats becoming the norm lately with tons of software companies. Processor speeds,standard ram and hard drive space just keep getting higher and higher each month so they can spend less money on shrinking their stuff.

 

wow. I only had one report of this problem on my support desk, I didn't realise it was such a big deal. I'll release a new version today.

I spent hundreds of hours in v2.3 to make it faster with multithreading etc. I'm guessing multithreading is actually made everything slightly bloated but it definately makes things more responsive, i.e you can actually controll the interface while its logging now. I may change it so that you have the option of using the multithreading or not.

 

I'm admittedly a corner case, being so memory constrained; I wouldn't complain if I was told point-blank that my application isn't supported (I'm amazed everything I'm using still runs acceptably on Win2k, to be honest). But, there was a very noticeable memory footprint increase from 2.2 to 2.3, and coupled with a weaker processor, behavior is exceedingly jerky. So, 2.1 is probably the version I'll stay on for the foreseeable future, because it has the unique combination of working LC-1 logging and reasonable size.

At some point, I'll probably plunk down for an Eee and add a touchscreen to it, but for now, this does the job.

(Honestly, my workflow probably lends itself better to something else anyway; a small-footprint logging component like Mitsulogger, with a detailed log analyzer/visualizer like DataLogLab, perhaps. Gauges and real-time display aren't something I find very useful except for very rare circumstances; I have real physical gauges and other full-time alerting for that, and a text editor lets me see the numbers just as well as an on-screen display.)

 

How much of an increase in RAM footprint did the multithreading require? Will the option to disable it also decrease the RAM footprint?

 

Yeah I'm gonna make a seperate .exe that has a small footprint for those who don't need the xtra features. that will just do the bear minimum features for logging to csv. and it will use the same settings data.xml so you can set it up in the full evoscan, and run it in the tiny footprint exe for maximum dyno logging performance.

 

the file size is growing because of the 60,000 new lines of code added for Actuators/ABS/AYC/Subaru/GPS/Video/Gauges you name it.. its huge.. If you are a developer and want to contribute to our weekly teamspeak meetings let me know.

 

v2.4 released.

 

downloading now - not available as a direct download - need to replace "3" with "4" in the URL...

 

lol, not much gets past you lot

I am making one more change for v2.4

In v2.1 onwards I changed the AFRMap to match the ecuflash AFRMap values...

in v2.0 AFRMAP = x
LOADCALC = 5*513*((0.256*x)-(-0.1026*[Battery]+1.8741))/[AFRMAP]

in v2.3 AFRMAP = (14.7*128)/x
LOADCALC = 5*513*((0.256*x)-(-0.1026*[Battery]+1.8741))/[AFRMAP]


in EvoScan v2.4 I will leave the AFRMAP as (14.7*128)/x and I'll change the

LoadCalc to match correctly with =5*[InjectorScalingTextBox]*((0.256*x)-(-0.1026*[Battery]+1.8741))/(14.7*128/[AFRMAP]) and I'll add a box to the form for you to easily change the Injector Scaling (cc/min) value.