MS3 PID Idle Target - Why does it change when returning to idle?
 

Hello all

I can't seem to find this answer anywhere, or any features in TunerStudio to control it, so I'm asking here as a last resort. Let's say my car is fully warmed up, and the idle target in the Idle Target Curve is set to 850. If I let off the throttle in neutral at, say, 2000RPM, RPM will fall until about 1200, where Idle Target shoots up to 1200 and slowly decays to 850. I imagine this is some sort of "soft landing" feature, but is that not what the initial value table is for? Or dashpot adder (does dashpot adder even do anything if I'm using a lookup table)? Or PID settings to control ramp rate and overshoot? Having the PID algorithm attempt to hit a moving target just seems like an added level of complexity that needn't be there.

Is there somewhere I can change where this kicks in? Or the rate it changes to my actual target?

Thanks.

subd for the answer. mine does the exact same thing.

does the idle target actually shoot up to 1200 rpm in logs?

dashpot opens and extra whatever % above your initial duty values. your initial duties are where PID should begin, not where you should immediately return to idle at.


depends. whats your PID delay?


not really. that's the whole point of PID.

have you like never looked at the like 30-40 different settings you can adjust in idle contorl?

again, L2T.

Yes it does. Shows up live if I make a gauge for target rpm, and it shows up in the log. I'll try to attach one, but I'm on my phone so it may not work. https://www.dropbox.com/s/nxi984j3ih...39.51.msl?dl=0
See record 6869 for example. But it seems to do it in many other places.

I know what it does, my point is it seems redundant if you're using the initial value table. Makes sense if you're using "last good value".

3 seconds. Changing it doesn't change the speed at which my target rpm changes when rpm drops towards idle.

I meant that we can control soft landing through dash pot settings, through PID settings and through initial values. This extra behavior is redundant (and indeed I think a dash pot setting is redundant as well, since one could simply increase the values in the initial value table to achieve the same effect, unless I'm missing something)

Let's lose the attitude, it's neither helpful nor warranted. As stated in the OP, I've scoured the manual, the Internet, and tunerstudio and have found nothing to reference this behavior, much less control it.

No idea what l2t means. See above comment, and I'm referring to the rate that the "CL Idle Target" goes from 1200 to my specified target of 850.

Mine does the same thing. Returning to idle, at some point, while the rpms are slowly dropping all the sudden idle target rpm shoots up to exactly what the current rpm is. Usually once rpm is about 15% above the 'real' idle target. Then it drops down (linear) to the real target again. Funny enough it doesn't seem to do anything to idle PWM.
https://www.miataturbo.net/attachmen...ine=1454697322

might be built into the code during dashpot so PID doesnt fight it. I'd have to ask Ken.

When I was researching this on msextra, I think I remember that Dashpot came first and people struggled with it. Then the initial value table came in a later version of the code to do (kinda) the same thing, only better (hopefully) and the dashpot was never removed. So you have both to play with.

You can control the soft landing using the dashpot settings, or the initial values table. The PID settings control how well controlled the idle will be once the other two are done. PID control by itself won't necessarily get you a soft landing to your idle RPMs unless you're a CL control wizard or have a way underdamped control loop.

As far as the CL idle target ramping down from 1200...frankly, I never plotted that value, and see that mine is acting similarly! I always thought that this behaviour was a result of slightly too high initial values and tolerated it to keep from the RPMs falling too fast and resulting in a stall. Since it was so close (in my case) to the 2 sec PID ramp to target value (what I'm using), I thought that's all it was.

You're saying that changing that value has no effect on the length of this CL idle target ramp...interesting.

This would make sense... did they not disable the dashpot if the initial value table was selected? I suppose tomorrow I'll set dashpot to 0 and see what happens...


Yeah, the PID has to have an initial value from somewhere (be it the last setting, last setting + dashpot, or worst-case I suppose it would use some static value) to solve the equation. Table lookup of intelligent guesses gives the PID less work to do, so that makes sense. For what it's worth, I got a masters in Mech. Engineering, with a specialty in dynamics and controls... and got a job which used none of it. So this kind of stuff excites me :rofl:.

I did too, and in my quest for OE-quality idle I discovered this. I adjusted the value from 2 seconds to 7 seconds and was unable to detect a difference in the ramp rate (by looking at me "CL Target Idle" gauge).

I too have not seen an effect from the ramp to target. The jump in target RPM, I have only seen do strange things on the first transition to idle after start-up. I put a question about that on MS Forums and never received a response.

I use dashpot, but see your point that it may not be necessary. However, if I remember correctly, it helps buffer small changes like lights on or off, that occur only sometimes, and I prefer to not add to the target table. Still, your point makes sense that they can be integrated, you just have to tune with lights and HVAC fan on.

I took a closer look at a log I did yesterday, trying to find a correlation between the jump in the CL Idle Target and anything else - and couldn't find anything...until I noticed that when it happened the value was set to whatever the RPM was at the time of the jump.

Now here's my guess - and it's all just wild conjecture at this point - after all of the CL activation conditions are met AND the PID delay time elapses, the CL Idle Target is set to the current RPM value. THEN the dashpot kicks in and some mysterious formula calculates how long the dashpot should be in effect (by way of the dashpot decay factor) and the CL Idle Target is linearly reduced from the current RPM to the Target RPM figuring that the PID control will ramp down the idle speed to the target smoothly.

Now that we have the Initial Value Table in place, the two are fighting/complimenting each other; the dashpot saying, "Here's your (linearly decreasing) idle RPM target" and the initial values saying "PID loop, this is (the RPM/Temp-dependent) idle valve setting that you should start with". That gives us options to turn off one, or the other, or both, or neither.

Options are good...right? Me, I'm using both. I don't mind the RPMs "shooting" up to 12-1300, especially during cold mornings when there's a tendency for the car to stall because of an idle dip. This behaviour is like an automatic throttle blip before settling to a steady idle, so it works for me. YMMV

PS - My degree is a Bachelors in Mech Engrg, and control theory was one of my favorite courses (of course, I've not used any of this in 20 years). Problems like this are "cool".

rwyatt

I agree, that when the target jumps it goes to the RPM that the engine is running. But I don't understand your statement that the engine then jumps to some higher RPM, as, the target is where it is. Why would it increase?

The negative thing I was getting, is that, upon a start, things are OK, but if I move out of a parking space, then put in clutch to go from rev to 1st, closed loop does not engage well. Then, every other time, it works fine. It seems some flag is set at the start to idle that screws up the very next move to idle, but then not again. It could just be coincidental that the RPM's I'm at when I make that Rev to 1st transition that is very different from every other time I go into idle.

I'm not sure why it does, but it does (at least for me). I'll look through some logs and see if I can catch when it happens. The symptoms are; coming to a stop and letting the engine lug to slightly below where the CL initial value is for that temp. Upon letting off the clutch, the RPM will increase to (what I think is) the initial value setting and then drift back to the idle setpoint.
This sounds suspiciously like you're using the "Use last value" setting in the CL Idle Control - and the IV table isn't doing anything for you. Of course, if that was the case, you wouldn't be able to set anything in the table, so that's not the problem.

Again, just guessing...

OK, now I understand, it's when you force the engine slow.

No, I have never used the "use last".

So I went out today and set the dash pot value to 0 and it didn't seem to make a difference. The plot thickens.

MS3 PID Idle Target - Why does it change when returning to idle?
 

The target changes to rpm that you enter pid at. Then ramps down to the table's value.

No plot.

Yes, this was already known. What isn't known is if we have any control over the ramp rate. Now we know the dashpot settings have no effect, like rwyatt thought it might. So far my guess is that it's hard coded.

Mine takes two seconds to ramp down to the target as defined in the table. This coincides with two values in my PID idle control: "PID Delay(s)" and "PID Ramp To Target Time(s)". Of those two the more likely candidate seems to be the "Ramp To Target". Can't test right now since the car is partially disassembled.
In any case, I don't quite understand WHY we change the target at all. What's the benefit here? As far as I understand it only slows the time for reaching the actual target.

These were my first guesses as well.. I changed ramp to target from 2s to 7s and wasn't able to detect a difference. Might try again later while logging (I was just counting in my head while watching it live).

As for the purpose, I suppose it's to keep the pid from experiencing such a large error signal when it first enters closed loop - an error of 400+rpm (if cl idle starts at around 1200-1400 and target is 850) might cause some weird problems - large overshoot, oscillations, etc.

MS3 PID Idle Target - Why does it change when returning to idle?
 

Developer said: allows control of the speed with which it returns to target.


Has anyone tried to change the ramp time yet?

So...I started digging through old logs, trying to see if I could find an instance when the time for the ramp of the CL Idle Target RPM was something other than 2 sec. I found one from late September where the time to ramp down was consistently 3 sec (or thereabouts). Guess what the PID Delay was set to?

...wait for it...

3 seconds!

That's empirical evidence that this is what is determining how long that taper-down time is. Maybe I'll do a quick test on the way home tonite. Set the PID Delay to 5 sec and see if the ramp-down time changes accordingly.

As to the purpose...I'd tend to agree with Uncle H, with the additional guess that this is an artifact of the "dashpot-only" days. Yes, it's to reduce the error signal to the PID loop but since the introduction of the initial value table this is/should be redundant IF the IV Table is used.

Dashpot is slightly different than the initial valve table. If you are at 0% throttle and blip to 2% and let off, AND you meet the criteria to exit CL Idle, your initial values will take over but the Dashpot will NOT kick in.

Do the same thing, but change 2% throttle to 10%, and dashpot kicks in.

Dashpot helps keep the idle from shooting up 500 RPM when you barely gave it enough gas pedal come out of CL idle.

Why does my car not ramp to target when it's supposed to? PID settings are off, too much P or D, not enough I.

Change them to

P = 0
I = 200
D = 0

time interval for the control loop to 100 ms

And it will go to target in whatever time you tell it to. You'll need to tweak the P term a bit but my guess is you're using the slider, or you have settings with a lot of P and D, not enough I and it's overdamping the system to the point it can't reach the target you specify in the time you want it.

FWIW - I did a test today. Changed the PID Delay value from 2 sec to 5 sec. Here's the resulting log;

https://www.miataturbo.net/attachmen...ine=1455058017

The main trace is w/ PID delay at 5 sec, the compared trace is w/ PID delay at 2 sec. You can clearly see that the ramp down time is different (the white trace): 5.111 sec vs 1.786 sec.

@Pat;
My idle PID settings are: P = 55, I = 65, D = 2

As you can see from the trace above, my idle goes to the target RPM and doesn't oscillate (too much - could be better). I've had I as high as 100 and P as low as 0 but the settings above seem to be doing the job. Also, my control loop time interval is 60ms and I am using the slider (set to 1500). I am also using idle adaptive advance timing to "trim" the CL idle and it seems to be working a treat.

If you're using the slider, you're not using the PID values. Can only use one or the other.

Try the settings I posted and see what happens. Your RPM's oscilate while it goes to target in the pic you just posted. They could be MUCH better. Mine would follow to target withing 25 RPMs and not vary at all. And I could run 2 sec, 5 sec, whatever. I found the slider did what you posted, overdamped.

Damn! And here I thought that the slider was "assisting" the PID loop. :facepalm:

I'll test this tomorrow and post findings..."News at 11" ;-)

Also try

P=5
I=200
D=0

That's what I was running last, and it worked great on my setup. The little bit of P term helped a touch

Ran your settings this afternoon - here are the results (nothing else changed but the PID settings above and removed the slider);

https://www.miataturbo.net/attachmen...ine=1455128151

What I noticed;
- The RPMs seemed to drop about the same but the green trace shows there was a bit less oscillation coming down to the target w/ Pat's settings (the lighter trace).

- The red trace shows that the Idle Duty drops a lot quicker to the setpoint without so much as a wiggle.

- I'm going to have to reduce my IV Table 'cause there were a few instances of this;

https://www.miataturbo.net/attachmen...ine=1455128151

Where coming off-throttle (TPS in yellow) causes the PID settings to set the IV too high (Idle Duty in red) which "spikes" the PID loop into an unintended oscillation - the exact opposite of what the table is supposed to be doing (as I understand it).

I want to get some longer idle events to make sure that perturbations (fans on/off) don't cause problems, and reduce my IV Table (methodically) to eliminate the spiking. But I think I've got some new CL Idle settings!

Thanks Pat :bigtu:

If you want, email me your tune and I'll update your idle settings to what I ran. I had this nailed down really well on my setup.

If you have those PID setting than your idle probably sucked

Which one; mine, Pat's, or both?

This seems pretty non-sucky to me;
https://www.miataturbo.net/attachmen...ine=1455198244

The dither in the idle RPM is +/- 20 RPM once it settled, and this was before using Pat's numbers.

pat's 0 - 200 - 0 settings.

on your log:
what's the scale of the idle duty we are looking at? rpms dont seem very reactive to changes in the idle duty.

im assuming you have adaptive timing turned on as well a battery voltage idle correction?

my idle was bonkers stable, and that was before the easy pid slider, look-up tables, idle targets easing entering PID, and all the other improvements.

this shows mine with a/c and headlight actiavtion:

everything is auto-scaled.

Idle Duty max; 42.7, min; 23.9 on that plot. What you're seeing is a drop from 32.5 to 26.7.

Lights on/off seem to not change the idle that much (if any). Fans on/off have a bigger impact (I'm running both fans in parallel). Other than that my idle is pretty stable - just need to spend more time w/ initial values - but this freakin' weather is driving me crazy! One morning it's 20*, the next it's 50* (I'm exaggerating, of course, but not much). Makes for a helluva a time trying to test things.

You can add idle-up % for one of the radiator fans (at least with MS3-Basic). Not for lights, P/S or A/C cabin fan to "high" though.

that's where the voltage idle % compensation comes into play. you can kick up the idle speed if the voltage drops AND you should be using adapative timing so it advances the motor to maintain idle targets.

Brain,

I do use adaptive timing. I'm not complaining about my idle, just giving Wyatt some more options. Also, Reverant's voltage control on the MS3 is so strong that I don't see any voltage lag until about 600 RPM's, which is basically only if I'm trying to stall with the clutch. So compensation of idle % with voltage is not meaningful.
But I'll be open minded and look for short voltage dips just as lights come on, to see if it even shows on Tuner Studio. Or do you think it is possible that the dip could be short enough to not show, but long enough that the idle valve compensation could be meaningful? That will have to wait until I get the car running again.

Back on topic: Has anybody really figured out yet, why the target rpm is going to current rpm when entering CL? There was some conjecture going on, but so far no definitive answer if I recall properly. Should we just set the "Time to reach target" to 0 and get rid of the whole thing?

Hmmm, never thought about using the idle voltage compensation to deal with this...worth a try.

I am using adaptive timing, but "only" +/- 4 degrees - should I consider more?

Empirically, time to target has no effect, it's PID delay (and that can only go to 2 sec, min) that has an impact on this behavior. Maybe taking this over to msextra will get a definitive answer...

This is wrong. Sensitivity slider is active all the time.

Megasquirt Support Forum (MSEXTRA) ? Idle Control - methods? (View topic)

https://www.miataturbo.net/attachmen...ine=1455293835


Thanks Aidan!

It may be dumb logic, but it's why I prefer the NA alternator over the NB.

When youre controlling the alt, the voltage stays at ~14.2v and doesnt ever move.

The NA alternators dip with voltage hits (like activating lights, a/c, fans, etc) and you can use that to react to and open the idle valve against and tune it quite well to keep things stable

Even though the voltage stays stable with teh NB alt, the engine load might change, but you can't compenstate for that really beyond the PID code just reacting to the load change.

That's why I have a RX7 alternator!! :bigtu:

I ditched that NB alt a while ago.

Its also active during boost control closed loop

So, now my question is; if the slider is always on, AND it acts as a multiplier to the PID values (as suggested in the msextra link), what is the meaning of the value of the slider setting? The range is 0-4000...4000 "what"? Am I multiplying the PID values by 4000? Is it a percentage multiplier (i.e. 4000=4000%, or "times 40")? Is it just some relative value (relative to what)?

Just WHAT am I doing by using the slider? Inquiring minds want to know.

(Sorry OP for hijacking your thread)

Its just a multiplier. I was digging through the code yesterday trying to figure it out. But the code is horribly commented. Let me see if i can dig something up again.

this is what docs say:

from the developer back in 2014:

My basemaps use 500 for the PID gains, and the the PID is set to 100 - 100 - 0, most people say it's pretty damn close out of the gate.