gslender

iTrader: (1)

Ok, so this "Idle valve duty hystersis, based on RPM" has got Santa intrigued... tell me more... how do you see this working.... what do you want changed?

Cheers,
MegaSquirtSanta

PS - as you've all been good boys/girls, I've worked some magic on a release that has Clutch/Neutral input PE0 PID lockout so you can dribble along in gear and when you drop the clutch, only then it jumps into PID... Very Niiiiiccceee !!

Reverant

iTrader: (10)

Any more features you want to copy off my own firmware?

gslender

iTrader: (1)

I've added a few things to the 1st post regarding what is in testing, in works or planning to be released soon!!

gslender

iTrader: (1)

Depends, what are you willing to share?

bearda

The way I remember it what helped before was a user-defined deadband around the RPM target, so once an RPM within the band was achieved it stop changing the idle valve duty until the rpm fell out of the band. If you had an idle target of 900 RPM set up and a +- 50 band at 30% it wouldn't move from 30% until you went over 950 RPM or below 850. I'm not sure how that was implemented exactly (maybe a floor on the instantaneous error term) but when mariob did it it prevented some of the oscillation some of us experienced in (what should have been) steady-state.

Awesome. Can this be combined with a clutch launch control input on FLEX/PE0? I think a bunch of us may be wired up this way already.

gslender

iTrader: (1)

Ok, got it, and will re-look at this for a future release. Wouldn't just less D help here?

Greg - do you need this mod or is this a tuning issue with too much D?


Yep, it will continue to allow Launch control (if enabled) to work. I've actually also got a way to enable/disable launch based on clutch activation duty (I'll explain how later) so you can still disable launch, rev to 7,200 rpm (for whatever reason you need to do that) and then enable launch via the clutch with the launch retard to 4,500 etc... best of both worlds!!

Cheers,
MegaSquirtSanta

Greg G

Yes the RPM target hysteresis/deadband as implemented in the mario code will delay PID action. In my case, I eventually turned it off because it made droops so much worse. Of course with the AC idle up, it may not be so bad anymore.

Anyway I have suggestions which I think will make it much better, IMHO.

1. Make the deadband individually configurable above and below the target, instead of equally added to both sides of the target. That way, we avoid delayed action vs droop, but still get some benefit of a fatter target. Or if the user wants it equal, he can do so.

2. Change the output of the closed loop PID within the deadband by a user defined damping factor! If you want no reaction within the deadband, use a 100% damping factor. If you want PID to just be less jumpy, use 50% or whatever factor you wish.


Oh, and the antistall feature was pretty nice, as a failsafe feature. Below a set rpm (say <400), the idle valve would open up to prevent a stall. Did wonders for your peace of mind knowing that you couldn't stall (most of the time).

PeteNMA

The advantage of having the dead zone is that you can run aggressive PID settings to drive the idle duty quickly, but once you're close enough to your idle target the PID stops moving the valve which helps stop oscillation, which would make idle tuning a lot easier. It'd also make it a lot easier to get a car running on MS2 and functional faster, which can only be a good thing.

It was in the mariob tweaks but license terms couldn't be agreed so it never made it into the release code.

I'm not 100% sure how the current PID code works, if I'm right then it just loops constantly whilst watching the PID parameters. If so then a simple If, Then, Else based on a Min Idle RPM < current RPM < Max Idle RPM should be enough.

Greg G

Hmmm. Perhaps another condition for activation of the dead zone is a minimum RPMdot value. That way, the dead zone activates to stabilize idle when near target, but does not impede the action against fast changes (sudden droops).

JasonC SBB

I think there's a better way to implement hysteresis.

More later.....

Greg G

I discussed this with Jason, and his idea seems better! It's a moving hysteresis window, applied to the valve, not the rpm target. Basically it smoothness the signal by not allowing it to jumps of far from a set-width window, which constantly adjusts based on the input. I'll let him do the explaining. Basically, it calms the jittery valve duty but does not affect pid action.

Here's his explanation (he discusses tps dot but it will be applied in our case to idle valve duty output):

richyvrlimited

iTrader: (1)

Man I love collaborative efforts like this.

Great job guys!

JasonC SBB

Pls. read my posts in this thread:

http://www.msextra.com/forums/viewto...301785#p301785

The hysteretic window is good for filtering the *output* of a feedback loop, such as the PWM signal that goes to the idle solenoid. It greatly reduces any "shivering" or hunting around of the solenoid. It is a bad idea to use it for the input signal such as RPM. Greg found this out firsthand.

The appropriate filter for an *input* signal, such as the RPM signal for the idle control loop, or the MAP signal, is a "Bessel" lopass filter.
I gave a sample in the above msextra link.

PeteNMA

That sounds great. My question as a code outsider is can that be coded in such a way as to not use a whole heap of CPU time and also to fit into the remaining flash space?

Greg G

Ooooh I like it. My valve duty graph looks exactly like that! Smoothening the output might just be the ticket to a calm yet reactive steady state idle.

Reposting the explanation:
See pictures explain it so much better

JasonC SBB

Santa,

If I may suggest ... the whole idle strategy needs to be re-architected.

The main changes I suggest are these:
- the idle_duty% is: lookup table values + feedforward values + PID

- PID always turned off if the wheels are connected to engine, but all lookup tables and feedforward *always* active in determining duty%

- TPS > 0 exits PID

- Whenever PID (closed loop) exits, I is *always* reset to zero

- the output of I has to have a + and a - limit. That is, e.g. it can never add mroe than say, 15%, or remove more than 10% from the output.

- Whenever closed loop is re-entered, I *always* has to be reset to zero

- Whenever closed loop is re-entered there should be a "closed loop re-entry target RPM adder". This stays for like 1 sec, and then the target ramps down to the normal target over say, 3 sec. For example, target will initially be 1200 RPM upon re-entry. This target will stay for 1 sec, then ramp down to 850 over 3 seconds. This will solve the stopping-at-a-stop-sign idle dip, and it will also work well for stepping on the clutch when lugging the engine at 600 RPM.

- having a good set of feedforward setups is critical: a/c, voltage, IAT, etc.

Greg G

Jason and I had a long discussion last night about this. Mainly because my supercharger belt had broken on the dyno, so I had to drive home through a major traffic jam with no AC. So I had a good hour's data of crawling through stop and go traffic to observe the low speed stop and go behavior of the pid code. My car has no radio, so all I could do to entertain myself was watch the idle duty (how sad is that)

So yes I agree that:

1. The conditions for closed loop entry are a big factor. Having it active while in gear, especially in 'parking lot' driving conditions- say you are decelerating slowly driving up a slight slope, and enter closed loop. You slip the clutch to maintain a slow speed going up that slope. That drives the pid crazy and it drives the idle valve duty higher and higher. Then you let up the clutch to stop, bam! Idle shoots up to 1,600 or something like that.

The reverse is true if youre cruising down to a stop and you enter closed loop early- the pid code wants to close the valve so drops it to minumum value. When you clutch in, you get a droop.

These actions are mainly driven by the I term, and is called "integral windup". Since it never seems to get to target, it keeps adding and adding or subtracting and subtracting. This is solved in 3 ways- put a maximum limit on the I output, reset I on closed loop exit, and modify the entry to closed loop with a hardware mod. This can be a vss input(ms3), or a clutch neutral switch condition for closed loop entry (great mod pioneered by reverant).

2. The calculation of the idle valve duty must be improved over the current 'last known good' value, and correlated to the clt table (like warmup only mode) plus the feedforward factors like battery voltage correction, mat correction, AC input. You want to enter closed loop idle at a duty value spot on for the conditions, to get smooth entry. Presently it's something like "get it in the ballpark and let pid deal with it". Perhaps just a straight clt table lookup modified by the various feedforward adders will give a better consistent value. Like the best of both world between warmup only and close loop idle modes...

The code is pretty good already, but I think these improvements will have a real tangible effect and bring it to near oem level.

Found some good reading here:
http://chriswilson.tv/PID.pdf

PeteNMA

Another thing that the mariob code did was to use the open loop idle duty table to provide a known good value. The use of that table in conjunction with some pre-determined adders for A/C, headlights, etc may be a good place to start, and uses something that's already in the code

JasonC SBB

Note the following:

"Last known good value" alludes the last 'I' value be used. This is a mistake, it should be reset to zero.

"Last known value" alludes to "remembering" some kind of last value. Not really any different.

Here is why freezing or remembering the I value is bad.
For example, I is at -10% for some reason idling at a light, then you drive off.
You then encounter traffic and crawl the car in 1st gear with foot off of clutch, and let RPM drop to 700 RPM. You then push in the clutch. If you use I=-10%, the engine will die. You are better off with I=0. When PID is re-entered with RPM=700, the P will instantly add lots of duty cycle to get the RPM to rise rapidly.

Or if RPM is dropping very rapidly because you put it in neutral with RPM=2000. When it re-enters closed loop at say 1200, the D sees the dropping RPM and will output lots of additional duty in order to slow the RPM descent.


The correct approach is to use the various lookup tables all the time, even when not in idle. This replaces the phrase "last known value". This way the extra duty is there when a/c is on, etc.


If you want to get real fancy, you want an adaptive control scheme. This is like auto-tuning, where said lookup values and lookup tables are adjusted slowly over time.

Greg G

I was playing around with the scatter plot feature in MLV, and I think I figured out how to demonstrate the need for MAT idle valve duty correction!

Same data, presented 2 ways.


As you can see, at > ~128 MAT, the idle valve is not a happy camper. At that temp I suppose the air is significantly less dense that the valve has to open wider to maintain the RPM. If we put a feedforward mechanism to add a user defined amount of duty above a user defined base RPM, we automatically compensate for the lower air density and keep the PID happier/less involved. Proaction is better than reaction. Which hopefully leads to a stabler idle. A lot like the battery voltage correction, and the AC idle up.

Why MAT? Why not CLT? Here's why:


Once the engine is at operating temp, you can't see any clear change in idle valve duty based on CLT.

So yes please, to MAT based idle valve duty correction as a feedforward mechanism