generic_pid_routine: P term not working?

[Reverant]

I was trying to tune my closed loop fueling the other day, and I noticed that changing the P term didn't seem to make any difference. So I zeroed out I and D, and sure enough, the EGO correction stays at 100%, with any P value (1-200).

The same was true for closed loop idle control - when I zeroed out I and D, my idle would stick to the same duty and wouldn't move.

So I modified the code as follows, commented out:

Code: Select all

    if (config & PID_TYPE_C) {
        Kp = ((long) ((PV - PV_last_arg[0]) * (long)set_Kp));
    } else {
        Kp = ((long) ((error - *last_error) * (long)set_Kp));
        *last_error = error;
    }

and replaced with:

Code: Select all

Kp = ((long) ((long)(PV-SP) * set_Kp));

And bam, P is now working in both EGO control and CL idle control.

Am I missing something?

MS3 1.4.0.

[muythaibxr]

You have now made it work incorrectly. The P term will only do something for idle or fuel if the error changes. In the case of idle you probably needed more sensitivity on the slider.

The way you have it now, it is an I term not a P term.

[Reverant]

More sensitivity on the slider? There's none for EGO control. So how can I make it more sensitive? I have an AFR reading of 9, a target of 14.7, and the correction doesn't move unless I set "I" to something other than 0. No amount of "P" will make it change. Have you actually tested what I said? Set I and D to zero, and test if the correction changes at all.

[elaw]

Yeah, I've had a lot of issues with the 1.4.0 code too, including idle PID doing some really wonky things... but I think your issue is different.

The lack of response on the P term I can't explain, but as you troubleshoot it you need to know that the MS PID calcs aren't like the ones you see elsewhere.

In general for a PID controller, first an error term is computed as (PV - setpoint). Then P is computed as a constant times the error, I is computed as a constant times the integral of the error, and D is computed as a constant times the derivative of the error. The results of those 3 calculations are summed to yield the controller output.

MS does it differently. In the MS PID calc (at least the older ones), the error is computed as above. P is then computed as a constant times the derivative of the error, I is computed as a constant times the error, and D is computed as the *second* derivative of the error. The results of those calculations are summed *and then integrated* to become the controller output. Or in other words, the MS P calc looks like the D calc for a normal PID, the I calc looks like the P calc for a normal PID, and the D calc looks like nothing you've ever seen before.

So the bottom line is if you're going to rewrite the P calc, it needs to look like you'd expect a D calc to look, not like you'd expect a P calc to look.

I don't know the reason for all that... my best guess is the PID routine was originally written to drive a stepper motor which by its nature is an integrator. So rather than write a conventional PID algorithm then differentiate its output to drive the stepper, they wrote the algorithm so it can drive a stepper directly.

As I think the developers have mentioned, this scheme also helps avoid something called "integrator windup" since the controller output effectively *is* the integrator and by nature is limited in scope. The downside is that while a conventional PID calc is unaffected by the controller's initial/previous condition, this one is... and that can have some weird effects.

[Reverant]

Well, for what's it worth, the P term is not doing ANYTHING. Hell, don't take my word for it, try it. Set I and D to zero, and see if the correction moves at all, either the CL idle or the EGO correction.

[elaw]

Heh... I would if I was still running the 1.4.0 code!

I switched to 1.4 during the summer and the car ran okay, but idle control has deteriorated as the weather has gotten colder. Yesterday it was running awfully, I took a log, and among other issues it was *increasing* (rapidly) the idle PWM value even though the RPM was above target.

At that point I bailed and reloaded the 1.2.3 firmware I was running before and the thing runs like a dream now.

[Reverant]

I don't think the generic pid routine has changed since 1.2.x. Do you want to give it a try?

[elaw]

Good point... I'll try it when I get a chance, probably later today.

[elaw]

Well, I tried it and EGO correction P term seems to be working for me.

The attached log snippet starts with EGO settings of P=10, I=16, D=0. Just after the mark at t=1284.515, you can see the "EGO cor1" trace change a bit. That's when I changed the settings to P=10, I=0, D=0. After that the EGO correction clearly moves less, but it does move.

The firmware I'm running now is a modified version of either 1.2.3 or 1.2.4 - I can't remember which. But I didn't make any changes to the generic PID code.

[Reverant]

I just tried 1.2.4 and still no luck. Would you mind sharing your msq? Also, can you try with P=10, I=0, D=0 from the beginning?

[muythaibxr]

Well, for what's it worth, the P term is not doing ANYTHING. Hell, don't take my word for it, try it. Set I and D to zero, and see if the correction moves at all, either the CL idle or the EGO correction.

It won't do anything unless error changes.

[muythaibxr]

I just tried 1.2.4 and still no luck. Would you mind sharing your msq? Also, can you try with P=10, I=0, D=0 from the beginning?

If you are expecting P term to correct steady state error, you are not going to get anywhere.

[muythaibxr]

Heh... I would if I was still running the 1.4.0 code!

I switched to 1.4 during the summer and the car ran okay, but idle control has deteriorated as the weather has gotten colder. Yesterday it was running awfully, I took a log, and among other issues it was *increasing* (rapidly) the idle PWM value even though the RPM was above target.

At that point I bailed and reloaded the 1.2.3 firmware I was running before and the thing runs like a dream now.

We would appreciate it if we were notified of weirdness like this along with logs and msq.

We have not changed the PID routine itself but it might have something to do with the slider.

Ken

[elaw]

Ken,

I'll start another thread about that since it's most likely unrelated to Reverant's issue.

I hadn't done that before since I'd started another thread about another idle issue (here:http://www.msextra.com/forums/viewtopic ... 25&t=64303) and it seemed to get no attention... I figured you guys saw it was self-modded code and didn't read any further. I also know there have been some bug fixes since the 1.4.0 code was released and maybe my issue was one of them, but since I really want the customizations I need to be on 1.4.0.

[elaw]

Well, for what's it worth, the P term is not doing ANYTHING. Hell, don't take my word for it, try it. Set I and D to zero, and see if the correction moves at all, either the CL idle or the EGO correction.

It won't do anything unless error changes.

Reverant,

Ken makes a good point!

Can you post a log of what you're seeing? It would probably help figure out what's going on.

[mrx79]

Hallo together,

i discovered the same some time ago with the MS2Extra Code. As already explained, the fact that the P-Part does not react on error is intentional. Even if it is different to classical PID behaviour.

Based on this i read as much as possible about the guy who designed this so called "Type C" "PID" Algorithm. From what i read, many ppl who work with classical PID seem to disagree with him that this controller strategy is better then classical PID.
I would say (and this was also my impression from reading several threads) that Type C Algo has some benefits in non-Precontrolled, industrial process control scenarios where there is often a setpoint change. The algor. in my oppinion depends on the fact that there is little external disturbance (or at least very slow which can be then covered by the I-Part) to the process. In case of a setpoint change, you get a sudden change in error (but the main difference is, that the setpoint changes and not the PV value).
In this case, a P-Term is necessary as long at PV <> Setpoint.

But in our scenario we have a "hopefully" proper pre control, so there is no need for additional controler support at setpoint changes. Also we do not often change our setpoint (at least in EGO control). But on the other hand, the EGO controller face a HUGE amount of influence factors which we don't know and which we sometimes can't pre-Control.
Therefore it's important to have a controller algorithm which can react good on disturbances, rather then setpoint changes.

In my oppinion and experience, a classic PID can do this job better then the Type C algorithm.
The reasons are:
- you have a P-Term which can support the I-Term based on controller error.
- the classic P Termin is not depending on a derivative input like the P in Type C, everygthing which controles based not on gradient is more stable and easier to tune.
- Type C P Term is actualy a classic D Term, which brings often more harm then good as long as you don't exactly know your transfer function of what you want to control (which also assumes that the transfer function is equal all the time which is not true for an EGO control scenario).
- A I-Term always brings a 90° phase shift, which causes natural instability if kI is set too high. As the I-Part is the only part on Type C algorithm which consideres controller error, there is a typical demand for setting kI too high which you could otherwise cover with a little classic P-Part.

I currently get around it by basicaly using I-Term with a little P-Term. D-Term of TypeC is pretty much useless for EGO control (at least that's what i found out) as it just generates spikes. Only problem with this is, that either I-Term is too slow to cover short term lambda deviations or too big and then I-Term has to go up and down all over the place (don't understand this wrong, my pre-Ctl. is pretty good, all over the place means just the rest the controller has to cover which can't be properly pre-controlled)

Therefore, you can get along with TypeC PID controller, but he leaves some topics on the table.
I personaly would appreciate a classic PID integration pretty much, as i think it can do a much better work in our controling scenario then TypeC does.
Hopefully nobody is offended, thats just my experience and oppinion after trying to get along with the current integration.

[muythaibxr]

The main problem I have with classic PID for EGO is the requirement for a bias with which to feed the algorithm that is in the same units as the output. We have VE along with a host of modifiers multiplied by req_fuel in this case with a % modifier as the output. Type A could potentially work better and would be pretty easy to test. I may be able to come up with a way to use ideal PID there with some code rearrangement so the calculations that convert from all the percent modifiers to PW happen last. Integral windup can become a problem as well.

For idle I originally wrote it using the discrete method so we wouldn't need a bias table and we didn't have any feed-forward control. It gave the best response to sudden drops in idle speed such as come from turning on the AC. No matter how far you are from the target it responds the same.

I have not changed either of them because the vast majority who forget about how ideal PID works and just tune it with numbers that work for them get it to work fine. All of them would be forced to retune if I change it.

[mrx79]

I have not changed either of them because the vast majority who forget about how ideal PID works and just tune it with numbers that work for them get it to work fine. All of them would be forced to retune if I change it.

That is true, but as we don't have huge map's for PID parameters, i guess the rework is reasonable. A switch of course for compatibility would be awsome for those who are happy and don't want to upgrade.

I just can't follow your problem with the bias?! If course i understand the unit problem, but i don't see where the difference concerning units is between classical PID and TypeC PID.
I-Part windup, i guess is the same now and with classical PID. But here also a classical controller might help.
if we detect for example load/N changes we can disable or switch to a slower kI in dynamic and let the error dependend P part take over short term.
Also an overall min/max limitation of the I-Part is of course helpful, but this is already implemented some kind of with the controller authority calibration.

In my oppinion if the controller output should be percent (%), i guess input&error would work best as lambda difference so:
e = lambda setpoint - current lambda
esum = esum + e
output = Kp * e + Ki * Ta * esum + Kd * (e – eold)/Ta
eold = e
with Ta = calculation recurrance to equalize if recurrance changes to keep factor weighting equal.

As i'am now switching to MS3 for the next season, if the development team decides to do a test on classical PID, i'am more then willing to support as a alpha or beta tester.

[elaw]

I just tried 1.2.4 and still no luck. Would you mind sharing your msq? Also, can you try with P=10, I=0, D=0 from the beginning?

Here (attached) is my latest .msq, along with the .ini file needed to view it.

I can try testing with those parameters but it might be a few days - I've got a lot going on right now.

[muythaibxr]

I have not changed either of them because the vast majority who forget about how ideal PID works and just tune it with numbers that work for them get it to work fine. All of them would be forced to retune if I change it.

That is true, but as we don't have huge map's for PID parameters, i guess the rework is reasonable. A switch of course for compatibility would be awsome for those who are happy and don't want to upgrade.

I just can't follow your problem with the bias?! If course i understand the unit problem, but i don't see where the difference concerning units is between classical PID and TypeC PID.

The main difference is that before I didn't care if there was a unit difference, I just made it another correction to multiply into the others. If I have a requirement for a bias, I need to make sure the bias (mainly controllable via VE, MAT curve, baro curve, etc..) is in the same units as the EGO correction when the EGO correction is made. It's not impossible, or even that hard, but it's work.

In other words, I'd have to make sure we save the conversion to PW until last when I don't necessarily have to do that now.

I-Part windup, i guess is the same now and with classical PID. But here also a classical controller might help.
if we detect for example load/N changes we can disable or switch to a slower kI in dynamic and let the error dependend P part take over short term.
Also an overall min/max limitation of the I-Part is of course helpful, but this is already implemented some kind of with the controller authority calibration.

No these aren't the same. We avoid windup now because we limit the total correction. If we use ideal PID, we have to limit the total the I-term sum can hit to something that limits the correction to + or - the EGO authority. Again, not impossible, but more work, and what I just described isn't always the right thing to do. Sometimes you want the limit lower to help the P and D gains needed to get similar reactions from the PID loop to the I term to be on the same scale... in other words so that a P term of 100 has a similar amplitude of response to an I term at 100.

The way it is now, it's not possible to get windup. We just limit the end number the PID math can control to and we're done.

In my oppinion if the controller output should be percent (%), i guess input&error would work best as lambda difference so:
e = lambda setpoint - current lambda
esum = esum + e
output = Kp * e + Ki * Ta * esum + Kd * (e – eold)/Ta
eold = e
with Ta = calculation recurrance to equalize if recurrance changes to keep factor weighting equal.

As i'am now switching to MS3 for the next season, if the development team decides to do a test on classical PID, i'am more then willing to support as a alpha or beta tester.

I'd be more willing to test with a type-A loop instead of type C. That should give similar or almost the same response as ideal PID without the drawbacks.

Ken