Well... I think it's time to "come out of the closet" with some mods I've made to the MS3 code. To the devs: if you'd be interested in looking at code or further explanation of what I've done, I'm happy to help in any way I can. And if you don't want to touch it with a 10-foot pole, that's fine too!
The backstory is that although I had good success with a different engine in the past, I've never been able to get the MS3 boost control to work well on my current engine. Try as I might, I could never find a "balanced" point where gain was high enough that the boost wouldn't overshoot but low enough not to oscillate. So... I set about implementing my own boost-control scheme. Although I do want to make clear that when I say "my own", some of the ideas incorporated are not my own! I'll elaborate on that later.
I started with the 1.2.3 code since that's the most recent for which source is available, and did 4 things:
1 & 2) Made the PID an "ideal" PID (more or less - see below), and made the "initial values" table into a bias table. Both of those ideas are from the current MS3 code.
3) Took an idea from the scheme used in Saab's Trionic system and changed where the P, I, and D values come from. Instead of being fixed numbers, each now comes from a small lookup table which has RPM on the X axis and the absolute value of boost error (ABS(MAP - boost target)) as the Y axis.
Here's why I think that is beneficial. Due to its nature, the "gain" of the turbo-wastegate system varies with engine RPM. At least on my car, no matter what you do with the wastegate, you ain't gettin' no boost at 1000 RPM. So at that RPM the "gain" of the wastegate is essentially zero. At a somewhat higher RPM, around 2750 on my car, the turbo is just barely capable of making enough boost to exceed target, so the wastegate starts to have some "gain" (ie influence over the turbo) but not very much. But as RPM increases the turbo is capable of making more boost and making it faster, so the "gain" of the WG is increased. In my view the "gain" of the WG essentially gets multiplied by the gain of the PID controller, so making the PID gain variable over RPM provides a means of offsetting the varying WG "gain" over RPM to maintain better control of the system.
Having the P, I, and D numbers variable based on boost error essentially allows you to vary the nature of the controller based on conditions. With that feature, when boost is far from target, you can effectively make the controller a PD controller - the P terms brings boost to near the desired level quickly, and the D term controls overshoot - the I term is more or less irrelevant. When the boost is closer to the target, the feature allows you to bring in more I term to make the boost follow the target accurately, reduce P term to compensate for the increased I, and reduce D so the boost duty doesn't overreact to small variations in MAP.
I should add that the above is strictly my "educated guess" interpretation of the design philosophy behind something that was reverse-engineered - I could be completely wrong! But what I will say is that it works well, at least for me.
4) The third change I made was to control "integrator windup". For those not familiar with the concept, here's an example using numbers from my car. Say you're driving at steady-state on a flat surface at 2000 RPM, and floor the throttle. Boost target will go to say 225 kPa, and the turbo will start making boost but not much - a moment after you open the throttle MAP will be about 125 kPa. Since MAP is > 100 kPa, PID boost control will kick in and the integrator will start integrating. Since boost is way below target, the integrator value will rise quickly.
Now look at the situation a couple of seconds later. RPM will be, say, 2500. MAP might be 175 kPa, still well below target, but it's rising faster now as the turbo is starting to really spool. With MAP below target, the integrator value is still increasing.
A couple of seconds after that, at maybe 2750 RPM, the turbo is spooling like crazy and MAP reaches the set target of 225 kPa. At this point the boost controller should be well into opening the wastegate, except... the now-huge integrator value is still telling the controller boost is too low, and the wastegate stays shut (or not open as far as it should be). The result? Boost overshoot. The boost must go above target so the integrator value can be reduced before proper control will be achieved. I know in many cases adding a bunch of "D" term to open the wastegate when boost is rising fast can help with this, but IMHO that's a "band-aid" and brings other issues with it.
So the solution I came up with, in a nutshell, is don't run the integrator when doing so will be useless or counterproductive. With the mods I made to the code, when boost PID is first entered, the integrator is disabled and stays at zero. The integrator only gets enabled after the following conditions are met: both boost target and MAP are above a programmable threshold, ABS(boost error) is < 50 kPa, and D value is < 5. Or in English: when boost target and actual are both in the controllable range (above WG spring value), boost is close to target, and not changing too quickly.
Once those conditions are met, the integrator will continue to run until boost actual or target drops below the set threshold then it gets disabled and zeroed.
I'll continue in a separate post, but here's a log and screenshot showing the results: I think I still need to reduce the D term a bit, but it's working pretty darn well (and I'll take a slight undershoot vs. an overshoot any day).
Oh and one other thing I did that helps tremendously: the code now logs *all* the boost PID-related values. Measured value, multiplier term, and multiplied value for P, I, and D, as well as the end PID calculation and bias value. Also bit 1 of status8 shows whether the integrator is enabled or not.
