Q about CALC.PE

[Mr. P.]

joecar & weathermanshawn:

I wanted to run this idea by you gents - consider changing the formula for CALC.PE from:

"{GM.EQIVRATIO}>1 && {SAE.RPM}>1200"

to:

"{SAE.LONGFT1} == 0 && {SAE.LONGFT2} == 0"

My premise being that if both LTRIMs are zero then: the PCM is in OL, or the PCM is in CL and believes it's fueling is correct - either way I would want to be using the data from my WB02 sensor to determine what is happening with fueling.

Just a thought.

Mr. P. :)

[WeathermanShawn]

Interesting..:confused:.

Only problem is that the LTFTS do not always go to zero during PE Mode (Open-Loop). Even during Warm-Up (Cold Open-loop), the PCM stores the previous LTFTS and you have Trims at warm-up. Also, during WOT PE Mode the PCM stores any +LTFTS and adds them to the fueling.

So I do not think tracking Trim activity is any better than what we have set-up. Its somewhat imperfect, but the semi-skilled Tuner can change the RPM and EQ to any parameter they desire.

Good thought, its just not going to work..

[Mr. P.]

Gotcha, thanks for clearing my understanding of how those PIDs are used.

Mr. P. :)

[joecar]

I would define it as "{GM.EQIVRATIO}=1" and call it CALC.CL, and reverse the sense of the iff() parameters...

i.e. iff({CALC.CL}, {CALC.LTFTBEN}, {CALC.WO2BEN})

[ compare that with the current calc_pids.txt file ]

that then reads like this: "if CL, then use LTFTBEN, else use WO2BEN".

[WeathermanShawn]

I would define it as "{GM.EQIVRATIO}==1" and call it CALC.CL, and reverse the sense of the iff() parameters...

i.e. iff({CALC.CL}, {CALC.LTFTBEN}, {CALC.WO2BEN})

[ compare that with the current calc_pids.txt file ]

that then reads like this: "if CL, then use LTFTBEN, else use WO2BEN".

That sounds like it could work..:).

[mr.prick]

LTFTs can be active during PE. :doh2:

I have a similar calc_pid for STFT w/RTACS
"iff({STFT}<>0,{STFTBEN})",{BEN}

This uses STFT for a multiplier unless STFT is 0% then BEN will be the multiplier.
STFT does not carry over into PE.

[WeathermanShawn]

Thats a pretty smart calculated pid, mr. prick. Shows you can utilize Trims activity (STFT) as an indicator of PE Mode.

I think the more skilled Tuners and Calculated Pid Editors can figure out various ways to configure the 'iff' condition for PE Mode. Then it becomes a factor of how many extra channel pids it may take, etc.
Thanks for that suggestion.:cheers:

[joecar]

For closed loop trimming (STFT and/or LTFT) to be happening, EQIVRATIO has to be 1;

when EQIVRATIO is not 1 then STFT/LTFT can't be used for editing (since they are not being updated);

if EQIVRATIO is 1 during PE (it had better not be) then STFT/LTFT can be used.

[joecar]

Also, I think we meant to distinguish between CL/OL rather than PE enabled/disabled...

i.e. we want to select when to use LTFT and when to use WO2BEN.

[WeathermanShawn]

Hi Joe:

Were you thinking we should replace the existing CALC.PE with your new expression: iff({CALC.CL}, {CALC.LTFTBEN}, {CALC.WO2BEN})

I kinda like it (the new one)..

[mr.prick]

The iff function is handy for pre-filtering.
You don't want to waste 2 channels on {SAE.FUELSYS}
A lookup pid based of the PE table is another option but more work than it's worth.

[WeathermanShawn]

mr. prick, what is sad is that we had to make a decision whether to have users have all the 'pre-filtering' done via calc_pids.txt or just use a filter. If you think about it, you could do all of CALC.VET via intelligent filters instead of calc_pids.txt.

We chose calc_pids.txt. Ultimately you could have every filter in the txt files vs ever having to manually create a filter. But, I have seen just as many users struggle with the entire calc_pids.txt file concept.

I think your suggestion(s) are very good. Unless you deliver all of this 'pre-packaged' in the software..seems like users will have to struggle for awhile no matter how 'easy' you attempt to make it.

[joecar]

Hi Joe:

Were you thinking we should replace the existing CALC.PE with your new expression: iff({CALC.CL}, {CALC.LTFTBEN}, {CALC.WO2BEN})

I kinda like it (the new one)..Yes, I think we should replace CALC.PE with the new one...


We could go in either of these two ways:

A. define CALC.CL as "{GM.EQIVRATIO}=1" and WO2BEN as "iff({CALC.CL}, {CALC.LTFTBEN}, CALC.WO2BEN})"

[ CALC.CL reads as: if EQ is 1 then we're in CL ]
[ WO2BEN reads as: if CL then use LTFTBEN else use WO2BEN ]

or

B. define CALC.OL as "{GM.EQIVRATIO}!=1" and WO2BEN as "iff({CALC.OL}, CALC.WO2BEN}, {CALC.LTFTBEN})"

[ CALC.OL reads as: if EQ is not 1 then we're in OL ]
[ WO2BEN reads as: if OL then use WO2BEN else use LTFTBEN ]


Which do you like better, and which makes better sense...?

[WeathermanShawn]

I think I like the Closed-Loop definition the most, because some users still use CALC. VET just in closed-loop.

Joe I have attached our current calc.pids.txt. I think you might have had some changes to the syntax..I.E., displacement (), etc. that you wanted to update.

Do you remember that one?

Anyhow, heres our current one. When we are happy with it, we can Edit the thread and put in thee new one.
Good thinking on that..:cheers:

[joecar]

Ah, I don't remember the syntax changes... :doh2:

Here's that calc_pids.txt with CALC.CL replacing CALC.PE...


edit: updated calc_pids.txt with minor synax rearrangement.

[WeathermanShawn]

I'll update the calc_pids.txt on the CALC.VET Thread this evening.

Thanks again for your work.

I sent you a PM with those minor syntax changes..

[joecar]

Shawn, I updated the calc_pids.txt in post #15 with the minor changes you pm'd about, thanks. :)

[WeathermanShawn]

Thanks. I'm slowly editing the CALC.VET Thread with the new changes..

[joecar]

I also did the same edits to the Calc.MAFT cacl_pids.txt file:

Calculating-MAF-Airflow-From-VE-Table..CALC-VET-In-Reverse (http://forum.efilive.com/showthread.php?16413-Calculating-MAF-Airflow-From-VE-Table..CALC-VET-In-Reverse&p=149834#post149834)

[WeathermanShawn]

Just updated.

Double-check my edit when you get time..

It may take me a few minutes to replenish the 3 calc_pids.txt files on Page 1 of the CALC.VET thread.

They 'look' nice and streamlined now!

[mr.prick]

It's easier to build filters than calc_pids and filtering via calc_pid can get complicated too.

I'm not adding anything here, I'm just saying........

[WeathermanShawn]

No major disagreement there.

We hope to make CALC VET even easier in the future. We have a few new concepts in the making, and your ideas have certainly helped guide us.

Simplicity rules!:grin:.

Thanks, mr. prick, and to everyone who has added suggestions.