Closed loop idle target bug

sd1nl · Post by **sd1nl** » Sat Aug 02, 2014 2:37 am

Hi,

I have been watching the closed loop idle target today, and found what looks like buggy behaviour. See the attached log and msq.

Sometimes when driving the idle target is what it is supposed to be at idle (840rpm), but sometimes it is much higher (1050rpm or so). This is not consistent behaviour, and it matters because the initial value calculation is affected by the closed loop idle target. Resulting in an unpredictable drop to idle.

The drop to idle seems to be much nicer by the way when the closed loop idle targed is raised slightly when not being in closed loop. Why not implement this as a feature?

Also it is still not clear to me when the idle valve dashpot adder is applied and when not. When I blip the throttle a littlebit when idling no dashpot adder is applied resulting in near stalls.

Still a frustrating part of Megasquirt, and almost impossible to get it right.

Rene

Post by **jsmcortina** » Sat Aug 02, 2014 3:38 am

Please upgrade to the current release code. There was a small change to CLidle target that may be related.

James

sd1nl · Post by **sd1nl** » Sat Aug 02, 2014 3:43 am

I think that fix was already implemented in pre3.3.2beta4a. I think that was related with the idle target countdown.

I could do the upgrade nevertheless.

sd1nl · Post by **sd1nl** » Sat Aug 02, 2014 9:09 am

Upgraded to pre3.3.3beta1, but the behaviour is the same.

The closed loop idle target seems to stay at the last known value, which can be anything. This in turn influences the idle valve position that is taken from the initial values lookup table.

Result: unpredictable rpm return to idle

Solution: the closed loop idle target, when not in closed loop, should be: (idle target taken from idle target graph)+( fixed value). The fixed value should make the target a few hundred rpm's higher than the normal idle rpm for a given temperature.

This will give predictable results.

slyrye · Post by **slyrye** » Sun Aug 03, 2014 5:04 am

sd1nl wrote:Upgraded to pre3.3.3beta1, but the behaviour is the same.

The closed loop idle target seems to stay at the last known value, which can be anything. This in turn influences the idle valve position that is taken from the initial values lookup table.

Result: unpredictable rpm return to idle

Solution: the closed loop idle target, when not in closed loop, should be: (idle target taken from idle target graph)+( fixed value). The fixed value should make the target a few hundred rpm's higher than the normal idle rpm for a given temperature.

This will give predictable results.

I reviewed you msq, there's something strange the way you did your closed-loop initial values, my setup for my lancer is higher steps on cold cells and lower on top yours is inverted, i am mythiculous on my idle setup and found the code sufficiently working brilliant like a stock, my dashpot adder works fine aswell, mind checking your TPS lag , mine is set to about 96%

slyrye · Post by **slyrye** » Sun Aug 03, 2014 5:17 am

Dashpot decay reduces the duty over time (by an amount based on the factor set and the rpmDOT value
at that time). The algorithm used is decay_factor x 10 / rpmdot and the amount being subtracted is
logged in status4.

sd1nl · Post by **sd1nl** » Sun Aug 03, 2014 5:59 am

My idle steps are higher also when the clt is colder. The y axis is MAT, en my engine needs more idle steps when the MAT is high.

This bit works fine.

Problem with the current code is that there seems to be a bug in the code that causes the wrong value picked out of the initial values table.

Rene

Post by **muythaibxr** » Sun Aug 03, 2014 6:33 am

This does not happen in MS3, but it is possible that there is something going on in MS2. I will compare and see if I find anything.

sd1nl · Post by **sd1nl** » Sun Aug 03, 2014 7:02 am

Also something I noticed:

When driving around the idle stepper valve Is sometimes in a strange position (probably also the last position it was in when being in PID).

This is not a problem when you normally lift the throttle, because then the dashpot is added. But it can be an issue if you are in overrun, en you suddenly have to press the clutch.

The idle then plummets to zero if you are unlucky.

Rene

slyrye · Post by **slyrye** » Tue Aug 05, 2014 3:56 pm

sd1nl wrote:Also something I noticed:

When driving around the idle stepper valve Is sometimes in a strange position (probably also the last position it was in when being in PID).

This is not a problem when you normally lift the throttle, because then the dashpot is added. But it can be an issue if you are in overrun, en you suddenly have to press the clutch.

The idle then plummets to zero if you are unlucky.

Rene

I think that's when you need to install a "PID lockout switch", I also suffer from deep rpm stall when releasing clutch during cruising when over-run is engaged, what I did was raised the "total Idle valve close steps" limit sufficiently enough to mitigate this, not too high and not too low, also I tune in carefully my "Max decel load"

sd1nl · Post by **sd1nl** » Wed Aug 06, 2014 11:01 am

Not a bad thought, the lockout switch on the clutch.

But I still think it would help a lot if I the idle valve would already be in the proper position when I step on the clutch pedal.

It is unclear to me why the proper stepper idle valve position+dashpotadder is commanded when the system is engaging pid, and not when leaving pid. I assume this is because the code was developed with PWM valves in mind. They are quicker, and then this is less of a problem.

Hope this can be fixed.

sd1nl · Post by **sd1nl** » Wed Aug 06, 2014 11:32 am

Oh, and the msq and log were already attached in the first post. If any other info is needed I can make some extra logs.

DocWalt · Post by **DocWalt** » Fri Aug 15, 2014 5:29 pm

Figured I'd bump this as I see the exact same behavior on 3.3.2. Quite hard to predict what's going to happen when I return to idle since sometimes it's into closed loop well before it even bumps the target RPM up to start the ramp down. I also see the inconsistent dashpot behavior (which could be removed in my case if the idle target worked as I believe it should)

I'll attach an example as well.

sd1nl · Post by **sd1nl** » Mon Aug 18, 2014 9:46 am

Any news on this issue? Would be great to have it solved

sd1nl · Post by **sd1nl** » Wed Aug 20, 2014 8:56 am

Dear developers:

There is very little feedback on this unfortunately.

I will be brutally honest here:

I like Megasquirt very much, and I like playing with tunes and trying out new beta and alpha versions. When I find a bug I report it, send logs, try to explain it. This all in the hope future versions will be better (and they could be a lot better) and everybody will profit.

It just seems to be a little one way traffic lately. if you guys are just not interested, just say so: then I won't be bothered anymore to give anymore input.

Disappointed Megasquirt user.

Post by **muythaibxr** » Wed Aug 20, 2014 9:15 am

I have been extremely busy with work lately. I have seen your report, and have not had time to do anything with it.

I'll get to it as soon as I can get a chance.

wes kiser · Post by **wes kiser** » Thu Aug 28, 2014 1:28 pm

Do any of you guys use the adaptive idle timing feature? Every one wants to rely on airflow, but as a general rule it is the least responsive "button" you have to push. A properly setup adaptive idle table can mask HUGE errors in intial airflow.

I would also temper your dissappointment. Bugs exist in many commercial ecu's as well, and these guys do at least as good of a job responding to them.

DocWalt · Post by **DocWalt** » Sat Aug 30, 2014 9:25 pm

Due to this bug I can't use the adaptive idle timing feature because when the closed loop idle target spikes up like it does suddenly the idle bounces all over the place because of the timing change. I have to use RPM based idle timing, which isn't what I want to do, obviously.

pigga · Post by **pigga** » Sun Aug 31, 2014 4:12 am

Hi.
I compared the latest Alpha to the GSlender-Modded Firmware I used before. As far as I can see, the adaptive idle correction was implemented in a similar way?
In the beginning (when dialing in the values at GSlender 2.

I had similar problems to get adaptive Idle running.
Reason: Initially you have to set up a "flat" adaptive Idle Advance curve.
So you insert RPM-Delta Values let's say -500RPM, -250RPM, 0RPM, 250RPM and 500RPM for example. Then you set the Ignition advance accordingly (i.e. the lower RPM from target is, the more advance and the opposite for positive RPM-Delta values). I noticed (accidently) that it is important which way you enter the values of the X-Axis.
The negative RPM Values at the top, ascending to the positive values at the bottom of the table works correctly (*). It did not work the other way round, although TS always makes the graph appear in a way that it seems to be correct? Maybe this information is of any help. If not, no offence.

Screenshot 2014-08-31 13.00.14.png

* at least it works in my case. But I must say that I am not using the latest Alpha, so there might be some bug anyway

sd1nl · Post by **sd1nl** » Sun Aug 31, 2014 12:52 pm

The bug is in the inconsistent way the stepper motor behaves when letting go off the throttle or when returning to idle.

It is not related to idle advance timing (that works fine).

Rene

Megasquirt Support Forum (MSEXTRA)