NefMoto > Technical > Tuning > PID contoller calibration from square one
Pages: 1 ... 6 7 [8] 9 10
« previous next »
Author Topic: PID contoller calibration from square one  (Read 153806 times)
prj
Hero Member
*****

Karma: +1072/-480
Offline Offline

Posts: 6035
« Reply #105 on: November 25, 2015, 03:54:26 PM »
Quote from: elRey on November 25, 2015, 07:35:26 AM
If your new KFLDIMX will have this OFFSET applied when in use, how is it irrelevant?

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

The rest of the PID should be controlled using P/D in dynamic state and P/I in steady state.
Your I should not follow the max value from IMX+safety offset in normal conditions.
Logged
PM's will not be answered, so don't even try.
Log your car properly - WinOLS database - Tools/patches
elRey
Hero Member
*****

Karma: +32/-1
Offline Offline

Posts: 565
« Reply #106 on: November 25, 2015, 05:57:19 PM »
OFFSET I'm taking about is made up of

LDDIMXN
KFLDIOPU
LDIATA
KFLDIWL
KFRBGOF
and LDIMXAK

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

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

I believe if you exercise my addition tip of projecting the first part of the max % boost profile onto the other profiles, that will address your overshoot concern.
« Last Edit: November 25, 2015, 06:17:37 PM by elRey » Logged
Nottingham
Full Member
***

Karma: +13/-1
Offline Offline

Posts: 204
« Reply #107 on: November 25, 2015, 11:48:49 PM »
Did the linearization as prj suggested and... ...the difference is pretty big.
While overshoot at spool still remains and the boost tapers at higher revs, the overall behavior is significantly better.
The overshoot duration has decreased and the mid range (where most of the linearization was required) is significantly smoother.
ECU clearly knows how to control the boost now Grin

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

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

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

Karma: +1072/-480
Offline Offline

Posts: 6035
« Reply #108 on: November 25, 2015, 11:49:06 PM »
Quote from: elRey on November 25, 2015, 05:57:19 PM
OFFSET I'm taking about is made up of

LDDIMXN
KFLDIOPU
LDIATA
KFLDIWL
KFRBGOF
and LDIMXAK

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

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

I believe if you exercise my addition tip of projecting the first part of the max % boost profile onto the other profiles, that will address your overshoot concern.
ME7 does not have a pilot map. KFLDIMX is an I limiter. A pilot would drive the PID up and down, IMX does not do this. Overshoot is handled by D.
The whole ME7 boost pid is a hack. A poorly understood one at that.
Logged
PM's will not be answered, so don't even try.
Log your car properly - WinOLS database - Tools/patches
prj
Hero Member
*****

Karma: +1072/-480
Offline Offline

Posts: 6035
« Reply #109 on: November 25, 2015, 11:50:40 PM »
Quote from: Nottingham on November 25, 2015, 11:48:49 PM
Also for the first time, PID is reactivating at the higher revs when lde raises again above UMDYLDR threshold.
Never seen that happening in the past even the boost tapers just as much as before.
a) Make sure your I maximum is high enough at that RPM and that it is not riding the IMX.
b) Increase stationary I at higher revs.
c) If increasing it causes oscillation, increase stationary P somewhat and decrease stationary I a little.

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

However, if you increase it too much, on spoolup boost will stop before hitting target, and then I will kick in and it will still overshoot.
You can see it as a zigzag in the N75 DC just before boost hits target.
« Last Edit: November 25, 2015, 11:52:26 PM by prj » Logged
PM's will not be answered, so don't even try.
Log your car properly - WinOLS database - Tools/patches
Nottingham
Full Member
***

Karma: +13/-1
Offline Offline

Posts: 204
« Reply #110 on: November 26, 2015, 12:23:56 AM »
Ok in that case I probably already have too much D.
That´s exactly what happens, I think.

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

Karma: +1072/-480
Offline Offline

Posts: 6035
« Reply #111 on: November 26, 2015, 03:34:18 AM »
I would say D is too low at higher delta boost.

Graph is useless without plsol.
Logged
PM's will not be answered, so don't even try.
Log your car properly - WinOLS database - Tools/patches
Nottingham
Full Member
***

Karma: +13/-1
Offline Offline

Posts: 204
« Reply #112 on: November 26, 2015, 03:50:46 AM »
Thats easily fixed Smiley
Logged
Basano
Full Member
***

Karma: +90/-3
Offline Offline

Posts: 192
« Reply #113 on: November 26, 2015, 04:49:00 AM »
Nice topic. I'm learning as well.

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

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

Karma: +1072/-480
Offline Offline

Posts: 6035
« Reply #114 on: November 26, 2015, 07:55:42 AM »
Dynamic mode in spool area you probably want more P and less D.
Your I limit is too high.
Logged
PM's will not be answered, so don't even try.
Log your car properly - WinOLS database - Tools/patches
Nottingham
Full Member
***

Karma: +13/-1
Offline Offline

Posts: 204
« Reply #115 on: November 26, 2015, 08:07:57 AM »
Quote from: prj on November 26, 2015, 07:55:42 AM
Dynamic mode in spool area you probably want more P and less D.
Your I limit is too high.

Lower KFLDIMX?
Logged
Nottingham
Full Member
***

Karma: +13/-1
Offline Offline

Posts: 204
« Reply #116 on: November 26, 2015, 11:58:51 PM »
Did several changes over the last version.

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

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

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

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

Karma: +13/-1
Offline Offline

Posts: 204
« Reply #117 on: November 26, 2015, 11:59:57 PM »
Forgot the attachments  Roll Eyes
Logged
elRey
Hero Member
*****

Karma: +32/-1
Offline Offline

Posts: 565
« Reply #118 on: November 27, 2015, 12:01:36 AM »
Or you could try my way.
Logged
Nottingham
Full Member
***

Karma: +13/-1
Offline Offline

Posts: 204
« Reply #119 on: November 27, 2015, 12:46:23 AM »
Meaning substracting the "offset" from DIMX?
Sure, but it won´t solve the issues with PID which is causing the spikes in duty.

Also I´m not sure if substracting a constant offset is wise, even if it provides the correct I-limit.
There are environment variables which can change the offset too, such as tans (in LDIATA).
Also I haven´t logged ldimxak_w so I don´t know if it´s contents are fixed or not. Looking at the inputs of BBLDRPID they are not.
Logged
Pages: 1 ... 6 7 [8] 9 10
  Print  
« previous next »
 
Jump to:  

Navigation
Personal Tools
  • November 25, 2024, 12:04:24 AM
  • Welcome, Guest. Please login or register.
    Did you miss your activation email?

    Login with username, password and session length
Search
 
Advanced Search
About Disclaimer
All Rights Reserved 2010 Nefarious Motosports
Powered by SMF 1.1.21 | SMF © 2015, Simple Machines Page created in 0.042 seconds with 17 queries. (Pretty URLs adds 0.005s, 0q)