loading in the .cax

[Blacky]

I wrote an excel program to import all the 300ish DTCs and got the .cax working. Then I upgraded to the lastest EFILive release and it doesn't work anymore. Says things are overlapping but EFILive doesn't support DTCs and emissions related things(what my .cax contains) for LML so I am just confused now.

I'm going to revert back to the older revision for now.

There is a very good reason for the error message that you see in the latest release. If you have defined *.cax calibrations with addresses that overlap EFILive's pre-defined calibrations then your cax file has a problem and it may be altering memory that you did not mean to alter. Going back to the previous releae does not "fix" the problem it just doesn't check for it. You could end up messing up your tune file without even knowning which data you've accidentally changed. The reason we added the overlap check is becuase some people used cax files with mistakes in them and caused major problems when their cax files overwrote some part of memory that they were not expecting to overwrite.

I strongly recommend against using any tune file created from a cax file that has overlapping calibrations.

Regards
Paul

[RADustin]

Paul,

I appreciate your concern. I'm sure of my addresses I just didn't know if the new version EFILive takes a different format or what the deal was.

The version I was previously on and reverted back to did check for overlaps because it kicked back when I tried to define the DEF speed limiters.

Anyways. I *think* I'm ok.

[Blacky]

Can you send me the cax definition of the cal that the software is complaining about. I'll check to see if its a bug in the software or if it really is overlapping. It may be that one of the pre-defined calibrations is not at the right address. If there is a problem I'd like to get it fixed asap. Send to paul@efilive.com

Regards
Paul

[Taz]

Can you send me the cax definition of the cal that the software is complaining about. I'll check to see if its a bug in the software or if it really is overlapping. It may be that one of the pre-defined calibrations is not at the right address. If there is a problem I'd like to get it fixed asap. Send to paul@efilive.com

Regards
Paul

Hi Paul,

Is it OK if I do the same ?

Since last year's change to how *.cax files are handled, I have several *.cax parameters that won't load. I have a table for E67 ECMs - which is not defined in EFILive (or HPT) - but the *.cax will no longer load - I don't see how this distinct block of code is being used by the EFILive software.

Also, most of my T43 *.cax parameters will no longer load - the ones that I use most frequently are per shift torque management parameters (single parameter, not a table) - again, these are not available in EFILive - but are still blocked from loading.

Any help with this would be greatly appreciated - I am currently in the position where I have to use two versions of the software and two interfaces to get the job done.


Regards,
Taz

[RADustin]

It's basically suggested to mute the calz file, then use your cax to mod the bin. Then mute the cax and use the calz to mod. Then flash.

Only problems I see other than being a little cumbersome are if it's possible to hit out of range limiters.

I appreciate the fact that we have the ability to write and mod with the cax and efilive fixes our checksums...so I won't complain.

Maybe I could suggest that EFILive change the overlap directions to only check overlap on visible variables/tables.

[Blacky]

Hi Paul,

Is it OK if I do the same ?

Regards,
Taz

Sure, send to paul@efilive.com
Regards
Paul

[Blacky]

Maybe I could suggest that EFILive change the overlap directions to only check overlap on visible variables/tables.

Looking at how that might be done. It may have to wait until the V8 editor is done

The technical issue we have is that the calibrations are not processed in any user definable order so if the user has a calibration that uses the same memory locations as a pre-defined EFILive calibration, then there is no deterministic way for the V7 software to "know" which of the two overlapping calibrations will be written to the tune file last. Whichever one is written last will be the one that is stored in the tune file. It may be the value that your cax calibration was set to, it may be EFILive calibration's value.

Regards
Paul

[Dmaxink]

I wrote an excel program to import all the 300ish DTCs and got the .cax working. Then I upgraded to the lastest EFILive release and it doesn't work anymore. Says things are overlapping but EFILive doesn't support DTCs and emissions related things(what my .cax contains) for LML so I am just confused now.

I'm going to revert back to the older revision for now.

I know that feeling, it took me forever to load all my LML DTCs in back in the day

I'm the most thankful guy ever for cax files... So awesome efi have us this

[Taz]

... The technical issue we have is that the calibrations are not processed in any user definable order so if the user has a calibration that uses the same memory locations as a pre-defined EFILive calibration, then there is no deterministic way for the V7 software to "know" which of the two overlapping calibrations will be written to the tune file last. Whichever one is written last will be the one that is stored in the tune file. It may be the value that your cax calibration was set to, it may be EFILive calibration's value...

Perhaps I am missing your point on this ...

My experience is that when the Hex values in the calibration change - this changes both the displayed *.cax parameter value and the displayed EFILive calibration value.

As an example ... T43 OS 24239353 (2007 & 2008 MY). In the EFILive calibration the Based Desired Shift Times (D9000, D9030, D9060, D9080, D9100) are in separate folders. I created a table that displays all of these simultaneously, as well as the Sport Desired Shift Times. If I change my table values, or the EFILive calibration values - when the tune is reopened after being saved - both values have been changed (i.e. they are the same / equivalent), as the underlying Hex values have been changed.

In this scenario, flashing the tune is a non-issue, as there is no competition for supremacy between the *.cax parameters and the EFILive calibration parameters.


Regards,
Taz

[Blacky]

Perhaps I am missing your point on this ...

The calibration data shown on the screen is read from the bin image and stored in each of the calibration controls.

Let's assume there are two calibrations defined that use the same memory location like this:
B1111 is a calibration stored in a single byte.
B2222 is a user's cax definition which is also stored in a single byte at the same memory location as B1111.

When EFILive loads the file it reads the value at the shared memory location, lets say it is $55 and copies the value into B1111 and B2222, so they both start with the same value $55.

Now you change B1111 to 77. B2222's value will not change it will stay at 55. Then you go and change B2222 to 33, B1111 won't change, its value will remain at 77.
When the file is saved, both B1111 and B2222 are stored back into the binary image because they were both* modified.
Anyway, because V7 was never designed to handle overlapping calibrations, you can never know which calibration will be written back to the file first.
If B1111 gets written first, then B2222 gets written after it, then the file will contain B2222's value of 33.
If B2222 gets written first, then B1111 gets written after it, then the file will contain B1111's value of 77.

Next time you load the file both B1111 and B2222 will again have the same value, but the value ($33 or $77) will be determined by what happened during the previous file save operation.

* If one of the values was not modified, then its value would not be written back to the binary image so there will be no contention - but the software cant rely on the user "not doing something". There's already a bunch of "double checking" code that handles problems caused by the VVE implementation because multiple VVE tables can update the same base coefficients tables (i.e. overlapping). If multiple VVE tables are open and modified when the file is saved, the user is asked to close them and by closing them the user is forced to decide which of the multiple, open VVE tables gets applied to the coefficients table prior to saving the file. Right now developing an equivalent, generic solution for overlapping *.cax calibrations is not a high priority. It is something that we will address in the V8 editor.

Regards
Paul