Boost control change testing (MS2 and MS3)

[muythaibxr]

James and I have made the changes we have been discussing in the MS2 and MS3 sections to the boost control behavior:

MS2:
- Added delta setting and initial values table
- Made boost solenoid stay at 100% duty until (target - delta is reached) before jumping to the initial value duty and enabling PID.

MS3:
- Made boost solenoid stay at 100% duty until (target - delta is reached) before jumping to the initial value duty and enabling PID.

How to tune/test:
- Turn on closed loop boost control
- Turn on the initial values table
- Set your delta as low as you can (around 10-15 % load probably, make it larger if you need to in order to avoid overshoot)
- Make sure overboost protection is configured and working.
- Set control interval to about the same as valve frequency (so 19.5 Hz should be ~51ms control interval).
- Set tuning mode to "advanced"
- Set PID gains to all 0
- Tune the initial value table until you are spooling the way you like and reaching the target at various target values and RPMs
- Tune the I term to hold the target after PID is enabled.
- Tweak the initial values table to hit the target you want initially
- Add P and D term if needed to avoid overshoot and react to changes in throttle position after PID engages.

Please send me a PM if you want test code. Include the following:
- Your email address
- MS2 or MS3?
- screenshot or log of current boost behavior.

Keep in mind that this should be considered "test code." It has changes that we have only tested on the bench and have not tried in a car.

Discuss in this thread.

Ken

[jsmcortina]

The initial values table should have the Y axis rows at the target boost levels you want. Iif you use per gear or switching then set the rows for the different kPa targets and adjust the initial values to the open-loop duty you would expect to hold the boost at that point.

You'll need to fill the table in - the default values are all 100s.

I have another change pending that will leave the boost solenoid inactive when in cruise and out of boost - a few users had mentioned that they would like it to behave this way. I've not committed those changes yet as they could alter the testing of the changes that Ken has posted.

James

[muythaibxr]

Jose, I deleted your post. PM your info, don't post it here.

Ken

[JoseMiguel]

Sorry

Pm sent

[JoseMiguel]

anxiously waiting for the code!

[muythaibxr]

Yeah, I was waiting until this evening to see if anyone else was going to request it so I could just send it once.

I'll send it when I get home this evening.

Ken

[elaw]

Will this be in the next MS3 beta code?

I've never had any luck getting closed-loop working with my current setup, and am very interested in trying the new code. But I'm also going to be installing a new turbocharger very soon (probably next weekend), and I don't think there would be much point in testing before I do that.

[muythaibxr]

Assuming the concept works it'll be in the next beta.

It's already checked into the source repository. The MS3 code is basically already there in the current beta. The only change is to hold the duty at 100% (or your configured max) until you're close to your target then enabling PID and going to the initial value instead of holding the duty at the value in the initial values table until PID is enabled.

Ken

[elaw]

Ah, okay! I should have read more carefully - I though the changes were more extensive.

[muythaibxr]

Have you tried using the initial value table with the delta setting as they are?

Ken

[elaw]

No... I spent many hours unsuccessfully trying to make it work when I first set up the engine, and finally just gave up since open-loop actually works pretty well. Well at least it did until the weather got really cold...

I'm not sure the initial value table would really help my current situation - in fact I'm not sure there's anything that could help it! The problem is I need low gain to avoid oscillation, but high gain to keep up with the wildly varying amount of wastegate flow I need to maintain boost. To maintain constant boost, I'm running about 15% duty at 3000 RPM, and 100% at 6000!

What I think *might* work in my situation would be to have the "inital value" be not a "starting point" for PID operation, but always added into the equation. So the PID control would become more of a "fine-tuning" that's applied to the open-loop values, rather than having the PID fully in control of the WG.

But I also recognize that my situation is probably quite unusual. And it might well (hopefully!) change with the new turbo I'll be installing.

[muythaibxr]

The initial value I think could potentially help your situation since you'd not have PID controlling the wastegate until you're basically almost at the target anyway, and then all PID would have to do is hold the boost pressure instead of trying to reach it. The initial value is used as a starting point for PID, so it is essentially added in from that point on the way this PID algorithm works.

You're thinking more along the lines of ideal PID, where the output from PID directly sets the duty. The PID algorithms I use are already additive, so whatever the duty starts at gets added to (or subtracted from) on each iteration of the loop, and since that essentially is like integrating the whole PID equation, we take the derivative of the ideal equation and use that for the math on the chip. So we don't have to add the duty to every iteration, we just need to start with it.

It seems like your turbo is probably too small for your setup though if you actually want to hold a boost level all the way to redline.

Another thing to do if you have not tried is to limit the open and close values to be the actual open and closed values so the algorithm isn't going into duties that are "dead" as far as being able to change the boost. Fixing that can resolve a lot of issues.

Make sense?

Ken

[elaw]

Yeah, the turbo is definitely too small, and that will be fixed very soon!

Audi originally selected this turbo for an engine producing 165 HP, and when they went to a multivalve head for some reason they decided to keep the same turbo on an engine that produced 225 HP. And I'm getting about 300 out of it... good for me, but that poor turbo's being asked to do way more than it was designed to.

As far as open vs. closed, the valve I'm using has a pretty low mass (it's actually designed for WG control) and I'm running it around 20 Hz so it generally opens and closes fully on each cycle. There's a small amount of "dead area" at the PWM% extremes, but only a few percent. I definitely will look into trying to get those settings "just right" though.

[muythaibxr]

RE-read my last post elaw, I edited it and the edit is probably important.

[nathaninwa]

Im on track for testing on Saturday if you still need it then.

[muythaibxr]

OK.

I'll send code to the people who have responded to me tonight. If you want code and you have not already PMed me your email address, please do so (or I'll go look it up in the forum's admin area and use that).

Ken

[elaw]

Ken,

Thanks!

I did re-read your post and it makes perfect sense, but I think there's an important but subtle difference between that and what I'm imagining.

Let's take a possible scenario for my engine: driving along, the throttle is floored at 3000 RPM and held there until redline. As you state, near the start of the event the PID will kick in, with the valve % duty at the initial value from the table... let's say for argument that's 15%. But from that point until the engine reaches redline, the PID will be responsible for providing the large increase in % duty as RPM increases... up to 100% at 6000 RPM. So the output from the PID algorithm must increase sharply as RPM increases. Getting a large change in a short period of time requires large error values, which in turn requires high gain.

With the setup I envision, at each PID iteration the initial-value table would be read and a number pulled for the current combination of boost target and RPM. The output of the PID would then be *added* to that number to get the output % duty. So the large increase in % duty required to maintain boost would come from the table, and the PID would just "tweak" it - probably somewhere in the range of +/- 10%. This would allow the PID control to run with much lower gain.

Edit: just to be completely clear, I am definitely not asking that the code be changed for my sake! If you're interested in my idea and think it might benefit others that's cool. But it's quite possible my particular problem will disappear once I get the new turbo installed, and I wouldn't want you to go to the trouble for something that would be useful to me for 4 days.

[muythaibxr]

With the setup I envision, at each PID iteration the initial-value table would be read and a number pulled for the current combination of boost target and RPM. The output of the PID would then be *added* to that number to get the output % duty. So the large increase in % duty required to maintain boost would come from the table, and the PID would just "tweak" it - probably somewhere in the range of +/- 10%. This would allow the PID control to run with much lower gain.

What you're envisioning is exactly "Ideal" PID with the inital value table turning into a "bias table."

What I'm saying is that I don't think it's *that* much different from what I've already got. Let me try explaining:

Ideal PID:

In simple terms, without accounting for min and max duty, Integral windup, etc (images from http://bestune.50megs.com/typeABC.htm):

image001.gif

Or to put it in text form:

duty = (P gain)(Error) + (I gain)(sum of error over many iterations) + (D gain)(error from this iteration - error from last iteration) + bias

So the bias would just come from the initial value table and the bias table would always be active, so the value supplied for the bias would always be added in.

Type B PID:

image004.gif

Or to put it in text terms, we're summing the output of all previous iterations of the loop into the duty, so we have to take the derivative of the ideal PID equation, so what we end up with is:

duty += (P gain) * (this iteration's error - last iterations error) + (I gain) * (this iteration's error) - (D gain) * (2nd derivative of actual boost)

What this amounts to is that in the current implementation, you're starting with whatever duty you had in the previous iteration as your new "bias" and going from there. We use the initial value to "seed" the algorithm the first time through after PID is enabled.

What you're asking for is essentially to ignore the previous duty, and set a new bias on top of the PID adjustments based on an interpolated table lookup, which is essentially saying "switch to ideal PID and use a bias table." I think in the end either method is going to give you the behavior you're looking for, since from 1 iteration to the next of the loop, RPM is unlikely to climb much, boost is unlikely to change much, etc... So starting with the previous duty and adding to it isn't much different from starting with a newly looked up bias and adding the PID output to it.

I think the main reason you had so much trouble before is b/c there *was* no initial value table to start PID off with, nor was there a delta to tell it when to enable PID, so you were forced to make PID work under a wide range of differing conditions and potential spool rates to get to the target AND compromise the tune to try to hold the target without oscillation. This works fine for relatively "properly" sized turbos, but for your setup, it just can't work. With the new changes, you just set an initial value table that will hold the boost close to what you're looking for and set a delta that is close to the target so that when PID engages, it has very little to do in order to get you to your target, and you can focus the PID tune on just holding the boost where you want it, and reacting to changes in target when you move your foot around. Until you reach the target boost - the delta, the duty is set to max to spool as fast as possible.

Edit: just to be completely clear, I am definitely not asking that the code be changed for my sake! If you're interested in my idea and think it might benefit others that's cool. But it's quite possible my particular problem will disappear once I get the new turbo installed, and I wouldn't want you to go to the trouble for something that would be useful to me for 4 days.

I want to be able to control any setup, no matter how ridiculous. There are definitely people out there that do autocross for example who run very small turbos for their engines in order to spool at low RPMs who then want to hold boost to the top of the rev range. So your setup, while not ideal, is perfectly valid. It's also a good "worst case" to test the algorithm as it is now with the changes I'm asking people to test. IF you have time, gas money, and motivation to test it, I would appreciate the feedback, and would like to help you tune it if you're having trouble with it.

Ken

[elaw]

Well... I definitely have the motivation and the gas money! Time/practicality is the biggest holdup... it's a 20-minute drive from my house to the highway, and 90% of the time the traffic is too heavy to make boost runs practical. I also have no one to assist me... as I'm sure you know, this type of thing goes a whole lot faster when driver and tuner are different people.

Also when I swap the turbo, first priority for tuning will be correcting the VE table - I'm expecting it to need considerable work since the new turbo has a larger turbine and thus backpressure will be lower. Once I get the VE table set so I can run boost safely, maybe what I'll do is load my last closed-loop settings and see what happens. Then I can try working with the new features and see what difference they make.

[JoseMiguel]

I have the code and im testing it tonight. Ill get you back with the details!