Equation VE <> VE Table V2

[Bluecat]

Finally took the better part of the weekend and wrapped up the new version of the ve equation program. The only reason that I was able to finish it up so early was because I changed direction. Instead of making the ve table editor built in, I decided to make it a seperate program. I have so many individual programs for every little task on TPI, LT1, and even more odd ball stuff, that I decided I would be better off to make a universal editor to handle all the different formats and tasks. That way all the features would be avalible to me on every pcm. With that mentality I added to ability to view and cut/paste the data, along with a gui to open and save the tab delimited text files for archiving. But you can only cut and paste, no cell editing. The program will link to the other ve editor when I get it done for on the fly ve table manipulation, but there wasn't any reason to keep this program version delayed since most people are just looking for a better way to get the data into the program.

I haven't had a chance to make a new help file, so you guys will be on your own again for a while. The old link in the old thread will stay up incase people have problems with this new setup. So here is a run down of whats new so maybe everyone can figure it out...



1. You can now see both the ve tables and the equation constants from inside the program. From these visible tables you can cut and paste the data between the program, excel, hptuners, ect...

2. Only one VE Table and Equation constants set are kept in memory. If you Generate Equations from a VE Table, it will overwrite the Equation constants that are currently loaded. Same goes for the VE Table, the current one gets overwritten when you tell it to gen a table from the equations.

3. You can either open VE table and Equation data sets from the tab delimited text files or paste them strait in from HP Tuners. Most people will probally use the cut and paste, only using the internal file system for archiving and backups. I included several useful basemaps.

4. The text files now have the dedicated file extensions (.BVE and .BEQ). The internal data format is still about the same as it was with the table.txt and equation.txt. The only real difference is that the cylinder volume entry was moved from the equation to the ve table file, and is only present when the table data is in ve% format.

5. Yet more improvments to the equation generation algorithum for increase speed and accuracy.

6. When you change the ve table format it is dynamic. If your viewing the data is LS2 format and change to LS1 format, it automatically moves and rescales the data so that is relavent. So is the viewing of the data in GMVE or VE%

7. The ve table display has the appropriate histogram table axis setups at the bottom for easy creation of a histogram that matches the format.

8. The constant, map, rpm ect.. fields are oriented vertically inside the program so that they more easily fit on one page. Don't be alarmed, then are still treated horizontally when cut and pasted.

Here's the link, I've got to get back out in the shop or I'm going to get eaten by customers.

http://home.windstream.net/philliphsmith/EQ_VE_2.zip

[c6dude]

Great job on an awesome program Bluecat.
Can't wait to tinker with it tonight

Thanks XX
Perry

[Ben Diss]

This is fantastic. Great work!

[pdsq98gt]

I have vista and it won't open. Am I missing something?

[Bluecat]

Yeah, the old school VB dll's. Search for the filename it bitches about and you should be able to find the whole VB runtime to download. I think someone mentions it in the thread about the first version of the program.

[Jimmyz]

Wow!! Thanks for this Bluecat.

[Harlech]

My hero. Whats the donation link for paypal man?

[LazMan]

THIS is what I was talking about...and exactly the "best" approach! (best being the one that makes it easiest for the programmer)

Kudos!

[naschmitz]

This is some cool stuff. What would I do with my HPTuner without this?

[Bluecat]

Updated the program. (Bug)

I had not had to use it myself since the new version. Then as things normally come is sperts, I had three of these type computers in the past week. Quickly seen that the resloc was non functional, making the data garbage after being pasted into HPtuners with the current decimal point restrictions. Problem was coming from repeated incrementation of a floating point number. Anyways the way the data is stored, eventually you get some drift.

Example:

x = 5

x= x + 1 ' x = 6
x= x + 1 ' x = 7
x= x + 1 ' x = 8
x= x + 1 ' x = 8.999999

Anyway, after thousands upon thousands of + .00001 type increments you get stray crap lurking in the 6th and 7th digits past the decimal. So besides limiting the increment step, I had to add some code to make sure nothing grew past the 5th digit for the resloc option to work properly.

So please download the new version as all previous ones have the flaw. Without the functional resolution lock, the data generated becomes useless garbage after it is pasted into HPT.

Also after see more examples of how the data looks after being truncated by HPT, I think the reason some of the newer stock cals look so funny when you convert them to ve is because the data in the pcm is being truncated when we copy it out. Meaning the 5 digit limitation is HPT imposed and the stock GM numbers in the computer are much more detailed.

[ktoonsez]

Thanks for the update, I was seeing this as well and would just keep re-generating numbers until it worked out to be close. Could this be why I get zeros in some of the columns as well? Maybe that is something else you might have to look at blocking out as well? Sometimes I end up with zeros in 1 to 3 of the columns and if it happens to be in one of the RPM tables it really effects the AFR as you go up in RPM in that particular MAP column. I.E. you start off rich in the bottom area of that Zone and end up Lean by the time you reach the top of the Zone. Also I have found that if you move the scroll button 4 or more click toward "Sigle Cell" with "Automatic Zone Boundaries" OFF the program just hangs forever.

P.S. never heard back from you on combining code.

[Ben Diss]

Thanks for the update.

I'm having trouble matching the output from the gen 1 program to the current ones. I feed both my table and gen a new set of equations using the same settings, but I keep getting different numbers.

Also, I'm still fuzzy on the effect that the "Sigle Cell <--> Zone Edge" slider has? Can elaborate on that please?

[ktoonsez]

Ben

Moving the slider towards the Sigle Cell will will try less hard to smooth the values sitting at the edges of the zone. A good example would be the 3200 RPM range in my LS3. Starting at 3200 the VE table takes an abrupt spike upward, if I don't move the slider towards the Sigle Cell it will try to smooth the values of 3200 to more match 2800 and 3600. Did that make sense? As far as the different numbers go, I think you know that the equations are always defferent everytime you generate them, the thing that is important is that after you gen the equations, re-gen the table and the table still have the same numbers you used to make equations, plus or minus 1-2%.

[Ben Diss]

Ben

Moving the slider towards the Sigle Cell will will try less hard to smooth the values sitting at the edges of the zone. A good example would be the 3200 RPM range in my LS3. Starting at 3200 the VE table takes an abrupt spike upward, if I don't move the slider towards the Sigle Cell it will try to smooth the values of 3200 to more match 2800 and 3600. Did that make sense? As far as the different numbers go, I think you know that the equations are always defferent everytime you generate them, the thing that is important is that after you gen the equations, re-gen the table and the table still have the same numbers you used to make equations, plus or minus 1-2%.

Thanks. I see that now. I'll play with it a bit and find a good setting to use. My table has some abrupt changes too, so understanding this helps a great deal!

[ktoonsez]

Oh yeah, that was a major find for me when I was trying to get the table fine, fine tuned. It will help alot but remember you can't go more than 3 clicks towards sigle on the newer program or the program will freeze with the "auto zone boundaries" OFF which I have to do or it will keep re-numbering my zone RPM's and get everything out of wack again.

[Bluecat]

Send me the ve table and equation file with the rpm boundries your using when it hangs. I tried for a while this morning and couldn't get it to screw up.

On the zeros your getting (a few posts ago), show me an example. Sometimes a zero is what fits best.

And the on the sharing of code, I've just flat out been to busy lately to worry much about this stuff. If I can make it past the lsx shootout I should have all kinds of time this winter to work on stuff like this.

[ktoonsez]

Send me the ve table and equation file with the rpm boundries your using when it hangs. I tried for a while this morning and couldn't get it to screw up.

On the zeros your getting (a few posts ago), show me an example. Sometimes a zero is what fits best.

And the on the sharing of code, I've just flat out been to busy lately to worry much about this stuff. If I can make it past the lsx shootout I should have all kinds of time this winter to work on stuff like this.

No problem at all, I know you're a busy guy. I attached my equation and VE table file (renamed with .txt to upload). Make sure to uncheck "auto zone boundaries", move slider all the way to "sigle cell", and then "gen equations" and it freezes for me. The equation file I attached has quite a few zero's in it, doesn't have them in RMP or RPM2 in this one but has them in all 3 MAP's which probably could cause the same heart-ache just on the horizontal plane (MAP) instead of the vertical (RPM). Like I said the thing that hurt me the most is when they show up in the RMP2 or RPM.

[Bluecat]

I'm still at a loss. Ran with your numbers and the slider all the way to single cell, still no freeze. Tried it from both the compiled version and from inside the VB runtime. Here is what it generates.

http://home.windstream.net/philliphsmith/ktoonsez.BEQ

I also ran it with auto boundries on to see where the auto was screwing you up. Did what I expected it to do. Your ve table is pretty smooth, Should look right with the boundries about anywhere. The only place it really has to have one at is 3200 where you have a pointy dip, which the auto algorithum picked up and placed one at 3200. Does your VE really go down hill between 2800 and 3200? You see stuff like that on big cam car, but it is usually at a lower rpm and just looks different. Here's what it generated, looks to match just as well using the default settings.

http://home.windstream.net/philliphsmith/ktoonsez_2.BEQ

And on the zeros, thats just what it comes up with. Nothing going on wrong. Both the zeros in the eq file you sent and the ones in the files I generated are legit, it's not droping anything.

So I don't know why your freezing. Maybe a os issue. All this is done on a ME machine. But I run XP on my laptop and don't have a problem. I'll have to try your files and the slider check box settings on my laptop and see if it hangs.

[ktoonsez]

1. Yes, I do have a medium cam with some overlap and it likes that 2800-3200 dip for some reason.
2. The zeros: What I was suggesting is that maybe it shouldn't allow zeros so that part of the calculation doesn't get nulled so to speak (have no weight on the equation). It was just an observation I had while tuning, a few times I guess the zeros got in the right place, I think for the 1200-2400 range, and 1200 was running very rich and by the time I got to 2400 in that same MAP it was well into the lean percentage. The zero thing was just what happened to come to mind as I was analazying the data and as you saw my table is nice and smooth and is pretty darn accurate, just had that trouble 3 or 4 times, did a re-gen of the equations till I got the zero count down some and the problem went away. Could have been all in my head as I get very little sleep here and there too.
3. The freeze: That is so wierd, I just tested on a few more of my PC's, this freeze happens on a 64 bit Vista, 32 bit vista, XP service pack 2, XP service pack 3.

Maybe someone else out there that reads this can try my files from post #17 and see if they lock up (the programs window says "Not Responding" after a few seconds after starting the "gen equations"). I did let it go for about 5 minutes one time just to see if it was just really busy and couldn't respond to screen updates but it never came back alive.

[Bluecat]

Ah, if it stops for more then a 10-15 seconds its dead. There are several loops that keep repeating until a certain condition is met and could hang if it never gets there, but they all have max pass counters to prevent infinte loops.

Does it ever make it to "zone x" in the status text box? If it never makes it to were it says its working on a zone, there isn't a whole lot it could be hanging up on. Not but about a page worth of code, and its most just reading in form objects status (sliders and check boxes) and zeroing out arrays. But I really need to see it hang up in the design enviroment to see what line of code its hung on. You do for sure have the newest version?

I can force it to not allow zeros, but I'm not sure what it will acomplish. If a zero in a particular field makes the best zone match, it is what it is so to speak. I agree that your ve table is smooth and sexy looking, you've definatly gave it some love. But the equation map is right on top of it. I don't see any major gaps between it and the ve. If the equation numbers need to be different, it because the ve numbers it was built from need to be different. Unless we are still fighting a problem where the numbers are getting fubared by HPT. Copy the data into hpt and back into my program to check that its staying intact and still matches the original ve table. There may be another problem other than the decimal precision.

And I'm not sure about the re-gen everytime. This whole sceme is very complicated and one little change to anything will snow ball and make the whole results different. But there is no magic or random ness to it. If the ve table and all the program settings are the same, it should generate the exact same equation constants everytime.