Idle Control Algorithms - Brainstorming

Official FreeEMS vanilla firmware development, the heart and soul of the system!
User avatar
BenFenner
LQFP144 - On Top Of The Game
Posts: 360
Joined: Wed Jul 09, 2008 3:15 pm

Re: Idle Control Algorithms - Brainstorming

Post by BenFenner »

BenFenner wrote:I'd like to see ignition timing trim versus idle error/delta. 2D table.
Newb explanation:

You have a target idle rate (in RPM) at any time. You also have the actual RPM of the engine at any time. There will always be a difference between these two. This difference is called the idle error. Basically, how off is the engine RPM from your requested RPM at that time?

For example, let's say you're asking for 850 RPM in your tune at this particular time. The cam/crank angle sensor is reporting 900 RPM for the tach signal. You have an error of +50 RPM.

Another example, let's say you're asking for 850 RPM in your tune at this particular time. The cam/crank angle sensor is reporting 775 RPM for the tach signal. You have an error of -75 RPM.

Got it?


With this error, you know if the engine is too slow, or too fast, and by how much.

This is used to determine an "ignition trim" or ignition timing advance/retard value which will be applied to the final ignition timing value used by the engine. This is helpful because advancing ignition on an otherwise uncontrolled engine will increase RPM. And likewise retarding ignition will decrease RPM on an otherwise uncontrolled engine.

So you have a 2D table with 0 error in the middle and positive RPM error on the right (engine is spinning too quickly) and negative RPM error on the left (engine is spinning too slowly) with maximum error maybe from -300 to +300 RPM.
Typically as error goes left on the table you advance timing to speed the engine up. As error goes right on the table you remove timing to slow the engine down.

This is actually the first line of defense when it comes to idle control since ignition timing works so quickly and subtly.


BenFenner wrote:Next is obvious; fuel trim versus idle error/delta. 2D table.
Almost identical to the example above, this idle control works because enriching the air/fuel mixture tends to slow the spinning rate of the engine. Leaning out the mixture (to a point) tends to raise the stable rate of the engine.

This is used as the second line of defense when it comes to idle control because it works almost as quickly and almost as subtly as the ignition timing changes.
User avatar
Fred
Moderator
Posts: 15431
Joined: Tue Jan 15, 2008 2:31 pm
Location: Home sweet home!
Contact:

Re: Idle Control Algorithms - Brainstorming

Post by Fred »

Why simple curves, why not PID?
DIYEFI.org - where Open Source means Open Source, and Free means Freedom
FreeEMS.org - the open source engine management system
FreeEMS dev diary and its comments thread and my turbo truck!
n00bs, do NOT PM or email tech questions! Use the forum!
The ever growing list of FreeEMS success stories!
User avatar
BenFenner
LQFP144 - On Top Of The Game
Posts: 360
Joined: Wed Jul 09, 2008 3:15 pm

Re: Idle Control Algorithms - Brainstorming

Post by BenFenner »

I'm not sure I have a good answer to that question. Possibly for simplicity of tuning and possibly for simplicity and predictability of the trims?
I do know with 2D curves you can build in your own dead-band intuitively and easily.
asx
TO220 - Visibile
Posts: 6
Joined: Tue Feb 08, 2011 12:58 pm

Re: Idle Control Algorithms - Brainstorming

Post by asx »

Here's what I'd want: (X is any user settable value)

PID activated on TPS <= X.damn_near_zero
Check if engine braking or returning to idle. Not sure on this implementation (RPMdot and Map?). Can use i/o on clutch switch and neutral switch, but I'd make it optional.

If engine braking, set idle valve to Coast_down value (or pull value from 3D Initial Duty Cycle Table)
(Ignore if using 3D IDC table) Coast_Down value should either a 2x2 2D table or just 2 different values such that at above RPM X use Coast_down_X else use Coast_Down_Y. This way when driving aggressively/racing (Coast_Down_X) the idle valve is near closed making RPMs drop quickly and allows for quick and smooth shifts, but when i'm putzing around town (Coast_Down_Y) the valve is more open on lift, slowing RPM drop and allowing me to shift more slowly and smoothly. This saves my synchros if I would have had to shift quickly all the time or my clutch from having to slip&blip between gears if I really wanted to shift slowly (and look like a jerky noob because my 6puck clutch doesn't like to be slipped)
If returning to idle, set idle valve to appropriate Coast_Down value and let revs drop until RPM<=X.Fast_idle (~2k RPM or so for most users?) pull Initial Duty Cycle value from small (4x4?) 3D IAT (or CHT) vs Target RPM table and start PID code.

On engine cranking compare CHT to IAT to check for a hot start condition, add a user set value to both the RPM target and the idle valve duty cycle for a user set time period (typ. 30 seconds) to help with hot start leanness. It's not a big deal, but I get embarrassed having to crank my car multiple times because I refuse to put my foot in it to keep it running because I shouldn't have to.
Last edited by asx on Sat Aug 18, 2012 6:07 am, edited 1 time in total.
User avatar
Fred
Moderator
Posts: 15431
Joined: Tue Jan 15, 2008 2:31 pm
Location: Home sweet home!
Contact:

Re: Idle Control Algorithms - Brainstorming

Post by Fred »

Care to re-write some of that without the (meaningless) MegaSquirt-specific jargon? Or by dashpot do you mean this: https://en.wikipedia.org/wiki/Dashpot and if you do, how can you set idle to a rate of change/friction value?

The valve definitely needs to be closed most of the time for optimal engine braking and normal "feel".

The car that I'm driving at the moment has obnoxious idle control. It tries to maintain idle rpm while in gear and slowing down. Result: You can't go slower than X speed for each gear, which is utter bullshit.

Your post was 100% about air control, right? Good stuff, but I'm also looking for input on fueling and timing controls specific to idling well. Just for the record.

Fred.

Here's what I'd want: (X is any user settable value)

PID activated on TPS <= X.damn_near_zero
Check if engine braking or returning to idle. Not sure on this implementation (RPMdot and Map?). Can use i/o on clutch switch and neutral switch, but I'd make it optional.

If engine braking, set idle valve to dashpot value (any way we can have a 2D table for dashpot values vs RPM? or even just dasphot = X.low_dcycle @ X.high_rpm<RPM else dashpot = X.high_dcycle. This way when driving aggressively / racing the idle valve is near closed making RPMs drop quickly and allows for quicker/smoother shifts, but when i'm putzing around town the valve is more open on lift, slowing RPM drop and allowing me to shift more slowly (and not put excessive wear on my synchros).

If returning to idle, set idle valve to dashpot value and let revs drop until RPM<=X.Fast_idle (~2k RPM or so for most users?) pull Initial Duty Cycle value from 3D IAT vs Target RPM table and start PID code.
DIYEFI.org - where Open Source means Open Source, and Free means Freedom
FreeEMS.org - the open source engine management system
FreeEMS dev diary and its comments thread and my turbo truck!
n00bs, do NOT PM or email tech questions! Use the forum!
The ever growing list of FreeEMS success stories!
asx
TO220 - Visibile
Posts: 6
Joined: Tue Feb 08, 2011 12:58 pm

Re: Idle Control Algorithms - Brainstorming

Post by asx »

I did mean dash pot in the MS terminology, yes. Personally, I think the terminology fits since the main purpose is t hold the rpms high when returning to idle to prevent stalls, but i can see the lack of clarity is an issue. I'll cleanup my post tonight (3-6hrs) when I can get on something with a real keyboard instead of my phone.

I both agree and disagree about closing the valve. My miata (99) is effectively completely reliant on the idle valve. With the throttle closed, valve closed, and clutch disengaged (from the flywheel), there is too much engine braking. It is great for shifting quickly as the rpms fall quickly, but far too fast when I'm leisurely shifting. With the clutch engaged (locked to the flywheel) It is good for coasting down steep hills, but too "jumpy" when freeway driving and it sheds far too much speed when going down small hills. What about an option to close the valve / overwrite valve duty cycle in the engine braking / fuel cut on overrun code?

Personally, i like using the idle control to lug me around in heavy traffic and parking lots. There can definitely be a safety issue if the idle code is badly tuned and the valve "runs away." Not sure how to avoid that beyond being able to set a max RPM after which you are kicked out of the control loop and a new initial duty cycle is pulled on reentry. This is one of the reasons why storing/reusing the last duty cycle used is the devil.

I don't really have any comments on idle specific fuel/spark controls. Most ECUs I've dealt with either have more than enough table resolution to dedicate a couple columns to idle rpms, or they had small idle trim tables, or I took advantage of map switching to give one table a lot of low rpm low map resolution and then switch at boost onset to a table with a lot of high map high rpm resolution.

On a semi related note, how do you feel about fuzzy logic vs pid? I think that for novice users its a lot easier to tune the fuzzy logic values (i.e. O.E. 16bit subaru ecu boost control) than understand PID, BUT that could be fixed by good documentation, which I sure as hell haven't seen from a certain s12c based ecu.
User avatar
Fred
Moderator
Posts: 15431
Joined: Tue Jan 15, 2008 2:31 pm
Location: Home sweet home!
Contact:

Re: Idle Control Algorithms - Brainstorming

Post by Fred »

asx wrote:I did mean dash pot in the MS terminology, yes. Personally, I think the terminology fits
Until I searched, JUST before I posted, I didn't know that a dashpot was something other than a potentiometer on your dash. I had no idea that it was a term for a damper. Which likely explains my disdain for that aspect of their terminology, though I still think it's unclear.
the main purpose is t hold the rpms high when returning to idle to prevent stalls, but i can see the lack of clarity is an issue.
This seems like a weird thing to have to do. I've driven quite a few different cars, and as far as I can recall, none of them held the RPM artificially high post revving just to prevent stalling out. They just naturally fell back down to their steady state. The closer they get to that, the less they are decelerating anyway.
I'll cleanup my post tonight (3-6hrs) when I can get on something with a real keyboard instead of my phone.
Cool, I grabbed a copy as-is in tiny format in my post for reference, go nuts, if you want :-)
I both agree and disagree about closing the valve.
This paragraph made me think about some behaviour that I experienced where tip-in was ruthless (negative torque to considerable positive torque in a step), I wonder if that's what you mean?
My miata (99) is effectively completely reliant on the idle valve.
As are many modern engines.
With the throttle closed, valve closed, and clutch disengaged (from the flywheel), there is too much engine braking.
I'm not sure there is such a thing. Driven an older diesel? They engine break enough to swing the arse out in a corner, and I love it :-)
It is great for shifting quickly as the rpms fall quickly, but far too fast when I'm leisurely shifting. With the clutch engaged (locked to the flywheel) It is good for coasting down steep hills, but too "jumpy" when freeway driving and it sheds far too much speed when going down small hills.
Clearly this trailing throttle air flow would be user settable, not necessarily zero by default. I can see it being a problem, maybe, but even if you leave the shifting for 5 minutes and it's sitting at idle, it's just going to come back up to match with a tiny bit of clutch slip.
What about an option to close the valve / overwrite valve duty cycle in the engine braking / fuel cut on overrun code?
I'm not sure that it's necessary. Motec engineers call it "feed forward" and I call it "essential" to have an open loop tune of what you want before PID takes effect at all. This is certainly how it'll work. For the given conditions, TPS, RPM, CHT, ? there will be a particular duty as a base and the PID, if even used, will act with that as a foundation adding to or subtracting from this. You can't have a PID loop work properly without it, period. If some clowns elsewhere tell you otherwise, ignore them, their credentials are shady at best.
Personally, i like using the idle control to lug me around in heavy traffic and parking lots.
Sure, that's a personal choice. I prefer the natural torque level, though, not one that increases with sustained RPM differential.
There can definitely be a safety issue if the idle code is badly tuned and the valve "runs away." Not sure how to avoid that beyond being able to set a max RPM after which you are kicked out of the control loop and a new initial duty cycle is pulled on reentry. This is one of the reasons why storing/reusing the last duty cycle used is the devil.
What sort of idiots do that? Wait, don't answer that.
I don't really have any comments on idle specific fuel/spark controls. Most ECUs I've dealt with either have more than enough table resolution to dedicate a couple columns to idle rpms, or they had small idle trim tables, or I took advantage of map switching to give one table a lot of low rpm low map resolution and then switch at boost onset to a table with a lot of high map high rpm resolution.

What do you mean by "small idle trim tables"? This is likely what I'm referring to and trying to come up with a rough design for.
On a semi related note, how do you feel about fuzzy logic vs pid? I think that for novice users its a lot easier to tune the fuzzy logic values (i.e. O.E. 16bit subaru ecu boost control) than understand PID
I have no opinion, educate me! :-)
, BUT that could be fixed by good documentation, which I sure as hell haven't seen from a certain s12c based ecu.
LOL, I have no idea what you mean.

Fred.
DIYEFI.org - where Open Source means Open Source, and Free means Freedom
FreeEMS.org - the open source engine management system
FreeEMS dev diary and its comments thread and my turbo truck!
n00bs, do NOT PM or email tech questions! Use the forum!
The ever growing list of FreeEMS success stories!
asx
TO220 - Visibile
Posts: 6
Joined: Tue Feb 08, 2011 12:58 pm

Re: Idle Control Algorithms - Brainstorming

Post by asx »

Phone post again.

Re:dashpots. Again I was unclear. If you're familiar with carbed cars they hold the throttle open to physically damp throttle closing

Re:deltaT (Torque) jerkiness. Pretty much, except the positive torque at tip-in is constant and there's too much negative torque with the idle valve closed on decel so it's hard to transition smoothly. So with the valve more open on decel (MS speak = dash pot) I decreased the negative torque (more positive) so that the deltaT is lower and I get less jerk on tip-in

Re:feed forward. I agree feed forward is mandatory. I was grasping for that term when I said "pull initial duty cycle values from 3d table..." in my first post but couldn't remember it from my systems engineering class. Also I meant that on overrun/coast down/whatever you'd cut fuel then close the valve.
Possibly on tip in if it's less than like 10% throttle you could open the valve first and then turn the fuel back on to soften the torque transition. Could be kind of dangerous if set wrong though. Stab the throttle and get nothing? Scary. I'd have to think about it . Oooh I get what you're saying. You're thinking a map vs rpm initial duty table that covers the full rpm & load range where I was talking about a small map just around target idle? I think the full map would be a good thing.

Re:trim tables. 3d tables that would have map on the y axis and either rpm or rpm.error from the idle code. So you could either have a super zoomed in version of your main fuel/spark map that switches at like rpm < x & tps=0
(Map vs rpm ala ms1extra and kind of shitty) or you could trim the spark/fuel +/- based on the rpm.error from the idle code. The gslender modified ms2extra firmware does this. I haven't gotten a chance to play with them yet.

Re: fuzzy logic. This is how the wrx 16bit ECUs boost control works (I would assume the idle works similarly, but I never paid much attention to it because I wanna go fast). 2 3d tables and 1 2d. A 3d table for initial duty cycle (IDC table) (load vs rpm), a 3d table for boost target (load vs rpm), and a 2d table for the fuzzy logic (action vs boost.error) (I think it was called transient boost duty or something?). It "fedforward" the initial valve position from the IDC table and calculated a boost error from the target table. I believe the fuzzy logic table had something like 6 columns corresponding to an amount to raise/lower the duty cycle.
Way too little boost was a big duty cycle jump
still not enough boost = medium jump
almost enough = small jump
close enough = no jump
a touch too much = tiny drop (about half the jump from almost enough IIRC)
too damn much! = medium drop

It was pretty easy to understand (Intuitive even) but did mean that there was almost always some static error, but IIRC it was too small to notice. I'm not sure how well this translates into idle control.
User avatar
Fred
Moderator
Posts: 15431
Joined: Tue Jan 15, 2008 2:31 pm
Location: Home sweet home!
Contact:

Re: Idle Control Algorithms - Brainstorming

Post by Fred »

Good stuff! Thanks :-)

About "dashpot" vs "coastdown", my confusion was rooted in using carburetor terms AND behaviour with relation to an electronic system with vastly more sophistication. Plus, I swear I've dropped carby plates closed and watched them snap shut and not be damped. Another source of confusion is using 2 values for this rather than a table and simply calling it IdleBaseDuty RPM vs. duty, or something. The warm up stuff could just be done with a percentage change over base depending on temperature. The idle rpm target over temperature should match the open loop curve pretty closely or PID will be working harder than it has to, and, consequently doing a worse job than it could be.

So, then:

2D curve of base airflow (PWM or stepper or whatever) vs RPM (modern equivalent to carby dashpot/damper)
2D curve of percentage change over base based on temperature (provides suitable airflow for cold conditions)
2D curve of desired RPM vs temperature. (provides suitable RPM for cold conditions, should match above)
PID tuning values and conditions etc to stop it doing stupid things. (tuned and setup for vehicle in question)

Done. Or not? :-)

Fred.
DIYEFI.org - where Open Source means Open Source, and Free means Freedom
FreeEMS.org - the open source engine management system
FreeEMS dev diary and its comments thread and my turbo truck!
n00bs, do NOT PM or email tech questions! Use the forum!
The ever growing list of FreeEMS success stories!
asx
TO220 - Visibile
Posts: 6
Joined: Tue Feb 08, 2011 12:58 pm

Re: Idle Control Algorithms - Brainstorming

Post by asx »

I concur. :)

Edit: the 2 value deal was more about a minimum workable solution. A 2d curve would be a much cleaner and transparent solution
Post Reply