Should PW be different between 1&3 and 2&4 ??

[gslender]

Hi,

I've been playing with a JimStim and a spare DIYPNP board (microsquirt2) and noticed an odd behaviour with Seq Inj.

Initially, when first turning on, and you've got the JimStim set to steady RPM (1275) and steady MAT (29), CLT(91) and TPS (4) running same config/tune that would be running on the car (using a similar DIYPNP / Microsquirt2) all the PW are exactly the same.

If I play with the RPM up and down, eventually the PW1&3 become different then PW2&4.

For example, mine right now are 6.430ms (1&3) vs 5.931ms (2&4).... is that expected? Seems odd?

G

[gslender]

Just tried it with 3.2.1 firmware and same behaviour??

I'm seeing up to .5 ms difference between 1&3 and 2&4 !!

Why?

g

[gslender]

Ahhhh... figured it out!

It is EGO control. For some odd reason, it mucks up the PW such that they are different between cycles... I've yet to wire in the O2 pot on the JimStim. Will do that and see if the AFR is bang on will it still do it... I hope not!

G

[gslender]

Yup, with EGO control on it is almost impossible to get the PW back to stable again once it veers off AFR Target. I think the PID controller is to blame.

[gslender]

OMG the ego control seems to be only applying to PW1 and (therefore PW3 for seq inj) in which case it isn't working on the PW2 (& PW4) side of things!!??

[richyvrlimited]

OMG the ego control seems to be only applying to PW1 and (therefore PW3 for seq inj) in which case it isn't working on the PW2 (& PW4) side of things!!??

Good catch!

[gslender]

I know what is wrong in the code too.

In ms2_extra_ego.c in the ego_calc function it only updates outpc.egocor1 when for seq inj it needs egocor2 updated as well (or maybe the main function is wrong in how it applies egocor1 and egocor2 for sequential ?? (it would depend on what Ken or James was thinking when they did this).

Code: Select all

        outpc.egocor1 = egocor_100[0] / 100L;

        if (flash4.dual_tble_optn) {
            egocor_100[1] += ego2step;
            if (egocor_100[1] > (100000 + ltmp)) {
                egocor_100[1] = 100000 + ltmp;
            } else if (egocor_100[1] < (100000 - ltmp)) {
                egocor_100[1] = 100000 - ltmp;
            }

            outpc.egocor2 = egocor_100[1] / 100L;
        }
/// this code below needs to be added to fix it
        else outpc.egocor2 = outpc.egocor1;


[gslender]

Just checked MS3 1.03 and found that it was fixed or at least sorted so the bug doesn't exist in that firmware!

Code: Select all

    outpc.egocor1 = outpc.egocor[0];
    if ((ram4.EgoOption & 0x03) && (ram4.egonum > 1)) {
        outpc.egocor2 = outpc.egocor[1];
    } else {
        outpc.egocor2 = outpc.egocor1;
    }

[jsmcortina]

The MS3 implementation is quite different though.

James

[jsmcortina]

Please post an MSQ.
I just tried this on the bench and with the settings I'm using I don't see a problem? (All four PW follow each other.)

James

[gslender]

Please post an MSQ.
I just tried this on the bench and with the settings I'm using I don't see a problem? (All four PW follow each other.)

James

James, you can simply read the code and/or watch egocor1 and egocor2 in TS.... egocor2 never changes off 100% whilst egocor1 does... the bug is there!

I added the fix I described and it now works fine.

G

[gslender]

just to show you... in ms2_extra_main.c

Code: Select all


            lsum1 = (lsum * ((outpc.egocor1 * lsum2) / local_div)/100);
            lsum1 = lsum1 * ((outpc.vecurr1 * (long)flash4.ReqFuel)/ 10000); // .01 usec
            if (((flash8.seq_inj & 0x03) == 3) && (seq_inj_ctrl & SEQ_HYBRID)) {
                lsum1 *= 2; // double the reqfuel do to the single pulse
            }
            lsum2 = (lsum * ((outpc.egocor2 * lsum2) / local_div)/100);
            lsum2 = lsum2 * ((outpc.vecurr2 * (long)flash4.ReqFuel)/ 10000); // .01 usec

lsum2 only works on egocor2 !!

[jsmcortina]

Yes, but normally egocorr2 = egocorr1
You do need to post an MSQ because only certain conditions highlight this.
I'm seeing it now - it happens if PID EGO, but not with "simple" which is how I tested.

James

[gslender]

Yes, but normally egocorr2 = egocorr1
You do need to post an MSQ because only certain conditions highlight this.
I'm seeing it now - it happens if PID EGO, but not with "simple" which is how I tested.

James

Well, as long as you found it.

G

[racingmini_mtl]

I agree that the code needs to be corrected as shown. It is obvious if you look at the simple algo code which does have the correct egocor2 else statement.

Jean

[jsmcortina]

The just-released 3.2.2 aims to correct this bug.

Thanks to Grant for pointing it out.

James

[Peter Florance]

Yes, but normally egocorr2 = egocorr1
You do need to post an MSQ because only certain conditions highlight this.
I'm seeing it now - it happens if PID EGO, but not with "simple" which is how I tested.

James

Plus then James has something to test.

[ashford]

is this problem showing up when using single o2 sensor or dual?

[jsmcortina]

I observed it with a single sensor selected.

James