MPTuner

[wowzer]

hmm - the disassembler is kinda the poor bastard child of the program. i used it years ago to work with the 89 t1 smec stuff and that's about it. if there is enough interest i 'll put some effort into making it more "worthy". can ya send me the cal (or a link) so i can see what it's trying to do/not do. then i can offer some advice and maybe get some direction from you all on what you would like to see.

[Aries_Turbo]

here was the cal i was trying to disassemble and then reassemble so i had a good complete table file but with the stock memory locations.

http://www.turbo-mopar.com/forums/at...0&d=1223690263

thanks

Brian

PS. morris, you RULE. when i find something with the program that doesnt quite work or whatever, i get a little discouraged but then i make a request and you always seem so eager to make the program better that it erases my discouragement immediately. thanks again for your hard work.

[Aries_Turbo]

another small issue.

with LM data, the FuelFullThrottle, FuelPartThrottle and FuelNoThrottle tables extend past the range of the graph. they always have and most likely always will unless the range is extended or the injectors used are HUGE and the required pulsewidth is lowered.

problem is that i cant drag the last point off the screen and i cant move it with the arrow keys off the screen and i have to be able to do so to set up the fuel properly. plus T-LM has some goofy looking data for the 2.2L version of the last point of FuelFullThrottle... no where near enough fuel and i cant even move it back up to where its supposed to be due to the limitations on where the points are allowed to be moved and the graph size.

Thanks.

Brian

[wowzer]

brian - which version of mptuner are you using? version 1.0.7 should have fixed some the of lm fuel table display issues. which bin/tbl/template are you using? give me a link and i'll take a look-see. i remember having the same issue but can't recall how long ago or with which bin.

also, fyi, working hard on making the disassembler a little better. hopefully will have it updated in a week or so which should make disassembling some of the old stock bins alot better. also, some new and improved features in mptuner. pm me if you want.

morris

[Aries_Turbo]

ok, i did a little more testing. i was using T-LM V10... the 2.2L version. i recreated what i did. when i load the stock cal it loads fine and i can see everything just fine.

what happened was i went to scale for a 3-bar map and it seemed to scale the running fuel tables REALLY wierd. the last point stayed where it was and the rest of the table seemed to arch toward the upper left kinda like it scaled for injectors or something. it threw me off on what was happened.

it just doesnt seem to scale for map correctly. i looked in the scaling list and it says its going to scale for the xaxis but it doesnt look right....

i am using 1.0.7.

brian

[Aries_Turbo]

ok i just went and scaled a table manually in d-cal.

when you scale for map, the whole table raises.... including the last point because when the table is scaled for a larger range, the last slope must extend out and the end point will naturally be higher as the pressure is higher so the pulsewidth is higher.

ok, i did a manual scale of the table in MPTuner to test. it wont scale the last slope properly. it needs to scale the slope and then update the last point or something.

now for the other issue.... yeah if the last point is above the graph, i cant even click on it. i cant select it by using pgup and pgdn and then using the arrows. i cant edit it at all. i need to be able to edit that last point.

using a 2.5L cal on the LM with the pulsewidths the way they are the last point is above the graph immediately upon loading.

Brian

[wowzer]

couple things -

first, the logic behind the scaling of the x axis is that the y values should NOT change. all you are doing is restating the 2 bar map x values to the same value (psi) after scaling to 3 bar map. mptuner does that. the problem you are seeing, and i guess maybe my thought process is wrong, is that the phantom point value at the far right can not shift to the left like the other points since the phantom point ALWAYS has an x value of FF. so if x can't change, and y can't change, then the point doesn't move.

so, i need direction from you all - if instead of holding the last point y value constant, i adjust the y value also and keep the slope constant, even though all the other slopes have changed. and, as dcal shows, the y value can then go off the graph. my concern is what may happen in the actual code (rob????) if the calculated y value is invalid, i.e. too large. perhaps it may overflow and end up being some ridiculously low number.

i DO need to fix being able to access a point that is off the graph, so thanks for pointing that out. i ASSUMED that would not happen! the fix could be not to let any point go off the graph!?

anyhow - i'll wait for feedback before i change the program. btw, the next update of mptuner already allows you to edit that last y point value (sorry - you'll have to wait).

lastly, the 2.5cal does start up way above the graph for whatever reason, whether the table bytes are wrong or the scaling is wrong. to fix it EASILY, double click on the y value (24576) and change it to something like 36864. save the cal, reopen it, and it should now work. again, maybe rob can take a look to see what it should be.

one thing i do need to also reconsider is how to handle the comparison cals when the range values are different. currently the comparison graph is displayed as it would appear as if it was the main cal. it is not rescaled into the current main cal parameters. so, taking the example above (i.e. changing y to 36864), when you compare the 2.2 and 2.5 graphs, they will not line up well since the 2.2 uses a max y of 24576 and the 2.5 now uses 36864. so, the 2.5 graph will display "lower" than it really should. make sense? should i change this?

whew.

[wowzer]

slept on it brian and i agree that the slope needs to be held constant. e.g. on the 2 bar, 14.7 psi may be around 20k (which would be the phantom point). mapping to 3 bar should result in 14.7 still being at 20k, which it now isn't since the phantom point can't shift left. so i'll fix that.

[ShelGame]

couple things -

first, the logic behind the scaling of the x axis is that the y values should NOT change. all you are doing is restating the 2 bar map x values to the same value (psi) after scaling to 3 bar map. mptuner does that. the problem you are seeing, and i guess maybe my thought process is wrong, is that the phantom point value at the far right can not shift to the left like the other points since the phantom point ALWAYS has an x value of FF. so if x can't change, and y can't change, then the point doesn't move.

so, i need direction from you all - if instead of holding the last point y value constant, i adjust the y value also and keep the slope constant, even though all the other slopes have changed. and, as dcal shows, the y value can then go off the graph. my concern is what may happen in the actual code (rob????) if the calculated y value is invalid, i.e. too large. perhaps it may overflow and end up being some ridiculously low number.

i DO need to fix being able to access a point that is off the graph, so thanks for pointing that out. i ASSUMED that would not happen! the fix could be not to let any point go off the graph!?

anyhow - i'll wait for feedback before i change the program. btw, the next update of mptuner already allows you to edit that last y point value (sorry - you'll have to wait).

lastly, the 2.5cal does start up way above the graph for whatever reason, whether the table bytes are wrong or the scaling is wrong. to fix it EASILY, double click on the y value (24576) and change it to something like 36864. save the cal, reopen it, and it should now work. again, maybe rob can take a look to see what it should be.

one thing i do need to also reconsider is how to handle the comparison cals when the range values are different. currently the comparison graph is displayed as it would appear as if it was the main cal. it is not rescaled into the current main cal parameters. so, taking the example above (i.e. changing y to 36864), when you compare the 2.2 and 2.5 graphs, they will not line up well since the 2.2 uses a max y of 24576 and the 2.5 now uses 36864. so, the 2.5 graph will display "lower" than it really should. make sense? should i change this?

whew.

FWIW, the last point is a phantom. It doesn't really exsist. The ecu only looks at the last slope. If the Y return calculated from the slope is greater than 0xFFFF, it gets defaulted to 0xFFFF. So, it won't overflow and cause a very low PW, but you won't get a PW higher than 49152uSec either...

[ShelGame]

slept on it brian and i agree that the slope needs to be held constant. e.g. on the 2 bar, 14.7 psi may be around 20k (which would be the phantom point). mapping to 3 bar should result in 14.7 still being at 20k, which it now isn't since the phantom point can't shift left. so i'll fix that.

Actually, the last slope needs to be scaled as well. If you keep it constant, the calcualted PW past the last point (not the phantom point) will be too low in a scaled table.

What you need to do is, hold the final slope constant. Then recalc the 'phantom point', then scale the phantom point, the recalc the final slope and phantom point. Becuase the 'phantom' point is held at a constant Y, it needs to be scaled twice.

[Aries_Turbo]

yeah the slope has to change as you are cramming in more data in the same amount of space. how actually to accomplish that, you and rob can figure it out.

BTW, i tried changing the y-axis limit and reopening it and it will let me view the table better. finally, an editor that actually changes the image of the graph based on the mins and maxxes!!!!! all the others just used the axis min and max as purely informational which was annoying!

FWIW, the last point is a phantom. It doesn't really exsist. The ecu only looks at the last slope. If the Y return calculated from the slope is greater than 0xFFFF, it gets defaulted to 0xFFFF. So, it won't overflow and cause a very low PW, but you won't get a PW higher than 49152uSec either...

is that the max for the LM and the SMEC? cause the smec were half (hex value wise) vs the LM.

it does look like i have alot of headroom from what the hex values are and FFFF with the LM.

that 49152 doesnt seem to be much of a limitation because when you want more power, you need larger injectors due to the duty cycle limitation so you are always scaling back the values (pusewidth) for the physical increase in fuel of a larger injector.

brian

[wowzer]

rob - ya lost me. using the tlm10 full throttle bytes, show me how the phantom point/last slope should be calculated.

[MopàrBCN]

I am actually having an issue opening MP Tuner in Windows7. I am positive that the first version I used was working fine. Now it starts, shows the icon but does not show a window. Anyone else having this issue and knows a fix?

[Aries_Turbo]

i have an occasional problem when on my Tiny2003 (hacked, slimmed, os... super fast on older hardware) laptop and my regular XP box. ill open a cal, then go to open the same one again or sometimes a different cal and the program will just crash and disappear. i open it again and load a cal and all is well.... till i try to open another cal or the same one again. not a huge issue but something to note, none the less.

brian

[wowzer]

if you can recreate the error i'd love to know. gotta be something stupid i'm sure!

[gkcooper]

I am actually having an issue opening MP Tuner in Windows7. I am positive that the first version I used was working fine. Now it starts, shows the icon but does not show a window. Anyone else having this issue and knows a fix?

Try right-clicking and "Run as Administrator".

[MopàrBCN]

Hi, did this but to no avail. I have reinstalled everything and installed it from scratch and now it works again. No idea what caused this....

[MopàrBCN]

Hi figured another issue:

My scaling just went mad. I was pointed to this problem by another user here in Spain. I later figured you are using vb 6 so propably you are not working with globalization methods.

The problem arises when your region uses a "," as decimal separator instead of "." which is basically all of western europe as far as I can see.

I suppose you have methods where you add a "." manually to decimal numbers at some point. I would define a global variable for that and let the user chose how decimals are seperated (and save this in a local config file or have a section for it in the ini.

I just tried to fix the scaling results and it is impossible. Now I recompiled everything - reset my region settings to USA and it works....

[MopàrBCN]

BTW: The same localization problem causes an error when you try to check the AFR check box!

[MopàrBCN]

Question: ConstantSparkAdvanceWhenSettingBasicTiming is set at 6º. Is this a scaling issue and really it is set to 12 or is this wanted like this?