MS2 Beta 6 - closed loop idle problem
Moderators: jsmcortina, muythaibxr
-
- Super MS/Extra'er
- Posts: 2413
- Joined: Sun Mar 06, 2005 9:15 am
- Location: Chicago, IL, USA
- Contact:
MS2 Beta 6 - closed loop idle problem
Ken,
I have been driving this latest S19 that has the ignition fix for the Time after spark. This week it has been very hot here in Chicago. Most of the time, it works beautifully, but under certain conditions, it can get under the lockout conditions and then when I truly drop throttle, it dies. It appears to be that under current conditions (High MAT, A/C running) the idle DC is near MAX, when the throttle is dropped below the tps threshold, idleDC goes from closed to lastDC+adder and in the heat, this allows the map value to rise above the lockput, allowing the idle control to drops into the PID loop. This runs the idleDC down and when I release the clutch, it stalls. Recently with no A/C on, I did not see this problem.
Do you intend that the decel load be below a normal idle load? Mine can idle at 34 or less at times - especially in winter.
Currently, I have 3 suggestions:
1) table of lastidleDC and map lockout values
2) allow it to reset if the load goes above the threshold - if it dips slightly below load and comes back up, it will reset idleDC to the dashpot value. This may be hard to do as I have no idea how LastIdleDC will affect this
2) keeping IAC closed until rpms drop below the rpm threshold AND tps is below the tps threshold - this will keep load values very low and allow for a decent gap between idle load and overrun
http://ys3al35l.googlepages.com/stall.jpg
http://ys3al35l.googlepages.com/idle_settings.jpg
KeithG
I have been driving this latest S19 that has the ignition fix for the Time after spark. This week it has been very hot here in Chicago. Most of the time, it works beautifully, but under certain conditions, it can get under the lockout conditions and then when I truly drop throttle, it dies. It appears to be that under current conditions (High MAT, A/C running) the idle DC is near MAX, when the throttle is dropped below the tps threshold, idleDC goes from closed to lastDC+adder and in the heat, this allows the map value to rise above the lockput, allowing the idle control to drops into the PID loop. This runs the idleDC down and when I release the clutch, it stalls. Recently with no A/C on, I did not see this problem.
Do you intend that the decel load be below a normal idle load? Mine can idle at 34 or less at times - especially in winter.
Currently, I have 3 suggestions:
1) table of lastidleDC and map lockout values
2) allow it to reset if the load goes above the threshold - if it dips slightly below load and comes back up, it will reset idleDC to the dashpot value. This may be hard to do as I have no idea how LastIdleDC will affect this
2) keeping IAC closed until rpms drop below the rpm threshold AND tps is below the tps threshold - this will keep load values very low and allow for a decent gap between idle load and overrun
http://ys3al35l.googlepages.com/stall.jpg
http://ys3al35l.googlepages.com/idle_settings.jpg
KeithG
-
- Site Admin
- Posts: 8230
- Joined: Thu Oct 14, 2004 12:48 pm
Most likely, you can tune this bad behavior out with the current code.
It'll only start checking for lockout if your TPS goes below the threshold you have set for it, so most likely, you have that threshold set too high...
That said, the way it works is this (pseudo code):
So there are a few different ways you could solve this problem, and it'll probably be a combination of these that you want to do:
1) Make your TPS threshold lower. I'm going to be adding the ability to set it to .1% units because on my own engine, this is necessary. I need to be able to set it to around .3-.5%
2) Make your idle wait time longer. Values of 1-3 seconds are going to be too short. I recommend 5 seconds. This mimics the behavior I see on most newer cars now.
Actually, thinking about it, that may be all that's needed.
Ken
It'll only start checking for lockout if your TPS goes below the threshold you have set for it, so most likely, you have that threshold set too high...
That said, the way it works is this (pseudo code):
Code: Select all
if TPS > TPS-thresh
hold valve closed
else
open valve to last DC + adder
if RPM <RPM> user-idle-wait-time
PID
endif
if idle-wait > user-idle-wait-time and RPMdot <RPMdot_thresh> MAP thresh
PID
endif
endif
1) Make your TPS threshold lower. I'm going to be adding the ability to set it to .1% units because on my own engine, this is necessary. I need to be able to set it to around .3-.5%
2) Make your idle wait time longer. Values of 1-3 seconds are going to be too short. I recommend 5 seconds. This mimics the behavior I see on most newer cars now.
Actually, thinking about it, that may be all that's needed.
Ken
I am running in very hot conditions and even cool, wet conditions in the morning. This new code is flawless so far. The lockout code catches the high idle everytime.
Ken, I know everybody’s PID settings are going to be different, but I'm curious to know what your settings are. I am having a slight issue with the correction delay because it seems to take a couple seconds longer than it should to begin correcting when below the target rpm. To me, this tells me the P term is too low (currently set at 10) however, if it's any higher, I get bad oscillation. What it will do is jump down to the min PID (keeps rpms about 600) and then jumps to 1000rpms. With the PID settings I have now, they are 99% perfect. When it starts correcting, it goes straight for the proper DC and stays there, keeping rpms smooth as can be. However like I said, this pre-correction time seems to be too long.
Ken, I know everybody’s PID settings are going to be different, but I'm curious to know what your settings are. I am having a slight issue with the correction delay because it seems to take a couple seconds longer than it should to begin correcting when below the target rpm. To me, this tells me the P term is too low (currently set at 10) however, if it's any higher, I get bad oscillation. What it will do is jump down to the min PID (keeps rpms about 600) and then jumps to 1000rpms. With the PID settings I have now, they are 99% perfect. When it starts correcting, it goes straight for the proper DC and stays there, keeping rpms smooth as can be. However like I said, this pre-correction time seems to be too long.
-
- Site Admin
- Posts: 8230
- Joined: Thu Oct 14, 2004 12:48 pm
The "pre correction" time is set by you... that's the PID delay.
I'm not sure why it would go down to 600 rpms then take a while to go back up... That says to me that the PID settings are wrong... When you let off the throttle, it shouldn't drop below the setpoint, then come back up, it should drop right to the setpoint, slowing down the correction as it gets closer to that point. Maybe I'm misunderstanding the problem you're describing.
The way it works is this:
P: Causes instantaneous change... the further you are from the target, the larger the change.
I: Causes buildup of error to make a change... so if your target is 800, and you're sitting at 850, eventually, over time, that 50 rpms will add up to enough error to cause the algorithm to decrease the duty.
D: Causes correction to slow down as you get closer to the target, but depends on how fast you're approaching the target
Ken
I'm not sure why it would go down to 600 rpms then take a while to go back up... That says to me that the PID settings are wrong... When you let off the throttle, it shouldn't drop below the setpoint, then come back up, it should drop right to the setpoint, slowing down the correction as it gets closer to that point. Maybe I'm misunderstanding the problem you're describing.
The way it works is this:
P: Causes instantaneous change... the further you are from the target, the larger the change.
I: Causes buildup of error to make a change... so if your target is 800, and you're sitting at 850, eventually, over time, that 50 rpms will add up to enough error to cause the algorithm to decrease the duty.
D: Causes correction to slow down as you get closer to the target, but depends on how fast you're approaching the target
Ken
No right now the PID values I have keep the rpm at my target of 800 and does a really good job doing so. I just meant that I have my min PID dc value set to keep rpms no lower than 600. So if PID wanted to, for whatever reason it could make rpms as low as 600. With my current PID settings, rpms scale right down to the target when I let off the throttle. The delay I am talking about is when I am idling at 800 (target) but then when the AC or something draws more power forcing the rpms to drop to say 700-750, it seems to take too long to bring the rpms back up to 800. Right now, PID will perfectly bring the rpms back but only after a few seconds (3-4 seconds). If I increase my P term any more, it will freak and when rpms go lower than the target, it will shot to 1000rpms and then because it's so much higher than the target, it will drop to the lowest DC possible. Right now it doens't do this because i've fine tuned the PID settings (I think) but the correction time lag when PID is active is annoying me. When rpms drop below 800, even by just a little, I want it to immediately correct right to the target, not over or under. This is how it works when stock. If I increase any of the values, it will only over/under correct.muythaibxr wrote:The "pre correction" time is set by you... that's the PID delay.
I'm not sure why it would go down to 600 rpms then take a while to go back up... That says to me that the PID settings are wrong... When you let off the throttle, it shouldn't drop below the setpoint, then come back up, it should drop right to the setpoint, slowing down the correction as it gets closer to that point. Maybe I'm misunderstanding the problem you're describing.
Ken
-
- Site Admin
- Posts: 8230
- Joined: Thu Oct 14, 2004 12:48 pm
you might want to tinker with making a higher "I" value then. It takes a few seconds to correct because RPM doesn't go that far from the target, and it takes a while for the integral error to build up and affect a change.
The stock system probably has a bit of a built-in "cheat" though... meaning it has an input from the AC button so the ECU knows that the AC is being turned on before the compressor is actually engaged. If I had enough I/O, I'd incorporate that, and a VSS to get everything perfect. Right now, as long as your engine doesn't stall, and eventually comes back to the right value, I think it's working as well as it can.
Ken
The stock system probably has a bit of a built-in "cheat" though... meaning it has an input from the AC button so the ECU knows that the AC is being turned on before the compressor is actually engaged. If I had enough I/O, I'd incorporate that, and a VSS to get everything perfect. Right now, as long as your engine doesn't stall, and eventually comes back to the right value, I think it's working as well as it can.
Ken
Last edited by muythaibxr on Wed Aug 08, 2007 9:10 am, edited 1 time in total.
-
- Super MS/Extra'er
- Posts: 2413
- Joined: Sun Mar 06, 2005 9:15 am
- Location: Chicago, IL, USA
- Contact:
Currently, my TPS is at 1%, so I cannot go any lower that with the current code. I guess I could jockey around my TPS calibration a bit, though. I have been lengthening the time variable and I can get it to be decent with A/C, but with A/C off, it seems like it waits too long before regulating. I'll play with it and see what works.
The pic was from yesterday's log.
This is a clip of today's (A/C on through this run):
http://ys3al35l.googlepages.com/stall.xls
Note that at one point during a coast in gear that MAP goes above the threshold and it starts ramping down idleDC (time 216242.5). I do not get the stall here because I am still in gear, but later when I actually depress the clutch (216333). Adding time to this will help and I'll see what happens as it gets longer. Right now I am at 2 sec, so I can add time to see how it behaves.
As for Matt's discussion of PID tuning. I think what we are fighting, a bit, is that the 'pulse' varies that we are trying to tune the engine response to. The 'pulse' is the dropping rpm when the engine braking pulls rpms down as we approach idle. In my case, my drpm/dt is drastically different with A/C on than without. I have not looked at it to compare, but in neutral with the clutch depressed, it falls through the rpm threshold rpm probably 2x as fast with A/C on as with it off. In other cases, it varies as well depending on how it entered idle (quick stab, let off, coast in gear, clutch, etc...). For a PID algorithm to work well, the system needs to be somewhat regular or at least consistent and any inconsistencies end up being a compromise with the PID constants.
Ken does not agree with me on this, but I feel if the IAC is closed during overrun and only opens as it crosses the rpm threshold (and is kept closed when the throttle is open) the Drpm/dt ends up being higher and more consistent for the PID loop to control. We can agree to disagree on this as he has more accurately duplicated what the OEMS successfully do, so it should be able to be tuned for many engines here as well. I did it the other way in MS1/E because that is what felt best for 1 installation, mine...
KeithG
The pic was from yesterday's log.
This is a clip of today's (A/C on through this run):
http://ys3al35l.googlepages.com/stall.xls
Note that at one point during a coast in gear that MAP goes above the threshold and it starts ramping down idleDC (time 216242.5). I do not get the stall here because I am still in gear, but later when I actually depress the clutch (216333). Adding time to this will help and I'll see what happens as it gets longer. Right now I am at 2 sec, so I can add time to see how it behaves.
As for Matt's discussion of PID tuning. I think what we are fighting, a bit, is that the 'pulse' varies that we are trying to tune the engine response to. The 'pulse' is the dropping rpm when the engine braking pulls rpms down as we approach idle. In my case, my drpm/dt is drastically different with A/C on than without. I have not looked at it to compare, but in neutral with the clutch depressed, it falls through the rpm threshold rpm probably 2x as fast with A/C on as with it off. In other cases, it varies as well depending on how it entered idle (quick stab, let off, coast in gear, clutch, etc...). For a PID algorithm to work well, the system needs to be somewhat regular or at least consistent and any inconsistencies end up being a compromise with the PID constants.
Ken does not agree with me on this, but I feel if the IAC is closed during overrun and only opens as it crosses the rpm threshold (and is kept closed when the throttle is open) the Drpm/dt ends up being higher and more consistent for the PID loop to control. We can agree to disagree on this as he has more accurately duplicated what the OEMS successfully do, so it should be able to be tuned for many engines here as well. I did it the other way in MS1/E because that is what felt best for 1 installation, mine...
KeithG
-
- Site Admin
- Posts: 8230
- Joined: Thu Oct 14, 2004 12:48 pm
You should probably just set the MAP value as close as possible to the idle kPa as you can... maybe 1-2 kPa less..Keithg wrote:Currently, my TPS is at 1%, so I cannot go any lower that with the current code. I guess I could jockey around my TPS calibration a bit, though. I have been lengthening the time variable and I can get it to be decent with A/C, but with A/C off, it seems like it waits too long before regulating. I'll play with it and see what works.
The pic was from yesterday's log.
This is a clip of today's (A/C on through this run):
http://ys3al35l.googlepages.com/stall.xls
Note that at one point during a coast in gear that MAP goes above the threshold and it starts ramping down idleDC (time 216242.5). I do not get the stall here because I am still in gear, but later when I actually depress the clutch (216333). Adding time to this will help and I'll see what happens as it gets longer. Right now I am at 2 sec, so I can add time to see how it behaves.
For 2.0, I think the code is working very well, and with the change to the TPS threshold to allow .1% units, I think your problem would be fixed. I'll try to get that into the next beta, which I'd like to release this weekend.
Barring any other problems, I want to release 2.0 within the next week or two.
In 2.1 I may try to add a few more small parameters to try to enhance the lockout code... but the main focus of 2.1 is going to be getting EAE to work better on hard stomps on engines that have small manifold volume compared to engine volume.
Ken
The only main problem I have is a spot of fluttering of the idle control valve, because it instantaneously goes to the closed value and instantaneously goes to the open value, which means that at the approx percentage of the crossover on the TPS I get fluttering.
I also get a big jerk if I don't pull away carefully as the ICV snaps shut. I'll have to play with my PID values because at the moment it doesn't catch it in time and then overcorrects.
I also get a big jerk if I don't pull away carefully as the ICV snaps shut. I'll have to play with my PID values because at the moment it doesn't catch it in time and then overcorrects.
-
- Site Admin
- Posts: 8230
- Joined: Thu Oct 14, 2004 12:48 pm