MS3 PID Idle Target - Why does it change when returning to idle?
#1
Junior Member
Thread Starter
Join Date: Jul 2009
Location: Orange County, CA
Posts: 419
Total Cats: 45
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.
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.
#3
Boost Czar
iTrader: (62)
Join Date: May 2005
Location: Chantilly, VA
Posts: 79,729
Total Cats: 4,126
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?
#4
Junior Member
Thread Starter
Join Date: Jul 2009
Location: Orange County, CA
Posts: 419
Total Cats: 45
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.
See record 6869 for example. But it seems to do it in many other places.
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)
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.
Last edited by Morello; 02-05-2016 at 06:56 AM.
#5
Senior Member
iTrader: (1)
Join Date: Sep 2011
Location: Lambertville, NJ
Posts: 1,215
Total Cats: 74
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.
#7
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)
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.
#8
Junior Member
Thread Starter
Join Date: Jul 2009
Location: Orange County, CA
Posts: 419
Total Cats: 45
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.
You're saying that changing that value has no effect on the length of this CL idle target ramp...interesting.
#9
Retired Mech Design Engr
iTrader: (3)
Join Date: Jan 2013
Location: Seneca, SC
Posts: 5,012
Total Cats: 859
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 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.
#10
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".
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".
#11
Retired Mech Design Engr
iTrader: (3)
Join Date: Jan 2013
Location: Seneca, SC
Posts: 5,012
Total Cats: 859
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 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.
#12
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.
Again, just guessing...
#16
Junior Member
Thread Starter
Join Date: Jul 2009
Location: Orange County, CA
Posts: 419
Total Cats: 45
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.
#17
Senior Member
iTrader: (1)
Join Date: Sep 2011
Location: Lambertville, NJ
Posts: 1,215
Total Cats: 74
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.
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.
#18
Junior Member
Thread Starter
Join Date: Jul 2009
Location: Orange County, CA
Posts: 419
Total Cats: 45
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.
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.
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.
#20
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.
...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.