NefMoto

Technical => Tuning => Topic started by: prj on March 20, 2017, 07:49:04 AM



Title: Actual pre-control in LDRPID
Post by: prj on March 20, 2017, 07:49:04 AM
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.


Title: Re: Actual pre-control in LDRPID
Post by: KasperH on March 20, 2017, 08:25:25 AM
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 :)


Title: Re: Actual pre-control in LDRPID
Post by: NOTORIOUS VR on March 20, 2017, 09:08:54 AM
Well that's interesting... I"ll have to try that trick


Title: Re: Actual pre-control in LDRPID
Post by: nyet on March 20, 2017, 09:52:05 AM
Thanks for this, prj.


Title: Re: Actual pre-control in LDRPID
Post by: vwaudiguy on March 20, 2017, 10:47:43 AM
Bravo


Title: Re: Actual pre-control in LDRPID
Post by: TijnCU on March 20, 2017, 10:57:47 AM
Looks very logical, thanks for sharing! If your spreadsheet works well this will save a lot if calibration time!


Title: Re: Actual pre-control in LDRPID
Post by: aef on March 20, 2017, 01:58:53 PM
Something must be wrong here.
PRJ never started a thread before.  ;D

Thank you for this post!


Title: Re: Actual pre-control in LDRPID
Post by: prj on March 20, 2017, 02:30:55 PM
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.


Title: Re: Actual pre-control in LDRPID
Post by: SB_GLI on March 20, 2017, 04:15:30 PM
From a stock BEL allroad.  Same as you describe here?


Title: Re: Actual pre-control in LDRPID
Post by: prj on March 20, 2017, 04:16:31 PM
Yup, exactly.


Title: Re: Actual pre-control in LDRPID
Post by: contrast on March 21, 2017, 11:45:47 AM
Excuse my ignorance, but how are the values of KFLDRL populated? KFLDRAPP?


Title: Re: Actual pre-control in LDRPID
Post by: nyet on March 21, 2017, 12:01:42 PM
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?


Title: Re: Actual pre-control in LDRPID
Post by: prj on March 21, 2017, 03:54:21 PM
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.


Title: Re: Actual pre-control in LDRPID
Post by: Jason on March 21, 2017, 08:07:08 PM
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.


Title: Re: Actual pre-control in LDRPID
Post by: STEVEPHILP on April 15, 2017, 02:40:56 PM
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??



Title: Re: Actual pre-control in LDRPID
Post by: jibberjive on May 23, 2017, 12:24:35 AM
Interesting!

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.

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


Title: Re: Actual pre-control in LDRPID
Post by: vwaudiguy on June 14, 2017, 10:22:52 PM
Interesting!

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

Second this.


Title: Re: Actual pre-control in LDRPID
Post by: prj on June 16, 2017, 05:38:44 PM
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 :)


Title: Re: Actual pre-control in LDRPID
Post by: A4Rich on June 17, 2017, 07:20:01 AM
I Would love to contribute, and have Excel skills! ;D. Let me know.


Title: Re: Actual pre-control in LDRPID
Post by: TijnCU on June 17, 2017, 01:45:42 PM
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


Title: Re: Actual pre-control in LDRPID
Post by: STEVEPHILP on June 19, 2017, 05:27:45 AM
This would be superb if it becomes reality


Title: Re: Actual pre-control in LDRPID
Post by: SB_GLI on July 16, 2017, 08:32:46 AM
I was considering writing something for this in a .NET app and open source it.  Would anyone actually help code it though?


Title: Re: Actual pre-control in LDRPID
Post by: TijnCU on July 16, 2017, 11:28:11 AM
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


Title: Re: Actual pre-control in LDRPID
Post by: STEVEPHILP on July 17, 2017, 04:35:18 AM
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.


Title: Re: Actual pre-control in LDRPID
Post by: KasperH on July 17, 2017, 05:30:39 AM
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 :)


Title: Re: Actual pre-control in LDRPID
Post by: SB_GLI on July 17, 2017, 06:43:43 AM
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.


Title: Re: Actual pre-control in LDRPID
Post by: rnagy86 on July 17, 2017, 07:12:41 AM
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?


Title: Re: Actual pre-control in LDRPID
Post by: SB_GLI on July 17, 2017, 08:28:28 AM
haha, already!   I just started on this last night!

I will try to get something out there tonight.


Title: Re: Actual pre-control in LDRPID
Post by: STEVEPHILP on July 17, 2017, 09:29:51 AM
^^ Hero Member for a reason.

Nice work.


Title: Re: Actual pre-control in LDRPID
Post by: KasperH on July 17, 2017, 02:59:53 PM
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.

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


Title: Re: Actual pre-control in LDRPID
Post by: SB_GLI on July 17, 2017, 08:39:08 PM
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.


Title: Re: Actual pre-control in LDRPID
Post by: SB_GLI on July 19, 2017, 07:46:35 AM
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.


Title: Re: Actual pre-control in LDRPID
Post by: TijnCU on July 19, 2017, 08:23:56 AM
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.


Title: Re: Actual pre-control in LDRPID
Post by: SB_GLI on July 23, 2017, 08:29:36 PM
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.


Title: Re: Actual pre-control in LDRPID
Post by: SB_GLI on July 23, 2017, 08:36:01 PM
After a tiny bit of massaging, this is what KFLDRL looks like for me.


Title: Re: Actual pre-control in LDRPID
Post by: contrast on July 24, 2017, 02:47:27 AM
Did you set KFLDIMX perfectly linear too?


Title: Re: Actual pre-control in LDRPID
Post by: TijnCU on July 24, 2017, 04:27:25 AM
Here's a first version of the tool.  
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!


Title: Re: Actual pre-control in LDRPID
Post by: SB_GLI on July 24, 2017, 08:05:01 PM
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.


Title: Re: Actual pre-control in LDRPID
Post by: userpike on July 24, 2017, 10:50:05 PM
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?


Title: Re: Actual pre-control in LDRPID
Post by: STEVEPHILP on July 25, 2017, 01:08:22 AM
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



Title: Re: Actual pre-control in LDRPID
Post by: STEVEPHILP on July 25, 2017, 01:59:54 AM
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...


Title: Re: Actual pre-control in LDRPID
Post by: SB_GLI on July 25, 2017, 04:59:44 AM
Why don't you take some wgdc out where it's 95%?

Or take that hump out of wgdc @ 3900ish?

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.


Title: Re: Actual pre-control in LDRPID
Post by: SB_GLI on July 25, 2017, 05:01:47 AM
All values in DIMX under 1800mbar are 81%? in the tool?

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.


Title: Re: Actual pre-control in LDRPID
Post by: SB_GLI on July 25, 2017, 05:21:20 AM
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...

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.  ;)


Title: Re: Actual pre-control in LDRPID
Post by: STEVEPHILP on July 26, 2017, 12:45:01 AM
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


Title: Re: Actual pre-control in LDRPID
Post by: SB_GLI on July 26, 2017, 06:23:50 AM
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.


Title: Re: Actual pre-control in LDRPID
Post by: SB_GLI on July 27, 2017, 11:15:21 AM
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.


Title: Re: Actual pre-control in LDRPID
Post by: nyet on July 27, 2017, 11:37:54 AM
Once I get my motor together I will try to do the same and let you know.


Title: Re: Actual pre-control in LDRPID
Post by: vwaudiguy on July 27, 2017, 12:06:43 PM
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.

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.


Title: Re: Actual pre-control in LDRPID
Post by: nyet on July 27, 2017, 12:17:19 PM
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.


Title: Re: Actual pre-control in LDRPID
Post by: vwaudiguy on July 27, 2017, 12:18:33 PM
Also overshoot is in the nature of almost all PIDs, whether or not they have feed forward components or not.

Agreed.  :)


Title: Re: Actual pre-control in LDRPID
Post by: SB_GLI on July 27, 2017, 03:00:38 PM
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.


Title: Re: Actual pre-control in LDRPID
Post by: vwaudiguy on July 27, 2017, 04:22:47 PM
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!


Title: Re: Actual pre-control in LDRPID
Post by: nyet on July 27, 2017, 04:51:26 PM
26psi request and 32psi overshoot is a little too much...

Agreed there, 100%


Title: Re: Actual pre-control in LDRPID
Post by: STEVEPHILP on July 29, 2017, 01:56:12 AM
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.



Title: Re: Actual pre-control in LDRPID
Post by: SB_GLI on July 29, 2017, 07:08:00 AM
You're correct the log files are based on the Hilton/Dream3r format.

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


Title: Re: Actual pre-control in LDRPID
Post by: nyet on July 29, 2017, 09:34:23 AM

I never realised excel screwed the csv so badly.


Never use excel. Ever. It is a cancer.


Title: Re: Actual pre-control in LDRPID
Post by: KasperH on July 30, 2017, 12:06:47 PM
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?


Title: Re: Actual pre-control in LDRPID
Post by: STEVEPHILP on July 30, 2017, 12:35:07 PM
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.



Title: Re: Actual pre-control in LDRPID
Post by: SB_GLI on July 31, 2017, 06:59:21 AM
The logs should contain;

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


Title: Re: Actual pre-control in LDRPID
Post by: KasperH on July 31, 2017, 09:43:05 AM
Can I do several pulls in one log and it would still register correctly in the program?


Title: Re: Actual pre-control in LDRPID
Post by: SB_GLI on July 31, 2017, 11:10:47 AM
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.


Title: Re: Actual pre-control in LDRPID
Post by: KasperH on July 31, 2017, 12:19:26 PM
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


Title: Re: Actual pre-control in LDRPID
Post by: contrast on July 31, 2017, 12:28:22 PM
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!


Title: Re: Actual pre-control in LDRPID
Post by: STEVEPHILP on August 01, 2017, 01:37:28 AM
Indeed ^

Massive massive kudos SB-GLI.

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



Title: Re: Actual pre-control in LDRPID
Post by: armageddon on August 01, 2017, 11:50:09 AM
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


Title: Re: Actual pre-control in LDRPID
Post by: SB_GLI on August 01, 2017, 12:13:54 PM
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"


Title: Re: Actual pre-control in LDRPID
Post by: armageddon on August 01, 2017, 12:44:01 PM
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?


Title: Re: Actual pre-control in LDRPID
Post by: SB_GLI on August 01, 2017, 01:17:49 PM
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.


Title: Re: Actual pre-control in LDRPID
Post by: armageddon on August 01, 2017, 01:27:16 PM
I understand it, that´s how I have been doing it...

just didn´t know how you have designed this tool

thanks


Title: Re: Actual pre-control in LDRPID
Post by: prj on August 01, 2017, 02:10:35 PM
Good job :)


Title: Re: Actual pre-control in LDRPID
Post by: prj on August 01, 2017, 02:20:30 PM
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.


Title: Re: Actual pre-control in LDRPID
Post by: SB_GLI on August 01, 2017, 04:00:15 PM
Anyone who has a set of logs can feel free to share them.


Title: Re: Actual pre-control in LDRPID
Post by: armageddon on August 02, 2017, 12:54:58 AM
if you referring to linearization runs, here you go


Title: Re: Actual pre-control in LDRPID
Post by: SB_GLI on August 02, 2017, 04:35:57 AM
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.


Title: Re: Actual pre-control in LDRPID
Post by: armageddon on August 02, 2017, 06:03:11 AM
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



Title: Re: Actual pre-control in LDRPID
Post by: prj on August 02, 2017, 11:57:32 AM
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.

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


Title: Re: Actual pre-control in LDRPID
Post by: SB_GLI on August 02, 2017, 01:09:30 PM
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.


Title: Re: Actual pre-control in LDRPID
Post by: SB_GLI on August 02, 2017, 09:13:23 PM
- 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)


Title: Re: Actual pre-control in LDRPID
Post by: aef on August 02, 2017, 10:48:44 PM
hats off

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


Title: Re: Actual pre-control in LDRPID
Post by: armageddon on August 03, 2017, 01:33:43 AM
Can not get new version to work with my logs, error message pops up

whith your logs works fine..


Title: Re: Actual pre-control in LDRPID
Post by: SB_GLI on August 03, 2017, 04:44:59 AM
Can not get new version to work with my logs, error message pops up

whith your logs works fine..

Sorry bout that.  Fixed


Title: Re: Actual pre-control in LDRPID
Post by: contrast on August 03, 2017, 07:41:10 AM
Latest version crashes with Volvo log files.


Title: Re: Actual pre-control in LDRPID
Post by: SB_GLI on August 03, 2017, 08:50:04 AM
Latest version crashes with Volvo log files.

lolz, please upload your logs here.


Title: Re: Actual pre-control in LDRPID
Post by: contrast on August 03, 2017, 09:02:21 AM
lolz, please upload your logs here.

sorry...

attached.


Title: Re: Actual pre-control in LDRPID
Post by: SB_GLI on August 03, 2017, 09:31:03 AM
sorry...

attached.

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


Title: Re: Actual pre-control in LDRPID
Post by: contrast on August 03, 2017, 10:37:09 AM
Dl winrar


Title: Re: Actual pre-control in LDRPID
Post by: SB_GLI on August 03, 2017, 01:19:23 PM
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.


Title: Re: Actual pre-control in LDRPID
Post by: contrast on August 03, 2017, 01:38:49 PM
Yes, I downloaded the zip. I will try again.
Maybe its because I edited the axes?


Title: Re: Actual pre-control in LDRPID
Post by: Lost on August 04, 2017, 01:37:10 AM
Thanx for great gui. 
Just to clarify.
This is used only with Visual logger or both VL and Me7 logger?


Title: Re: Actual pre-control in LDRPID
Post by: SB_GLI on August 06, 2017, 02:07:47 PM
Fixed a bug for contrast
Made grid control better for copy/paste and editing a selection.


Title: Re: Actual pre-control in LDRPID
Post by: SB_GLI on August 06, 2017, 04:11:55 PM
gah, and one more multi-threading bug, caused the grid to load up differently in some cases.


Title: Re: Actual pre-control in LDRPID
Post by: armageddon on August 07, 2017, 11:39:20 AM
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


Title: Re: Actual pre-control in LDRPID
Post by: SB_GLI on August 07, 2017, 12:01:41 PM
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.


Title: Re: Actual pre-control in LDRPID
Post by: armageddon on August 07, 2017, 12:40:35 PM
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


Title: Re: Actual pre-control in LDRPID
Post by: SB_GLI on August 07, 2017, 12:45:42 PM
right mouse clicks are for the weak     :P


Title: Re: Actual pre-control in LDRPID
Post by: SB_GLI on August 08, 2017, 05:41:21 AM
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.


Title: Re: Actual pre-control in LDRPID
Post by: rnagy86 on August 27, 2017, 02:38:02 AM
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)


Title: Re: Actual pre-control in LDRPID
Post by: KasperH on August 27, 2017, 05:58:01 AM
i think it might be the derivative term being to aggressive?


Title: Re: Actual pre-control in LDRPID
Post by: prj on August 27, 2017, 06:00:10 AM
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.


Title: Re: Actual pre-control in LDRPID
Post by: SB_GLI on August 27, 2017, 06:20:14 AM
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.


Title: Re: Actual pre-control in LDRPID
Post by: rnagy86 on August 27, 2017, 08:58:09 AM
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?



Title: Re: Actual pre-control in LDRPID
Post by: SB_GLI on August 27, 2017, 06:11:51 PM
You want to increase the values of the DIMX pressure axis.

Please post your logs.


Title: Re: Actual pre-control in LDRPID
Post by: rnagy86 on August 28, 2017, 06:45:25 AM
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


Title: Re: Actual pre-control in LDRPID
Post by: SB_GLI on August 28, 2017, 07:24:55 AM
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.


Title: Re: Actual pre-control in LDRPID
Post by: rnagy86 on August 28, 2017, 07:27:42 AM
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.

Yes, it is 5120.


Title: Re: Actual pre-control in LDRPID
Post by: rnagy86 on August 28, 2017, 08:20:30 AM
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.

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.


Title: Re: Actual pre-control in LDRPID
Post by: armageddon on August 28, 2017, 09:12:17 AM
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


Title: Re: Actual pre-control in LDRPID
Post by: rnagy86 on August 28, 2017, 09:16:23 AM
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...


Title: Re: Actual pre-control in LDRPID
Post by: SB_GLI on August 28, 2017, 12:47:06 PM
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.

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.


Title: Re: Actual pre-control in LDRPID
Post by: SB_GLI on August 28, 2017, 12:48:17 PM
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

See my last post.  The tool is not picky.


Title: Re: Actual pre-control in LDRPID
Post by: rnagy86 on August 29, 2017, 12:49:19 AM
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.


Title: Re: Actual pre-control in LDRPID
Post by: Lost on August 29, 2017, 04:13:21 AM
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.


Title: Re: Actual pre-control in LDRPID
Post by: SB_GLI on August 29, 2017, 05:37:33 AM
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.


Title: Re: Actual pre-control in LDRPID
Post by: Lost on August 29, 2017, 05:50:54 AM
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.


Title: Re: Actual pre-control in LDRPID
Post by: SB_GLI on August 29, 2017, 05:57:59 AM

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

look again?


Title: Re: Actual pre-control in LDRPID
Post by: rnagy86 on August 29, 2017, 06:01:20 AM
I think I did not upload a graph of the latest run, just the log and the tables.



Title: Re: Actual pre-control in LDRPID
Post by: SB_GLI on August 29, 2017, 06:09:02 AM
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?


Title: Re: Actual pre-control in LDRPID
Post by: rnagy86 on August 29, 2017, 10:27:18 AM
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!


Title: Re: Actual pre-control in LDRPID
Post by: SB_GLI on August 29, 2017, 10:39:05 AM
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.


Title: Re: Actual pre-control in LDRPID
Post by: armageddon on August 29, 2017, 11:26:14 AM
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  ???




Title: Re: Actual pre-control in LDRPID
Post by: SB_GLI on August 29, 2017, 11:48:39 AM
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.


Title: Re: Actual pre-control in LDRPID
Post by: rnagy86 on August 30, 2017, 12:10:08 AM
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.




Title: Re: Actual pre-control in LDRPID
Post by: SB_GLI on August 30, 2017, 06:40:22 AM
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.


Title: Re: Actual pre-control in LDRPID
Post by: SB_GLI on August 30, 2017, 06:47:45 AM
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.


Title: Re: Actual pre-control in LDRPID
Post by: dragon187 on August 30, 2017, 06:56:37 AM
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)


Title: Re: Actual pre-control in LDRPID
Post by: rnagy86 on August 30, 2017, 07:03:35 AM
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.

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  ;)


Title: Re: Actual pre-control in LDRPID
Post by: SB_GLI on August 30, 2017, 07:22:53 AM
Can you please add some kind of info button where it display what variables should be in the logfile?

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


Title: Re: Actual pre-control in LDRPID
Post by: prj on August 31, 2017, 02:51:27 AM
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.

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.


Title: Re: Actual pre-control in LDRPID
Post by: nyet on August 31, 2017, 11:35:37 AM
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)?


Title: Re: Actual pre-control in LDRPID
Post by: armageddon on September 01, 2017, 11:36:02 AM
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.

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/)


Title: Re: Actual pre-control in LDRPID
Post by: SB_GLI on September 01, 2017, 01:05:21 PM
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



Title: Re: Actual pre-control in LDRPID
Post by: dragon187 on September 01, 2017, 01:10:29 PM
Thanks man
Like that work


Title: Re: Actual pre-control in LDRPID
Post by: SB_GLI on September 05, 2017, 07:40:23 AM
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.


Title: Re: Actual pre-control in LDRPID
Post by: armageddon on September 05, 2017, 10:53:56 AM
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.


Title: Re: Actual pre-control in LDRPID
Post by: SB_GLI on September 05, 2017, 03:22:58 PM
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.


Title: Re: Actual pre-control in LDRPID
Post by: SB_GLI on September 09, 2017, 03:26:30 PM
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.


Title: Re: Actual pre-control in LDRPID
Post by: SB_GLI on September 09, 2017, 04:48:33 PM
Confirmed!  Zeroing LDDIMXN gave near perfect results with the data generated from the tool.


Title: Re: Actual pre-control in LDRPID
Post by: SB_GLI on September 10, 2017, 01:17:23 PM
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.


Title: Re: Actual pre-control in LDRPID
Post by: STEVEPHILP on December 09, 2017, 02:07:22 AM
Can anyone explain how the spool filter works please?

I.e. how do you set it?


Title: Re: Actual pre-control in LDRPID
Post by: KasperH on December 15, 2017, 01:20:22 AM
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.


Title: Re: Actual pre-control in LDRPID
Post by: Lost on December 15, 2017, 03:46:34 AM
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.


Title: Re: Actual pre-control in LDRPID
Post by: KasperH on December 15, 2017, 04:03:45 AM
Yeah, but the actual was 20% lower than requested, so nowhere near the 1.5%(in my case)


Title: Re: Actual pre-control in LDRPID
Post by: SB_GLI on December 18, 2017, 07:31:01 PM
explain  how to configure a filter in the program?

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.


Title: Re: Actual pre-control in LDRPID
Post by: vwaudiguy on January 21, 2018, 06:46:00 PM
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. :)


Title: Re: Actual pre-control in LDRPID
Post by: SB_GLI on January 21, 2018, 09:18:54 PM
Also looking forward to the update(s) you mentioned.

Version 1.7


Title: Re: Actual pre-control in LDRPID
Post by: cgramme on January 28, 2018, 07:11:03 PM
Would flattening KFLDRL give me a fixed duty cycle similar to using KFLDRAPP. I'm having trouble finding KFLDRAPP. Noob problems.............


Title: Re: Actual pre-control in LDRPID
Post by: HelperD on January 28, 2018, 07:22:37 PM
Replied in your other post.


Title: Re: Actual pre-control in LDRPID
Post by: 6L20vt on February 22, 2018, 12:20:24 AM
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


Title: Re: Actual pre-control in LDRPID
Post by: SB_GLI on February 22, 2018, 12:21:21 PM
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.


Title: Re: Actual pre-control in LDRPID
Post by: 6L20vt on February 22, 2018, 02:33:55 PM
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


Title: Re: Actual pre-control in LDRPID
Post by: SB_GLI on February 22, 2018, 06:04:23 PM
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.



Title: Re: Actual pre-control in LDRPID
Post by: 6L20vt on February 23, 2018, 12:43:55 AM
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


Title: Re: Actual pre-control in LDRPID
Post by: SB_GLI on February 23, 2018, 10:05:26 AM
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.



Title: Re: Actual pre-control in LDRPID
Post by: 6L20vt on February 23, 2018, 01:17:47 PM
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


Title: Re: Actual pre-control in LDRPID
Post by: SB_GLI on February 23, 2018, 06:35:20 PM
that should work fine.  I like to keep KFLDIMX linear though.


Title: Re: Actual pre-control in LDRPID
Post by: 6L20vt on February 23, 2018, 09:28:13 PM
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


Title: Re: Actual pre-control in LDRPID
Post by: 6L20vt on February 23, 2018, 11:28:24 PM
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


Title: Re: Actual pre-control in LDRPID
Post by: SB_GLI on February 24, 2018, 06:32:57 AM
yes, imx is linear according to the data that I entered in the tool

It's not


Title: Re: Actual pre-control in LDRPID
Post by: SB_GLI on February 24, 2018, 06:35:36 AM
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

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.


Title: Re: Actual pre-control in LDRPID
Post by: 6L20vt on February 24, 2018, 06:40:10 AM
It's not

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


Title: Re: Actual pre-control in LDRPID
Post by: 6L20vt on February 24, 2018, 01:09:09 PM
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


Title: Re: Actual pre-control in LDRPID
Post by: SB_GLI on February 24, 2018, 05:35:38 PM
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.


Title: Re: Actual pre-control in LDRPID
Post by: SB_GLI on February 24, 2018, 05:42:03 PM
You just need a little more q2 and it will be perfect.


Title: Re: Actual pre-control in LDRPID
Post by: 6L20vt on February 24, 2018, 09:45:11 PM
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


Title: Re: Actual pre-control in LDRPID
Post by: vwaudiguy on February 24, 2018, 11:34:17 PM
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.


Title: Re: Actual pre-control in LDRPID
Post by: 6L20vt on February 25, 2018, 12:32:09 AM
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


Title: Re: Actual pre-control in LDRPID
Post by: 6L20vt on February 25, 2018, 05:08:44 AM
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


Title: Re: Actual pre-control in LDRPID
Post by: 6L20vt on February 25, 2018, 08:20:43 AM
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


Title: Re: Actual pre-control in LDRPID
Post by: SB_GLI on February 25, 2018, 03:09:45 PM
logs would be helpful


Title: Re: Actual pre-control in LDRPID
Post by: 6L20vt on February 25, 2018, 03:22:36 PM
logs would be helpful

here is it. thanks


Title: Re: Actual pre-control in LDRPID
Post by: SB_GLI on February 25, 2018, 03:44:41 PM
logs need ldtvr_w.

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


Title: Re: Actual pre-control in LDRPID
Post by: 6L20vt on February 25, 2018, 03:55:41 PM
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?


Title: Re: Actual pre-control in LDRPID
Post by: nyet on February 25, 2018, 09:58:53 PM
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


Title: Re: Actual pre-control in LDRPID
Post by: 6L20vt on February 25, 2018, 11:18:33 PM
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?


Title: Re: Actual pre-control in LDRPID
Post by: SB_GLI on February 26, 2018, 07:04:49 AM
i actually agree, less q2 will help remove oscillation, and it will expose where you need to fix up IMX

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.


Title: Re: Actual pre-control in LDRPID
Post by: 6L20vt on February 26, 2018, 08:19:31 AM
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.


Title: Re: Actual pre-control in LDRPID
Post by: SB_GLI on February 26, 2018, 09:43:33 AM
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.


Title: Re: Actual pre-control in LDRPID
Post by: 6L20vt on February 26, 2018, 10:29:39 AM
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


Title: Re: Actual pre-control in LDRPID
Post by: nyet on February 26, 2018, 12:20:35 PM
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.


Title: Re: Actual pre-control in LDRPID
Post by: 6L20vt on February 26, 2018, 12:33:34 PM
Do you think that would be correct?


Title: Re: Actual pre-control in LDRPID
Post by: 6L20vt on February 26, 2018, 12:45:06 PM
sorry this is the image


Title: Re: Actual pre-control in LDRPID
Post by: SB_GLI on February 26, 2018, 04:46:26 PM
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.  :)


Title: Re: Actual pre-control in LDRPID
Post by: contrast on February 27, 2018, 11:36:15 PM
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.


Title: Re: Actual pre-control in LDRPID
Post by: 6L20vt on February 27, 2018, 11:44:15 PM
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.


Title: Re: Actual pre-control in LDRPID
Post by: 6L20vt on March 01, 2018, 02:41:54 PM
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.


Title: Re: Actual pre-control in LDRPID
Post by: SB_GLI on March 17, 2018, 12:36:46 PM
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.


Title: Re: Actual pre-control in LDRPID
Post by: SB_GLI on March 21, 2018, 08:15:12 AM
Should I use the KFLDIMX axis values your tool suggests me (and log again of course... :-\)?
0 - 400 - 800 - 1200 - 1400 - 1600 - 1800 - 2000

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.


Title: Re: Actual pre-control in LDRPID
Post by: SB_GLI on March 21, 2018, 04:03:27 PM
Thanks, did it, logged again, applied calculated kfldrl and boost runs pretty good, I can definately feel a difference.

SB_GLI, I love you <3  ;D ;D #nohomo

Attaboy


Title: Re: Actual pre-control in LDRPID
Post by: sonflasch on April 27, 2018, 02:09:50 AM
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



Title: Re: Actual pre-control in LDRPID
Post by: sonflasch on April 27, 2018, 05:51:54 AM
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


Title: Re: Actual pre-control in LDRPID
Post by: sonflasch on May 09, 2018, 09:25:02 AM
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




Title: Re: Actual pre-control in LDRPID
Post by: prj on May 11, 2018, 02:31:10 AM
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.


Title: Re: Actual pre-control in LDRPID
Post by: sonflasch on June 01, 2018, 10:45:12 PM
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


Title: Re: Actual pre-control in LDRPID
Post by: prj on June 02, 2018, 05:02:01 AM
Not the correct way to do it.


Title: Re: Re: Actual pre-control in LDRPID
Post by: sonflasch on June 02, 2018, 05:08:40 AM
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


Title: Re: Actual pre-control in LDRPID
Post by: prj on June 02, 2018, 05:21:55 AM
Correct is to make plgrus_w = pu_w like ECU's that have CWPLGU when it is set to 1.
This is a hack.


Title: Re: Re: Actual pre-control in LDRPID
Post by: sonflasch on June 02, 2018, 05:28:34 AM
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



Title: Re: Actual pre-control in LDRPID
Post by: cgramme on July 09, 2018, 12:21:29 AM
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.



Title: Re: Actual pre-control in LDRPID
Post by: dream on July 11, 2018, 03:55:34 AM
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.


Title: Re: Actual pre-control in LDRPID
Post by: prj on July 11, 2018, 04:41:11 AM
Horrible approach and even worse advice.

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


Title: Re: Actual pre-control in LDRPID
Post by: dream on July 11, 2018, 11:01:49 AM
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.


Title: Re: Actual pre-control in LDRPID
Post by: cgramme on July 11, 2018, 08:40:30 PM
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.


Title: Re: Actual pre-control in LDRPID
Post by: SB_GLI on July 12, 2018, 07:18:29 AM
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.


Title: Re: Actual pre-control in LDRPID
Post by: cgramme on July 12, 2018, 12:11:59 PM
Thank you for the response.

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.

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.



Title: Re: Actual pre-control in LDRPID
Post by: SB_GLI on July 12, 2018, 01:20:31 PM
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?


Title: Re: Actual pre-control in LDRPID
Post by: prj on July 12, 2018, 01:36:45 PM
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.


Title: Re: Actual pre-control in LDRPID
Post by: cgramme on July 12, 2018, 01:43:52 PM
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.



Title: Re: Actual pre-control in LDRPID
Post by: cgramme on July 12, 2018, 02:40:17 PM
So I have redefined KFLDRL. This is what it was following... notice that the map isn't on the correct axis.



Title: Re: Actual pre-control in LDRPID
Post by: cgramme on July 12, 2018, 04:07:36 PM
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!



Title: Re: Actual pre-control in LDRPID
Post by: SB_GLI on July 12, 2018, 06:40:33 PM
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!


Title: Re: Actual pre-control in LDRPID
Post by: cgramme on July 13, 2018, 05:48:46 PM
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.



Title: Re: Actual pre-control in LDRPID
Post by: dream on July 16, 2018, 12:20:10 AM
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.


Title: Re: Actual pre-control in LDRPID
Post by: dream on July 16, 2018, 04:04:29 AM
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.


Title: Re: Actual pre-control in LDRPID
Post by: SB_GLI on July 18, 2018, 01:12:58 PM
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.


Title: Re: Actual pre-control in LDRPID
Post by: aef on July 18, 2018, 04:18:27 PM
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?


Title: Re: Actual pre-control in LDRPID
Post by: dream on July 20, 2018, 12:21:48 AM
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 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.


Title: Re: Actual pre-control in LDRPID
Post by: SB_GLI on July 20, 2018, 06:24:31 AM
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?

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.


Title: Re: Actual pre-control in LDRPID
Post by: jpurban on July 20, 2018, 09:57:34 AM
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.



Title: Re: Actual pre-control in LDRPID
Post by: SB_GLI on July 20, 2018, 11:18:45 AM
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.


Title: Re: Actual pre-control in LDRPID
Post by: jpurban on July 20, 2018, 09:07:46 PM
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.***


Title: Re: Actual pre-control in LDRPID
Post by: cgramme on July 30, 2018, 06:01:58 PM
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?





Title: Re: Actual pre-control in LDRPID
Post by: prj on July 31, 2018, 12:50:22 AM
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.


Title: Re: Actual pre-control in LDRPID
Post by: aef on July 31, 2018, 01:35:10 AM
great explanation, thank you prj

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


Title: Re: Actual pre-control in LDRPID
Post by: prj on July 31, 2018, 03:31:04 AM
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.


Title: Re: Actual pre-control in LDRPID
Post by: cgramme on July 31, 2018, 10:44:09 AM
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.

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.


Title: Re: Actual pre-control in LDRPID
Post by: prj on July 31, 2018, 01:19:02 PM
Looks normal enough to me and easily linearizeable with KFLDRL.
Of course it would be easier if the response was more linear.


Title: Re: Actual pre-control in LDRPID
Post by: !nfern0 on August 12, 2018, 09:31:19 AM
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.


Title: Re: Actual pre-control in LDRPID
Post by: Dejw0089 on January 20, 2019, 06:16:12 AM
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


Title: Re: Actual pre-control in LDRPID
Post by: Dejw0089 on January 21, 2019, 11:04:38 AM
Read the thread and you will find out...
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?


Title: Re: Actual pre-control in LDRPID
Post by: stein on January 21, 2019, 08:48:41 PM
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.


Title: Re: Actual pre-control in LDRPID
Post by: Dejw0089 on January 22, 2019, 03:08:17 AM
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?


Title: Re: Actual pre-control in LDRPID
Post by: nyet on January 22, 2019, 10:34:55 AM
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.


Title: Re: Actual pre-control in LDRPID
Post by: Dejw0089 on January 22, 2019, 12:27:57 PM
Please sit back and learn more before you try, you could easily kill your piston rods with too much duty cycle at once...
Sorry, normally I'm very helpful. But I won't explain it to you, if everything is explained above. And if you don't understand this then you won't understand my answer anyway.  ;)
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.


Title: Re: Actual pre-control in LDRPID
Post by: aef on February 12, 2019, 06:29:18 AM
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?



Title: Re: Actual pre-control in LDRPID
Post by: SB_GLI on February 12, 2019, 07:35:22 AM
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.


Title: Re: Actual pre-control in LDRPID
Post by: aef on February 12, 2019, 07:51:12 AM
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
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.

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



Title: Re: Actual pre-control in LDRPID
Post by: SB_GLI on February 12, 2019, 11:27:13 AM
Quote from: aef
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

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.

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

Because it was not real data, only an example?




Title: Re: Actual pre-control in LDRPID
Post by: aef on February 12, 2019, 04:12:25 PM
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?



Title: Re: Actual pre-control in LDRPID
Post by: aef on February 13, 2019, 04:23:13 PM
I finally got it

what do you think?

last question: what is the range filter for?


Title: Re: Actual pre-control in LDRPID
Post by: aef on February 14, 2019, 12:49:55 AM
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.

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


Title: Re: Actual pre-control in LDRPID
Post by: SB_GLI on February 14, 2019, 11:50:58 AM
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.


Title: Re: Actual pre-control in LDRPID
Post by: STEVEPHILP on March 02, 2019, 09:27:16 AM
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?





Title: Re: Actual pre-control in LDRPID
Post by: SB_GLI on March 02, 2019, 06:30:00 PM
Are you saying spool rate is impaired using this method?

Yup.


Title: Re: Actual pre-control in LDRPID
Post by: prj on March 15, 2019, 08:24:53 AM
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?
Because it is not neccessary to use more.

Because it was not real data, only an example?
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.


Title: Re: Actual pre-control in LDRPID
Post by: aef on March 28, 2019, 11:34:46 AM
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



Title: Re: Actual pre-control in LDRPID
Post by: nyet on March 28, 2019, 02:38:24 PM
Lower your boost request or do the 5120 hack. You are asking for trouble that close to the ps limit


Title: Re: Actual pre-control in LDRPID
Post by: Aardschok on April 11, 2019, 11:09:28 AM
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?


Title: Re: Actual pre-control in LDRPID
Post by: automan001 on May 16, 2019, 05:46:26 AM
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.


Title: Re: Actual pre-control in LDRPID
Post by: D1CE on June 26, 2019, 02:53:02 PM
HI! Im use this tool first time. Can you check my logs? Now i have underboost around 2000mbar. Target is 2400


Title: Re: Actual pre-control in LDRPID
Post by: Aardschok on June 26, 2019, 02:59:38 PM
Can you check my logs?

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


Title: Re: Actual pre-control in LDRPID
Post by: soul87 on July 31, 2019, 12:20:03 AM
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...


Title: Re: Actual pre-control in LDRPID
Post by: nyet on July 31, 2019, 12:31:33 AM
I don't see anything wrong with using i-max to hard limit spikes. YMMV


Title: Re: Actual pre-control in LDRPID
Post by: soul87 on July 31, 2019, 12:51:10 AM
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 ...


Title: Re: Actual pre-control in LDRPID
Post by: nyet on July 31, 2019, 12:53:13 AM
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.


Title: Re: Actual pre-control in LDRPID
Post by: soul87 on July 31, 2019, 01:08:18 AM
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...


Title: Re: Actual pre-control in LDRPID
Post by: nyet on July 31, 2019, 02:04:01 AM
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.


Title: Re: Actual pre-control in LDRPID
Post by: prj on July 31, 2019, 01:02:29 PM
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.


Title: Re: Actual pre-control in LDRPID
Post by: nyet on July 31, 2019, 03:45:20 PM

2. During spool IMAX is irrelevant because all the DC comes from P/D, IMAX is irrelevant until you go into steady state.


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.


Title: Re: Actual pre-control in LDRPID
Post by: soul87 on July 31, 2019, 11:29:02 PM
1. You should not use positive adaptation.

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


Title: Re: Actual pre-control in LDRPID
Post by: prj on August 01, 2019, 12:39:58 AM
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 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.


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

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