Closed loop idle target bug

[jsmcortina]

Will a fresh MSQ and datalog of my adaptive idle advance settings help?

Please post exact matching MSQs and datalogs. Remote diagnostics is already difficult enough!

James

[PDX5]

Here's a matching datalog and MSQ of just the adaptive idle advance. (The cold advance is active).

3.3.2h.msq

2014-12-05_16.38.04.msl

Please see 168204.2 and 168335.1.

Both instances the CL Idle Target is ~1290rpm and my desired rpm is 850rpm.

From 168204.2 to 168205.95 the idle speed is really close to my desired target rpm of 850rpm. However it's targeting 1299rpm and bumping the timing up to 23.2* instead of something close to 14*.

Same thing from 168335.1 to 168343.48. Targeting 850rpm would be perfect. But again it's targeting 1292rpm. Even though the idle valve isn't using that target... the adaptive idle advance feature is. When the closed loop idle does engage again at ~850rpm the timing works well to maintain my desired 850rpm.

If I try to use adaptive idle advance I have to restart the engine several times until I get a CL Idle Target closed to my desired speed. Otherwise the ignition timing will just stay at 22* because it thinks 850rpm is too slow. I think this is similar to what others posted in the beginning of this thread. Therefore we've been using Idle Advance in RPM Mode.

[jsmcortina]

That sounds like a failure in the implementation of the adaptive idle. The closed-loop idle target RPM is doing what it is supposed to, but that feature is mis-using the target RPM. (It was contributed code.)

I'll consult with Ken, but I'll likely remove the manual option to ensure that the feature will only run when closed-loop idle is active.

James

[PDX5]

The disappointing part is that I was using Adaptive Idle Advance in manual mode for over 6k miles before upgrading to 3.3.2 and it worked really well. I would go back to 3.3.1 but the 3.3.1 that I downloaded from the downloads page has the same behavior as the 3.3.2.

Using Adaptive advance in manual mode allows me:
- To have a flat area near idle in my Ignition Table 1 and avoids jerkiness at speeds near idle.
-Drops advance/rpm before Idle PID engages
- Idle advance at 41kPa, Idle PID at 44kPa, and engine idling around 45kPa warm.
-Cold RPM speed is higher than warm idle speed, but RPM based advance causes the timing to be low in cold coolant temperature.

- If I use adaptive advanced linked to CL PID... i might as well alter my Ignition Table 1. (Low speed drivability suffers significantly)
I can lower the Idle PID decel load kPa and increase the RPMdot Threshold to link adaptive advance but then false activation of Idle PID and stalls occur. I have a clutch switch, but still require a neutral switch which I haven't been able to construct.

This is how I've implemented the feature:
-Target rpm = 0 delta and 14* advanced
-Low rpm = increased advance
-High rpm = decreased advance

From what I've read this is how ignition advance should be used to stabled idle and it worked really well 3.3.1.

[jsmcortina]

The disappointing part is that I was using Adaptive Idle Advance in manual mode for over 6k miles before upgrading to 3.3.2 and it worked really well. I would go back to 3.3.1 but the 3.3.1 that I downloaded from the downloads page has the same behavior as the 3.3.2.

There's only one 3.3.1 and nothing has been changed relating to idle for ages from what I can see in the ChangeLog.

James

[PDX5]

Are PID conditions for CL Idle purposely ignored during startup? The only setting that seems to be effective at startup is the PID delay, even though PID conditions are not met.

Here's the MSQ:

3.3.2c.msq

In the datalog below you can see CL Idle (status 2) engaging below the Decel Load kPa at 2242.295s. RPMdot was also high immediately before CL engaged. PID delay appears to have started counting immediately after startup and not when the PID conditions were met.

2014-11-30_15.11.56.msl

Another example in the datalog below at 2722.637s. CL Idle engages well below the decel load kPa and above the RPMdot threshold.

2014-11-30_15.19.56.msl

This behavior is what causes the error at startup with the CL Idle Target RPM. IF CL Idle were to engage following the PID conditions at startup, then the CL Target RPM that the code grabs when it enters close-loop would be much more accurate (and Adaptive Idle Advance in Manual Mode could still be used). In the first datalog you can see the idle duty spike because CL Idle engages, the RPM spikes as a result, and results in very rough startup behavior.

Is this a bug? Perhaps a result from the changed feature in 3.3.1 to 3.3.2

Main changes from 3.3.1 to 3.3.2

Bug fixes:
Make ramp time use the ramp time setting instead of using the PID delay.
Apply same CLidle target change from MS3 to fix "stuck" problem after start.

I've altered all my PID conditions and nothing has an effect except PID delay, when still appears to countdown from startup and not when PID conditions are met.

[jsmcortina]

In the datalog below you can see CL Idle (status 2) engaging below the Decel Load kPa at 2242.295s. RPMdot was also high immediately before CL engaged. PID delay appears to have started counting immediately after startup and not when the PID conditions were met.

There's actually a two second gap in your datalog right at that point, so I can't use that datalog for any analysis.

Another example in the datalog below at 2722.637s. CL Idle engages well below the decel load kPa and above the RPMdot threshold.

The datalog do look odd, but I am not able to replicate that on the bench.

I discussed the other issue (RPM target value used for adaptive idle) with Ken and have since investigated the code. It looks like it is a very easy change to make the code always use the curve lookup value instead of the actual target value which includes the taper. I've made that change already.

EDIT: You should also get a working TPS.

I'm planning on releasing a new pre-3.4 alpha code soon which will include any changes I make here.

James

[PDX5]

There's actually a two second gap in your datalog right at that point, so I can't use that datalog for any analysis.

I noticed that... I wonder why the datalog would stop recording there. I didn't touch anything during that period.

The datalog do look odd, but I am not able to replicate that on the bench.

I'll upload another datalog+msq that may help after this post.

I discussed the other issue (RPM target value used for adaptive idle) with Ken and have since investigated the code. It looks like it is a very easy change to make the code always use the curve lookup value instead of the actual target value which includes the taper. I've made that change already.

That's really great! Thank you.

EDIT: You should also get a working TPS.

TPS is actually wired up and working very well. My datalogs correctly/intentionally show no TPS movement at startup since that what we're looking at for these issues. The rough rpm at startup is not me touching the throttle.

[jsmcortina]

Please try the current pre-3.4 alpha code. It has the small change to the adaptive idle RPM number in place.

James

[PDX5]

I'll give the pre3.4 alpha 7 a try.

Continuing the false Idle PID engagement at startup (*I already wrote this before pre3.4alpha7 was posted):

Are PID conditions for CL Idle purposely ignored during startup? The only setting that seems to be effective at startup is the PID delay, even though PID conditions are not met.

Here's the latest MSQ:

3.3.2c2.msq

and datalog:

2014-12-09_14.01.07.msl

Startup Idle PID engages at: 112.653s, 248.362s, 406.161s.

At 112.653s: CL Idle/status 2 engages below the decel load kPa. RPMdot was high before engagement. TPS is correctly below the 0.1% threshold. CL Idle engaged 2 seconds after cranking. *If I change the PID delay the problem the delay and still not the other PID conditions.

At 248.362s: CL Idle/status 2 engages above the RPMdot threshold. Only engages for a brief moment (closes the idle valve) and drops out again. TPS is correctly below the 0.1% threshold. Again, CL Idle engaged 2 seconds after cranking.

At 406.161s: PID Idle conditions are met, but the PID delay is not met for RPMdot.

You can see CL Idle engaging falsely at startup and then disengaging. After initial startup the CL Idle begins to behave correctly - following the PID conditions.

I'm using the PID lockout switch to disengage CL Idle at startup, once rpm stabilizes I press the button to turn on CL Idle and it drops into idle as expected. If there wasn't a problem then I would not require a switch to ignore CL Idle at startup.

[jsmcortina]

I know you've just posted up those logs and the analysis, but it is probably best to see if the new firmware changes anything. If you are seeing the same behaviour then I'll take another look.

James

[PDX5]

I was able to give pre3.4alpha7 a try. The edit to the adaptive idle advance feature works great! Thank you again!

Now if we can figure out why CL Idle is engaging when the PID conditions are not met. Same issue in pre3.4alpha7 as in my previous post.

*I'll be away from the car for a few months starting 12/13 so can work on this for a few more days before I won't be of use.

[jsmcortina]

I dug deeper and that's what it is supposed to do, just after crank it is designed to go into closed-loop idle. Otherwise, what is supposed to happen to the idle valve? It was just at the cranking duty.

James

[muythaibxr]

James is correct. It is purposely skipping some of the checks for going into PID just after crank.

[PDX5]

I dug deeper and that's what it is supposed to do, just after crank it is designed to go into closed-loop idle. Otherwise, what is supposed to happen to the idle valve? It was just at the cranking duty.

The problem is that it goes into CL Idle not following the Idle PID conditions... then it "realizes" the conditions are not met and it drops out. I can't change my PID conditions to keep it from dropping out of closed-loop without ruining drivability. This is just not ideal behavior.

How about following the all PID conditions and using the Crank to Run Taper... to transition from cranking idle valve duty to near running idle valve duty?

At some point in the taper the Idle PID conditions would be met and CL Idle would take over to maintain idle speed. Similar to the way Afterstart Enrichment tapers in a smooth linear fashion. You could have a steady taper from cranking duty until CL Idle engages and control the taper with the time setting. It seems like this is what the Crank to Run Taper should be doing by definition.

This would result in a very smooth startup every time.

The current design of the code doesn't appear to use the Crank to Run Taper. Crank to Run Taper works in Open-Loop. It should be functional in Closed-Loop as well.

Maybe you guys have a better implementation but what I suggested above is similar to how I use my PID lockout switch; it's an annoying band-aid but it works. Otherwise every time I start the car it revs like teenager starting his first car with the throttle pressed. I don't like this behavior on a cold engine, let alone a warm engine. Passangers immediately wonder if the car will make it down the road.

[jsmcortina]

Have you tried less cranking duty? Your engine revs up to 1800RPM at 112.043s _before_ closed-loop is going anything.
During the time that CL-idle is active, the engine isn't responding well - the actual RPMs are mostly a lot higher than the target. e.g. at 118.334 the actual RPM is 200 above the target.

How is your idle valve wired ? It seems very sensitive. But also, look at the timing changes in the log. Lots of advance at the start is making it hard for the idle valve to pull the revs down.

James

[PDX5]

Have you tried less cranking duty?

I went ahead and worked on this a bit. I set cranking duty equal to running duty. Removed the extra 1-2% idle valve duty for the "overshoot".

Initial behavior looks good. Cranks straight into Idle PID and holds. Looks good to me. I'll test these setting a bit and report back.

I think my understanding of Cranking Duty might have been the culprit here. I had read that an 'overshoot" to about 17-1800rpm was good at startup. I'm guessing that is not necessary and was the cause of erratic startup behavior.

[DocWalt]

I'm VERY encouraged by the updates to this thread. Thank you James and Ken. I can't wait to give the code changes a try. Hopefully I can also get away with lowering my cranking duty on my new engine (I doubt it, higher compression surely isn't going to make it easier to spin the engine), since I was also seeing the same strange jump to closed loop idle then bouncing out in the seconds following startup.

[DocWalt]

I gave this a try with my car, idles great and easily catches itself, even on 2 of 4 cylinders. Nice