NefMoto

Hey guys,

Can we get a how-to on calibrating the LDRPID from scratch? I mean from a clean slate.

First discovering duty <=> boost open loop
then duty linearization
and only then P I D components

?

i.e.
What needs to be set to get into the mode for open loop discovery of duty <=> boost relationship and duty linearization.

And then what are the steps of setting a specified duty, run car, and record boost maintained by that duty @ RPMs and then set another specified duty, repeat.

I'm finding the stock PID maps are way off when different wastegates (actuators) and more open exhausts are used. And just tweaking the PID maps are getting me no where fast.

Thanks,
Rey

Hi.

Sounds like a tall order! The phrase "from square one" worries me because it is stated in the LDRPID module of the funktionsrahmen that this is done using an engine dynamometer in the laboratory using the Ziegler-Nichols tuning method (apparently a very good standard theoretical method of working out the necessary proportional, integral and derivative parameters). Presumably involving scores of hours work. This will, of course, be for a new engine design for which no prior art exists. For uprated variants of existing engines, I presume the engineers start with the existing control parameters as a baseline.

Somehow, I think that even an overview of the process is beyond us.

Doug

...previous post continued because of truncation:

I did a quick Google search and there is a very short summary of the Ziegler-Nichols tuning rules on Wikipedia which references the original source here:

http://www.mstarlabs.com/control/znrule.html

The Ziegler-Nichols method apparently results in aggressive gain and overshoot which probably explains why we all see overshoot of boost on the stock maps! The table gives parameters for different states including 'no overshoot'. Worth a look but I've never used it myself in any context even though I'm surrounded by PID controllers at work.

Two years ago I wrote a simple PID control loop for a motorised mass with encoder feedback. I used this method to tune it and I was amazed how easy it was.

The biggest problem with attempting this with a vehicle is that the first step is to deliberately set the loop to oscillate around the setpoint so that you can measure its period. In a lab with position or velocity as the setpoint this is easy, but when it is boost pressure you would need to hope one oscillation period was somewhat less than the time it takes to redline. You would need several oscillations to be sure you got the period accurately. Plus you have other inputs to the control loop that you can't control (you'd have to disable a lot of ME7 protections to allow this behaviour).

I have a feeling that this method would yield a significantly worse result that the stock PID tuning as a starting point.

In my opinion it would be far better to get a really good understanding of each term, then tweak each variable based on iterative testing.

I agree :(

To make matters even more difficult, tuning a BRAND new PID is going to be difficult if you are trying to tune near max MAP readings ....

OK. I agreed with everythign said.

how about starting simple. Duty linearization.

I'd probably put the wastegate + n75 on a bench, apply cracking pressure + a few psi to the n75, and see how far the gate opens for a given duty.

Maybe get a stock wg and compare.

How far a wastegate moves is not always linear to boost held in a complete system.
Or even the same throughout the RPM range.

What I did:

set CWMDAPP = 8

set all cells in KFLDRAPP = 0
ran several runs and logged actual boost thru entire RPM range
set all but lower 3 PED% rows = 10
ran several runs and logged actual boost thru entire RPM range
set all but lower 3 PED% rows = 20
ran several runs and logged actual boost thru entire RPM range
set all but lower 3 PED% rows = 30
ran several runs and logged actual boost thru entire RPM range
repeat thru 80%

For each RPM axis value in KFLDRL I traced the logged boost.
SO, I end up with a map (in excel) with same axis as KFLDRL but with z values of actual boost at that duty/RPM node. (not linear)

I then made another map than was linear from 0% to 80% (last duty I had real data for)
for each RPM.

I then cross reference the linear values in in the non-linear map and interpolated.
The value I ended up with went into the KFLDRL map.

I'll post pictures later.

nice  work... I'm in to see some data.

awesome i'd like to see that too!

You can see I had to make several runs in different gears to cover the whole RPM range.
then trace (yellow) the boost curve that emerges from the compiled runs.


logged runs from KFLDRAPP = 0
traced at same RPM points as KFLDRL in yellow (table below)
(http://creativeion.com/rey/vw/turbo/duty_cal_0.gif)
(http://creativeion.com/rey/vw/turbo/duty_cal_0_trace.gif)

logged runs from KFLDRAPP = 10 (leaving lower 3 PED% rows =0)
traced at same RPM points as KFLDRL in yellow (table below)
(http://creativeion.com/rey/vw/turbo/duty_cal_10.gif)
(http://creativeion.com/rey/vw/turbo/duty_cal_10_trace.gif)

logged runs from KFLDRAPP = 20 (leaving lower 3 PED% rows =0)
traced at same RPM points as KFLDRL in yellow (table below)
(http://creativeion.com/rey/vw/turbo/duty_cal_20.gif)
(http://creativeion.com/rey/vw/turbo/duty_cal_20_trace.gif)

logged runs from KFLDRAPP = 30 (leaving lower 3 PED% rows =0)
traced at same RPM points as KFLDRL in yellow (table below)
(http://creativeion.com/rey/vw/turbo/duty_cal_30.gif)
(http://creativeion.com/rey/vw/turbo/duty_cal_30_trace.gif)

logged runs from KFLDRAPP = 40 (leaving lower 3 PED% rows =0)
traced at same RPM points as KFLDRL in yellow (table below)
(http://creativeion.com/rey/vw/turbo/duty_cal_40.gif)
(http://creativeion.com/rey/vw/turbo/duty_cal_40_trace.gif)

logged runs from KFLDRAPP = 50 (leaving lower 3 PED% rows =0)
traced at same RPM points as KFLDRL in yellow (table below)
(http://creativeion.com/rey/vw/turbo/duty_cal_50.gif)
(http://creativeion.com/rey/vw/turbo/duty_cal_50_trace.gif)

logged runs from KFLDRAPP = 60 (leaving lower 3 PED% rows =0)
traced at same RPM points as KFLDRL in yellow (table below)
(http://creativeion.com/rey/vw/turbo/duty_cal_60.gif)
(http://creativeion.com/rey/vw/turbo/duty_cal_60_trace.gif)

logged runs from KFLDRAPP = 70 (leaving lower 3 PED% rows =0)
traced at same RPM points as KFLDRL in yellow (table below)
(http://creativeion.com/rey/vw/turbo/duty_cal_70.gif)
(http://creativeion.com/rey/vw/turbo/duty_cal_70_trace.gif)

logged runs from KFLDRAPP = 80 (leaving lower 3 PED% rows =0)
traced at same RPM points as KFLDRL in yellow (table below)
(http://creativeion.com/rey/vw/turbo/duty_cal_80.gif)
(http://creativeion.com/rey/vw/turbo/duty_cal_80_trace.gif)

The completed duty<->boost table above give me this:
(http://creativeion.com/rey/vw/turbo/duty_cal_nonlinear.gif)

Notice how non-linear the boost response to duty.

Then I carry down the 0% and 80% data columns and calculate the linear boost per duty steps. This is how.
For each RPM node find the delta boost between 0% duty and 80% (or highest duty you log).
Then using the 0% and 80% columns, map the linear boost for each step between them.
So, for 0 to 80 by increments of 10 there are 8 steps. I take the delta found for each RPM and multiple it by the increments of 8 steps + the lowest boost (0%).

(http://creativeion.com/rey/vw/turbo/duty_cal_linear_tbl.gif)

Once I have this linear table I get this:
(http://creativeion.com/rey/vw/turbo/duty_cal_linear.gif)

Now I use the values for the linear boost table and look up/interpolate  where it would fall on the non-linear table to duty.

(http://creativeion.com/rey/vw/turbo/duty_cross.gif)

But this is really done by an excel formula:

(http://creativeion.com/rey/vw/turbo/duty_interpolation_calc.gif)

Once I do this lookup/interpolation for all nodes I get the final KFLDRL values:

(http://creativeion.com/rey/vw/turbo/duty_linear_final_tbl.gif)
(http://creativeion.com/rey/vw/turbo/duty_linear_calibrated_map.gif)

vs stock:

(http://creativeion.com/rey/vw/turbo/duty_linear_stock_map.gif)


Granted this is not 100% accurate because the true boost response is not a straight line between each duty node, but I doing the lookup/interpolation against it as if it were straight. You could build the first table with more duty nodes for a more accurate calibration, but that requires more KFLDRAPP change/run log sessions.

amazing work... thank you so much for sharing.  What turbos and waste gates did you do this with?

Simple K04 replace for a B5 passat 1.8T. Internal wastegate with actuator.

But stock PID maps could not hold boost steady at all. Since I was going to rework PID maps I thought it wise to make sure KFLDRL was calibrated correctly. I'll see if  I can post some before and after request boost vs actual boost graphs.

I would like to see those.

wow nice work, interesting stuff. I'm still very much in the just reading phase but it to see your work displayed graphically vs formulas I dont yet understand.

Alright, im bumping this to verify my sanity regarding boost linearization. I understand what is described here is for making the boost linear to WGDC, and why that is desired.

What I have gotten hung up on is what is also really desirable, boost vs rpm linearity. Look at a fixed duty WOT log, the curve doesnt stay very level in most applications.

What we do here is to linearize within this characteristic to make DC weigh "equal" or linear, since the DC output pre LDRL must be linear.

I hope any of this makes any sense, what im asking for is: Is it not desirable to linearize the raw DC to output a more stable boost pressure vs. RPM?

So you're looking for a more linear 'spool' (linear powerband), like one would desire on a road course?  Just making sure I'm understanding you right.  I think most people with big turbos want the max spool they can get at a given time, when going WOT, and don't car so much about spool linearity (until the point where it reaches desired boost, from then on, of course, you want it to be a linear cap).

I think you misunderstand the goal.

The linearity you are looking for has nothing to do with linear powerband; it has to do with the PID controller acting better if the control response is linearized.

I understand PID controllers and the need to linearize it to match the wastegate response (independent of boost level/boost profile), but I thought Bische was saying something else. I thought he was referring to utilizing the boost control to slow down the boost profile to a more 'linear' slope with regard to RPM (rather than just having the turbo spool asap and just using the boost controller to cap off the boost at a peak level, like most of us do).  After looking again at his post, I see he's just talking about using a different reference to linearize the PID (linearize the PID with respect to RPM rather than N75 DC), and not necessarily linearizing the actual boost profile with RPM.

Look at the graph I attached. What would be desirable is for the pressure to stay level once the WG cracks at a fixed DC, like the line I painted on there.

If we linearize with the top DC boost curve as reference, there will still be some of this behaviour as the that curve is not "flat" either.

I am about to go through all this to calibrate Tial 770 KFLDRL. I am on virgin waters here since there is no file in existence that actually has working PID control for GT turbos on this engine... due to obvious as we just pioneered the mechanism to use  boost sensor above 22.5psi.

So... Any chance (elRay) to post that excel formula in copy/paste format? [:)]

That's why PID controller is implemented, to adhere as much as possible to that flat line (or whatever load/pressure limit limit you throw at it). MEechanically there is no way to come up with soem linearization and have flat boost curve... It might be possible to come close but would go out of the window as soon as temps for example change etc.

ElRey - Can you please clarify for me, is this what your KFLDRAPP looked like when you did 10%?  I just want to make sure this is exactly what you did, to verify your procedure.  My reading of your method was a bit ambiguous, perhaps I'm an idiot idk... anyways, this should clarify.

I understood it this way too. You want to have 0% DC under 40% of gas pedal position to not kill yourself when driving casually but otherwise at max duty the table allows. It is really not important what values you use but the one you'll have your pedal at during the pull, which probably means 100% when you floor it.

Correct. I didn't want the ECU holding the N75 open @ 10% when it wasn't needed. So, I left the lower PED rows set to 0.


If I were to do it again on another car I would consider this -> Exposing some VS_VERST vars to TKMWL (unisettings) func ? (http://nefariousmotorsports.com/forum/index.php?topic=2853.0title=)

Unless you have an emulator. Must be nice.

How about I attach my excelsheet?

Snatched :)

I will have to modify it if I can only run DC up to 60 though, right?

If you are only calibrating up to 60%, then I would make KFLDRL linear from your newly adjusted 60% row to the 95%=95% row. But I'm just guessing. Experience/testing may prove different.

Thanks. Looks like audi did exactly that for 80 and 95 columns.

and then how are the runs done/logged? so lets say I lock wgdc at 10%, do I do a wot run in each gear and start a fresh vcds logging session for each run in each gear? how do I combine all the logs for that 10% wgdc together? sorry if these questions sound stupid but the last thing I want to do is do all this logging only to have to go and redo it all.

I switched my M-box to use RS4 axis.  Now my lowest functional column after 0% is 3% instead of 10% like on the stock M-box.
Here's what I'd do.  Set CWMDAPP = 8.  Set my KFLDRAPP to look like what you see in the image below.
Now.   Go out and find a nice stretch of road.  Get moving and get into third gear.
Do a few pulls from 1500 to 6500, or whatever your target power band is on your engine.
Go ahead and log your RPM and Boost Actual.
Take your logs and get your RPM and Boost Actual for each pull into a spreadsheet.

What you want to do is a linear interpolation.  So that you have a matrix with columns: [RPM_general BoostPull#1 BoostPull#2 BoostPull#3...]
Then you want to take the mean of your BoostPull#K columns, so you now have a mtrix:  [RPM_general BoostPullAvg].
Is that what you were confused about?  Get the data and upload it for me and I'll help with the mathematics for you if you need.
The spreadsheet gives you a great start on that tbh.

Thanks very much!

I've been trying to resolve something from the FR and I'm having no luck.

I've been comparing two WinOLS RS4 box, a tuner-pro k-box using prj's auto-K-xdf, and a tuner-pro m-box also using prj's auto-M-xdf.

Here's the problem.  I can't get correct LDDIMNN, LDDIMXN.  Can someone please assist me he here with details?

How would I search for this on my own, btw?

From my reading of the FR, we need these tables to be modified to get proper I control.

The FR says the following:

9. LDDIMNN: apply in the case of transitory problems arising from lighter dynamic response of around 5%, otherwise use the maximum value to deaden/nullify the function.

Thus with a value of 100 for all points in the stock m-box, this functionality is turned off...
The RS4 however appears to use LDDIMNN.

silentbob touched on LDDIMNN here:  http://nefariousmotorsports.com/forum/index.php?topic=315.30  Not much detail, alas.

My understanding in broad concept is that LDDIMNN is subtracted from the output I-value such that the I output is never allowed to drop below that value.  If it's set to 100, then I is permitted to drop to zero.

LDDIMXN is added to the output I value so that the limit is increased in the prescribed circumstances.

Again, my understanding, good for a laugh if nothing else.

OK.  So it's known that with the M-box values set to 100, this function is absolutely turned off.
You can see it quite clearly in the K-box, this function is absolutely used.
Toying with this stuff isn't simple or safe.  All of your axis maps and values need to exact and your list of variables super precise.

I feel I'm personally far from even copying the RS4 settings onto my K04S4 m-box setup... tbh.

would LDDIMNN apply to the med9 as well? So to drop KFLRAPP to 0 LDDIMNN must be set to 100?

I think I have still a big misunderstanding at this point...

The N75 Duty cycle is a result of adding P, I and D value based on lde.

KFLDIMX is only the upper limit for I value at a given point.

So if actual boost reaches desired boost, lde will be zero.

So the components P, I and D are all multiplicated with zero and added to zero...  so duty cycle is zero...

So without LDDIMNN what keeps the N75 duty cycle up to the needed value (for example 75% in steady state, desired = actual and lde = 0)

I do not get it from reading the FR on and on again...

the CHANGE in duty cycle is a result of P, I and D.




No, the duty cycle merely doesn't change from where it was.  Everything's good assuming actual meets requested.

Ok, that should be my big misunderstanding - I will read it again..  thx

No, you had it right. The DC is the sum of P I an D

I is not zero. if lde is zero. Read up on PIDs

the I-limit is the steady state requested PID output.

Missed this first time through.  KFLDIMX is a pilot value, not an upper limit.  It is the output under steady state conditions, and takes over from the PID under near-zero lde condition, if you will.  Follow ldimx output from the KFLDIMX logic in the FR.    The FR calls it a 'limit' but then says it 'describes the steady state duty cycle', "I- Begrenzung festlegen:
KFLDIMX: mit den station¨aren Tastverh¨altniswerten beschreiben." PDF page 874

There are other documents such as patents that describe the whole thing better than the FR.

Err. that isn't quite right. It doesn't take over, and it isn't really a pilot value. It prevents the I from accumulating infinitely.. such that when I reaches DIMX, and lde goes to zero, it is the only remaining non-zero PID component.

This seems interesting.  I'm going to continue my quest to clarify all of the LDR-PID address and axis details.  Here's an interesting looking function:
I wonder how much work it would take to build an optimization of sorts.

ME7's PID has all sort of gain scheduling, so its unlikely any of that will work well :(

Sure it does.  Not in a digital 'lde is near-zero so switch to KFLDIMX' way, but it modifies what would otherwise happen, so in that sense it takes over.  (Knew I was in trouble as soon as I wrote it.)

Bosch calls it a pilot value; seems to fit.  Well, they call the value derived therefrom a pilot value to be perfectly accurate.

Your description is the simplest and clearest I've yet seen yet.

Bringing this back. Trying to calibrate my tial 38.

Logged with KFLDRAPP set to 10-60% so far, arranged all my data nice and converted mbar to psi. I understand what's going on to get the duty->boost table and to linearize it and all that jazz, but I can't see to figure out how to "trace" the values for logged boost. Like what elRey does to get the yellow lines on his graphs. I have tried numerous functions such as TREND, VLOOKUP, INDEX MATCH, etc but to no avail.

I made a table with the KFLDRL axes, and I'm trying to fill it with values from my logged data. Any advice on what excel functions to use? I have googled almost everything I could think of, and my memory from my MATLAB/Excel class is a little foggy, lol.

I manually traced it. I added my own column of data and adjusted each value so that line follows the overall curve.

You can try max() in the new column if you think grabbing the max boost from all the other data columns, but you first need to normalize or find all the boost values at common RPM nodes. Your logged data probably will not have common RPM nodes across all your runs. It can be done, I just didn't take it that far.


edit: I had to open the spreadsheet to remember.. the base table(top left) on sheet3 is the source for the trace lines. You have to manual enter values there. You can start with low values then flip to the graph. You should be able to then 'grab' the nodes on the graph and drag it to where you want. Be sure not to drag left/right, just up/down.

Ah, I see. I was hoping that wasn't going to be your answer lol. Guess its time for some plugging-and-chugging.

You don't have to.

Thanks for that!

I see your measured table, I presume in to be measured in bar, and other calculation tables, but I'll still have to trace out my logs to find the boost pressures for each duty cycle, no?

Use my WinLog converter posted here:
http://nefariousmotorsports.com/forum/index.php?topic=2049.0 (http://nefariousmotorsports.com/forum/index.php?topic=2049.0)

After that make a matrix graph with boost pressure as the displayed variable.
Filter it by TPS > X

Set the RPM with a 40-100 way leeway each way.
Example matrix graph attached.

Then open your logs, with 0, 10, 20 and so on and write down the values.
You will still have to manually write them into Excel, but you won't have to do tracing.

Example matrix:

 :o You are the man. That is much easier than just picking values.


What are the opinions of re-scaling the axes of KFLDRL/DIMX? Are the axes shared with any other maps? Since I have a big turbo 1.8 I don't see much sense in having such high resolution from 1000-3000RPM.

EDIT: The FR says that KFLDIMX and KFLDRL are the only maps that use that RPM axis. I see no reason I can't change it, just have to make sure KFLDIMX gets changed appropriately, which is easy using prj's spreadsheet.

Also you don't need to write anything down, just "Copy Matrix to Clipboard" option under file menu in Winlogview, paste into Excel.  Really cool and easy

Cool, I didn't know that myself ;)

Hey Prj - Quick question regarding your spreadsheet.

On the Measured table, are you just setting column 95 to 2?  As-in, 2.0 bar is your target boost?  And then you are finding the other measured columns including 80 by doing actual controlled CWMDAPP=8 runs?

It's not "target boost", it's just a "very high value" so it gets filled with 95.

I have something to add to this thread.

Just giving KFLDIMX the "WGDC value to reach target" is not going to give good results when the wastegate behaviour (KFLDRL) is fairly non-linear.
This is because after initial ramp up most of the duty cycle comes from I.

Now if for example at a point with a value of 70 KFLDIMX your KFLDRL reads 85, then effective WGDC will be way too high, as the 70 maximum in the KFLDIMX map will be "amplified" up by KFLDRL, resulting in a 85% max DC at that value, and not 70%.

The solution is to reverse lookup the "WGDC value to reach target" map through KFLDRL.

For example, taking the original resulting boost target -> wastegate duty map:
(http://gm.mainframe.no/pics/ldimx_orig.png)

And running it in reverse through KFLDRL:
(http://gm.mainframe.no/pics/ldrl.png)

Results in:
(http://gm.mainframe.no/pics/ldimx_result.png)

This allows the PID to maintain much better control and all but eliminates overshoot on spoolup.

Yes. *everything* goes through KFLDRL, so if you are looking at your logs to see what WGDC is right (for a given set of conditions), it always has to be run "backwards" through KFLDRL to get the pre-lin value.

I find it helpful to always log both post and pre-lin.


This statement is true regardless of KFLDRL :)

Does anyone keep pictures with prj's examples?

I don't have pics, but all prj means is that when you get your WGDC -> boost pressure table that you made by logging, you need to run it reverse through DRL to get pre-lin values of DC to populate DIMX.

So in my case, I wanted to set boost for 20psi. My logs show that 20psi is achieved using ~55% WGDC. You can't just plug 55% into the DIMX table, you need to reverse lookup using DRL. So I found 55% DC on the Z-axis at the given RPM from the logs and traced it back to the DC axis in DRL, which turned out to be ~34%. This value is then used in DIMX.

I don't understand, and I would like to see these pictures that aren't showing up.  I have seen how reducing the values of KFLDRL down to about 80% over 3000 rpm in the furthest column does get rid of the boost spikes on the freeway in the high gears, however it does seem to make spool slower in the lower gears, and does seem to make response slower as well in place of the over boost (pin the thorttle on the freeway and boost takes longer to build back up).

Let me try.

Forget KFLDRL for a second. If wastegates and turbos were perfectly linear, then there would be no need for it, but we will get to this later.

Let's look at KFLDIMX. It defines prescribed value of "I" component, which mashed together with "D" and "P" is eventually used to cycle wastegates at a certain duty cycle. Inputs into KFLDIMX table is a number describing difference between desired pressure and atmospheric pressure expressed in mbar (called LDE, "boost error"). If you're missing 1700mbar, then 1700 column is used, for a given RPM, to pick "I" limit for controller and off it goes.

There are also "P" values, defined in two tables for dynamic (big difference in desired and current boost) and static (small difference, I think it is 50mbar or so) whose values are expressed for each 100mbar of LDE. "P" output seems to be mainly responsible for spool up since it generates very large numbers with large LDE and diminishes to little numbers as you approach boost target when it switches in static "maintain boost" mode.

The "D" part is only used to keep current boost level in desired boost level band.

Ok, so now after all the calculations you get some PID value, which with ideal turbos would just be applied to wastegates and the car would be happy. Unfortunately turbos don't respond linearly at all. Not enough that a turbo capable of 40psi doesn't make 0 psi with 0 DC or 20psi with 50% DC (this would be linear!), it also generates different boost levels with the same exact DC as it moves up the RPM band. That's why a need for KFLDRL, think of it as a scaler that knows turbo's secrets and how to translate requested PID value to something that when applied delivers a predictable and constant boost level as the car revs up.

You will now ask, so why KFLDIMX is also changing with revs? I low revs, it is obviously high to help spool up. For the rest of table, when the turbo can easily spool up without high WGDC, I can't really answer this as I don't understand it perfectly myself. Usually the variations are small once the turbo is expected to be in spooled up range so maybe it is just a smoothing applied to table...

If you feel that your spool up is slow then you need to make changes to "D" as well. What turbos do you run, what wastegate pressure and what values for KFLDIMX/KFLDRL (k03, k04, some random stuff?)?

I think your definitions of P, I, and D are not very good :/

Yeah, well. I hope he gets slightly better idea of how it all works as obviously super technical explanation doesn't make it home... like in my case [:)].

PID on ME7 as simply as I can think of it:

I -> Integral.  No need to go into integrals or calculus.  Stock coefficients Q1DY and Q1ST will output numbers that reach a limit in a very short amount of time.

We know that given intake air temperature (IAT), ambient pressure and humidity, once target boost is achieved, there is a WGDC that produces "X" amount of boost at "Y" rpm on a given engine/turbo/wastegate setup.

For all practical purposes there is a map for this and it's also the limit of that integral output above.  It's KFLDIMX. "X" boost is the X-axis of this map and "Y" RPM is the Y-axis. 

P -> Proportional.  P maps are Q0DY = dynamic and Q0ST = Static) and are a proportion of boost error.  What level of boost error divides them?  This is defined by UMDYLDR.

Q0DY allows rapid correction of large boost errors and flexibility on spool and change in throttle for different gears, IAT, and altitude (more specifically ambient pressure), each of which cause target boost to be reached at a different RPM.   

Q0ST needs to be large enough to make effective changes to WGDC (KFLDIMX), once target boost is attained.  Too low and adjustments won't be adequate and boost will stray from target.  Too high and boost will fluctuate around target (sine curve-ish).

SO:
I effectively gives a base WGDC
P gives the positive/negative change for flexibility to correct all errors very quickly.

D -> Derivative.  P and I are plenty potent enough to control boost but tuning will be a compromise between slower response near where error approaches zero and overshoot the target.   Hence, the Derivative Component.

D is used to "dampen" boost with a lower WGDC just before that larger error closes on target boost so you don't overshoot/undershoot your target.  The map KFLDRQ2 needs to be adjusted to be active at the rpm close to and above where your boost starts to meet requested and just large enough and at error values to eliminate overshoot.   

Now finally, KFLDRL.  Boost Linearization.  WTF is that?   In the RPM range that requested boost can be reached, there is no need for the full range of 0% to 100% WGDC.   This is where KFLDRL comes in. The map serves to magnify the area of WGDC that effectively makes a difference in controlling boost.   

It's impossible to understand PID and how it all works together without spending the time to see how changes in each component affect boost and wastegate duty cycle.   Start at the beginning of this thread and log, log, log.

Just as important, all that logging at different fixed WGDC to build your KFLDRL map will provide nearly all the data points to adjust the other PID maps for your setup.

Hope this helps.

Key here is, you need correct KFLDRL for your turbo. If this doesn't match what your turbo is doing at given RPMs and WGDC, you will never be able to properly tune the turbo.

Definitely. Take some logs using KFLDRAPP, use the spreadsheet to populate KFLDRL, and then reverse lookup DIMX values from logs.

Guys, I need some help with winlogview. I have converted csv to winlogview format but for some odd reason my matrix only shows few first cells... Im attaching both matrix file and logs :)

Greetings ,

On the stock S3 BAM ECU , 366847 , KFLRAPP is already filled with zeros , any reason why ? I assumed this map is used to test purposed only when CWMDAPP is configured to 8 so it didn't matter , correct ?

Also , why did you need to log various gears , in my case I could get good resolution using ME7 logger in 3rd gear at WOT ? I could do this on my pal's dyno .. however that's also a pain ..
I guess the road is the best ..

Thanks

Super hero member ! Thanks , this does DLR and DIMX correct ?

Thanks again

Any luck with this ? I was also looking at the HPA values in DIMX , in the stock BAM binary it goes only up to 1000 hpa (I assume that's 1bar gauge pressure) . Would it be worth it doing this ?

I haven't tweaked it any more as I have been pretty busy, but when I get back to the country I might give it a shot.

Maybe some others can chime in and provide some insight.

hi there guys, sorry for the dumb question, this can be also for correct a non overboost fault. a lost of pressure problem?

i'm fixing a poorly made map for my friend that have an 1.8t jetta, the max desired boost is already in their limits, 2550 mbar, and the boost reach it for only 1k revs then go down. this can be fixing tweaking the diverter too i think, but maybe its lowering because IAT also right?

how i can check if its because the IAT?

http://grabilla.com/03a02-cb8df034-816f-4955-95b6-fe9e115aaf83.png

thanks, i'm new at tuning :)

Stock k03? A k03 won't hold more than 1bar to redline, if that.

Rescale the hpa axis evenly so the last column is a touch higher than the max boost you plan to run.   This gives the most resolution while still covering your full range of manifold pressure.

Pablo ,

Thank you !

Am I correct in saying that the axis is plsolr_w  , defined as "relative target(desired) charge pressure" , which is manifold pressure less ambient = gauge pressure ?

Thanks

I can't state with full knowledge that psolr_w is the correct variable the axis uses, but gauge pressure in mbar or kpa (which ever you prefer to use) is right.   

My KFLDIMX hpa axis is stock.... while running with the 5120 hack and 4 bar MAP sensor so the axis is in effect doubled.   

250 mbar ~ 7 psi, 1000 mbar ~ 29 psi. 

So, did anyone achieve any real results by using this method or is it just a theory?

I mapped out the boost at various fixed duty levels using KFLDRAPP. The WG on the turbo has rather small operating range (around 15% - 45%) so I tested with small intervals.
While the boost response to the fixed duty cycle is sane, the values calculated for KFLDRL based on the results are not.

It didn´t make any other difference besides increasing the delta between ldtvr_w (pre-lin) and ldtvm (post-lin). Even with PID already shut down (B_lddy = 0) the ldtvr_w doesn´t follow KFLDIMX at all.
With plsolr_w at 1000mbar, ldtvr_w output is lower than KFLDIMX specifies for the pressure (28% vs. 35%). The modifications are not coming from KFLDIOPU, LDIATA or KFLDIWL either as these maps are zero by default.

Basically I am trying to get overboost in control. The boost always spikes 300-400mbar higher than requested, eventhou KFLDIMX contains the correct values which are required to keep the boost stable at the specific plsolr levels.
The problem is that I cannot get the ECU to follow these values. In regions where the turbo wakes up (2700 - 3200rpm) the desired duty cycle is exceeded and at higher rpms (>5500) it droops down. PID isn´t too helpful in
controlling the boost spike, since lde has reached zero (B_lddy = 0) and the PID has entered in stable state therefore making little to no difference.

The turbo I am using has somewhat similar characteristics as K04-064, however the waste gate characteristics are drastically different.
According to VAG the actuator of K04-064 starts to crack at 300mbar, has total travel of 13mm and has "calibration pressure" of 500mbar with 4.25mm travel.

The waste gate on this F23T hybrid turbo starts to crack at 483mbar and it is able to hold around 572mbar with 0% duty.

When looking at the stock KFLDIMX map of a car using this K04-064 turbo (S3), it is clear that the map is perfectly linear until 3500rpm.
Even at the higher RPMs the deviation from linear is only couple percent.

Compare different N75 valves, inner diameter and flow capability varies.

There is only one N75 model for TFSI.

Didn't read full thread but is the tfsi N75 physically different from the old style eg. 1.8t vw oem N75? Does it have to be a TFSI N75?

Yeah, the TFSI and TMPI N75s are completely different.
You could probably make an adapter, but I don´t think the issue has anything to do with the N75.

Most likely the wastegate actuator (which came with the turbo) itself is a POS. It is some sort of crappy adjustable "high lift" actuator, which has significantly higher cracking pressure / different travel than the OEM ones.
It´s cracking pressure varies depending on the temperature and generally it feels like it is extremely sensitive.

But regardless, IMO the method described in this thread for calibrating the KFLDRL doesn´t appear to provide any sane values. I´m pissed about the fact that there is no real information about it >:( The few phrases in FR and the patents mentioning it are useless.
However based on the FR it seems like KFLDRL is something that is calibrated by trial and error, and isn´t anything you can just calculate based on other measurements.

Regardless, the boost control in MEx. is a huge let down to me.
 

You'll have to do a lot more than simply modifying KFDRL. Why would you assume that is the only map you have to modify?

You're only allowed to be "disappointed" in a PID if you actually understand how PIDs work and how to program them.

You could not be more wrong. The FR describes exactly how to fill it. Those of us who understand this have made tools to calculate it based on measured boost. There is absolutely 0 guesswork involved.
Boost PID calibration is fairly simple in ME7/MED9 once you know what you are doing.

The pilot logic is crap in that it is an I limiter, not a true pilot map like on EDCxx.

I´ve looked into the calculation sheet prj posted, and my values are calculated in the same way.

Check the attachment, you can see my cropped tables in there.

When these values were used, the pre-lin value dropped significantly.
Even with psolr slightly over 1000mbar ldtvr_w never raised above 28.5%. Meanwhile the linearized value (ldtvm) stayed around where it should be.
The boost was even more erratic compared to situation where linearization is disabled.

With linearization disabled (KFLDRL 1:1) ldtvr_w is pretty constant with KFLDIMX, however once the PID enters stable state (B_lddy = 0) the ldtvr_w and ldtvm (obviously) overshoot heavily.

Which means nothing if you didn't get EVERYTHING else 100% right.

That isn't how PIDs work.

The sheet is not correct, it is old and missing a crucial component.

Right.

I guess you´re not going to tell what is the correct method to calculate KFLDRL then?

I can stare at the "Figure 7" (of the patent) for days without getting anywhere.
I can also read the description of KFDRL is FR as many times as I want, but it won´t take me anywhere either since it is in German.
The translation through Google translate isn´t even close enough accurate for something like this.

Wait, so you are going to tell everyone that the worksheet that you posted is wrong, yet do nothing to fix it and continue to be cryptic about what is wrong?  You've told us (me personally) in the past, "if you aren't doing it this way, then you are doing it wrong" with the pretense of using your stupid excel sheet.  :-\

Step 1) log ldimx_w and extrapolate a general ldimx OFFSET from existing KFLDIMX
Step 2) with linear KFDLR log boost vs duty
Step 3) using spread sheet extrapolate new KFDRL AND new temp KFLDIMX
Step 4) extrapolate new final KFLDIMX by running new temp KFLDIMX thru new KFDRL then minus OFFSET

I have work to do, I do not have time to update the excel sheet.

This is correct.
Step 4 is missing from the excel sheet I posted a long time ago.

Step 2 can be done with CWMDAPP?

yes, with KFLDRAPP for WGDC

I known the difference of my current DIMX and ldimx_w (ldimx_w is significantly higher, but parallel otherwise).
I´ve logged boost vs. duty by using KFLDRAPP with CWMDAPP for the full range I need to linearize.

What do you mean by "extrapolate"?
In the attached picture the delta between ldimx_w and KFLDIMX is ~10.6 @ 3000rpm.

Which Excel?
Yours, prj´s and what version?

Thanks!

Just had more time to read elRey's reply.
Not fully correct.

You need to run fixed DC and log the car. Better in a high gear/slow ramp rate on dyno, but you can do some manual correction after and get away with 3rd gear pulls.
Do 0, 10, 20, 30, 40, 50 and so on. The higher you can go the better, but there are always component limits.

Based on this data you need to generate a KFLDRL table, then a KFLDIMX table with inverse lookup through your KFLDRL.
This can be done with a spreadsheet.

Current LDIMX and offset is completely irrelevant.

That's exactly what was meant by step 2 and seems the others knew that.


same as step 3


step 4


If your new KFLDIMX will have this OFFSET applied when in use, how is it irrelevant?

Along with the subtraction of the OFFSET, here's a couple more tips...

Don't just subtract OFFSET from KFLDIMX globally. That would result in no nodes equaling max duty. You want to be smart about applying offset to only the non-maxed nodes and max nodes adjacent to non-max nodes if needed.

Increase the last axis node of KFDRL duty axis to reflect your max duty if greater than stock 95%.

Log your max duty until max safe boost is reached. Then project that max duty boost profile down to each the non 0%, lower duty vs boost profile BEFORE each profile's peak boost. As each profile between 0% and max % should match max % profile up to that profile's peak boost. Then leave the rest of the profile alone. This will simulate ECU holding max duty until target boost is reached.

Greater than 95% ???

???

if TVLDMX > 95%

Because it is.
Offset is the safety offset? You are not supposed to tune that into the table. The safety offset is there to account for irregularities.
IMX is just that - maximum I limitation. It should be above the actual WGDC you have to run - roughly correct, but mostly there to prevent massive overshoot.

The rest of the PID should be controlled using P/D in dynamic state and P/I in steady state.
Your I should not follow the max value from IMX+safety offset in normal conditions.

OFFSET I'm taking about is made up of

LDDIMXN
KFLDIOPU
LDIATA
KFLDIWL
KFRBGOF
and LDIMXAK

Which of those are you considering a 'safety' correction?

I thought community was agreed KFLDIMX is utilized as a pilot/seed.

I believe if you exercise my addition tip of projecting the first part of the max % boost profile onto the other profiles, that will address your overshoot concern.

Did the linearization as prj suggested and... ...the difference is pretty big.
While overshoot at spool still remains and the boost tapers at higher revs, the overall behavior is significantly better.
The overshoot duration has decreased and the mid range (where most of the linearization was required) is significantly smoother.
ECU clearly knows how to control the boost now ;D

Also for the first time, PID is reactivating at the higher revs when lde raises again above UMDYLDR threshold.
Never seen that happening in the past even the boost tapers just as much as before.

The overshoot seems to be caused by a extremely brief spike in ldtv which occurs immediately after PID has shut down / entered to stable state (B_lddy = 0).
The spike is around 7% higher than the duty cycle should be, before and after this point. It is visible in both ldtvr_w and ldtvm, but not in KFLDIMX map.
This suggests that both KFLDIMX and KFLDRL (and their relation / linearization) are fine.

So would it be the stable state P (LDRQ0S) & I (LDRQ1ST) maps be the fault here?
Compensating the spike with KFLDIMX / KFLDRL doesn´t sound to be a good idea since that would treat the symptoms and not the illness itself.

LDDIMXN is safety.
KFLDIOPU - this should not do anything at the level you are calibrating at.
LDIATA - this should not do anything at the level you are calibrating at either.
KFLDIWL - again this should not do anything at the level you are calibrating at.
KFRBGOF - nor should this.
LDIMXAK - this is adaptation, you are not supposed to encode this into KFLDIMX.
None of those matter when filling KFLDIMX. You fill KFLDIMX, then you set the zero point in the correction maps as the point where you filled it.
And use the correction maps for correction.
Adaptation is a whole other thing entirely, those who have trouble tuning the basic PID should turn it off.

ME7 does not have a pilot map. KFLDIMX is an I limiter. A pilot would drive the PID up and down, IMX does not do this. Overshoot is handled by D.
The whole ME7 boost pid is a hack. A poorly understood one at that.

a) Make sure your I maximum is high enough at that RPM and that it is not riding the IMX.
b) Increase stationary I at higher revs.
c) If increasing it causes oscillation, increase stationary P somewhat and decrease stationary I a little.

If you have issues with overshoot, do not just lower I.
You need to increase D (LDRQ2) in the lowest boost delta area most likely.

However, if you increase it too much, on spoolup boost will stop before hitting target, and then I will kick in and it will still overshoot.
You can see it as a zigzag in the N75 DC just before boost hits target.

Ok in that case I probably already have too much D.
That´s exactly what happens, I think.

As long as PID is on the ldtv is fine, however as soon as PID shuts down (stable) the ldtv shoots up, and then immediately back down.

I would say D is too low at higher delta boost.

Graph is useless without plsol.

Thats easily fixed :)

Nice topic. I'm learning as well.

Maybe show the sign of the PID components (P, I & D) when you graph them? D is in fact negative.

Then you can see at a glance what's being added and what's being taken away just looking at the picture :-)

Dynamic mode in spool area you probably want more P and less D.
Your I limit is too high.

Lower KFLDIMX?

Did several changes over the last version.

Increasing stable state I (LDRQ1ST) definitely reduced the tapering of the boost at high rpms.
After increasing it PID doesn´t kick back in anymore at higher revs (> 5000rpm) as the lde stays withing UMDYLDR threshold.
Now it is spot on at the very end, however I need to increase it even more in 5000-6250rpm region.

I also increased dynamic P and reduced D in the area where the ldtv oscillation occurs, causing boost spike. This had no dramatic effect eventhou D was lowered by over 10%.
P shows an anomaly right before PID is entering stable state, because P is still active while D has already dropped to zero. This could be a result from the poor sample rate and not a true issue with the values thou.
With these changes the ldtv oscillation got more severe (lasts longer) so most likely the changes were incorrect.

I also lowered the I-limit by 8-15% in the spool region and increased the rate of descent when closing in the spool area.
This lowered the overshoot, but the current values are already significantly lower for given psolr, than the ones require to reach those levels in fixed duty conditions (CWMDAPP = 8 + KFLDRAPP).

I think I keep the I-limit for now and try different adjustments to dynamic P & D to get rid of the oscillation in ldtv.
If the boost still overshoots, I lower I even further.

Forgot the attachments  ::)

Or you could try my way.

Meaning substracting the "offset" from DIMX?
Sure, but it won´t solve the issues with PID which is causing the spikes in duty.

Also I´m not sure if substracting a constant offset is wise, even if it provides the correct I-limit.
There are environment variables which can change the offset too, such as tans (in LDIATA).
Also I haven´t logged ldimxak_w so I don´t know if it´s contents are fixed or not. Looking at the inputs of BBLDRPID they are not.

[editors note] ugh sorry nottingham I accidentally edited your post instead of following up

sorry sorry :(

I can't recover the content - nyet

IMO you need two things:

1) Flat request during spool for good amount of time before expected peak boost.

2) More Q2 for large lde (1 is required so dlde/dt is large throughout spool).

Just my 2 cents. May or may not work.

The ME7 PID really needs a parallel feedforward - so in that sense, the i-limit sort of provides that purpose, since during spool, enough I should have accumulated that it rides the limit, which ends up being somewhat similar to feed forward.

This is a graph of:

lditv_w (LDR, duty cycle from the I-regulator)
ldptv_w (LDR, duty cycle from the P-regulator)
ldrdtv_w (LDR, duty cycle from the D-regulator)

and

ldtv_w (LDR duty)


You can see the contribution from D is negative just before the steady state (~ 3000 rpm). Once steady state is reached, then D is set to zero (that’s hardcoded in). D acts to reduce the output –> the output is (P) + (I) + (-D). Once you remove D, you remove its negative contribution to the output and so the output increases again.

If you have a large D (big negative contribution), yes it will make the output smaller, but once it goes into steady state and D is zero the output jumps back up again if I is significantly large. That’s why you want to have a look at the other terms. If I was a bit less when D is removed, you wouldn’t such a big jump.

(http://nefariousmotorsports.com/forum/index.php?action=dlattach;topic=517.0;attach=17851)

If you logged the OFFSET in the same conditions as boost vs duty, then you don't have to worry about environment variables changing offset.

Irrelevant.

Correct way is to zero all the offset tables when tuning the boost pid, record the environmental conditions and when you are done tuning fill the offset tables with reasonable values!

Why don't we zero every f'ing table, put the car on a environement controlled dyno and spend weeks, or months recalibrating the whole ecu from scratch?

Get real.

I restored KFLDRQ0 to the same level as it was previously, and increased KFLDRQ2 in the region where the turbo starts to spool and reaches the maximum spool.
It dulled the spike in ldtv significantly, however the spike is still there. I logged ldptv, ldrdtv and lditv this time instead of the raw ldrk? values.
To be honest, trying to understand PID even remotely is probably the hardest thing I´ve ever done. I have no idea what I am doing, obviously ::)

I would assume ldrdtv isn´t suppose to look like that...

Ignorance is bliss. Calibrating ME7/MED9 PID from scratch with adaptations and corrections active is a sure way to disaster.
Zero all offsets and then re-populate based on the pre-populated maps, but choosing your current conditions at zero point. You are not throwing away any data, just making life a lot easier.
ldimxak_w should be zero all the time during calibration regardless and unless you really know what you are doing and know how to adjust it and it's adaptation points, should never be enabled at all.
I am done on this subject - if you do not understand what I am saying, then so be it.


I'd request a little more boost earlier on. That will help with your D spikes... but that is a hack.
You can reduce D at high Delta P, and increase D at low Delta P. That should help with unneccessary high D at large Delta P that you are having initially and lower the overshoot towards the end with lower Delta P. (P as in pressure).

Does anyone have a sheet that fills DIMX correctly via KFLDRL. I've done linearisation but need to sort DIMX to get actual to follow requested

I do... Not here though. Will post if I can remember tomorrow.

Reminder  :)

Double reminder :)

triple reminder

You must have missed this sticky:
http://nefariousmotorsports.com/forum/index.php?topic=12352.0title=

Hi,

I will change my k03s turbo with a F21T. For the k03s I tuned the PID controller with feed forward. I would like to do it with the F21T. I know how to change WG_DC ti a constant value. K03s cannot boost too much at lower rpm, so with 95% fix dc it was no issue to log from 2000rpm. But with f21t I don't want to kill my engine for example 1,5 bar at 2500rpm. Is there any safety feature when the dc is fixed and the actual boost is more than the requested?
Or do you have any propossal how to measure the new turbo and wg linearization?

Thank you

The safety feature is a properly tuned PID

But when wgdc set to a constant pid is not working...

Then don't set wgdc to a constant.

How to do the WG linearization without that?

Ok now I follow. You mean you don't want to break your car while running test pulls.

Just be careful. If you didn't remove any DTCs or controls you should be fine, as long as your fueling holds up.

Limit your wg/rpm range to safe areas when you're doing pulls.

Hi guys, I'm in the process of PID tuning on my 1.8T. I was a lot surprised because I have 1.8T with k04-015 which should be equivalent to k03-073 but my turbo is so strong (considering small K03-04 turbos) that I was really  scared to finish the runs  ;D
With 50%DC I'm boosting 20PSI in 4000rpm and 14PSI in 6000rpm. I finished it on 50 percent and decided not to continue because I dont want to throw a rod.   Elrey in the first post mentioned that he is running also k04 on his passat and on 50%DC he was still far from 14PSI.

I need to analyse logs and make new KFLDRL from it so I will see if I'll be succesful or not. I couldn't imagine put some strong Garret in it or some F21L and make linearisation runs than.  :o

It's much easier to get rid of linear boost on a big turbo than a smaller nervous shit

Use a time in x axis or a check wot filter in options

Check Your WG ... probably its to tight...

It's already solved. WG was okay, turbo was completely new but it is pretty strong. Through this manual I made new KFLDRL  (KFLDIMX linear) and now boost is exactly where it should be. Amazing thread. 

Good job.

what software is this? that ui looks so much nicer than tunerpro haha

It's excel sheet, just for calculation, but author added nice charts. File is posted in this topic.