Morello

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.

dr_boone

iTrader: (1)

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

Braineack

iTrader: (62)

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.

Morello

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.

stefanst

iTrader: (1)

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.

Braineack

iTrader: (62)

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

rwyatt365

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.

Morello

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 .

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).

DNMakinson

iTrader: (3)

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.

rwyatt365

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".

DNMakinson

iTrader: (3)

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.

rwyatt365

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...

DNMakinson

iTrader: (3)

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

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

Morello

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.

Braineack

iTrader: (62)

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

No plot.

Morello

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.

stefanst

iTrader: (1)

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.

Morello

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.

Braineack

iTrader: (62)

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


Has anyone tried to change the ramp time yet?

rwyatt365

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.