loading in the .cax

[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