E38 IVT table required

[Tre-Cool]

Any chance we can get the "IVT Weighing co-efficient" added to the early 12612381 os please.

This table is extremely useful in the early model os's when running a scaled tune.

In HPT it's called "IVT Weighing co-efficient AFR TERM" seems to be setup for 0 to 80% ethanol but the data value on a standard tune is set to 7.92 for all percentages.

By halfing this value it fixes the ivt open loop table and makes it work like it normally would with a 50% scaled tune.

I can email through 2 tunes, 1 with it scaled to help find it.

[GMPX]

The process to add tables isn't a 5 minute job, but we have a growing list of 'can we please haves' for E38 I'll add this to it. I'm a male, I can't multi-task

[Tre-Cool]

if i have same tune besides the required table modified, wouldn't that make it quicker to find to update the calz or create a quick cax file for now?

[Taz]

Hello Tre-Cool,

You have always helped out on this Forum over the years. I can make you a CAX file for this, but I probably won't have the free time required for a week or so. There is also no way to know if this CAX file will get blocked from loading by the newer software versions, until I have a chance to test it.

There is no need to post the tunes that you mentioned above.


Best regards,
Taz

[GMPX]

if i have same tune besides the required table modified, wouldn't that make it quicker to find to update the calz or create a quick cax file for now?

Sure it would make it quicker, but there is still a bit of messing around to generate the .calz files.

There is also no way to know if this CAX file will get blocked from loading by the newer software versions, until I have a chance to test it.

Well if the table is in the OS area then yeah it might, otherwise that was an odd comment though I suspect you were taking a shot.

[Taz]

... Well if the table is in the OS area then yeah it might, otherwise that was an odd comment though I suspect you were taking a shot ...

Hello Ross,

I hope that all is well with you. If by some bizarre twist of fate, I ever believe that the correct course of action is to make a derogatory comment about your software company – you would not be left with any doubt – it would be crystal clear.

The current CAX file restrictions are not limited to the OS area of the calibrations. If this were actually the case, the resultant impact on the user would be negligible. The reality is that CAX files are blocked from loading from many of the segments within the overall calibration – and are often inconsistently applied OS to OS.

This situation is similar to the current TIS2WEB restrictions – which you complained loudly about. If comments made about CAX file restrictions evoke a defensive response in you, I would encourage you to take positive action – and correct the situation.

This Forum used to be a fun and positive place. You, me, gmh308, and others used to share a camaraderie of sorts, and more than a few laughs behind the scenes. I had abandoned this Forum for awhile, as I had grown tired of dealing with idiots - that are an unfortunate phenomena of the Social Media world.

I am trying to put some enjoyment back into my busy life – and charitable actions (like helping out on this Forum) are things that I enjoy (or at least used to).

Tre-Cool took the time to answer a question (via PM) that I had awhile ago. As an honourable person, I now feel compelled to return the favour – and write him a CAX file for one E38 parameter. However, even if I isolate that parameter and complete the CAX – it still may not be allowed to load by the current software.

My comments to Tre-Cool were intended to let him know that I would create the CAX for him, but that I would then have to test whether or not it would load – in other words, don’t get your hopes up just yet.

If you have been led to believe by your staff that CAX files are only being blocked in the OS area of a calibration - that is not true. If you have been led to believe by your staff that CAX files are only being blocked in an area of a calibration where EFILive already has a preexisting parameter or table - that is also not true.


Best regards,
Taz

[GMPX]

If you have been led to believe by your staff that CAX files are only being blocked in the OS area of a calibration - that is not true. If you have been led to believe by your staff that CAX files are only being blocked in an area of a calibration where EFILive already has a preexisting parameter or table - that is also not true.

Well guilty as charged, I don't know what restrictions are in place on the .cax files as it stands now, last time I discussed this internally it was to restrict the OS area from being modified and not allowing any already defined calibrations (in the .calz) file to clash with something in the .cax.
I will see if I can get Paul to chime in, it may very well be some of these restrictions are happening unintentionally.

[Taz]

Thank you Ross,

You have always presented as an honest and reasonable person. Blocking the OS portion of a calibration from CAX files would be completely OK with me. The only CAX files that I use that contain OS addresses are for the LS1-B PCM - and that is no real loss.

If specific examples would assist you or Paul, I don't mind sharing these privately with either of you.

I have a significant number of parameters defined via CAX file for the E67 and T43 controllers.


Best regards,
Taz

[Taz]

Sorry ... I should have also mentioned that the CAX file for Tre-Cool was allowed to load without issue. I sent it to him today for testing.


Best regards,
Taz

[GMPX]

Probably best to send it to Paul please, though he is always very, very busy so I'm not sure when you will get it resolved. If you send him the details with a link to this thread then we'll see how it goes.