muythaibxr

This would be correct with the standard "Ideal" PID. It is not correct here.

Increasing P with the type B algorithm *SLOWS* response since the reaction to rising boost will be quicker (opening the wastegate more, slowing boost rise).

Ken

muythaibxr

Based on that, I'd say that your P term is much too high.

Lowering it should help you considerably. Your initial ramp is leaving you at 30 kPa below the target. I would turn off D, then I'd lower P until you get it spiking a couple psi over the target.

Then increase I until it holds the target through the RPM range. When you're done with I, you may have to adjust P again until it overshoots the target by the same amount as before, then slowly ramp up D until it doesn't overshoot.

Braineack's tune looks pretty good to me, though I don't think his target is as high as yours.

You may also want to consider slowing down the control interval a bit too. That should make things more easily controllable. I'd use 12-15 ms.

Ken

muythaibxr

Most likely based on your comments about getting the open loop table right, you're not using even type A, you're using the "Ideal" PID equation, and using the open-loop table as the bias for the PID equation once the PID controller starts trying to regulate boost. With the 3 "types" listed in that site, a bias does not need to be included every time through the loop, just an initial position (we use 0, which means keep the wastegate closed).

I used type B because type A includes the setpoint into the D term, which can make the D part of the equation responsive to target changes. I did not want that to happen, hence sticking with type B instead of type A.

Ultimately you can get the same results either way (ideal vs one of the 3 "types), and the way I did it, you don't really need a bias table. The only reason I'm considering adding it is because one user said the boost rise was too *fast* since the controller keeps the wastegate completely closed instead of going to an initial non-zero value when you initially cross into boost. He wants the open loop table to provide the initial value so the boost rise is more manageable.

Ken

miatauser884

iTrader: (11)

OK I'll try this. I was trying to get it to just barely overshoot with P. I'll lower P until I get 1.5-2psi overshoot. Am I trying to get the boost above target the entire time in boost with P, or just the initial ramp?

By maintain target with I, Do you mean the avg of the oscillations above and below target, or should it stay at or above target once I is tuned?

Tuning D will be obvious once it is clear how P and I are supposed to be tuned.

It would be great if the answers to the above questions would be added to the tuning manual. Although the manual seems clear, I think there are a few subtleties that will remove the room for interpretation.

muythaibxr

Just the initial ramp. I'd expect it to ramp up to a bit above the target, then slowly fall back down a little as RPMs climb.

I mean once you get it to a bit of overshoot with P, the I term should make it go back down to the target, and then hold it there with minimal oscillation. Keep in mind that when you add I term, you might have to increase the P term a bit. Adding the I term will make it overshoot more than it was previously with just P.

Then what you'll want to do is get it to where the I term will hold boost at the target with little or no oscillation, and readjust the P term until it overshoots a bit again. Finally, Add just enough D term to get rid of the overshoot.

Sure.

Once you and I are both clear on what needs adding, I'll update it. The better the manual is the less time I spend on forums!

Ken

JasonC SBB

Big oops. Without an open loop table, you are relying on the 'PI' to find the duty cycle you need in order to hit the target. The problem with this approach is you need a large P and a large I, and I has the "windup" problem.

It would be good to have:

1) A 2D table of boost target vs TPS (3D so you can have an RPM varying WOT boost target would be more flexible)

2) A 2D table of open loop solenoid duty cycle vs. target boost. A 2nd table for open loop duty cycle trim vs. RPM would be good to have too. This is a "feed-forward" scheme.

3) PID params with a clamp on 'I', e.g. max I output is +/-5 % duty.

With the above strategy you first tune the open loop tables. Then you use P and D to get it ramping fast without overshoot - the P will help keep the wastegate closed during spoolup, D will open the wastegate pro-actively X ms before it hits target, and the small 'I' will get rid of any remaining error in the open loop tables. The I' 'must be clamped to a small value such as +/- 7%, in order to prevent the classic "integrator windup" problem. Also for the same reason, you will want 'I' to be clamped to zero until target is within 2 or 3 psi, within the error of the open loop tables.

Having the open loop tables in control system parlance, is having a "feed-forward plant". High performance feedback loops use it.


I do have WG%, in the graph I posted, it's the dark blue trace in the bottom half, labeled "Boost WG out". In the plots too are 'P' which is green, and light blue which is I.

The orig thread is here. It was about adding a 'D' circuit to the AEM because it doesn't have one. The annoying overshoot is now completely gone.

https://www.miataturbo.net/showthrea...ight=overshoot

?? I don't understand the question. The AEM updates the calculations at a high rate relative to the solenoid frequency, as far as I can see.

miatauser884

iTrader: (11)

The above instructions are perfect.

Here is a question: I was under the impression that once the PID values were dialed in they would be good for whatever the boost target you have set. Is this correct?

In other words.....I am tuning at 17psi, but plan on running 20psi. I just don't want to deal with the overshoot issue at the limit of my map sensor. Do I have to retune the PID settings if I change max boost target?

JasonC SBB

I think what you call the 'P' term addend in the control output is not -Kp*error but rather Kp*target or Kp*process_variable where PV is MAP. The "type A" controller in the allen-bradley page you linked is -Kp*error, not Kp*target, making it a "real PID". What I call a "feed-forward" or "open loop table", you and the Allen-Bradley page call "bias".

By implementing Kp*target, you are trying to create an open loop output or "bias", based on what the target you want is. This is like having a single number for the open-loop table, instead of a 2D table. This may work OK for WOT boost tuning; it may be not OK if the duty cycle required at WOT and changes with RPM despite a fixed boost target.

If this is what you are trying to do, it's worth having a real 'P' (meaning -Kp*error) along with the other 'P'-that-is-not-a-P factor.

Yes but in type A, as I described above, the P term calculation includes the target.

What's wrong with including the target? If your foot says "5 psi", then abruptly goes to "10 psi", why wouldn't you want the D term to briefly shut the wastegate completely so as to ramp to 10 psi as quickly as possible?

The reason some feedback loops don't want the 'D' term to include the setpoint, is because they don't want the control valves or actuators, to slam open or closed when the operator abruptly changes the target. This is not an issue with boost controllers, because the solenoid already slams open and closed 15~30x per second, and the wastegate slamming open or closed is no big deal either.

I disagree. Given that the "correct" duty cycle varies with boost target and RPM, having no feedforward tables will reduce performance, as the 'I' needs to wind up to find the "correct" duty cycles. The feed-forward tables instantly give a "best guess" value for duty cycle given target boost and RPM, and the PID loop speeds up the rise by keeping the wastegate closed initially, and correcting any remaining error. Without PID and with full 3D open loop tables, the error I got was as much as 1.5 psi out of 10, with a 5 psi wastegate can that crept up to 8 at redline.

How can boost rise be "too fast", if your right foot demands it? (Provided there is no overshoot)


Cheers.

muythaibxr

Nope, not exactly, we don't have the windup problem because our I term is no longer a sum. It doesn't continuously grow like it would with the typical standard PID equation. Take a look at the equations on that site I posted, you'll see what I'm talking about. That's one of the reasons I chose the method I chose. the I term is essentially:

CO += (I * Error)

and then I limit the total range of CO to the open/closed duties the user sets.

instead of

CO = bias + (I * (errorsum))

In which case I'd have to bound errorsum to avoid windup, and I'd still have to bound CO to avoid duties that don't make sense.

The result using the method on the website is that the I term has no way to windup.

Already have this, 3D.

I don't think we *need* this. I'm adding something similar for the reasons I specified before (ms3 only). It is also 3D.

Again, you're thinking in terms of the "ideal" PID equation. This is not necessary with the method I'm using because there is no windup problem.

I could, and like I said, I'm going to add the ability to use the open loop duties as starting points for when closed loop engages, but it's different from the standard PID equation when those values are actually used as the bias for PID every time through the PID loop.

The rest of the comments about wastegate duty, etc... weren't intended for you, so apologies for that.

Ken

muythaibxr

It will get you to the target, but will probably not reach the full 20 psi as quickly. You might have to readjust the P term again.

Ken

muythaibxr

I don't agree. I'm using what I'm using for my P term because by making CO = CO + PID, I'm doing an integral on the final output. This requires me to take the derivative to get back to the same result. The P I'm using is the derivative of the ideal PID P term because I'm essentially using CO as my "bias."

If you look at any of the equations in the site I listed, they all have the I term looking like "I * error" which is essentially what you're saying is a "real" P term.

Again, because I'm doing CO += PID many of the problems and "tuning tips" used with the standard PID equation are no longer needed.

Which is fine. I actually did that on purpose so that changes in target would result in changes to the wastegate duty. If target suddenly changes down, the wastegate will open up, then the boost will be close to the new target, so the I term won't have to do as much to get the rest of the way there.

Nothing in P and I, I just didn't see any reason to include it in the D term since the P term is already going to cause response to target changes. I wanted D to respond only to rate of change of the process variable.

Again, I think that with standard PID, the open loop table is not only recommended, but required, so I agree with you on that point. It won't work well or at all without it.

With the method I used to implement it PID, the bias is not needed because I'm making CO additive. CO(t-1) is essentially the bias, but then that made it so that in order for PID to work properly, the derivative of the whole equation had to be taken.

The complaint I got from this guy was that a slow rise to target helped him maintain traction (autocross or track racing I think)... a fast rise to target broke his rear tires loose. He didn't want to have to control it with his right foot

Ken

miatauser884

iTrader: (11)

I thought that was the point of the tps controlled boost target? You can get fancy with controlling the boost.

Unfortunately, Having to adjust P for every target is a shortcoming. It would be nice if it ramped to every target as fast and stable as possible.

Is there an algorithm that would allow you to do this?

muythaibxr

Actually now that I think about it, when I helped shueind (spelling?) tune his boost control, we didn't have to adjust his PID numbers at all when we increased the target, so I might have misspoken.

When I looked at your msq though, I noticed that you have the same target set in the whole table.

I don't know why that particular guy didn't want it to reach the initial target quickly, but he asked for that feature to slow it down, and since it's not too hard to do, I'll add it.

I've heard of others asking for it because they're running way too much power for their transmission/diff to handle, and they break things if boost comes on too quickly.

Ken

muythaibxr

It might be better if we continue this over at msextra.com. I don't check this forum nearly as often as that. If you don't mind of course. This discussion might benefit owners of cars other than miatas too.

Ken

miatauser884

iTrader: (11)

Excellent, I'm glad I won't have to retune as I change the target.

I have all cells the same in hopes that the algorithm would keep the WG shut to get to target faster. If I were on the track I would not do this. I would have it ramp slowly based on throttle position. I would only allow the boost to reach it's maximum at 90%-100% of the throttle.

Open loop does seem to spool faster because I keep the WG shut, then modulate the duty cycle to reach the target and maintain it.

miatauser884

iTrader: (11)

Sure, do you want to cut and paste, or me? What section? It would be really nice to have whatever gets done for MS3 to be backported to MS2. Boost control is a very important feature.

muythaibxr

I'm just saying I didn't have to when I helped local guys tune it. Your mileage may vary, but I don't think you'll have to change it.

I'm not 100% sure this is necessary. Once you step on the throttle, the target will change to the top value pretty quickly.

That's more like what I'd expect.

You can make PID do that by following the advice I gave. I might be able to make it spool faster still if I backport the "don't open the wastegate until you are x from the target" feature.

Ken

miatauser884

iTrader: (11)

That would be super. Try not to let too much of the good stuff skip over MS2. Those of us running the DIypnp can not upgrade to MS3 without an entire ecu change.

muythaibxr

Good question. If you want, you can summarize the problem and what you've done so far and what you plan to do in a new thread. I can cover anything you don't put there. It's good for all the users to see this sort of thing. And helping with this sort of problem also helps with updating the manual.

The MS2/extra development section would be good since you're using ms2/extra 3.1 which isn't quite released yet.

I can't backport everything, there just isn't enough time in the day. Most of my effort is currently on MS3 now since we're trying to clean that up and get it to 1.0 release status. However, the specific feature I called out could be backported pretty easily I think if there's room in the flash page that the other boost control settings are in for the single setting I talked about.

I can add that and then email you a test msq to try it with if you're OK with that.

Ken

muythaibxr

It's not really a matter of letting it skip over. The MS3 and MS2 codebases are different enough that it's not always simple to backport a feature.

Often it's usually something to do with the way flash or RAM are arranged that gets in the way.

For bigger features, it's just not possible to backport. The MS3 has 32K of flash dedicated just to tuning data, and 1M of flash for the code itself. The MS2 has 128 K for everything, and it's already up to ~110K if I remember right.

Ken