Once again - EGO control pid - rpm dependency

[W126]

I've found that the pid parameters are rpm dependend.

Using the Ziegler–Nichols method
https://en.wikipedia.org/wiki/PID_contr ... ols_method
to tune the pid parameters,
I ended up with the following values for idle (650 rpm) and 2000 rpm.

Idle
P = 42
I = 27.5
D = 16.1

2000 rpm
P = 39
I = 86.2
D = 4.4

These values work good. But the idle values don't work at 2000 rpm and vice versa.
That means the pid parameters are rpm dependend (I suppose load dependend too)
and I wonder how I could ever find values that work for any rpm.

Maybe there is something wrong with the pid algorithm ?

Jan

MS3 1.5.0
Tuner Studio 3.0.25

[nathaninwa]

Ironic you bring this up. I've installed a Pro in my tow rig and things are getting dialed good. I had ego control setup to basic and on Saturday on the drive home from the track I worked with pid settings to smooth out the narrow bandoscialtoon I was getting. I forget exactly, but pid numbers are 10/50/5. When I got home I noticed idle was all funky, going lean on me. So watching ego correction I could see it pulling a ton of fuel, going lean and gong back into narrow band type oscillation.

I worked around this by turning in the correction table and limiting ego correction to 8% then dialing in idle ve a little better

[muythaibxr]

Did you adjust the delay table?

[nathaninwa]

The delay table, I'll work with that. I'm headed to the race track on Saturday and play with along the way

[W126]

I use "Use IGN events", not "Use delay table".
It's alot of work to build a delay table.
Does the pid work better with the delay table ?

[muythaibxr]

Yes that is kinda the point of it. The amount of time it takes for changes to the PW to show as AFR difference changes with load and RPM. If this isn't tuned then PID won't work as well because it will be trying to make changes to PW more or less often than it can tell whether the changes made a difference.

[W126]

that makes perfectly sense. Technically lambda delay is a dead time.

But: How do I get a reasonable lambda delay table ? It has 12x12=144 cells.

Lambda Delay.jpg

Without a dyno, that isn't doable.

I have build a delay table for VEAL which has 9 cells and it took me hours.

[muythaibxr]

You can extrapolate from the VEAL one pretty easily. Just use that to fill in the MS one in the corners/edges, then fill the rest in linearly using TS's extrapolate function.

[W126]

OK, I'll give it a try.

[vw_chuck]

Pretty sure EGO delay and Lambda delay are two very different tables. They don't do the same thing. If they did then VEAL would just use the bigger one I would think. Why would they waste space making two tables that do the same thing in the code?

[elaw]

Different code, different timelines, but the tables are equivalent.

TS has had the delay table for VEAL for a long time because VEAL needs it. The EGO delay table in the MS firmware is a much more recent addition.

[vw_chuck]

Then why does Veal still have that table? Shouldn't Veal look to the higher resolution table and get rid of the little one?

[elaw]

I'm not 100% sure of this but I think VEAL may now be able to use the table in the firmware?

But it would still need to have its own to support other/older MS firmware versions that don't have the built-in table.

Also keep in mind that the MS firmware and Tunerstudio are written and maintained by different people with different goals and priorities. So while the EGO delay table was put in the firmware to meet some particular need, reworking VEAL would be done by a different person and may not be top priority for him.

[W126]

I've tried the ego delay table with P=42, I=28, D=15.
Here is the response to switching lambda target from 1.0 to 0.9 and vice versa.

Idle

42-28-15-idle-ego-delay.jpg

2000 rpm

42-28-15-2000-ego-delay.jpg

The ego control reacts worse than before (using ignition events).

The problem is that the pid parameters are rpm and load dependent.
As you can see here (sorry german) https://www.hs-koblenz.de/fileadmin/med ... such_3.pdf,
the pid parameters P, I and D are dependent on the dead time Tu, which is ego delay.

pid.jpg

So we need a table with pid parameters per load/rpm instead of ego delay.
Otherwise pid ego control will never work satisfying.

[wes kiser]

How are you populating the delay table? From a physical standpoint, the delay IS the reason for the rpm dependency.

[vw_chuck]

Fill in your EGO/lambda delay table correctly and see how it works. You need to log pulsewidth and AFR and when you change AFR target see what the delay is from when pulsewidth changes.

[W126]

I have interpolated from the VEAL table according to muythaibxrs suggestion.
Ofcourse the delay is the reason for the rpm dependency.
But what the actual pid algorithm does is simply wait <delay> milliseconds before applying a new correction.
That won't work.
The pid parameters P, I and D have to change with load and rpm.

[elaw]

I agree in principle... I actually did something like what you speak of with boost control. But I can see it being a real nightmare to tune!

One other thought: I'd think that if you had a really good handle on the sensor response time (taking into account not only the reaction time of the sensor itself but all the factors in the engine) you probably would not need I or D at all. I and D are there to compensate for response-vs-time issues of the controlled system, and if you can nullify those issues, they should not be necessary. Ideally even the P term would be really simple... if you know the fueling is off by 2% at a specific point, just add 2% and you're set.

Of course the above would only work perfectly in a perfect world, and in reality engines (and our characterizations of them) tend to be less than perfect.

[muythaibxr]

All I see in the logs is PID isn't tuned properly at idle or 2000 RPM. Could you tune out the oscillation at idle then show it oscillating or not reaching target at 2000 rpm? Also Wes's question is good. How are you determining delay?

[W126]

switched ego control to simple, measured time from ego correction minimum to lambda maximum respectively
ego correction maximum to lambda minimum.
Blue line to white line.

ego delay.jpg