something wrong with my axis conversion?

gitman · Post by **gitman** » Sun Sep 14, 2014 8:32 am

i am trying to duplicate the "Eprom, subtract" function in WinOLS for an axis definition. if i try to enter the following equation into the Conversion Editor for the Row axis...

CELL(INDEX() + 1, FALSE)-(THIS() * 0.75)

...the Conversion Editor says that the format looks valid, and then i hit OK to go back to the row properties. i apply my changes and notice that the Row axis changes to all 0's. when i go back to the Conversion Editor again, the equation has completely disappeared. what am i doing wrong? is there an issue with my equation?

i also tried:

CELL((INDEX()+1), FALSE)-(X * 0.75)

which is not all that different, but got the same behavior.

if i take out the CELL() function completely, so that it looks like...

(INDEX()+1)-(X * 0.75)

...TunerPro accepts it. its wrong, but it accepts it. it appears to be something about the CELL() function that it doesn't like.

i am using version 5.00.8414.00

thanks for your time

Post by **Mangus** » Mon Sep 15, 2014 12:25 pm

So the value of the cell currently being calculated is to be the value of the neighboring cell minus 75% of the value of the binary data for the current cell?

The neighboring cell relies on its neighbor as well, and its neighbor relies on its neighbor. This, itself, isn't a problem, until you get to the last cell in the table. Where does it's value come from?

Send me an XDF, Bin, and instructions outlining what to look at and the desired behavior and I'll take a closer look when I have some time.

gitman · Post by **gitman** » Mon Sep 15, 2014 6:27 pm

good point about the last cell. TBH i'm not totally sure where it's supposed to get its data for the last cell, but i know what its supposed to be by looking at WinOLS, so i came to 192. based on that, i came up with an IF() statement to handle the case of the last cell:

IF(INDEX()+1==INDEXES();192-(X * 0.75);CELL(INDEX() + 1, FALSE)-(X * 0.75))

its ugly, but it should still work, no? because the equation still disappears from the editor after applying the changes to the XDF.

here are the bin and XDF files:

http://gitman.me/files/06A906032PLS0003.bin
http://gitman.me/files/06A906032PL.xdf

The table name is KFDZWOB. All I'm doing is right clicking the table, going to 'Edit Parameter XDF Info', clicking the 'Rows' tab, clicking the 'Edit' button 2x, and then inputting the aforementioned equation. I then click 'OK' 2x, and 'Apply', at which point I see the axis change to all 0's. If you follow the same directions to get back to the equation that you had just entered, and you'll notice that its now gone.

The actual bytes in the bin converted to decimal are 75,100,125,163. In WinOLS, I see the calculated values as -155.25 (from 75), -99.00 (from 100), -24.00 (from 125), 69.75 (from 163). The factor specified in WinOLS is 0.75 (equivalent to X*0.75 in TP), but the method is "Eprom, subtract" which is not the same as setting the Label Source to "Internal, Pure" in TP (but WinOLS "Eprom" option is the same).

These are the calculations used to derive those values:

-99.00-(75*0.75) = -155.25
-24.00-(100*0.75) = -99.00
69.75-(125*0.75) = -24.00
192.00-(163*0.75) = 69.75

thanks

Post by **Mangus** » Tue Sep 16, 2014 12:01 am

I'll have to add error messaging. The equations fail to be saved because they're invalid. The first one fails because you should be using semicolons for parameter delimiters, not commas.

I'll be taking a closer look at the second one. Another (perhaps easier and more efficient) way to do the second is to use the global equation for all except the last one. On that one, do a cell-level equation with 192-(X * 0.75).

gitman · Post by **gitman** » Tue Sep 16, 2014 6:41 am

Mangus wrote:I'll have to add error messaging. The equations fail to be saved because they're invalid.

so when it says its valid, that's probably based more on the use of operators, etc., and not functions. am i correct in thinking that?

Mangus wrote:The first one fails because you should be using semicolons for parameter delimiters, not commas.

ahh, i think i know why i got screwed up there. in the help document, under the table functions list, this is how the CELL() syntax is defined:

Code: Select all

CELL&#40;r; c, precalc&#41;

i saw the comma and it threw me off

Mangus wrote:I'll be taking a closer look at the second one. Another (perhaps easier and more efficient) way to do the second is to use the global equation for all except the last one. On that one, do a cell-level equation with 192-(X * 0.75).

i'll check that out

thanks

gitman · Post by **gitman** » Tue Sep 16, 2014 6:57 am

i think i may have stumbled on to at least a reason for seeing what i'm seeing.

so if i put in CELL(INDEX();TRUE), i am able to see the precalc value for the cell. i can then change that to CELL(INDEX()+1;TRUE) and it basically moves everything up 1 row. once i change the "precalc" param to "FALSE", that's when things go wrong. it makes sense because TP hasn't yet done the calculation for the next row, as it's going to do that after it's done calculating THIS row. since it doesn't have the calculations done for the remaining rows, attempting to use the post-calc value fails.

need to think about this a little more then...

Post by **Mangus** » Tue Sep 16, 2014 7:50 am

Even with the per-cell equation on the last cell?

gitman · Post by **gitman** » Tue Sep 16, 2014 8:43 am

Mangus wrote:Even with the per-cell equation on the last cell?

i haven't attempted to go that route yet, still trying to see if i can accomplish everything with a single equation

appears the conversion editor window only supports up to 255 characters.

i'm trying to use nested if statements to arrive at the proper values, and TP is cutting it off after 255 characters.

IF(INDEX()==INDEXES()-4;192-(CELL(INDEX();TRUE)*0.75)-(CELL(INDEX()+1;TRUE)*0.75)-(CELL(INDEX()+2;TRUE)*0.75)-(CELL(INDEX()+3;TRUE)*0.75);IF(INDEX()==INDEXES()-3;192-(CELL(INDEX();TRUE)*0.75)-(CELL(INDEX()+1;TRUE)*0.75)-(CELL(INDEX()+2;TRUE)*0.75);IF(INDEX()==INDEXES()-2;192-(CELL(INDEX();TRUE)*0.75)-(CELL(INDEX()+1;TRUE)*0.75);IF(INDEX()==INDEXES()-1;192-(CELL(INDEX();TRUE)*0.75);X*0.75))))

(btw this is after changing address stepping to -1 to reverse the order of the axis values)

Post by **Mangus** » Tue Sep 16, 2014 8:55 am

If you need more than 255 characters, there's almost certainly an easier way. That's a beefcake of an equation you've got there, and it would be (at best) horribly slow and inefficient to calculate across the table.

gitman · Post by **gitman** » Tue Sep 16, 2014 9:03 am

the length of it is attributed to the fact that i'm using 4 IF()'s and modifying the equation based on the cell index number. it shouldn't be any more work for the application than specifying an equation for each cell in the axis, just instead of the application conditionally applying an equation based on the index, i'm doing it through the conversion editor.

if i can indeed access the post-calc values by specifying the equations individually to each row axis value, then that simplifies the math for sure.

Post by **Mangus** » Tue Sep 16, 2014 9:15 am

gitman wrote:the length of it is attributed to the fact that i'm using 4 IF()'s and modifying the equation based on the cell index number. it shouldn't be any more work for the application than specifying an equation for each cell in the axis, just instead of the application conditionally applying an equation based on the index, i'm doing it through the conversion editor.

if i can indeed access the post-calc values by specifying the equations individually to each row axis value, then that simplifies the math for sure.

As previously mentioned, use a table-wide equation since most of the cells use the same conversion. Use a per-cell equation only for the cells which differ (the last cell). Unless we're now talking about a different table or a different conversion for the table.

gitman · Post by **gitman** » Tue Sep 16, 2014 9:30 am

apologies, but i'm not understanding how to do that based on the requirements: the main cells have a conversion factor of X*0.75. the column axis has a conversion factor of X*40. the Row axis is what i'm trying to get working like the "Eprom, subtract" option in WinOLS, while still keeping its own X*0.75 conversion factor.

table cells factor = 0.75 [uses "Eprom" option in WinOLS]
column axis factor = 40 [uses "Eprom" option in WinOLS]
row axis factor = 0.75 [uses "Eprom, subtract" option in WinOLS]

so based on this information, can you please explain a little more how to accomplish what you're recommending by modifying the global table equation? because as i'm understanding it, that would throw off the calculated values of the main cells.

thanks for your time

Post by **Mangus** » Tue Sep 16, 2014 9:42 am

We're speaking specifically about the row axis conversion. Not the column, not the main table. My suggestion is based on the information you provided in the initial posts.

What does the "EPROM, subtract" option do in WinOLS? I don't have any experience with WinOLS.

gitman · Post by **gitman** » Tue Sep 16, 2014 11:24 am

Mangus wrote:We're speaking specifically about the row axis conversion. Not the column, not the main table. My suggestion is based on the information you provided in the initial posts.

ok. its just that i'm not understanding how to enter a table-wide equation that affects only the row axis, and then how to enter a different equation for the last index of that axis. equations entered at the conversion tab modify the main table. besides that and the conversion editor at the row tab, i'm not sure where else i could enter an equation for the row axis.

Mangus wrote:What does the "EPROM, subtract" option do in WinOLS? I don't have any experience with WinOLS.

given these hex values: 4B 64 7D A3
when converted to decimal: 75 100 125 163

without any conversion specified, TunerPro displays the rows as:
75
100
125
163

what WinOLS does with Eprom subtract is it takes the last value, subtracts it from 256, and then uses that resulting value as the base value to subtract from. i think the key difference to what TP is doing with "Internal, Pure" is that it's pulling the last row axis value first and then running calculations on it prior to any user-specified calculations.

in order of calculation:
256-163=93
93-125 = -32
-32-100 = -132
-132-75 = -207

apply the factor 0.75 and you get the row values (low to high) which is what you would see in WinOLS:

-207 * 0.75 = -155.25
-132 * 0.75 = -99.00
-32 * 0.75 = -24.00
93 * 0.75 = 69.75

so instead of just pulling the data and displaying in order as decimal, it starts with the last byte and subtracts that from a constant for the last row, and then decrements each subsequent row by the numerically-next row's calculated value.

Post by **Mangus** » Tue Sep 16, 2014 1:51 pm

Create a new table that represents the row axis. Address 0x29806. Set up the conversion how you need it. Then in the KFDZWOB table row tab, select "Linked, Scale" and specify the new table you created.

If you set the global equation for the new row axis table to be something like:

CELL(ROW()+1;0;FALSE) - X

you may find that TunerPro reports a circular reference. With this equation by itself, this is true. However, the last cell having its own equation makes it false. That's a bug. To workaround it for now, set each cell's equation to be that, except for the last (256 - X).

Edit: I've confirmed this works.

1) Create a new table at address 0x29806. 4 rows, 1 column.
2) You'll use per-cell conversion for this table due to the bug mentioned above. The last row's equation is
(256-X) * .75

The other three cells use

CELL(ROW()+1;0;FALSE) - (X*.75)

3) In the KFDZWOB table, row tab, set "Linked, Scaled" and browse to the new table created in step 1.
4)Apply all changes
5) Open the row table and the XFDZWOB table
6) Profit.

That should get you going.

This also allows you to actually modify the axis by modifying the new table. Making changes to the axis table should reflect immediately in the main table.

Email me if you'd like me to send you the modified XDF with this working.

Enjoy!

Post by **Mangus** » Wed Sep 17, 2014 2:22 pm

Did you get it working?

Post by **Mangus** » Fri Sep 19, 2014 2:36 pm

I'll consider this resolved.

gitman · Post by **gitman** » Sun Sep 21, 2014 11:31 am

sorry no, i have not had time to work on this. family and work. i'll post an update when i can. i appreciate the direction.

thanks,

thadeausmaximus · Post by **thadeausmaximus** » Thu Nov 06, 2014 12:39 pm

I had the same problem and arrived at the same solution. But It doesn't work right when editing cells by the corrected values. So I came here looking for a cleaner solution. For now I can just edit the hex directly.

I am using "CELL(ROW()+1;0;FALSE)-X*FACTOR+OFFSET" in each row with "(256-X)*Factor+OFFSET" for the final row

I am working on a bosch 2.1 ecu. It defines the axis for each table in a header before the table data. Starting at the end of the axis it places the current value of the parameter in the accumulator (where the results are stored from addition) then starts adding the values from the axis definition starting from the end. It has found its row/column when the accumulator hits 256 or greater (Triggering the carry bit). For an axis A B C D E the value of each row in the axis is
a = offset + factor*(256-E-D-C-B-A)
b = offset + factor*(256-E-D-C-B)
c = offset + factor*(256-E-D-C)

Post by **Mangus** » Thu Nov 06, 2014 12:55 pm

There's a fix coming in the next build that should solve the recursion issue that is probably what's keeping this from working for you. Meanwhile, use "THIS()" instead of "X" in your equation, and it should work. Note that you can use a global table equation of CELL(ROW()+1;0;FALSE)-THIS()*FACTOR+OFFSET, and set the last row's specific equation to "256-X)*Factor+OFFSET.

thadeausmaximus · Post by **thadeausmaximus** » Thu Nov 06, 2014 2:07 pm

Thanks.