Braineack

iTrader: (62)

When I get home I'll look.

y8s

iTrader: (8)

Jason, when you select closed loop boost control in tunerstudio, it disables the dutycycle table used for open loop and ENables a table that has boost targets and the axes are throttle% and RPM.

muythaibxr

This one:

http://bestune.50megs.com/typeABC.files/image008.gif

Which has not actually had the setpoint removed from P, only D. (Notice that P is still Kp * [e(k) - e(k - 1)], set point is part of error by definition, so set point is part of the P term)

His type C loop below the type B one has setpoint removed from both P and D (and is what I use for my closed loop idle algorithm).

I didn't cripple it at all. I was going to add an additional feature for that guy though that was selectable. I've not done anything yet though for that particular guy.

Ken

muythaibxr

Keep in mind that my algorithm considers 0% to be closed wastegate not open (like yours seems to), so duty ramping up is the equivalent of reducing boost not increasing it.

I treat 0% as closed wastegate and 100% as open wastegate.

When not in boost and upon entry to boost, the duty is 0% (closed wastegate). Then as soon as you enter boost, PID engages and starts opening the wastegate depending on your settings. For most that I've tuned this has been fine, and I suspect that even for djp once his PID numbers are dialed in, it should work fine.

The setting I'm adding for djp allows PID to stay disengaged until you're x kPa from the target, essentially keeping the wastegate closed up until that point, which should make it possible to get a faster spool than possible if it starts controlling as soon as you enter boost.

One thing people should do on here though is make sure that you know what duty actually affects boost. So what duty do you have to hit before you see it affect boost?

If you see it affect boost immediately at 0-1%, then 0% is the proper closed duty. If you have to get to 20-30 % before it affects boost, then that should be used for the "closed" value.

Tuning that will allow you to more accurately tune the P term for good response and fast spool.

Ken

muythaibxr

I am going to add a feature that lets you use the open loop table as the starting point for duty in closed loop operation. However, since that'll make the algorithm start with the duty already fairly high, it may cause slower spooling.

Ken

miatauser884

iTrader: (11)

I think with the new setting you will have to tune the PID to perfection, then slowly play increase PID engagement point until there is no overshoot.

This in effect is creating an artificially low P term since low P increases spool.

How fast can the algorithm respond? If I have the PID engage a fraction of a sec before target, will it be able to bleed off the new volume of air to stay at target?

What values will we be controlling for the PID engagement term?

Is what I am asking making any sense?

I'm thinking that if we know the inherent delay in the system, electronic and mechanical. Shouldn't we be able to adjust a value that represents the amount of time the PID algorithm needs to respond in order to hit target without overshoot? If you know the delay for one turbo, you change to a larger turbo, then the PID delay would increase by the ratio of the large turbo flow volume/ small turbo flow volume.

miatauser884

iTrader: (11)

This will also mean that you have to adjust the open loop values every time you change your target. This is why closed loop is so appealing to me. I will sacrifice a little spool if once tuned I can just change my target and everything is fine.

here is my open loop table for 20psi. Obviously this is not going to work if I use this for 15psi

[IMG][/IMG]

muythaibxr

Yeah, this is part of why I did what I did in the first place.

I'm going to make it completely optional, so users who want it can use it, and users who don't can ignore it.

Ken

miatauser884

iTrader: (11)

I guess just put an rpm based delay. Simple, and trial and error will dedicate the appropriate delay point. Fully tune the PID algorithm. Then keep increasing the PID delay rpm. When it overshoots, you've gone too far. Those that are really gung ho could start to tweak their P term again to gain the maximum delay rpm and hopefully fastest spool.

I like this idea, I'm not a fan of using open loop.

Sorry about not responding on the msextra forum it doesn't seem to be migrating over. At least I put a link to this thread over there.

muythaibxr

Actually, the way I envision it is that you'd have to set the setting to what you want it to be, then tune PID. P and D will probably need to change if the algorithm works this way. I could be wrong though.

Kinda, but you'll be able to raise your P term since you'll need it to respond more quickly. This could make it respond better to target changes.

It's not really a matter of how fast the algorithm can respond, but how fast the system as a whole can respond. The turbo has inertia so it's not going to slow down super fast just because you open the wastegate more. The algorithm itself is running a lot faster than the turbo can respond IMO. And I can make it respond quickly to a change in boost, but the turbo will always lag behind that change by a bit.

There's just a single value that you set that basically says "when I'm x % load below the target, turn on PID."

Sure.

The problem is that delay itself changes. It's not constant, and will depend on a large number of factors, so it's likely that if I did it that way, it'd be yet another table to tune. That's a similar problem to the PID EGO algorithm, I currently have it cycle based (you specify the number of ignition events between each correction). That works alright, but I think the optimal solution is a table of delays on RPM vs load between when you make a fuel change, and when the MS sees the change. It's pretty easy to tune that for EGO with a datalog, but I'm not sure how easy that would be to tune with boost. In any case, I think it'll be a pain to tune that table.

Even if you know the delay for one turbo, if you switch turbos, it's likely that you'd need to retune both PID and the delay value (or table).

Ken

muythaibxr

I'm making a setting that is basically "start controlling boost when you're X under the target." I'm not making it RPM based (yet). The hope is that you'll try it, and if it works, I'll leave it the way it is. IF it doesn't work, I'll have to add a curve, but I don't think this should be the case.

I am not either.

The main thing I wanted over there was the end result of your tuning efforts. As long as they make their way over, that's fine.

Ken

y8s

iTrader: (8)

ken, is there a way to make a minimal psi boost trace with a closed wastegate and then have it wide open at 5 psi so you get a known spool profile?

obviously the BC doesn't have to do anything but hold the gate closed until there's positive pressure and then start controlling as it increases above 0psi.

muythaibxr

I'm not sure I understand what you're trying to do.

I think you can do what you're trying to do by experimentation in open loop mode.

Ken

JasonC SBB

Not true if the open loop table is duty cycle vs. target. (As opposed to duty cycle vs. MAP, or duty cycle vs. TPS)

That's why at a minimum, you need a target vs. TPS table, then a duty vs. target table.

JasonC SBB

Yes there is a delay, or more accurately, a "phase lag". There is a lag in the time it takes to fill the wastegate can and move the swingvalve, and there is an inherent overshoot in that the compressor has to overspeed slightly in order to pressurize the air volume in the i/c and plumbing - in order to prevent boost overshoot the compressor shaft needs to undershoot its RPM briefly. (briefly slow down then back again to maintain boost) I saw this in boost control plots that included shaft RPM.

This is what the 'D' term is for. It implements what is called a "lead compensator". The lead compensator can be described in terms of *time*. In my car, it needed to be between 200 and 300 ms. This is actually also the lead time the solenoid needs - IOW as boost approaches target and it's ramping up, if you draw a straight line to the target, the duty cycle needs to begin opening the wastegate ~250 ms before it would hit target had the boost climb been maintained.

y8s

iTrader: (8)

I'm trying to overcomplicate things!

In order to build a duty cycle table that is optimum for spool, you need to know how fast the turbo spools, right? There's no point in raising duty cycle before the turbo is above a certain MAP threshold.

I was just wondering if there was a way to have the MS "learn" your turbo's spool profile and generate a rough open loop duty cycle table based on it.

Then use that duty table as the basis for PID.

JasonC SBB

Agreed. Having to get the 'I' to slew through the deadband of 0-20% (in your example), adds to the windup problem. FWIW in the AEM, the problem is mitigated by using 3D open loop tables (which then start at 20%), then clipping the 'I' portion to +/- 5 or 7%.

JasonC SBB

I believe the OE's "learning" is to update the open loop table of duty vs boost.
The PID parameters may or may not be updated based on overshoot and ringing.

JasonC SBB

Bingo. That right there explains the behavior described. It's not because it's type B vs. A. (which only matters when the target is changing). That you implemented the derivative (delta CO), also doesn't matter.

So you're essentially initializing I to be = P, and the CO at "closed" 'gate.

A potential issue I see, is massive overshoot when the driver, while at WOT at some high RPM, quickly lifts then floors it again - the turbine will still have a lot of RPM, and the PID will be initialized at 0 duty / closed wastegate. This test was a benchmark for me while tuning my AEM + D circuit. It'll show to a lesser extent at a fast upshift at redline. I tolerate 0.5 psi.

muythaibxr

Maybe, although the "learn" functionality is probably better done in the tuning software (it already does similar things with autotune for fuel).

I do think that my "delay PID control until x kPa from target" feature will help though.

This is another one I'm willing to meet up to try things with. I personally don't have a turbo car (I'm actually going to be working on fixing that situation by putting a turbo engine/tranny/diff/etc.. in my rx7, hopefully this summer), but if I can meet up with someone who has one and doesn't mind letting me tinker a bit, I can try all my ideas out at once, and just load new code for every idea.

Ken