EGO PID Control

[Ballistic]

I've been using the wideband EGO PID/Smith Predictor control algorithm for a while now, but aside from lowering Transport delay 2 from the default of 4000 to 800, I hadn't changed any of the other settings.

I wasn't able to find a guide to these settings, and it seemed to work OK while cruising so I let it go, but I was getting some occillation at certain RPMs and loads.

What follows is my understanding and I welcome corrections if I'm misguided:

The total transport delay is the time difference between when fuel is injected, combusted, exhausted, read by the O2 sensor and then sent by the O2 sensor controller to MegaSquirt.

Total transport delay (ms) = Transport delay 1(ms) + Transport delay 2(ms)

However, Transport delay 2 time is calculated from the Transport delay 2 (rpm) bin in MegaTune.

I think it would be helpful if in MT the rpm bin for calculating Transport delay 2 would be labeled as "RPM Factor for Transport Delay 2" or some such. It's confusing to assign units of rpm for a time factor.

I derived an rpm to enter in this bin by viewing datalogs I had used for tuning AE and finding the time differential between the end of a too large "pump shot" and the deepest part of the resulting too rich AFR valley. I'm sure there is plenty of opportunity for error here, but it at least gave me a starting point. I averaged six data points to arrive at an rpm of 950.

Solve this equation to find rpm: (T x MAP x rpm)/12000 = rpm

Where:

• T = observed transport delay time (ms) - Transport delay 1 (ms)
  MAP = MAP value in kPa at data point
  rpm = rpm at data point (I averaged the rpm and MAP values from the two data points to get a single value)

i.e. for a 0.213 s delay at 42 kPa and 1294 rpm, I get ((213-10)*42*1294)/12000 = 919 rpm

I'm confused by the units displayed in MT for the PID control variables as percent is shown for each. I'm not sure what units should apply to the Proportional gain term. Is it dimensionless? Shouldn't the Integral and Derivitive parameters be in units of time?

Some information from Wikipedia:

1.Kp: Proportional Gain - Larger Kp typically means faster response since the larger the error, the larger the feedback to compensate.
2.Ki: Integral Gain - Larger Ki implies steady state errors are eliminated quicker. The tradeoff is larger overshoot: any negative error integrated during transient response must be integrated away by positive error before we reach steady state.
3.Kd: Derivative Gain - Larger Kd decreases overshoot, but slows down transient response.

Effects of increasing parameters
Parameter:
. . . . Rise Time : . .Overshoot :Settling Time: S.S. ErrorSteady State?)
P: . . Decrease . . .Increase . . .Sm.Change . .Decrease
I: . . .Decrease . . .Increase . . . Increase . . . . Eliminate
D: . .Sm.Change .Decrease . . Decrease . . . .Small Change

I'm currently using:
10 ms
950 rpm
P = 25
I = 15
D = 5

I need to datalog more to see if these values need to be changed, but for an initial guess they seem to work pretty good. The occillation is gone, and the EGO correction moves to a value and holds.

[grippo]

You are only the 2nd to try this so bear with us as we all learn how this works. I believe the eq you are using is intended to give you a slope or coefficient that doesn't really have units. It assumes you have a measured transport delay at a fixed rpm and map value, e.g, at idle, and you can put the specific rpm, map and measured delay into the eq and you get out a program input (KDly2) needed by the MS II code to approximate the transport delay at any arbitrary rpm and map. KDly1 is the sensor response delay and include the averaging done by whatever WB interface system you are using. You could get some idea of the K2 delay by estimating exhaust flow velocity and measuring pipe/ port lengths or by maybe using a spare port to energize a solenoid to squirt a small single shot of extra gas into the intake at a fixed time. You then datalog everything and measure how long it took from the time the solenoid was energized to when the extra gas showed up on the afr reading.

Look at the beta lsit thread by Dave Edge. For the last few days he has been posting logs of his experiences.

[Ballistic]

I'm continuing to get good results with consistant AFRs. AutoTune seems less flakey since Gego is more stable.

I've changed to a more EFI friendly cam, so I've been repeating some of my AE and VE table tuning.

. . . squirt a small single shot of extra gas into the intake at a fixed time. You then datalog everything and measure how long it took from the time the solenoid was energized to when the extra gas showed up on the afr reading.

Since my smaller cam needs less AE, datalogging under burst mode allowed me to do essentially what you've described, just not at steady state conditions.

[Ballistic]

Update:

This continues to work very well. The only parameter I've changed from my initial guessed at settings is the proportional term from 25 to 33 to 50.

I'm now using:
10 ms
950 rpm
P = 50
I = 15
D = 5