EGO correction offset with just P-term

This is a forum for discussing the development and testing of alpha MS2/Extra code. Documentation
(Runs on MS2 and Microsquirt)

Moderators: jsmcortina, muythaibxr

Post Reply
mrx79
Experienced MS/Extra'er
Posts: 299
Joined: Wed Oct 29, 2008 8:26 am
Location: Frankfurt / Germany

EGO correction offset with just P-term

Post by mrx79 »

Hi,

today i wanted to do some bench testing of the EGO control after i've seen the PID_scaling_factor during some code studies and i wanted to know how if effects my PID settings. For this i disabled the I and D term and wanted to see how the scaling factor effects P output.

While testing this, i found, that somehow, the EGO correction was somehow offset shifted and was not 100% (zero correction) when AFR=AFR target.
With some experiments i found, that if the controller is activated with an offset between afr and afr_target this becomes the new zero correction point. From there richer lambda result in lower then 100% corrections and leaner to bigger then 100% corrections like it should be. Just with an offset.

If the controller activation conditions are met while afr=afr_target, everything works fine.

Maybe also soneone can give me some more background informations about the PID scaling factor... if the correction is %age, why does the req_fuel value matter?
Honda CRX B16A1 Turbo | MS3 running | pre1.5.1 beta7 Firmware | 24/1 Dual Wheel | COP ignition | 725cc ID injectors
mrx79
Experienced MS/Extra'er
Posts: 299
Joined: Wed Oct 29, 2008 8:26 am
Location: Frankfurt / Germany

Re: EGO correction offset with just P-term

Post by mrx79 »

Hi,

i'am not sure, but maybe found something.
From my understanding of a PID controller, the P-Term should be:

Code: Select all

e = afrtarget - afr
p_term = kp * e
but in the code you find:

Code: Select all

uctmp = (ego < 90) ? 90 : ego;
PV = ((long)(uctmp - 90) * 10000L) / 110L;
Kp = ((long)(PV - PVarray[0]) * flash4.egoKP);
PVarray[1] = PVarray[0];
PVarray[0] = PV;
with PV equals afr (unitless converted number)
and PVarray just a time delay'ed version of PV
and Kp = PV-PVarray[0] * ecoKP
then Kp (p-term) would be an aplified value of the delta between the current and the last actual afr.

This doesn't make much sens for me, as Kp (p-term in the code) would never become zero, even if afr = afr_target, as afr_target is not part of the equation.
Also the output of ego_closed_loop_pid_dopid (egostep) is always integrated into egocor_100 with all three parts (kp, ki and kd)

Does this mean that the PID controller is not a clasical one, but only PID of the step size of the intervention?!?
I always thought that PID EGO control in MS is a classical PID approach of deviation between target and actual value.

Best regards
Malte.
Honda CRX B16A1 Turbo | MS3 running | pre1.5.1 beta7 Firmware | 24/1 Dual Wheel | COP ignition | 725cc ID injectors
muythaibxr
Site Admin
Posts: 8228
Joined: Thu Oct 14, 2004 12:48 pm

Re: EGO correction offset with just P-term

Post by muythaibxr »

Please use the search function. Most of the PID algos we use are not ideal PID, they are discrete PID. http://bestune.50megs.com/typeABC.htm

We are using type C.
Megasquirt is not for use on pollution controlled vehicles. Any advice I give is for off road use only.
robs
Master MS/Extra'er
Posts: 564
Joined: Sun Jan 17, 2010 4:26 pm
Location: Sydney, Australia

Re: EGO correction offset with just P-term

Post by robs »

That's very interesting.

I've only skimmed the link and will study it more closely, but type C looks like it won't have any idea where to go unless the "I" term (K_i) is non-zero. Have to admit I assumed you could simulate the simple algorithm by setting a P value with I and D zero.

Have fun,

Rob.
muythaibxr
Site Admin
Posts: 8228
Joined: Thu Oct 14, 2004 12:48 pm

Re: EGO correction offset with just P-term

Post by muythaibxr »

Correct. With that kind of PID you have to set I to reach target.
Megasquirt is not for use on pollution controlled vehicles. Any advice I give is for off road use only.
robs
Master MS/Extra'er
Posts: 564
Joined: Sun Jan 17, 2010 4:26 pm
Location: Sydney, Australia

Re: EGO correction offset with just P-term

Post by robs »

I have a general interest in this so I spent some time yesterday trying the discrete PID (type A and C) formulas in a simulator I had written some time ago. Certainly different from continuous PID. Here's a comparison plot of discrete (red) and continuous (blue) aiming for a PV of 50.
pid.jpg
Two points:
  • The discrete PID stuff definitely reacted much more quickly to a change of setpoint and very quickly stabilised near the correct value but, try as I might, I couldn't get it to hold on the right value. Besides picking my own PID values I tried out various algorithms -- Zeigler-Nichols and ITAE-Load but no go.
  • Tuning the PID parameters is very different. Tuning continuous you typically start with some P, then add a bit of D and, maybe/maybe not mix in some I. For the discrete PID you definitely start with some I and blend in P. Took quite a bit of D to have any effect, and it generally wasn't what I wanted.
On the first point, quick adjustment to a new setpoint seems really desirable with EGO feedback (say) and being off by a smidge is no biggie. The second point seems more important. Previous experience can lead you down the garden path and it'd be good to see a worked MS/Extra example (a quick Google didn't turn much up for me).

Interesting stuff anyway.

Have fun,

Rob.
mrx79
Experienced MS/Extra'er
Posts: 299
Joined: Wed Oct 29, 2008 8:26 am
Location: Frankfurt / Germany

Re: EGO correction offset with just P-term

Post by mrx79 »

Hi Rob,

which discrete PID is the red line? Type A or C, because this makes quite a difference?
What i find a bit questionable is the fact that in the Type C has only the control deviation in the I-Term. And all examples i could find (had found some interesting discussions with the author of the Type C algorithm in some PID controller forums and others seem to share my thoughts) concentrate on following a setpoint jump.

But especialy in a EGO controller, the controler must be robust for disturbances, as this is what we usualy need the controller for.
A setpoint change can also occure, but for this we also have the precontrol as well which usualy does a good job.

When you analyze the formula a bit more closely, the P-Termin the Type C controller seems more to have the effect of a classic D-Term (without setpoint influence of course). The D-Term has some side to side swing effect, so first supports the direction of PV and in the following calculation cycle reacts on the opposite direction.

I'am wondering that not much more ppl ask questions, as the tuning strategy of the PID terms must be much different from a classical PID approach.
Maybe because much ppl use the controller (like me currently) more like a I-Controller support for small deviations of the map and ignore the benefit's of a realy good tuned PID controller to generate a much more robust system behaviour?!
Honda CRX B16A1 Turbo | MS3 running | pre1.5.1 beta7 Firmware | 24/1 Dual Wheel | COP ignition | 725cc ID injectors
dontz125
Super MS/Extra'er
Posts: 4200
Joined: Mon May 11, 2009 7:14 pm
Location: York, ON
Contact:

Re: EGO correction offset with just P-term

Post by dontz125 »

I would suggest that the vast majority of MS users have never heard of PID tuning before trying to tune in their unit, and have no basis on which to compare different tuning techniques. From some of the questions asked, I would suggest a not-uncommon technique seems to be to throw numbers at it almost at random and hope something improves.
QuadraMAP Sensor Module -- PWM-to-Stepper Controller -- Dual Coil Driver
Coming soon: OctoMAP Sensor Module
TTR Ignition Systems
robs
Master MS/Extra'er
Posts: 564
Joined: Sun Jan 17, 2010 4:26 pm
Location: Sydney, Australia

Re: EGO correction offset with just P-term

Post by robs »

mrx79:
The red line was type C. I should have said. I mostly focussed on it since it's what's MS2/Extra uses.

I agree that it's interesting that the I-term is the only one that "knows" the target, with the other terms just basing their outputs on previous outputs. The thing I found questionable was the statement at the link Ken provided that type C was simply "better" than the others. Well, it's better if you care more about speed of response; doesn't look to be all that great if you care more about accuracy. Just another case of "all general statements are false".

You raise a good point about whether setpoint changes actually are much of a problem for EGO feedback. My thinking was that the AFR table is interpolated just as the VE table is and so the setpoint is continuously being redefined. But in an ideally tuned engine under ideal conditions, the VE table's interpolated squirts will perfectly match the AFR table's corresponding interpolated EGO. So you could define the process variable of AFRError with a setpoint of zero (the code may well do this, I haven't checked). Ideally, this would settle on a value to compensate for humidity of the day, etc. For this purpose it seems stability would be more valuable than responsiveness. In the real world, as you say, "disturbances" have to be handled. I suspect that sometimes they're best handled with a quick response, other times it'd be better to ignore them. Hmmm.

dontz125:
I suspect you're right. Have to confess that I'm still using simple EGO feedback myself. I guess some of the random number sprayers might be better off doing the same.
muythaibxr
Site Admin
Posts: 8228
Joined: Thu Oct 14, 2004 12:48 pm

Re: EGO correction offset with just P-term

Post by muythaibxr »

I chose C because of its responsiveness. If you tune I properly accuracy is not an issue. Originally I did this for idle because the setpoint does not change rapidly but sudden added load happens regularly. I then just reused the same code for the rest of the PID algos.

For EGO type A or B might work better because they will allow P-term responses to set-point changes, but as you say the VE should be close, giving PID very little to do. I usually give it enough I to allow it to hit target without overshoot and add a tiny bit of P for transient deviations with EAE. With this method I can get an AFR that tracks within a couple of tenths of target even during transients.

For boost standard ideal PID with a bias table seems to work best (best response to setpoint changes and factors in bias all the time, giving PID less to do).
Megasquirt is not for use on pollution controlled vehicles. Any advice I give is for off road use only.
mrx79
Experienced MS/Extra'er
Posts: 299
Joined: Wed Oct 29, 2008 8:26 am
Location: Frankfurt / Germany

Re: EGO correction offset with just P-term

Post by mrx79 »

muythaibxr wrote:For EGO type A or B might work better because they will allow P-term responses to set-point changes, but as you say the VE should be close, giving PID very little to do.
Not only can the P&D Term in a classical PID algo see setpoint changes, they can see deviations due to disturbances even if the setpoint is stable. This is the far more important point. Do you have any comparison between clasic and Type C controller performance when keeping the setpoint equal and just deal with a disturbance jump for example?

Also why i think at least a classical P-Term is better, usualy we even don't have disturbance jumps in our system, but more like DT1 types of errors. Due to the reason that we have a pre-control.
muythaibxr wrote:I usually give it enough I to allow it to hit target without overshoot and add a tiny bit of P for transient deviations with EAE. With this method I can get an AFR that tracks within a couple of tenths of target even during transients.
Can you please post one of your logs, once without EGO control and then the same with EGO control?!
I find it especialy difficult to tune the Type C PID for transient errors, as everything goes into the integration (also P & D Term)
Honda CRX B16A1 Turbo | MS3 running | pre1.5.1 beta7 Firmware | 24/1 Dual Wheel | COP ignition | 725cc ID injectors
muythaibxr
Site Admin
Posts: 8228
Joined: Thu Oct 14, 2004 12:48 pm

Re: EGO correction offset with just P-term

Post by muythaibxr »

mrx79 wrote:
muythaibxr wrote:For EGO type A or B might work better because they will allow P-term responses to set-point changes, but as you say the VE should be close, giving PID very little to do.
Not only can the P&D Term in a classical PID algo see setpoint changes, they can see deviations due to disturbances even if the setpoint is stable. This is the far more important point. Do you have any comparison between clasic and Type C controller performance when keeping the setpoint equal and just deal with a disturbance jump for example?

Also why i think at least a classical P-Term is better, usualy we even don't have disturbance jumps in our system, but more like DT1 types of errors. Due to the reason that we have a pre-control.
The type C PID will see deviations due to disturbances in the PV as well. They will actually respond more quickly and more consistently than standard PID because it always responsds the same regardless of distance from target.
muythaibxr wrote:I usually give it enough I to allow it to hit target without overshoot and add a tiny bit of P for transient deviations with EAE. With this method I can get an AFR that tracks within a couple of tenths of target even during transients.
Can you please post one of your logs, once without EGO control and then the same with EGO control?!
I find it especialy difficult to tune the Type C PID for transient errors, as everything goes into the integration (also P & D Term)
Closed loop should not really be used to control transient errors, that is what I use EAE for (kinda like another pre-control). The EGO sensor/controller don't respond fast enough to make trying to use closed-loop EGO for transients accurate anyway.

I generally don't even try to tune closed loop EGO until I have VE and EAE tuned.

Unfortunately I'm in the process of tuning my car now without EGO, so I don't have a good log to show you, but I've done this several times on other peoples' cars and my own car (several years ago on ms2, so no logs), and have had the same results every time. I generally don't need much, if any P-term, and just enough I-term to correct for slight offsets.

I will admit that tuning this kind of PID is different from ideal PID, but it has the added benefit that I don't have to use a bias table. I just take the output of the fuel equation from all the other corrections and multiply this in and I'm good to go.
Megasquirt is not for use on pollution controlled vehicles. Any advice I give is for off road use only.
mrx79
Experienced MS/Extra'er
Posts: 299
Joined: Wed Oct 29, 2008 8:26 am
Location: Frankfurt / Germany

Re: EGO correction offset with just P-term

Post by mrx79 »

Hi,

it wat not my intention to tune out transient errors with the EGO PID, you got me wrong on this point. The opposite is the case, like you saied, but as everything is integrated in the Type C approach i find it difficult to tune a fast/tight controller without overshoot during transients.

I would be glad if you can show some measurements, even without EGO if you don't have anything else right now. Just to see if we both talk about the same quality standard here. I think i've tuned my static VE as well as transient with EAE + a littlebit of TPS AE for WOT gradients quite well, also for all kinds of temperatures and ambient pressures, etc. but still there are always a few percent's left here and there.
Especialy during WOT pulls, i tuned it a bit on the rich side for best throttle response... but especialy these cases i think are hard to tune with a fast PID. Mainly because of the mentioned Integral characteristics.

my poin is that a real P is just not present which would be a short correction burst which does not go into the Integral part but which enables us to tune low enough I to ignore transient errors in the I part and which (due to the P character) are instantly out of the equation after the transient again.

Again, i would also not want them for the transient as well, as i'am rich enough here per precontrol, but they also usualy doesn't hurt as long as they are not integrated.

I'am also quite happy with a slower PID controller, but i think (also from my work experience for several OEMs), that a good PID controller can do better then that.

Please don't understant this as an ofence to the current implementation, it works and it brings the lambda to it's target which is the main goal.
I was just a bit confused when finding out why it akt's like it does because i expected something else ;-) Now i figure out a way to get to my point with the new knowledge about the controller.
Honda CRX B16A1 Turbo | MS3 running | pre1.5.1 beta7 Firmware | 24/1 Dual Wheel | COP ignition | 725cc ID injectors
lagos
Experienced MS/Extra'er
Posts: 197
Joined: Sat Jun 02, 2012 8:40 am

Re: EGO correction offset with just P-term

Post by lagos »

Since we have the mathematical formula and can generate some typical data from real world conditions, couldn't we use simulation software like MATLAB to find optimal PID Settings that could be used as recommended default values?
Post Reply