Does highspeed datalogging work correctly for you. The RoadDyno and highspeed datalogging share the same data capture code.

Also, does the Cancel/Stop button end the dyno run? It should terminate the run and return you to the main screen, regardless of the state of the run.

d

 

Yes, i did a couple high-speed logs. no problems. i also imported the high-speed logs into the run viewer (import, not load. load does not work with highspeed datalogs, is this by design?), no problem.

it was only when i ran a dyno run. and no, the cancel button doesnt work after the run, because as i said, the window is basically dead at that point. pushing the cancel button either does nothing or gives you a 'program not responding'.

it seems to be a problem in the transition between data capture completing, and the results being loaded into the viewer.

 

also, couple new bugs for you.

first is attached. errors when running SavGol on a dyno run.

Second, when choosing 'gnuplot' from the analysis menu, the status window just says 'the system cannot find the file specified'. i made sure pyxede has the path to gnuplot and everything...

 

That good to hear.

Ok thanks. I can't say I'm surprised as that's the the most complicated part of the program from a logic point of view. There's a lot of stuff going on concurrently; collecting data, updating the the data view, updating the dyno plot, watching for rpm threshold, watching for user intervention.

Does this problem always happen, or just sporadically?

d

 

These aren't so much bugs, as things that simply don't work yet.

SavGol us unusally tricky because it's not written in python like the rest of the program. Instead it's written in C and I use an automated wrapper generator to create python bindings. This is super-slick because it doesn't require hardly any work on my part to make them work together, and the smoothing function is blindingly fast as it executes in native machine code. However, I don't have access to windows to actually build the bindings. User's can do it themselves, but it requires advanced knowledge about program construction techniques and, honestly, I don't really know how to do it on windows.

Gnuplot configuration should work, but I haven't really tried it yet. You can set the command location manually by editing pyxede.cfg. It's just a regular text file so it should self explanatory.

thanks for the feedback. this is what makes program improve.

d

 

I ran two dyno's, both using different RPM ranges, and both froze.


by the way, is this forum ok for bug reports and stuff? is there another way you would like them submitted or anything?

 

ok, fixed that. i threw gnuplot inside the pyxede directory, so inside pyxede.cgf i changed the path from '..\gnuplot' to '.\gnuplot' might want to be more specific about where to extract gnuplot in relation to pyxede in your instructions.

by the way, gnuplot looks like it works pretty good for analysis. in the future can you send timing, AFR, Knock over to gnuplot as well? right now we can send the 'dyno run' over to gnuplot by selecting it. it would be cool if that 'plot with gnuplot' prompt has the ability to add the other vairables to your plot also.

great job though, pyXede is really coming along!!!

 

Well having any instructions how how to set up gnuplot would be a step in the right direction. I haven't really used gnuplot much lately, so support for it has fallen to the wayside. As you can see it needs to be tidied up and some good docs written. Want to be the documentation manager?

Haha. Before I know it, I'm going to farm out all the work.

Yeah, sure. It's not hard, it just takes time. The reason I've moved away from gnuplot is that it takes quite a bit of effort to make sure it works the way you want it to on all platforms since it's a completely seperate application and works slightly differently on each OS. You also can't do realtime plotting with gnuplot. It may surprise people to hear, but line for line, _most_ of the code for version 1.5 goes just to draw the plots to the screen. To get the performance I wanted I had to forego any kind of prebuilt plotting routines and do all the drawing by hand. That's right, I figure out how many axes I need, how big they are, what the labels should be, and where they should be located (pixelwise) on the screen. Then I do the same thing for the actual data. Then I scale it. At this point I think I'm getting better performance than even the best python scientific plotting libraries like SciPy and matplotlib.

A little dirty secret is that windows is at _least_ 2x slower than other platforms because of some stupid issue with the way that windows redraws the screen. For a long time, the software was completely unusable on windows. That's why there was such a lag between 1.0 and 1.5. If anybody wants to try it on X11 (linux, unix, etc), they'll find it to be very, very fast on screen draws. I use it on my very slow mac laptop, so the default screen update/refresh rate is like 0.5 seconds (2hz). On even a modest linux PC, I had no problems refreshing at 100hz. That's faster than the monitor itself refreshes -- faster than the Xede is sampling even.

Thanks for the encouragement.

Forums bug reports are fine with me. Although email always gets a priority bump and faster response (especially after my classes start in two weeks).

d

 

can we get readings if we have a non-smart xede? mainly actual timing readouts.

 

on a side note, a "how-to" from start to finish would be GREAT for us programming/computer challenged folks.

 

That's an understatement. I hate being a Neanderthal! I'm doing good to stay online...

 

Absolutely. If there's no smart hardware connected, it'll just have boring flatlines for everything related to AN0/1. Actually you don't even have to have an evo really -- just an Xede. Therefore V2 users should be fine as well. You can still do dyno runs, log timing, yadda yadda yadda.

If someone wants to create better documentation, then by all means go for it. My project is publicly hosted and anybody that wants to can contribute. I don't really have much modivation to write "here's how you get started installing a program" documents, but actually API documention is quite good. If somebody wants to take my Xede communication library and use it in another program, it'd be a snap.

More generally, I'm apt to choose function before form for things I build. I like to do really neat and wacky things. If they end up being insanely technical, so be it. I guess I think it's better to make the user smarter than the program dumb-er-er.

d

 

Well, please, someone else write a how-to on this stuff.....

Mainly, what to download, from where(everything needed and where to get it).

Your fellow evo owners would greatly appreciate it.

 

Did you go to the website? There _are_ windows install instructions there. If you read the WHOLE page you'll find a link to:

http://pyxede.sourceforge.net/windows_install.html

d

 

oh, you have basically what i was looking for on your site. I overlooked it...the "windows Instructions"

Thanks