NefMoto

As an intro - ME7 does not have pre-control.
Yup, that's right - there is no feed-forward.

All MED17 ECU's remedy this. And actually M5.92 and M3.83 have feed-forward.
As does every diesel ECU made starting with MSA-15.

Why did they kill it in ME7? Who knows. But the result is a convoluted piece of cr*p which is stupidly difficult to tune.
Because as you need more DC up top, the PID has to work really hard all the time, and I and P have to be super sensitive, which then causes oscillations in other conditions. They introduced tons of bullshit like LDDIMNN and LDDIMXN, I-part adaptation and so on.

And why?

To somehow make this clusterfuck work.

However, someone realized how bad this is at some point, and for example the RS6 and RS4 are calibrated way differently. By giving them some actual feed-forward and reducing the work the PID must do.
It's a giant hack, but the way it works is like this:
(http://nefariousmotorsports.com/forum/index.php?action=dlattach;topic=12352.0;attach=22352)

Since in steady state the majority of the boost input comes from I, KFLDIMX is used as a map to basically convert pressure to duty cycle - hence the reason it is perfectly linear.
And then you can view KFLDRL basically as a pressure-dc pre-control map. The axes are now essentially pressure - for example the axis value 60% in KFLDRL becomes 667mbar, and the map is a proper pre-control map, as it actually drives duty cycle off of it, while the PID only has to compensate for the actual drift from the pre-set map. Also, you don't need all that wastegate actuator linearization bullshit, as it's all now baked into one single map.

As for what happens to I - you need to choose the range for KFLDIMX so that it covers your required boost conditions. You will still need to do the linearization runs, but you will have just one map, and it will work much better than the stock clusterfuck.

I need to adjust my spreadsheet for this, but thought I'd post about this, as a few people who have been on here for a while might find the answer to the "why?" question useful.

If this really works "that simple" it would be awesome  ;D
It took me forever to get my PID in the range of sane.
And through it all I was always wondering why it was so extremely complicated  ???
And I was wondering why there was no feed forward, with would have made the PID correction so much more easier to do :)

Well that's interesting... I"ll have to try that trick

Thanks for this, prj.

Bravo

Looks very logical, thanks for sharing! If your spreadsheet works well this will save a lot if calibration time!

Something must be wrong here.
PRJ never started a thread before.  ;D

Thank you for this post!

You would be wrong.
I just prefer quality over quantity.

From a stock BEL allroad.  Same as you describe here?

Yup, exactly.

Excuse my ignorance, but how are the values of KFLDRL populated? KFLDRAPP?

But since this would be I riding IMX, it seems that the PID can only REMOVE WG via I, never add, so if you have a persistent underboost, the PID cannot compensate? Or you just let the I adaptation take care of that?

Not correct. That is what LDDIMXN is for.
Generally your PID should never ever ride I-max. There should be always a bit of free room. The only place it should be riding it somewhat would probably be 2nd gear, as in 1st gear it's still in dynamic mode.

I-max is not there to control overshoot whatsoever. It is there to provide a sane limit, which should always be a little higher than what is needed.
Overshoot needs to be controlled using D, so that it lands in steady state and after that P and I will take care of it.

You basically have two controllers in ME7 - a P/D dynamic controller and a P/I static controller with switching between them. This is a good way to do things from the PID perspective and boost control.
I adaptation is fairly useless in aftermarket situations. It is mostly there so it meets the target with loose component tolerances (due to aging) on a stock tune where there is room everywhere.

Can confirm this works well.  I was having all kinds of boost control issues on my Allroad with chinese turbos until I did this.  It's been great for the last year.

Can i i just echo Contrast... How do we populate KFLDRL?

Are you saying that the linearization runs are used to provide DC values for DRL....? Leaving DIMX as best guess estimates??

Interesting!


Is your spreadsheet posted somewhere that I might be able to snag it?

Second this.

Not the latest version.
It's kinda hacky at this point and requires some manual work, I need to bring out my excel-fu and finalize it.
Or someone else can do it :)

I Would love to contribute, and have Excel skills! ;D. Let me know.

I was working on this, but I really suck at excel.
 My idea is to load a CSV with ldtvm, nmot_w and pvdkds_w, then the values need to be averaged and transferred to the yellow box on sheet 2. From there, it needs to convert the actual mbar boost to the corresponding green columns based on the 100% boost value that will be used in KFLDIMX. The rows will have to be interpolated from fixed WGDC to represent the new requested wgdc.

I know what I want, just dont have the skill to make it work (and will do it manually untill then).  ;D

This would be superb if it becomes reality

I was considering writing something for this in a .NET app and open source it.  Would anyone actually help code it though?

That would be even better, but at this time A4Rich is already trying to implement the calculations in my spreadsheet. But I think there are some guys here that can help you for sure, like maybe guitar24t? He did a nice fkkvs gui.. I would love to help out, but I have never written anything outside of C166 ASM  ;D

Rob Hilton is the man for sure...don't see him on the forum much these days.

I do wonder if he's still that proactive these days.

i don't know if this will help get the ball rolling,
But i'm willing to donate $20 to the the person/s that i willing to write a GUI for this :)

I started on this last night.  I took my fixed DC runs, most of them at least.   I started on the GUI, and have it parsing a folder of log files, filtering out samples where accel pedal post >= 80%.   Now, just need to take these filtered data points and make magic happen.

Why don't you put it on github already so that other people can join in on it?

haha, already!   I just started on this last night!

I will try to get something out there tonight.

^^ Hero Member for a reason.

Nice work.

and i stand by what i say, the $20 is yours if you make the magic  :P

Magic is not yet made, but here's a start.  I added the LDRPID Tool to the VisualME7Logger git.

https://github.com/sbloom82/VisualME7Logger

It currently reads a directory of logs, filters the data by accel position, and parses the data into a somewhat usable format.  I've also included my fixed wgdc logs in the resources folder for something to work off of.

committed a few changes.  I've got it now so that the logs are populating absolute pressure values into a grid of DC/RPM.   I need to do something to detect spool up in the data points so it doesn't incorrectly average values of full boost and spool up boost for a given rpm/dc.
That's my progress so far, feel free to download the source and have at'er.

I have looked at it yesterday, will try to contribute. Good work so far, a solution for spool-up might be to check for a percentage of increase threshold? Once it settles there should not be much increase. Another option is mbar increase per 100rpm or something, maybe keep it a variable to suit different turbo setups.

Here's a first version of the tool.  I just took my first test run with the maps generated from the program and it seems to work pretty well.  I currently have a ton of overshoot in spots, but a little work on q2 should do the trick.   

To tired to explain how it works other than you load in a directory of log files, edit the axis and data that is loaded in, and generate a KFLDRL based on all that.

My log files that I used on the github if you want to mess around.  Otherwise, if anyone has other sets of log files to test with, please share!

edit, latest version of the tool is on the next page.

After a tiny bit of massaging, this is what KFLDRL looks like for me.

Did you set KFLDIMX perfectly linear too?

Awesome, I will test this tonight! I dont have a complete set of logs yet but I can verify against my manual work!
I really appreciate your effort in making this a GUI! Hope that there are other C# writers that can contribute in the finetuning of the program!

Using this method, I can't seem to get this lump of dc out after spool up.  It happens in every gear at every rpm range.  Once it falls back to steady boost is on the money every where, but that damn bump.

Why don't you take some wgdc out where it's 95%?


Maybe the turbo is spooling up so fast that the amount of dc less than 95% on the above plot before the overshoot, isn't enough to allow the turbo to slow down. So 95% wgdc till like 3400 or 3600rpm then drop it.

Or take that hump out of wgdc @ 3900ish?

Hi,

This is epic.

Just to clarify:

The line under KFLDIMX is where the values for the relevant IDE column are listed? Do you only need to write one line then?

So for example:

All values in DIMX under 1800mbar are 81%? in the tool?

I only ask becasue you can add more lines to the little DIMX table

In addition, is there a way of getting this tool to work with the following volvo log file format?

I've noticed that it wont parse file if they've been saved as .csv from excel too. (i.e, opened for viewing and saved)

It won't parse them... Will offer a $ contribution if you can...

This happens at all rpms, not just at 3,x00.  I really just need to log all the pid variables to see what part is causing that hump.  I don't think it's influenced by KFLDRL.

Yes, it only looks at the axis row and the first data row.  If you add more rows, it's not going to do anything with them.

It looks like it parses the log file just fine.. but isn't auto-detecting the variable based on the way the program expects them to be named.   Probably just need to add settings tell the program the variables to use.   For the time being, you can just modify the header row like this:

Time (sec),Pedal Position(%) wped_w,Engine Speed(RPM) nmot_w,

to

Time (sec),wped,nmot_w,

...but I looked at your log, and this is not a fixed DC log.  The program won't work with this.

Here's what it currently expects:
wped,
ldtvm,
nmot or nmot_w,
pvdks_w,
pu or pu_w or defaults to 1000


As for saving the log file to excel format and expecting anything to be able to parse it.... take a long walk off a short cliff.  ;)

Thanks for this. I'll give it a shot.

What I meant was that, if I open one of your own logs in excel and then save it as a CSV (say I change a header value ) then the excel saved CSV won't work. Even if I open a CSV and resave it as a CSV with no changes, it won't parse anymore.

I compared the two rW files, original and excel saved and they look a lot different.

Maybe I'll see if I can find and try a freeware CSV program.

This is still amazing work. Regds

Yes, it is very well known that excel fucks up a CSV.   Just ask Nyet what he thinks about this.  :)  Try using any log parsing program against a file saved in excel... it won't work.   Use notepad if you need to edit the file.

I've made changes to the program to work with "volvo" (I think you meant "hilton") files.   I will post a new binary when I figure the remaining kinks.   In the meantime, you can get the latest source and compile it if needed.

I am still battling overshoot and have been working on trying to correct it with manual changes.   My next attempt will be lower the DIMX values and generate a new KFLDRL from that.  I attached a graph of what my overshoot looks like.  I-Result follows I-Max, causing the hump, and then I-Result slow falls away from I-Max.  I just need to figure out how to correct this.

When I was messing around with different KLFDIMX values in the tool, I realized that the algorithm to calculate the DC for KFLDRL wasn't complete, and I ended up with invalid results.   I think my first pass, the values in DIMX were just right for me to not notice that something was off.

With that said, I've made changes to the algo to correct the issue.  I tried the generated values as is, but STILL ended up with overshoot.  The values in KFLDIMX were too high resulting in too high of I-MAX values, which ultimately caused that hump.  I was able to scale the KFLDIMX axis values up in my file to account for this, and now my boost is almost perfect.  I have a little work to do on Q2 again, to back track the changes I made to try to account for the overshoot.  

I am still not 100% happy that I had to make modifications to the maps after the fact, but it was very easy to just add another 10% to each DIMX axis values to get I-MAX in check.  I'd really like to find out why my boost isn't perfect right with maps generated from the tool, but this will do for now.

Once I get my motor together I will try to do the same and let you know.

Most OE calibrations/hardware have overshoot like you have. Not sure if it's a "feature" or laziness, or something that can't be completely dialed out if you want the spool. I don't see an issue with a small amount of overshoot especially considering what you have to work with pid-wise. Just my opinion.

Also overshoot is in the nature of almost all PIDs, whether or not they have feed forward components.

If they are steered primarily via I, overshoot is necessary for the control to converge and maintain stability on changing setpoints.

Agreed.  :)

My overshoot here was excessive, and the PID calibration that I did from hand that I was using for many years did a MUCH better job at controlling overshoot.

26psi request and 32psi overshoot is a little too much...especially when you take the time to write a program to calibrate the pid for you in hopes of PERFECT boost control in all ranges, you want it dead nuts accurate.

You go, boy!

Agreed there, 100%

This is very impressive.

I never realised excel screwed the csv so badly. You're correct the log files are based on the Hilton/Dream3r format.

I'd be inclined to do this for exhaust and dp upgrades even for stock turbo tunes regardless of 5120. Much more effective.

Awesome.

I updated the log parsing so that it works with this format with the latest version posted on this page.

Never use excel. Ever. It is a cancer.

So just to clarify, I need fixed DC logs of 10,20,30 etc. %WGDC all throughout the RPM band.

The logs should contain;

Wped
ldtvm
nmot_w
pvdks_w
pu_w

And then the program should be able to generate the numbers needed to populate KFLDRL?

Need to set fixed DC in kfldrapp and then activate calibration without torque structure by setting cwdrapp to 8.

Kfldrapp is set to 0 all across the table in the factory.

Leave lower %ped columns at 0 and set higher than say 50% ped to your fixed duty values.

You'll need maybe 8 iterations of the same file with different drapp values. From 10-80% duty.

In effect what this achieves is the same as the open loop boost method used when tuning above 1.53 mbar but broadcast across dimx where pid can provide its influence. It's awesome.

So yes the program generates KFLDRL for you based on the corresponding fixed DC logs.

DRAPP overrides DIMX and DRL.

throttlePlateAngle = wdkba
OR
accelPedal = wped or wped_w

dc = ldtvm
rpm = nmot or nmot_w
pressure = pvdks_w or pvdkds_w
baroPressure = pu or pu_w or pus_w or override value in program

Can I do several pulls in one log and it would still register correctly in the program?

Yes, it can do this, but then you might get weird averaging where you are spooling up.   You can mess with the spool filter to account for this.  I would really just do one pull in 3rd gear from 2,000rpm to redline for each dc.

Okay, I'm really excited to try out this tool.
I've always hated messing with the boost PID  :P

Although my PID was fine and worked, I still tried this.
Everything is perfect. Resulting KFLDRL drives awesome. Very easy stuff.
Only 0-40 duty logs are annoying to do cause car's so slow then.

EDIT:

Huge respect and thanks to the creator!

Indeed ^

Massive massive kudos SB-GLI.

This'll be default stage 2.5 tuning in due course I'm sure ;-)

Maybe I am using it wrong, but the generated kfldrl is completely flat, 0 10 20 etc

no matter what logs I use, I tried with yours and same result

Upload your file, but if you are getting a flat drl with my logs, you're not doing something right.   First "load" the files which will fill out the grid on the main form with pressure by rpm and dc, and with that filled in click "generate"

never mind, I was not seeing the load button  ;D  :P

another question, on IMX we fill with duty to achive those pressures?

The tool works based on the concepts that were described in the first post on this thread.  Understand those, and you'll know how to use the tool. 

Hint: With this method, KFLDIMX basically converts the KFLDRL axis into pressure.

I understand it, that´s how I have been doing it...

just didn´t know how you have designed this tool

thanks

Good job :)

Also, went through the thread - LDDIMX/LDDIMN can give you problems, might want to get rid of some of that.
Generally overshoot is not the fault of the I maximum or the pre-control, if the pre-control is calculated correctly.
At lower revs it can be because you are not loading engine enough at low revs when generating the map (don't have dyno), at all revs it is usually problem with too aggressive P or too little D.

Anyone who has a set of logs can feel free to share them.

if you referring to linearization runs, here you go

Those logs won't work very well without accel pedal in them.  The tool filters out points less than 80% pedal.   If you don't have accel pedal in the log, it takes every point.

they are old logs..

recent ones from other setup with accel pedal, but are a little big and only 40 to 70 duty

can´t seem to get a good result at 70 duty

but will try it tonight

I recommend using wdkba instead of wped and filtering by increasing rpm with some allowance for jitter.

That's not a terrible idea to use throttle plate angle instead, it's essentially the same thing, but I bet it will fix an issue that I had to work around where the WGDC is not at the expected fixed level as soon as the throttle plate is smashed to the floor.

I am currently filtering out spool up by a pressure increase over a set time span, which is configurable.

- Fixed some bugs in the way the pressure grid is loaded from logs
- additional filtering on throttle plate angle
- extrapolate cells with missing data (background red)

hats off

would recommend to add some kind of version number in the tool itself and toolname attached to your posts.

Can not get new version to work with my logs, error message pops up

whith your logs works fine..

Sorry bout that.  Fixed

Latest version crashes with Volvo log files.

lolz, please upload your logs here.

sorry...

attached.

This .rar seems to not be a .rar.   Or at least not one that 7zip can handle.

Dl winrar

first time I have had to use winrar itself to extract a rar....  7zip has handled it just fine in any other case I can remember.

Your logs worked just fine for me.   Did you dl the last update that I posted?  The zip file (v 1.2) immediately above your post saying that it crashes.

Yes, I downloaded the zip. I will try again.
Maybe its because I edited the axes?

Thanx for great gui. 
Just to clarify.
This is used only with Visual logger or both VL and Me7 logger?

Fixed a bug for contrast
Made grid control better for copy/paste and editing a selection.

gah, and one more multi-threading bug, caused the grid to load up differently in some cases.

another question...

is only possible to copy a  single cell at a time, at least that's what happening with me, it would be better if was possible to copy the whole table

It was always possible to copy the entire table to paste into ols.   Perhaps it's not an friendly with tunerpro, if that's what you are using.   TunerPro has some issues with copy pasting normal table formats.  If you are using tunerpro, the trick that I used back in the day when I used that program.... copy from source, paste into excel/open office, copy again, paste into TunerPro.

Regardless of that, with the last update I made those grids more copy/paste-able within the program itself.

ok, so its my problem, as I can only copy single cell

if I select all cells and right click, nothing,

nevermind, ctrl+c works fine...  :P

right mouse clicks are for the weak     :P

Since someone had this problem, I should mention this.

The tool looks in the specified folder for all .csv files.   If your file does not have the .csv extension, it will not detect it.

I've been trying to dial in the PID with this with my 0.9bar external wastegates and things are running
okay but there is something that I can't get rid of. I've a good amount of bump in wgdc on spoolup and
then of course it shoots back to 95% because actual is not meeting requested and then I think I will
have to do a run at 95% duty as well (only did up to 80) because my 95% KFLDRL column is too low
for reaching requested.
What do you guys think?

Thanks

(http://i.imgur.com/P1iD3ac.jpg)

i think it might be the derivative term being to aggressive?

That, also your map is useless below 3000 rpm.
So just start the RPM axis at 2500 or 3000 and go in 250 rpm increments.

I would also shift DIMX so that your 95 column untouched.  Get the control in the middle of the map instead of way at the bottom right.

Thanks for the input guys, I have moved the rpm axis and also changed the dc axis
to include 90 as well, however I guess it would be better to have something like
0 25 50 60 65 70 75 80 85 90 95. I've also halved KFLDRQ2 and I'm going to test
tomorrow. Here is what the current DRL looks like:

(http://i.imgur.com/1xOlj5l.jpg)

SB_GLI: What do you mean by shifting DIMX? Having 95 as the last column and shifting everything else to the left?

You want to increase the values of the DIMX pressure axis.

Please post your logs.

Doing anything with KFDRQ2 does not really affect the bump, so obviously
I have no idea what's happening :(
Raising the last column of KFLDRL by hand about 10% makes upper rpm ranges
a bit happier but still not perfect, I don't think that in 3rd gear I can produce much
more boost.

(http://i.imgur.com/mhkDa68.jpg)
(http://i.imgur.com/VENzmVp.jpg)

I've had to upload the files to my server because the forum was
not happy about them today...

Current log with that Q2: http://nerd.hu/tmp/20170828T145028.log (http://nerd.hu/tmp/20170828T145028.log)
Runs: http://nerd.hu/tmp/pid.tgz (http://nerd.hu/tmp/pid.tgz)

Thanks

Your KFLDIMX axis:  Assume this a 5120?  I don't see any pressure above the map limit in your logs so I am not sure.

I was suggesting that you increase the KFLDIMX pressure axis in the tool so that you leave the 95 column as 95.

Since 0 % DC is around 1bar for you, I would suggest coming up with a completely new KFLDIMX axis.

Try this axis and generate your data from it:

0, 500, 1000, 1250, 1500, 1750, 2000, 2250

FWIW, I wasn't able to make the output from the tool work "as is" either.  I ended up having to increase the KFLDIMX access by like 10% after the data was generated (in ols/tunerpro) to get my boost on the money.

Not that this will matter, but you might want to smooth out your DRL where the calculated data ends.   you have 40's in the 40 column, but 20s in the 50 column.  40 should be less than what you have in 50.

Yes, it is 5120.

Well I actually have runs for the lower duty cycles (30,40) so it's weird that the tool did not pick them up.
They do appear in the tool, but the generated DRL map does not have them.

the tool is very picky with the values that you put in imx, and looking at the generated drl i guess that you are not filling that correctly

looking to your logs, you have too low drl values

Yeah I might have to do the runs in 4th gear...

I think there is confusion as to how this tool works by some.  Using pre-control, in a nutshell, takes the KFLDRL axis and converts it to pressure via KFLDIMX.   Understand that, and you will understand how the tool works and why you are getting the generated values you are getting.

See my last post.  The tool is not picky.

Okay, changing the axis of IMX, did "fix" the low duty issue, but did not
get rid of the "valley" on spool, so that will be something else I guess.
The IMX axis was divided by 2 due to 5120.

(http://i.imgur.com/CBEpvWz.jpg)
http://nerd.hu/tmp/20170829T085636.log (http://nerd.hu/tmp/20170829T085636.log)

Anyway it seems that there is not much left in the turbos so I don't
see the point switching to stronger springs.

Your last DC axis is too high.
This means it reads the last column only past 2.25bar wich you are not reaching. Insted it looks up column under and it brings your boost down.
On your setup i would have 900 aka 1.8 bar as highest lookup column.

His axis value are good.  His logs show that he's running 2.2 - 2.3bar boost.

rnagy, you just have to manually smooth out the < 40 columns.  You didn't have any significant data from your logs that filled those columns in, and therefore you are left with the default values.

Not according the graph he posted on page 7.
He was hardly peaking 2.2bar and dropped to 2bar all the way.

look again?

I think I did not upload a graph of the latest run, just the log and the tables.

Not much work for the PID to do when you are requesting boost that requires your DC to be clamped hard at 95%.

How's part throttle boost?

Haha yeah, that's true, however since the turbos are done at least according to the compressor map, I don't see
any good reason to go with stronger springs. I will check part throttle tomorrow and I will also try with a lower boost
request curve to see if the PID works as it should. Regarding the dip in the spoolup area, maybe I should try to alter
the rpm axis of Q2 and go from there. I am still trying to understand how Q2 is actually coming into the big picture.

And of course thanks for all the help thus far guys!

Once you lower the boost request it will be interesting to see if the maps generated from the tool will work as is, or if you need to tweak the kfldimx axis like I did.  For me, it was as simple as adding 10% to the axis values to get it all on the money.

Now I am a little confused...

My understanding is that IMX axis is pressure above wastegate pressure (KFVPLGU) at least this is how I tuned mine with good results.
If I´m not wrong, that IMX axis makes no sense to me.

If your KFVPLGU is stock, 70% in KFLDRL should be ~1750mbar above wastegate(~1550mbar) but that duty is to low for your requests  ???

And that explains why I had to add a percentage to my KFLDIMX axis after the fact.   I knew there was something else at play here.  I think the tool needs to also take plgrus_w into account to calculate everything, or ask for an offset if not available, to be spot on.   I just went through the FR on this to better understand input of the KFLDIMX axis.  I will be logging and investigating tonight.   Thanks for pointing this out.

Just as a note, here is a 4th gear pull where the PID actually has to do something.
I think I will install a 1.2bar springs in the gates instead of the 0.9 ones, just to make
things happier.

Don't be fooled by how ECUxPlot auto sets the axis range.   While it looks like it might be doing something, it's only dropping from 95% to 90%.   If the scale was 0-100% you'd barely notice a blip in WGDC.

After logging last night, I notice that plgrus_w is almost always pu_w (atmospheric) and plsolr_w (input to KFLDIMX) is what I expected it to be... desired boost pressure - atmospheric pressure, therefore the tool should work as I expected it to.

This is on a 1.8t 032LP.

For me tool is perfect.

@SB_GLI
Can you please add some kind of info button where it display what variables should be in the logfile?
That will be perfect.

Thank you for great work  8)

I am not fooled I know the axis range can trick you, there is not much difference between 90 and 95% so that's the reason
I am switching to 1.2bar springs  ;)

throttlePlateAngle = wdkba
OR
accelPedal = wped or wped_w

dc = ldtvm
rpm = nmot or nmot_w
pressure = pvdks_w or pvdkds_w
baroPressure = pu or pu_w or pus_w or override value in program

It depends on the car. On 1.8T it's settable whether plsolr_w comes from plsol_w - pu_w or plgrus_w.
On 2.7TT it is not and needs to be changed in asm.

Wait, I'm confused, do you mean settable between plgrus_w (which is plsol_w-pu_w) or just pu_w (2.7t)?

I assume rnagy86 does not have it on stock form cause he has it the same as your 1.8t,

but this is RS4  whithout any modification to code:

(https://s26.postimg.org/v4zlzdth5/baseboost.png) (https://postimg.org/image/7qrmngbjp/)

Bug fix Friday!

1) Corrected an issue in the way data was interpolated if DC's in KFLDIMX didn't match the values of the KFLDRL axis, or KFLDIMX was not perfectly linear.
2) Added help text along with version information

Thanks man
Like that work

I've moved on to working on my allroad.  It's a 2003, using 551R.

The tool does not even come close with this binary because unlike my 1.8t, plgrus_w != pu_w.  This results is significant underboost.

plgrus_w follows base boost.  How should the tool work in the scenario? Could it take a 0% WGDC run and subtract those values from the rest of the runs to be able to generate maps that work?  I am struggling to understand the correct approach on this one.

Edit: Seems this way will require input of KFDPLGU for it to correctly generate a proper KFLDRL, either that or an ASM hack would be required to make plgrus_s == pu_w like it is on my 1.8t.

Don´t see why it does not work as it is, you should only need to change the axis on the actual file.

Use the tool the same way(assume plgrus_w = pu_w), but then add pu_w and remove plgrus_w to imx axis.

plgrus_w isn't static like pu_w.  Notice how it changes over rpm.  Changing the imx axis won't work for this.

Back to my 1.8t. 

LDDIMXN increases ldimx so it needs to be accounted for, either by subtracting these values from the KFLDIMX data, or modifying LDDIMXN.  In my file it was around a 6 point increase, which accounts for the 10% I added to the KFLDIMX axis.  I think it's okay to zero this table out but I still have to test this.

If you have a slower spooling turbo, I believe appropriately increasing NLDIAPU will disable boost corrections at lower rpms and make calibration easier.

Confirmed!  Zeroing LDDIMXN gave near perfect results with the data generated from the tool.

Version 1.6.

-Updated tool to process all logs of any fixed duty cycle, not just where the DC matches a KFLDRL axis.
-Added help text noting LDDIMXN.

Can anyone explain how the spool filter works please?

I.e. how do you set it?

I just noticed some strange behavior.

I just flattened KFTARX/B/ZK to 1 and got substantial under boost.
And when I reverted back to stock, boost was on point again.

Yeah, you basicly req less Load by having all values 1 where org values are + 2% and more under 30deg C IAT.

Yeah, but the actual was 20% lower than requested, so nowhere near the 1.5%(in my case)

The program filters based on throttle plate angle (wdkba) or accel pedal angle (wped|wped_w).  It uses throttle plate angle, if it exists, otherwise accel pedal, which has to be > 90% for a sample to be included.  a sample must be above min rpm param (default 2500) to be included.

From there it uses the spool filter to remove samples to the left of an "x" second window where the boost increase is > "y" amount.

I have an update to post, but forum file storage is stuffed.  It extrapolates upward which makes it easier to use when approaching MAP limit.

Just finding the time to try this tool, and everything's working great so far. Planning on getting to the meat of it this upcoming week. Wanted to say thanks for creating/ sharing this. Also looking forward to the update(s) you mentioned. Wanted to add, having it save the axis changes on closing would be a nice added feature. :)

Version 1.7

Would flattening KFLDRL give me a fixed duty cycle similar to using KFLDRAPP. I'm having trouble finding KFLDRAPP. Noob problems.............

Replied in your other post.

First of all thanks to the creators of this, it really is a great idea. I have used the tool to generate my maps, but I still have instability in the spool zone, and before touching it I want to know if I am not using this correctly or is it that I have to adjust other maps to correct this problem? I leave you a log of three tests wot in fourth gear

I think your boost request is causing the issues you are experiencing.  You have some pretty large changes in request in the spool up zone.   Flatten this out and it should take care of if for you.   Summary, increase request @ 2000 - 2500 to flatten the request out.

perfect, thanks for the help I'm going to try. Apart from this, do you think I should touch some other map in the pid ?, or should I just manually adjust the kfldrl map?

I attached photos of the generated maps, and the logs that I used

regards

You want to leave the 95 column of drl all 95 so that you can get fastest spool at all rpms.  Work the KFLDIMX table in tool to achieve this.

I never adjust KFLDRL after the tool.  If I have to fix anything up, it's usually general over/under shoot.  For that, usually a percentage adjustment the entire IMX axis is all that's need to get it perfect.  That and a little Q2 to fix spoolup overboost.  The rest should just trim out.

if I understand correctly, you propose me to modify the content of imx (linear values), and if I suffer overboost in the whole range or underboost, modify the axis of imx truth ?.

thanks

The change that I suggest to keep 95 locked at 95 in DRL is simply to make sure you aren't limiting WGDC to a lower value when you want fast spool up, it will not fix the issue that you have (I believe the LDRXN change I proposed will take care of that)

For example, if you have the value 65 in KFLDRL 95/3000, you will never be able to get WGDC values higher than 65 @ 3000 rpm and your spool rate will suffer. 

in summary, always leave 95 column values as 95.

I've made the changes you've told me, and now column 95 stays intact, I think this is what you wanted to tell me? thanks for your help

that should work fine.  I like to keep KFLDIMX linear though.

yes, imx is linear according to the data that I entered in the tool

well, I still do not get a stable result, this is the last test generated with the same axes of the last photos, but applying the spool filter in 65 / 0.20s, it has improved a bit, but I do not know if I should work any other map, or edit manually drl a bit.

thanks

It's not

Just modify the ixm axis values by a few percent (post tool) to get it to run through drl how you need it to.  Haven't yet looked at the log.

my imx is 400 10%,650 20%,750 30%, 950 40%, 1150 50%,1250 60%,1350 70%,1450 80%

looking at the log, I see that I have a cycle left at the beginning, and I am missing between 3k-4k, should I change the axis and increase the whole axis by a% or should I decrease it? If I increase it, it will make the hole worse, but then I can correct it from q2?
I wrote the imx data in the tool exactly as it is here

regards

look at your kfldimx in 3d view and tell me it's linear.... it doesn't need to be though it will work fine without it being perfectly linear.  it's just easier to make adjustments if it is.

You just need a little more q2 and it will be perfect.

call me an idiot, but I'm not sure I understood you, do you mean I should try to make this view more linear? let's say it is ascending but more straight?
Can you give me an example?
thanks

Yes, more straight. As in completely "straight". As in subtract your lowest value from the highest value of the hpa axis, and then divide that by the number of cells between them. Start on either end of the axis and add/subtract those values to get the stepping between the cells equal. Like SB said it does not have to be like this, but makes it easier to translate between the maps. This isn't going to really change your boost response, it's just simplifying part of the process. HTH.

Thank you for your clarification, now I have understood what I should do. Greetings, I will try it

ok I think this is what you wanted to tell me. I'm going to generate a new drl with all these changes and I'll try

I still have that instability up to 4k, in all the files generated by the tool has happened the same, I think the tool is doing its function, but there is something in my calibration that should be adjusted in that area, here are the screenshots of such maps as they are now, and two wot tests. It seems that from 4k begins to stabilize, q2 begins to fall in that area, I really do not know if I should lower the values of q2 before 4k. it is currently stock. I show you drl generated by the tool, linear imx, and lddimxn to zero. Thanks for the help

logs would be helpful

here is it. thanks

logs need ldtvr_w.

I'd still increase your request more at 2500 rpm and add more to q2.

what amount do you suggest that you add to q2?
I add it to the whole map? or just a certain area

I really thought that I needed to remove q2 to lower the oscillation, but I was wrong. really what does q2 do?

i actually agree, less q2 will help remove oscillation, and it will expose where you need to fix up IMX

I have been able to see in several calibrations stock for 1.8 k04, that q2, q1, q1st etc are around between a 30/50 lower percentage. my turbobe k04, although it is not the same model of 225, maybe it would be good to use all these maps?

difficult to tell anything without ldtvr_w, but I really think there's not enough q2.   I would add some (15-25%) in the first two columns from 2k - 4k and smooth it out.

Take note of how much your boost request is changing as actual is approaching requested.   This needs to be flattened out a bit otherwise it's going to be really hard for the PID to try to control it.

you mean, what should I do, increase more demand in that area?
I know I'm trying to control a turbo that charges me fast and soon, but I would not like to boost so low to protect the clunch, rods etc, and I really thought that the pid is there to control this phenomenon. going back to the log, then you see progressively necessary incremental there, and now that you have the variable that you needed to see, you can advise me on imx or something else that I need to adjust. thanks for your help

I'd try bringing IMX up a bit.. I don't see a lot of P or D activity in the area where you are underboosting, which means I is a bit low there.

They only come in long after the underboost to correct the I which is a bit low.

Unfortunately, increasing IMX will probably get you a bit more overboost, but it might help the underboost oscillation initiation.

I understand your concerns about surge, and they are not unreasonable, just realize it is very tricky to PID control a turbo during spool.

Do you think that would be correct?

sorry this is the image

Any change to flatten the request out more where actual begins to meet requested is what you need.   That means, either increase request around 2,500 or decrease request around 3k, whatever works best for you.  You have this gigantic cliff of a request and that isn't helping.  If you didn't have that, even if imx wasn't 100% on the money, it's close, and the difference would trim out after a pull or two.

Another thing to consider is that you might not have great data at 2,000 - 2,500 rpm which could be a contributing factor.

All in all, your calibration is really close, so I'd feel good about what you have so far if I were you.  :)

I would like to comment quickly by saying that setting up KFLDIMX and its axes along with proper set of logs has worked perfect for any turbo setup. Be it big and laggy or super quick spool. I haven’t had the need to touch any of the PID maps so far.

I do have a recommendation that yielded even greater results on fast spooling turbos. I did a set of 0-90 duty cycle logs in third gear from 1500 rpm to redline. This produced a map that I saved in WinOLS. Then I did the same logs in fifth/sixth gear from 1000 to about 3500 rpm. I then merged the two resulting maps together. This gave me data for zones that I access only during overtaking on highway for example etc. No overshoot/undershoot, actual boost follows target on point.

Thank you very much for your contribution, I will make more logs as soon as I can.

well after some tests and changes, I used the filter of the tool to try to make the spool softer, and I have achieved this

I have managed to reverse the situation, now it does not reach the demand, I think it is a matter of trying until it gets closer, and then making minor adjustments in other points.

What did you have in KFLDRL?  Do you intend on only running 1.1 bar max?  KFLDIMX should be configured so the lowest value is less than base boost, and highest value is greater than max boost you intend to run.  Make the values linear in between.

No, you should do what I said a couple of posts up.  Make an KFLDIMX that covers your desired boost range, and make it linear.   This should be an easy concept to understand.

Attaboy

on 1.8t it works great ...

could one include the consideration for plgrus_w for 2.7t?

or can someone tell me how I can use the tool for it.

unfortunately I can not do an asm hack.

Many Thanks



Gesendet von meinem SM-G930F mit Tapatalk

you could use CWLDIMX to input without the plgrus_w on IMX.
then use the measurements drive with fixed ldtvm ... tool.
but without plgrus_w or drive with CWLDIMX brings problems in the amount.
I do not know if that works for RS4 at all, I'm on the job

Hello @all

the input plgrus_w in pu_w I have changed with success-> check on the tabel witch ols300 ( plsol over Applikation).
I would rather leave plgrus_w original. I want to make it switchable,better for emulator ride.

my idea
when switching by CWLDIMX to 1, pu_w should be switched -> on picture marked.
how can I turn 0.0 to pu_w?
not a fixed value but RAM_pu_w
I'm not that good at the ASM hack yet, but I'm trying to learn

would then share my successes
Many thanks

https://ibb.co/iTLPJn
https://ibb.co/gn4UjS

You don't need plgrus_w original, because it's a nightmare to calibrate.
If you are not using original logic in it for boost control, then just make plgrus_w = pu_w, and change the actuator spring maps to reflect it.
Much easier to tune aftermarket, and not worse in any way - in fact done many times like this from factory.

on RS4
input without the plgrus_w on IMX (plgrus_w = pu_w)
look from address 07A6A0

Not the correct way to do it.

Why?

with ols300 on the table is ok..in the car too.

What is wrong in your opinion?

 I just wanted to change the input for IMX to use the tool.

table base load pressure I enter the values ​​at 0% tv for the other calculations



Gesendet von meinem SM-G930F mit Tapatalk

Correct is to make plgrus_w = pu_w like ECU's that have CWPLGU when it is set to 1.
This is a hack.

Thanks for answer
far as I'm not in ASM.

I just wanted to use the tool for rs4.

but I'm right that only the input for IMX is changed?



Gesendet von meinem SM-G930F mit Tapatalk

Trying to tune my 2003 quattro AMB 1.8t tiptronic :-X. I've tried a handful of variations in tunes, mostly adjusting the KFLDIMX mbar axis around trying to get the psi to be semi stable. I've messed around with slight variations in KFLDRL and LDRXN also... I know I need to zero out LDDIMXN, but I can't seem to find a good definition for the map and apparently I'm to stupid to figure out how to find it. So I've been trying to compensate with KFLDIMX.

I don't understand why ldtv isn't following ldtvr_w. I keep getting throttle cut due to overboosting. I've been reading as much as I can about the PID system, but I really don't know how to read the logged PID data. Also, I've been doing 2nd gear logs because there are a lot of police around my area, and I would like to continue having a license. I'm sure I'll get some 3rd gear logs soon but this is what I have to work with right now.

ldtv doesn't follows ldtvr_w even in this pre-control setting IMO.
I think you should shift desired upwards in LDRXN or WGDC downwards.

Running logs in 2nd gear is relatively short for the turbo to spool, and for comparing isn't really great either.

I am going to test this pre-control setting, not oncoming but next weekend and see what the results are.

Horrible approach and even worse advice.

KFLDIMX is supposed to be linear and you don't tune control by altering request ffs.

As I read it back now, I really have to totally agree with you on the approach that it doesnt make any sense at all what I said there. :-X

Ofc shifting up desired is defently NOT the option to tune control but he has room to have more desired unless he wants to drive around with 8-10 psi of boost, but that's not the point of this thread.

This is by far the lowest LDRXN request I've tried while tuning for this setup. Boost has been overshooting so much I wanted to turn everything down as much as possible and then start making adjustments in order to see what affects what and how/why. I have now 0'd LDDIMXN and raised LDRXN so it'll request about 12 psi.

I'm assuming my turbo can't go much over 30 psi, so I have my KFLDIMX mbar axis maxed at 2200 mbar as of now. This to me seems like it should make actual be less than request rather than overshoot. Am I correct by thinking that turning up the KFLDIMX mbar axis should give undershoot? or have I completely missed something?

New tune and some logs should be up tomorrow.

As already stated, something is wrong with your file.

ldtvm does not makes sense based on ldtvr_w and what you've shown in KFLDRL.

Also, there is no need to modify the KFLDRL DC axis.

You shouldn't even be thinking about LDRXN at this point.  LDDIMXN modification isn't really needed either.  You're just muddying the waters.   My advice is to limit your work to KFLDIMX and KFLDRL only until you get something that is close.

Thank you for the response.


Could you be a little more specific. Do you mean something is wrong with the way my bin is tuned, or do you think there is something else at play here? I have tried to follow as close as possible with the tuning I've read on this thread, and change only the needed maps.

I agree that KFLDRL dc axis needs to stay 0-95%, and only modify KFLDIMX mbar axis until I get a "close" calibration. I've tried messing around with the KFLDRL table a little and it hasn't seemed to affect much at this point. I've had KFLDIMX mbar axis up to 3000 and I was still getting overboost, so I'm kinda stumped at this point.

I did flash my ecu with the 518AK file from the "stage 1 tuning" thread and have been modifying this file. So far everything has seemed to be working fine. It is a different file than my original, but it was said to be interchangeable with my ecu. I can't think of the original bin file off the top of my head. I'll have to get it off my other computer and possibly try to define some more definitions for it so I can use the original bin.

More logs coming later today.

ldtvr_w is WGDC before linearization - this is the input into KFLDRL

ldtvm is WGDC (ldtv is the output of KFLDRL and in most cases == ldtvm)

in your logs, you have very low ldtvr_w, sometimes zero or less than zero, but ldtvm is something like 50-60.   Based on your screen shot of KFLDRL, ldtvm should also be close to zero, not 50-60%.  That is why I am saying something isn't right in your file.  ldtvm doesn't make sense based on what you are showing us in KFLDRL.

Perhaps you have a bad definition file aren't changing what you think you're changing.

Any chance you have CWMDAPP = 8 and it's following KFLDRAPP?

I actually change the axes in KFLDRL due to the way I calculate stuff. I guess not that important when you have a tool doing it for you.
But I just find DC for certain boost with an excel spreadsheet, use KFLDIMX as a conversion map, then change the axes.

Makes absolutely no difference in the end tho i guess.

I think I found the problem. When comparing KFLDRL with an unmodified version of KFLDRL I get this. This would explain the dips that wgdc was following. Wow. I have no idea how I got this improper definition, but finding this makes me very happy.

So I have redefined KFLDRL. This is what it was following... notice that the map isn't on the correct axis.

Not perfect by any means, but wgdc is now making sense.   ;D Finally I can get to dialing it in.

Thank you guys for all the help, and for an excellent tuning method!

This is where I will just modify the KFLDIMX axis by a fixed percent, and it's usually perfect after that. KFLDRL is set how you want it, now you just have to line KFLDIMX up with it.  Since you are underboosting, subtract 10-15 percent across the whole pressure axis.  Try it!

Subtracted 5% from KFLDIMX mbar axis, raised LDRXN slightly, and completely linearized KFLDRL as an experiment. I need to get some higher +60% wgdc logs so I can repopulate KFLDRL the proper way with the tool. Also, other than a custom downpipe my exhaust is basically stock, so that'll be addressed very soon. Would you think the dips in boost pressure could be symptoms of a restrictive exhaust/wastegate?

Next I will be raising KFLDIMX mbar axis by 5-10% and see what happens.

I've had some time this weekend to try this method.

Altough something isnt right, I think my def is not on spot because ldtvr is not likely to follow ldtvm in any way.

It shows that ldtv is at 95% when it comes from KFLDRL then after TVLDMN and TVLDMX it goes out as ldtvmd (as I can assume it from the FR) then into LDR_APP which comes out as ldtvm. But ldtvm is not even near where I've hoped to get it.

I haven't defined KFLDRAPP in my file (yet). I see that in my H-box its not used because all the values are 0. I am not sure but I am guessing they dint used it also either in a 6K0906032AA Seat file.
From my understanding from the FR is that KFLDRAPP is used when B_ldsapp = 1, so I am not sure if this would be the issue why my DC (ldtvm) is not in range with my KFLDRL (ldtv).

I have CWMDAPP 8 and because of the low actual boost it threw an DTC negative deviation which I think it caused the ldtvr_w and ldtv drop to zero in the log.

Anyway I don't understand why my WGDC is acting this way.

Also I am not yet confidend using the LDRPIDTool, but I am still going to work that out.

I think I found the issue regarding to FR cuz CWMDAPP = 8 (Feinabstimmung LDRXN, sowie Applikation aller Korrektureingriffe für rlmax (%LDRLMX)), which activates KFLDRAPP (which I haven't defined yet in my file).
So I am supposed to understand where the difference of ldtv and ldtvm is coming from.

Now I am going to find KFLDRAPP and see if the log is compared with the map.

Seems you might have put the cart before the horse.  You need to set KFLDRAPP to have a fixed WGDC in order to log fixed WGDC runs.

I have to change the ambient and all of the axis in your tool, right?

Or is the ambient just a filter for lets say: please use only the parts of the log with this exact ambient?

Can i add additional logs to the folder for more details with 65, 75, 85% duty or will it just use the ones matching the axis of KFLDRL in the tool?

I think I found KFLDRAPP (see picture).
I am going to alter it and test it later today in the car and see what the results are.

About the duty cycle in my last log,could it be that ldtvm was coming from vsldtv?
Because the KFLDRAPP was all 0'ed and FR shows it adds vsldtv before it goes out as ldtvm.

The fixed DC log's WGDC does not have to match the axis.  Ambient is just an override in the case that it's not included in your log.

Question regarding the design points of KFLDIMX desired pressure (pssol) axis, specifically setting the low axis point.  I've completed all the necessary runs at fixed DC -- just need some education to make sure I implement this correctly.  My boost control is seems acceptable now, but I want to try this approach if it offers any improvement...  Why not, right?

Here's what I think I've gleaned so far from this thread -- Please feel free to correct me:
1) KFLDIMX pssol axis should be distributed evenly, making linearization of the table values as easy as possible
2) KFLDIMX pssol high axis point should be above maximum achievable boost (not max desired boost).  This is done to ensure full range is covered (last row of KFLDRL table values is all 95).  LDRXN/KFLDHBN may limit boost below this level, but can be ignored here.
3) KFLDIMX pssol low axis point should be below "base boost"...

This may be a really dumb question...  What is the definition of "base boost"?  Intuitively, I think it is the curve representing maximum achievable boost at WGDC = 0 as a function of engine speed.  The value is lower at low rpm and peaks at a higher rpm, but before redline (for most turbos).  Is this correct? 

If so, what value of "base boost" do you use as the pssol low axis point since it varies?  My OEM file uses 1150, which is close to the maximum WGDC=0 boost achievable with the OEM 6 psi wastegate at any engine speed.  My wastegate pressure has been increased from about 6 psi OEM to 12 psi and my car will achieve about 1.6 bar (1600) at higher engine speeds at WOT and WGDC=0.

Everything you said here is accurate.   Don't overthink the low axis point.   Just pick a value that is below the amount of boost the turbo can produce at 0% WGDC where it's no longer ramping up.

Thanks for the quick confirmation.  I'll give it a go tomorrow.

*** Update:  Sharing my experience, for whatever it is worth... This method produced boost control at least as good as my best prior attempts, probably better.  No overshoot issues.  Didn't require any changes to boost PID. I'm sticking with it because it removes one variable (KFLDIMX) and makes fine tuning boost control in KFLDRL more straightforward.  Thanks to PRJ and SB_GLI for this thread.***

I've been trying to smooth the oscillations out of my boost profile, but I think I'm dealing with something I haven't seen in any other posts here or on other sites. I believe a "normal" linear wgdc pull should make a boost profile without a boost spike like I am getting from my turbo. Has anyone seen this type of spike from a linear wgdc pull? I can only assume it has to do with the wastegate itself, which might be too small or just not opening correctly initially. I am using a cheap t3/t4 .63 / .50 trim turbo with internal wastegate. The wastegate has been bench tested and seems to function properly and the turbo runs nicely except for this spike. Maybe my wastegate preload is set too high? Any ideas?

Push it WOT 1000 rpm later and overlay the two graphs that you get.
If they are identical, then nothing to worry about, that's what linearization is for.

If they are not identical, and you have the same "mountain" in a different place, then your wastegate preload is so high that you've limited the available wastegate travel and the wastegate is unable to open fully.

great explanation, thank you prj

can fueling have such a great influence on the boost? I mean extremely lean/rich which influences spool?

Not really.

Thanks for the help, prj. I have a few graphs I overlaid at 30% wgdc, two in 2nd gear and one in 3rd. If I tried to tune KFLDRL it would be unstable depending on what gear im in, because there is at least a 250 rpm difference in when boost comes on. I'm going to assume it is my wg preload being too high, because I did tighten it a few months ago.

Looks normal enough to me and easily linearizeable with KFLDRL.
Of course it would be easier if the response was more linear.

Hello all together,

I had some issues with some copy paste errors and was sometimes confused and changed the wrong areas when fine tuning the PID. So I made a simple excel sheet.

Here you can:

1. Insert your pressure axis and I values like in the LDRPIDTool
2. Insert your generated KFLDRL (or out of your tune/bin file)
3. Put a desired pressure and engine speed and see which WG DC comes out of the maps

At least for me it's useful to check very fast if all the values are giving me the DC I want at the end. Maybe some of you could use it too. I don't give you my word that it's 100% bug free  ;D
attached the file and screenshot.

Can anyone tell me what profit i has when edited IMX and DRL on stok k04-23 turbo? If I understand good it's for beter working of PID controller? So i can ignore original maps and make IMX linear and then altered DRL for new IMX map?

I edited KFLDIMX map to linear and I get somethink like this

I read but i think better to ask because english is not my National language so better to ask not only do everything wrong. So I must linearize imx then set CWMDAPP to 8 and set in KFLDRAPP to my fixed dc for log yes?

This isn't really a direct answer to your questions, but hopefully it helps fill in gaps that maybe can help you answer your own questions. Or maybe you already know this. Anyway:

In general the theory here (with pre-control, aka feedforward) is that if you know how your system responds, you can be more aggressive with your control inputs "ahead of time" rather than the reactionary nature of feedback (PID in this case) control, which relies on reading measurements of the system state and using those to determine what control input to use. In this case, you know approximately what boost control solenoid inputs cause what boost pressures at various operating states.

Ok. I understand what is for but I'm still thinking how to log I mean i must set KFLDRAPP to DC which I want to log? I'm understand this correct?

No, you should start by learning how PIDs work. Do not touch any map until then.

I understand Your answer and what doing this maps. When we set in IMX map 70 % on all rpms is 800 mbar boost then axis in DRL maps is represent that boost and then we set on each rpms DC when that boost is reached for example on 2500 rpms is 95 DC but on 4500 is 70 DC so PID only compensate deviation from that pressure for reach desired pressure as we want to make. But I want to know how to log properly for LDRPIDtool tool. Do I need to set stable DC or I can just log with linearized IMX map and CWMDAPP to 8 or I need then set in KFLDRAPP map each axis DC in DRL map and repeat loging for each value and then I received properly DRL map.
I don't care about connecting rods because I has forged connecting rods.
And if I irritated you I'm sorry.

What will happen if I log fixed 90 or 95% duty only until lets say 3500rpm. Will the tool use this logfile because there is WOT from start to 3500?
Or in general: should i log this 90% with a K03/K04 because it will overspool and get damaged maybe.

In PRJs first post there is 90% in the last column of KFLDIMX and 95% in the last column of KFLDRL.
I understand that you will have to set 95% in KFLDRL because of spoolup and for the absolut maximum duty.

Why is there 90% duty in the last column of DIMX? Is it because of the logic: the last column (pressure value) is higher than what you are planning to run so it doesnt matter if its 90 or 95?

Using this method, DIMX is merely a conversion of the DC axis in KFLDRL to pressure.  For example, if you have a 80% column in DIMX, and the value is 1,700, that means that the 80% column KFLDRL can be translated 1,700.  If you are requesting 1,700 mbar, the values in the 80 column will be used as the final DC.

not sure if i understand you with my limited english
lets say i would like to see 1600@3500 tapering to 1100@7000

i will have to set last column of dimx to 1800 with 95% because you have to cover the whole boost range in the dimx according to this some posts before

so why is prj only using 90@1000 in the first post of this thread?

You need to make sure that your highest DIMX column has values > 1600.  If you use 1,800 in a 90 column, for instance, that means that the values somewhere in between the 80 and 95 column of DRL will be used to specify the final duty cycle when requested pressure is 1,800.


Because it was not real data, only an example?

What is the range filter for? I dont understand it with just the words given.

I did logs with 5120hack but forgot to change some pvd* values in the ecu (multiply by two) so i renamed the columns to force the tool to use pvdkds_w.
My pu_w and pvdkds_w are multiplied by two during logging.

But I wonder why the tool does read these numbers. I mean if I compare the last row from tool (90) with the logged pvdkds minus pu. Isn't this the cell value in the tool 1:1?

If you have a look into the log you will find 2095-995=1100mbar boost @ 3000 but in the tool its red (interpolated and 600mbar higher)

I changed the min filter to 1900 and the red values in the export is a bit smaller.

Does throttle cut affect the log? I got this in the 90% log :(
Think i will have to log the 90% again with higher ldrxn wo have actual boost near reqboost, correct?

I finally got it

what do you think?

last question: what is the range filter for?

hmm not sure if i understand this.
why do i have 7 interpolated values in my 2000rpm row?

My only suggestion is to generate KFLDRL that has all 95's in the last column.   Max WGDC will otherwise be limited and you'll spool slower.

I dont do it that way. I set the last column in DIMX to max target boost and the lower pressure columns to the range in between. That way the last column in DRL won't allow any overboost and the part throttle load control has a higher resolution. Works perfectly.

Are you saying spool rate is impaired using this method?

Yup.

Because it is not neccessary to use more.

I assure you, it's as real as it gets, in fact it's so real it's straight out of a stock file.

Anyway KFLDIMX should have enough to convert pressure to dc. And preferrably it should be as close as possible to the actual DC on the top end, so you don't get big jumps in KFLDRL after.
As for why it doesn't go all the way - well it's steady state. It's not like KFLDRL, when you have spool, I is not doing much, it's all about P/D control.
So no, absolutely KFLDIMX does not need to go 95% or 100% or any other value. Don't forget stuff like lddimxn as well.

I have "okay" logs in 3rd gear wot.
Boost is following requested and everything looks fine. I already lowered the overshoot at 3k and lowered ldrxn a little bit from 5k to taper down

But in 5th gear it is overshooting. Is this just physics or is there a way to tune around?

Another thing i am noticing is load is maxed. I will log rl_w in the next log.

irl/iop is stock
ldrxn is attached
dimx/lrdl is attached
3rd gear pull attached

Lower your boost request or do the 5120 hack. You are asking for trouble that close to the ps limit

First, a big thank you to those who made this a reality.

I've written (a very simple) ASM patch to write pu_w into plgrus_w in order for this to work, fine. I have some overshoot but it's below MAP limit so I'm not too worried about that. But WGDC drops unexpectedly during underboost which I find a bit strange.. what have I missed?

Cool stuff, thanks for sharing! Came myself to this solution about 5 years ago when started tuning ME7.5 on my Skoda Octavia.
Hesitated to share this solution because I thought everyone would think this is crazy :) This is the way it PID was intended to work - everything should be flat except KFLDRL. Then you just say I want 80% which should produce me let's say 1.5 Bar of boost and PID stays around this value all the rev range so boost doesn't float and doesn't overshoot. And then you just play with KFLDRL to achieve proportional delivery of boost corresponding to % to duty applied to Wastegate.

HI! Im use this tool first time. Can you check my logs? Now i have underboost around 2000mbar. Target is 2400

I only see fixed DC logs... confirm that plgrus_w == pu_w

Regarding overall LDRPID me7 control...

Someone say before that You shouldn't ride I-max... but if You leave some room beetwen I and Imax it causing some unnecessary boost spikes after switching from dynamic to static mode because I-parameter after switch always start from Imax which is in big simplification KFLDIMX+LDDIMXN+LDIATA ... so then it takes time for I to drop from Imax to wanted level...

For me the stupid thing is that I start from I-max after switch... or maybe it can be regulated in some way ? LDDIMXN should be only for positive adaptation it shouldn't start from it...

I don't see anything wrong with using i-max to hard limit spikes. YMMV

This is an example...
If I leave some room to positive I-adaptation (distance beetwien I-result and I-max) it will amplify boost spike beacuse I-Result always start from Imax (altered by LDDIMXN)
If I will control spike with Imax it will ride Imax ...  so what is the point of LDDIMXN then (if there will be no room for positive adaptation ) it will be easier to zero it out ...

Please post original logs and or ecuxplot graphs.

Short answer is that using imax to limit spikes is not riding it. Post spike you can start bringing i-max up to give headroom.

Yeah but for example limiting Imax for max boost at 4000rpm after gear change for prevent spike will limit Imax also when I will go on full boost from low rpm (3000) to max rpm (6000) ... and passing 4000rpm region it will in some way disable I positive adaptation in this range because of lower Imax...

I agree with using I for limiting boost spike but for me its stupid design that I always start from Imax not from I directly from KFLDIMX>KFLDRL giving a LDDIMXN to work only if its needed...

Yep. You'll have to choose a happy medium. Some overshoot is always needed to bring I back down if it isn't capped. Its the nature of PIDs.

1. You should not use positive adaptation.
2. During spool IMAX is irrelevant because all the DC comes from P/D, IMAX is irrelevant until you go into steady state.
3. If you do the linearization runs correctly and tune correctly you will not have any boost spikes.

But as soon as it approaches target, p and d approach zero, and i is already maxed due to windup, so by definition it has to bounce off the imx.

I know.

Question is for what is the LDDIMXN for... it add a constant number to imax, why ?
Its a I positive regulation limit? I belive no

I does not always have to be maxed due to windup.
But regardless, if you use the approach outlined in the OP, and you actually have the correct DC through LDRL, and have D set correctly, then just before reaching peak it will do a spike down in DC to stabilize and then it will just track the target.



It simply is there to add a constant number instead of having to modify the whole table.
You can set it to zero.

I read all 18 pages in this topic, and still not sure how to take logs. What logs i need to use in the GUI tool ? From what i understand i need to change WGDC map(KFLDRL). First when i use 10% everywhere. After that 20% everywhere, than 30,40,50,60,70,80%. Also i need to make LDDIMXN map to 0 everywhere. Am i right or no ?

Hi,

This is very useful tool. My question is regarding the logs. I understand that make logs with different duty cycles. The question is that can I use my current tuned software or I should use an original one? Or what will happen with 95% DC? Currently I need 75% dc to be under 1,35 bar at 4000rpm.

Other question for log. I've check FR and I found and easier way to set DC. When we set 16 to CWMDAPP B_ldsafw also be active and it's activate LDRAPP. Is it also good? Or I need KFLDRAPP?

Thanks

16 is ok. Or 8 and then set the high throttle position to same value.

At my xdf I have only the LDRAPP map, hopefully at the right place :) Can I use the attached log's software for the calibration?

Hi,

I've made the logs. Can somebody help me to find good kflidmx axis values?
Other question. What do you think about my WG spring strength? Or this characteristic is normal for a k03s?

Thanks

I've change KFLDIMX axis. Is this good?

Ok.I help you.For log leave KFLDRL and KFLDIMX map oryginal values only change KFLDRAPP map. It is 8x8 map so change only 4 last row. Ex 70%, 80%, 90% and 100% PED values and set there in map percent of DC which you want (Ad you now 10% , 20%, 30% ....etc. ) and save all files as new ( dont overwrite).For LDRPID tool you need 9 files ( log 0% of DC too) and after that set KFLDIMX map as linear ( in 3D view straight line) and then put this one row (all are the same ) to LDRPID tool where is KFLDIMX map (and set axis as you has in your file) and set KFLDRL DC axis as you has in your file and then set RPM scale of main map (you can have other values ) and then load folder with your 9 files (logs) and click GENERATE. Then copy generated map to your tune (KFLDRL map) and flash tune to your car and make logs (don't forget about checksum before you flash your tune.

Hi,

I've made the changes and run test. Currently I'm facing with overshoot issues. With the D parameter change can I avoid these high overshoots?

Thanks

Your IMX is way too high again.

Sorry but I don't undestand why. I read all of the 18 pages from that topic and did everything based on that. What I didn't do is switch off LDDIMXN.
My KFLDIMX is linear, I've choosed the axis values from the logs what I did.

What I would like to try is change that KFLDIMX map values that at 1450 will be 80 and make the linearization. Change the D parameter too to prevent big overshoots.

Whatever you did, the result of IMX+DRL is too high. Keep IMX linear, but something is amiss with DRL in that region

What should I do? Yesterday I calculated with lower values in KFLDIMX and hopefully I will help to open wg before reach the limit.

try to ADD 10% to your KFLDIMX pressure axis and report back (with logs)

Zero out LDDIMXN?

I've just set the kfldimx output from 90% to 80% at 1450mbar. Is this also good?

I've modified the kfldimx regenerate the kfldrl add some to q2 and switch off LDDIMXN. The result is not much better.
What I'm thinking currently is modify kfldrl below 3000 rpm to open the WG a little. 2750 rpm with 70-80% lower the 95% requests.

No, increase your request so P provides enough wg during spool.

Which request? Sorry but I don't understand what should I increase.

Boost request.

What is the problem with my boost request now? It is flat and 1,35bar is enough for my config. I cannot set the pid to handle the current request?

request more during spool so the P part is large enough to generate 95 dc

?? Does it solve my overboost problem? I'm running 95dc before I reach the target. Can you explain a little bit how does it solve the overboost?

Thanks for the help and sorry if I ask stupid questions.

What can I do with overboost? I tried to change kfldrl below 3000rpm to open the wg an avoid oberboost but does not help. Now I measuring again with duty 70 80 and 95 because the air is colder and the turbo is faster a little.

Ldiata

This is my last log with modified KFLDRL.
I've attached also what the tool generated before.

I've just put together my previous log when I used my own KFLDIMX and KFLDRL values. What I can see is to prevent overboost around 3000 I need 71% dc before reach the target 1,35 bar. From the latest log my lower dc before reaching the target is 79.6875 and the input for kfldrl is 65.155. The PID output should be under 60 to get around 71% dc from the current KFLDRL table. What I can do is lower kfldimx table values around 2750 and 3000 or give more D.

After hacked the KFLDRL table I could reach a little overboost. Maybe I can lower a little bit more the kfldrl table before 3000rpm

How does it work for others? What is the problem with my tables if I need to modify the drl table to prevent overboost? I don't want to add more Q2. I raised it with 25 percent between 2750 and 4000 with 100 and 200 lde values.

Nobody?   :'(
I analyzed with VisualLogger(very good tool) and what I can see is when the set point is reached the system goes to steady state so it will run from imax because P and D is zero. The LDRPID tool generates the steady state values for KFLDRL. But the problem comes with WOT that the turbo won't be in steady state when reach the set point because it spools and will have overshoot. I thought about to put lower values in KFLDIMX but at this case I'm afraid to have undershoots because IMAX values will generate lower DC values so the turbo cannot reach the required set point in steady state and will have undershoots.

Yes, you've hit on the fundamental limitation of PIDs. You cannot avoid a small amount of overshoot.

I know that overshoot is a "need" of PID. The problem is that I can feel the leak(after the overshoot)(100mbar) during WOT. Does it make sense to add more D?

I had discussions about the Pid. And the suggestion was to lower IMAX values. My problem is with that currently KFLDIMX table has values for different pressure values(for 1,32 bar it will be 73) and KFLDRL table gets this value when the system reached the required pressure(P and D will be 0). The KFLDRL output will be DC value for 1,32 bar in different rpm values. So if I change KFLDIMX to lower values for example 1,32 bar will be 68, KFLDRL table output will be lower to se thre will be undershoot and I cannot raise because Imax limits it.

Maybe I found the problem. I left the spool filter on default value(75mbar/0,1s) but my system can make only ~40mbar/0,1s. I regenerate the DRL table with that and I got lower values below 3000rpm. I will test it tomorrow.

And the results. The problem was the spool config. Now it is work perfectly. Maybe a little bit undershoot. Should I raise DC values a little?

Hi,

Today I was on dyno. The result is not so bad but the PID again was not so good.
What can I do with this overshoot? This feed forward is not working properly with my config.

I've been working with the tool provided and am partly through loading all my logs.

I am at the 60% DC table and am curious if I need to run these up to redline? Seems like anything over this at high RPM (5000+) will be way over spinning the turbos.

Can I do 4th gear logs and just go up to 5000rpm or so and achieve the same data collection?

Also when you load the logs into the tool the RPM columns data show up red from 1000-2750 what does this mean?

Also there is some conflicting information in this thread about which axis to modify.

On DiMX you want the deviation axis to go from 0 - just above request. Do you modify the RPM axis in DRL to get better resolution?

Thanks and bumping an old thread!

This is only my understanding. Dont take it as 100% accurate.  In IMX map you set pressure you want to run. For me it is 0 - 1500mbar. From 0- 1500mbar make it linear. As for dc % my only successful attemp was that i set  it from 0 - 95 % also linear( first attempts i tried to take dc % from logs ). Then add your logs to LDRPIDTOOL and everything should be good, if your req boost makes sense.

when you wont do full logs from around 1500 rpm to redline, you will not have all needed values ---> in the LDRPID tool this is visualised as a red area then (which you asked)

Can someone help me to understand KFLDIMX axis?
It should be requested pressure in mBar as I see. But why everybody has different numbers there?
Most of screenshot has 0 to 1000 mBar scale. And what a strange factor and conversion I have?

You might be best to check the funktionsrahmen for your ECU, there are various ways it can be calculated, and some ECUs have a config switch that changes the method.

Thanks.
I guess it is plsolr_w - (close to desired boost) and I see (in .ecu file) that all parameters in mbar has factor = 0.0390625 * x
So I got results that looks like truth:

delete

My new axis (now there is plsolr_w - close to desired boost) for KFLDIMX is in attached screenshot.

This mean:
1) we cannot control boost less then 150 mbar (although this does not matter, because the actuator spring holds 300 mbar).
2) any boost above 1 bar has the same WG DC. How to control boost over 1000 mbar? Should I change plsolr_w axis?

Please, confirm me that I am right.

show your whole kfldrl table

Fixed DC logs are in progress yet.
10% DC log is ready now only

Yes change your axis for the desired boost range. My requested maximum boost is ~1350 mbar, so I set the kfldimx range to 200-1450.

Good thread. I tried this approach yesterday. I works for me. Not perfectly yet but normal. I did some KFLDRL tuning. But I think that it happens because the software didn't process my logs with 60 and 70 ltvdm runs. Also I think that this process can be automatized. ME7 software has LDRAPP constant and vsldtv variable. At least Volvo software didn't set vsldtv variable. So this variable can be freely modified by CAN request. So setting CWMDAPP to 16 switch code to work with LDRAPP plus vsldtv. All other activity can be automatized. Like settings vsldtv value. Writing logs for fixed ltvdm value and so on.

so i want to try this but i'm noob and a little confused.
so basically you just have to set your imx values linear, and then leave that alone.
then you customize drl from then on to get your boost to folloow correctly?

I wont have to fiddle with axis changing or conversion factors or anything?

well I gave it a shot.
Seems to work fine. To be honest I don't notice much difference from the default method.
except that i'm ignoring the IMX map all the time, just leave it linear. 
I suppose that's the point though.

How can I download the tool please ?
I can only find ME7logger here : https://github.com/sbloom82/VisualME7Logger
I can download the LDRPIDTool folder but it is only uncompiled file ..

Thank you

Just echoing Jordy971,
Is this tool by SB_GLi no longer available? It's not on the releases section of github.

its attached here http://nefariousmotorsports.com/forum/index.php?topic=12352.msg111830#msg111830

or you can use this aswell https://github.com/KalebKE/ME7Tuner

Awesome! Thanks so much!

Hi,

I love this tool but I have two problems on my ECU. Can anybody help please?
##1) When I set CWMDAPP=8 and riding WGDC using KFLDRAPP it does not give me full WGDC before 3k RPM. So its not possible to get correct boost data for tool input. See attachements 1 and 2.
2) I have almost done with PID tuning on my software but sometimes there is slightly "Actual Presure" and "MAF" drop after ActualBoost gets to the DesiredBoost. Is this PID problem or not? See attachements 3 and 4

Thank you very much.

EDIT:
ad 1.) Nevermind :) problem was inversed axes in KFLDRAPP map. So I defined wrong parametrs.

did not fully understand
after 9 passes and creating a map in ldrpid
made KFLDIMX linear
what to do with KFLDRAPP and CWMDAPP
  Should they stay at stock values?

Yes

steps:
your are switching into the application mode / applikationsmodus to do the actual pre-control wot runs and logs
you create new kfldrl and switch the application mode back to off
you do the fine tuning

Thank you for your prompt response

Thank you for your prompt response

Hi guys. Decided to try the LDRPID tool. I am getting weird values ​​in KFLDRL map. Can anyone take a look?

Did someone try the pre-control-mod in a Euro 512k ecu before?
Does not work for me. The WGDC jumps from 0 to 95. Diagram attached.
Same mapping on 1M ecu works like a charm.

Greetings
René

is source code available for this?

https://github.com/sbloom82/VisualME7Logger