loading in the .cax

[RADustin]

update 6-9-2014.

does anyone have a cax for any OS that has a 3d table that works? you can delete address and OS # and what not...just looking for format.

Thanks!

[joecar]

( briefly, what was the problem/fix just, for reference...? )

[RADustin]

( briefly, what was the problem/fix just for reference...? )

Backround-I was just trying to dip my feet in writing a CAX by changing the minimum amount of information in the template .cax so I could see what shows up where....

Problem- CAX data wasn't showing up in the tree when I opened the .ctz file.

Solution- Table name has to have numbers and can't be left as 'Bxxx' as it was in the template I had.


Now that I've been playing it, I've had several times I went to open the .ctz file and efilive tell me it is no good and make the bad file .tun. At first I thought I corrupted my .ctz file but that error just happens when the .cax formatting is incorrect.


I do have a new problem...

I'm trying to add a table to the CAX...4col by 15 row. I put my address in like this.. "BC5BA,BC5BC,BC5BE,BC5C0" ... but the table only shows up as a single 16 bit value(like if I only use one address). I have displaytype set to 3. What else do I need to do for a table to show up?

TIA

[Blacky]

I do have a new problem...

I'm trying to add a table to the CAX...4col by 15 row. I put my address in like this.. "BC5BA,BC5BC,BC5BE,BC5C0" ... but the table only shows up as a single 16 bit value(like if I only use one address). I have displaytype set to 3. What else do I need to do for a table to show up?

TIA

Make sure you specify the row and col labels as a quoted, comma separated list (i.e. "100,200,300,400,500" etc) or if the row/col labels refer to another table, use @xxxxx where xxxxx is the cal name of the table that contains the labels.
Regarsd
Paul

[RADustin]

Make sure you specify the row and col labels as a quoted, comma separated list (i.e. "100,200,300,400,500" etc) or if the row/col labels refer to another table, use @xxxxx where xxxxx is the cal name of the table that contains the labels.
Regarsd
Paul

I currently have this for the row/columns..

SI_COL = Metric Cols "1,2,3,4"
IM_COL = Imperial Cols "1,2,3,4"
SI_ROW = Metric Rows "1,2,3,4,5,6,7,8,9,10,11,12,13,14,15"
IM_ROW = Impereal Rows "1,2,3,4,5,6,7,8,9,10,11,12,13,14,15"


it still isn't working.

[Blacky]

I currently have this for the row/columns..

SI_COL = Metric Cols "1,2,3,4"
IM_COL = Imperial Cols "1,2,3,4"
SI_ROW = Metric Rows "1,2,3,4,5,6,7,8,9,10,11,12,13,14,15"
IM_ROW = Impereal Rows "1,2,3,4,5,6,7,8,9,10,11,12,13,14,15"


it still isn't working.

Send me the cax file and I'll see if I can see why its not working.
Send to paul@efilive.com

Regards
Paul

[RADustin]

Send me the cax file and I'll see if I can see why its not working.
Send to paul@efilive.com

Regards
Paul

Paul is awesome.

I should have had quotes around my axis names, like this...

SI_COL = "Metric Cols" "1,2,3,4"
IM_COL = "Imperial Cols" "1,2,3,4"
SI_ROW = "Metric Rows" "1,2,3,4,5,6,7,8,9,10,11,12,13,14,15"
IM_ROW = "Impereal Rows" "1,2,3,4,5,6,7,8,9,10,11,12,13,14,15"

[joecar]

Ok, I learnt two things from this (@xxxxx, and quotes around axis names)

[RADustin]

Joe,

Its nice that I ran across a problem and found a solution that may help you out.

You've helped me so much through the years you'll never even know.


I've also learned that these .cax files can't be opened when you try to load it. So if you are switching back and forth a bunch...you have to close it out.

I have also noticed it is going to take years to add the info I want to a cax. I really need to find a better way to add info quickly. I'm trying to do DTCs....I did 2 and gave up for tonight.

[RADustin]

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.

[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

[kangsta]

I just wanted to pass my regards to Paul for the EFILive software.

I'm in the same position as Taz, the new CAX handling is kinda inconvenient, particularly when you want to do the same things as you described however the public explanation Paul's given is one of the reasons EFILive is a premium piece of software. It is one of the few tuning tools I use that doesn't have weird bugs that are unresolved for months/years or indefinitely.

Really appreciate the work that goes into EFILive and look forward to a way of handling it in v8 :)

[Taz]

Hello Paul,

From your response it appears that I did indeed understand your original comments, with respect to overlapping *.cax files. The answer is simple - save the file, close it, then reopen it and confirm the parameter values prior to flashing the calibration. This does require a conscientious user, which in 2014 sometimes seems to be a lot to ask.

To avoid an argument (which is always my intention), I will gladly concede that in day to day use there is no reason to use a *.cax file that overlaps the existing EFILive calibration.

However, in practice this appears to be a matter of definition. When EFILive does not have a certain parameter available, and this parameter is distinct within the calibration (a table for instance), how does this remotely overlap with EFILive's calibration ?


... 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

To your comment that *.cax functionality is not a corporate priority ...

EFILive marketed and sold their product to myself and thousands of other people as providing certain functionality. One of my reasons for purchasing EFILive's product was the available functionality of segment swapping and user based *.cax file definitions - which were unlimited at the time of my purchase.

Other than legislated requirements that necessitate a change in functionality (which seems to be EFILive's position on USA based diesel controllers), functionality of a product sold commercially may be increased (i.e. adding new controllers) but never decreased - without the consent of the purchaser, and would potentially include some form of compensation of the purchaser. Anything contrary would potentially be actionable.

The above is merely intended to stimulate corporate thought. I am guessing that the change in *.cax file handling that occurred about a year ago was in response to "fools" (other words come to mind) that flashed controllers without understanding what they were doing, then tried to blame EFILive for their own stupidity.

Unfortunately we live in an era where people will buy a tool on Friday night, use it all weekend to complete a project, then return it to the store on Monday morning for a full refund - claiming that they didn't like something about it.

Something else to consider is that the *.cax functionality reduces the demand on EFILive to increase the parameter support for controllers. I have never complained about how limited some of the controller definitions are - I simply add what I need via the *.cax file process. I'm guessing many other customers do the same.

My sincere apologies Paul for the long, semi-ranting post. This issue has been a source of frustration for me of late. I have my first Gen V conversion in the works, and will need all the help I can get with the E92 ECM. I am hoping the fabrication shop building the tube frame runs behind on this !!!


Best regards,
Taz

[Blacky]

From your response it appears that I did indeed understand your original comments, with respect to overlapping *.cax files. The answer is simple - save the file, close it, then reopen it and confirm the parameter values prior to flashing the calibration. This does require a conscientious user, which in 2014 sometimes seems to be a lot to ask.

You're 100% correct. But there are people that use our software that expect it to protect them from doing anything wrong. To some people the ability for two different calibrations to overwrite each other is a serious bug/fault in the software. However, someone like yourself who knows what they are doing and is easily capable of managing that sort of conflict will not see it as a bug. We're walking a tightrope here.


To avoid an argument (which is always my intention), I will gladly concede that in day to day use there is no reason to use a *.cax file that overlaps the existing EFILive calibration.
However, in practice this appears to be a matter of definition. When EFILive does not have a certain parameter available, and this parameter is distinct within the calibration (a table for instance), how does this remotely overlap with EFILive's calibration ?
Yes and no. The overlap in this case is because we have added the DTC calibrations to the LML editor. Unfortunately due to strict regulatory controls by the US EPA, those calibrations are hidden/restricted for US customers.


To your comment that *.cax functionality is not a corporate priority ...
We are working (as a high priority) on some form of solution for the specific case of overlapping hidden cals. Just not on a general solution (in the V7.5 software) for overlapping, visible calibrations.


EFILive marketed and sold their product to myself and thousands of other people as providing certain functionality. One of my reasons for purchasing EFILive's product was the available functionality of segment swapping and user based *.cax file definitions - which were unlimited at the time of my purchase.

Other than legislated requirements that necessitate a change in functionality (which seems to be EFILive's position on USA based diesel controllers), functionality of a product sold commercially may be increased (i.e. adding new controllers) but never decreased - without the consent of the purchaser, and would potentially include some form of compensation of the purchaser. Anything contrary would potentially be actionable.

The above is merely intended to stimulate corporate thought. I am guessing that the change in *.cax file handling that occurred about a year ago was in response to "fools" (other words come to mind) that flashed controllers without understanding what they were doing, then tried to blame EFILive for their own stupidity.

I understand completely. I was pretty pissed when Sony took away the ability to run Linux on the PS3. However, we are not intentionally taking away something. As I explained earlier some customers see it as a bug, some see it as a feature. And I repeat, we are working on a way to allow you to overlap hidden cals.


Unfortunately we live in an era where people will buy a tool on Friday night, use it all weekend to complete a project, then return it to the store on Monday morning for a full refund - claiming that they didn't like something about it.
Yes some individuals try to ruin EFILive for everyone else (more than you could possibly know). But on the positive side, over the past 15 years I've been continuously surprised and heartened by the overwhelmingly vast majority of EFILive customers who are genuine, honest, hard working people. The number of times customers could have taken advantage of EFILive but instead chose to do the right thing has really impressed me.


Something else to consider is that the *.cax functionality reduces the demand on EFILive to increase the parameter support for controllers. I have never complained about how limited some of the controller definitions are - I simply add what I need via the *.cax file process. I'm guessing many other customers do the same.
Agreed 100%


My sincere apologies Paul for the long, semi-ranting post. This issue has been a source of frustration for me of late. I have my first Gen V conversion in the works, and will need all the help I can get with the E92 ECM. I am hoping the fabrication shop building the tube frame runs behind on this !!!
I don't see it as a rant, its constructive and helpful, thanks.

Regards
Paul