NefMoto

I've been running with KFMIRL altered to increase loads at all RPMs and % Torque Requested but with KFMIOP stock and the car ran like crap.  Torque monitoring was constantly intervening resulting in crappy part throttle response.  So I adjusted RLVMXN, RLVSMXN and KFMIZUFIL which reduced the part throttle lumpiness but I then began experiencing throttle-cut with Torque Monitor Code (Control Limit Exceeded) during part throttle acceleration from low RPMs and Torque monitoring was still intervening at cruise resulting in crazy Fuel Trims, misfires, rough running and just a generally poor part throttle experience.

So - I switch KFMIRL to stock except the last 3 columns which are smoothed to 240.  Result? Car runs great.  Smooth as can be albeit with a slightly dulled throttle response (Torque monitoring smoothing things out).

I'm trying to understand the ME7 Torque Model and have come to the conclusion that one cannot increase KFMIRL without sufficiently altering KFMIOP UNLESS one decided to 'disable' Torque Monitoring via KFMIZUOF.

Here is what I think I understand - If a KFMIRL load value deviates from the corresponding %Torque value in KFMIOP (which should be the inverse of KFMIRL) more than the allowed deviation from KFMIZUOF (which is zero for much of the table) then ME7 intervenes.  If this assumption is correct then increasing load values in KFMIRL and leaving KFMIOP stock will result in deviations much greater than what is defined in KFMIZUOF and the car will run like crap as ME7 tries to get things in line.

So - our options are -
1. Leave all but the last 2 or 3 columns of KFMIRL stock and KFMIOP and KFMIZUOF stock. Enjoy the silken rocket driving experience.
2. Raise Load values in KFMIRL across the board and properly tune KFMIOP to match and leave KFMIZUOF stock.  In this scenario greater loads are produced earlier but the Torque Model is still perfectly functional and able to give stock-like refinement.
3. Raise KFMIRL load values and leave KFMIOP stock but FF KFMIZUOF across the entire table effectively disabling Torque Monitoring (also I believe there are 2 scalar values related to temp thresholds which need to be altered).  I have not tried this so I don't know how wild the throttle is in this scenario.

Am I on the right track?  Am I completely wrong?

**addition**
Here are the values required to deactivate Torque Monitoring (per the FR).  I have not tried these:

Table KFMIZUOF = 99.6% for all base points
Z - 11619 * 0.390625
X - 1008E * 40
Y - 1166D * 0.390625

Scalar TMNSMN  = -48 C
11676 * 0.75 - 48

Scalar TANSMN  = -48 C
11675 * 0.75 - 48

Hi.

I've just been working through the FUEDK and MDFAW modules to try to understand the torque oriented structure better. There is a note in MDFUE 8.50 which states that KFMIRL and KFMIOP are the inverse of each other (as you have recognised).

I haven't fully digested the implications of this yet, but that statement would indicate to me that the entries in both maps must complement each other so that if you adjust one, you must ensure that the changes are suitably reflected in the other, or else the ECU will see something is amiss.

Therefore option 2 is preferred. You seem to have a good handle on this issue already.

TTQS

Thanks for the reply, Doug.  I also believe option 2 is preferred.  That said, let's reflect on how this is to be accomplished. For this example I am using a modified KFMIRL (load values increased by 25% across the table) and a stock KFMIOP both from an S4 Mbox -

KFMIRL -
x axis = % Torque requested
y axis = RPM
Output = Target Filling (Load)

KFMIOP -
x axis = Cylinder Filling (I believe this is actual Load as calculated by ME7)
y axis = RPM
Output = % Torque

If I request 80% of available Torque at 4000 RPM this resuts in a Load Value of 205.83 according to this altered KFMIRL
(https://lh5.googleusercontent.com/-nquYT-aKNvo/TmUQZn5VtlI/AAAAAAAADFM/sEOqgcmQ0uU/s800/kfmirl.GIF)

This will hopefully produce actual Load close to the requested value, however I believe that there are many occassions where actual Load will exceed requested for brief periods.  Let's suppose that the actual calculated value is 205.83, which if we look up in KFMIOP (stock) should correspond to 89.46 %Torque at 4000 RPM.  This is a +9.46% deviation in %Torque, assuming that actual Load is EXACTLY what was requested.  According to KFMIOP, this amount of Load should not be produced at 80% Requested Torque but rather at 89.46% Requested Torque.

(https://lh4.googleusercontent.com/-wRkVh7kYax4/TmUQZuskC3I/AAAAAAAADFQ/MORxmaU7tgI/s800/kfmiop.GIF)

 According to KFMIOP 80% Torque Request should result in a Load Value of between 144.75 and 168 (I assume that the 144.75 value is used until requested torque increases to 81.03%) and this results in Torque Monitoring intervening to reduce Actual Load.  The driver experiences jumpiness and stuttering at part throttle acceleration as ME7 tries to achieve requested Torque one moment and attempts to reduce Torque the next.

This scenario suggests that the appropriate strategy is to LOWER the output values in KFMIOP so that a given Load Value corresponds to a LOWER %Torque requested (effectively, for a given %Torque Requested a higher Load value is considered optimal). However, I have examined several professionally tuned files where the tuner has done the opposite (KFMIOP values are raised).  Either I am not understanding the model or the tuners are misinformed (GIAC comes to mind - and this does make some sense if we remember back to many of their early files having issues with Torque Monitoring throttle cut.)

Am I on the right track?

Hi BerTTos.

I'll need to consider the various modules in more detail because there are some issues which aren't clear, particularly why the maximum load on KFMIOP is 191 which is much less than the maximum requested load in KFMIRL (recognising that KFMIOP is the basic torque at basic lambda and basic ignition angle). I also note that the maps are the same in both TT 1.8T 225 and 240 PS stock files but LDRXN is modified. Perhaps the differences are not significant enough to warrant modifying these maps or perhaps there is no need to do so if the turbo is the same... I.e. the maximum load is set by what the turbo can achieve so no point in trying to increase it beyond that.

Nevertheless, the approach you suggest seems logical to me.

The map values are interpolation points so there should be a smooth transition between them.

I have been limited in my understanding from the get go because I have not been able or willing to examine known good professional tunes, especially my own. Hopefully I will rectify that situation this fall.

Thanks for a stimulating discussion and very timely since I was just looking into this on the day you posted.

TTQS

This is good discussion, thank you... I think i'm having issues with this is well.  It now has my full attention.   I'm going to give these modules a good read this week and see what i come up with. 

Great discussion guys!

I've only got one thing to say at this point since I don't know anything... but getting hung up on the one line in the FR saying it is the inverse might now be 100% right in the sense that it's supposed to be made smaller.

I have an supposed MTM (not sure if it really is or not) H-box file where KFMIRL is much larger then stock, and KFMIOP is also completely different and has larger numbers then stock.  That file is one of the smoothest driving files I've ever had.

I've been struggling with this as well, particularly the following:

1) As bertos pointed out, stock IOP map doesn't seem to be the proper inverse of IRL *everywhere*, just in most places.
2) Increasing IRL would seem to indicate the proper response is to LOWER IOP, not increase it.
3) Actually logging req torque vs actual torque during (what I think is) torque intervention in timing did NOT show that actual > req!

A few things I would like to add though

Never trust what "another tuner" has done. EVER.

IMO this is the #1 lesson that nobody seems to learn; NEVER copy somebody elses map unless you understand 100% why. Doing anything else leads to madness; you have a bunch of tuners just saying "trust me, this voodoo works, but I cant explain why" and later it becomes a "truth". I believe increasing IOP to reflect IRL is one of those things that tuners do that just makes no sense.

Also just because "my car runs great with map X", doesn't mean you did the right thing :)

There are a half a dozen things OTHER than IOP that can cause torque/timing intervention. I'm in the midst of trying to figure out what to log to find them all.

Here is my short list

etazwbm
miasrl_l
miasrs_w
miist_w
misol_w
zwbasar_0-3
zwist
zwopt
zwout

PLEASE if you see torque intervention, add these to your ME7L config and post em!

Finally, I am thinking of writing a program to take a IRL and convert it to an IOP.

Given #1, the irony would be that it would NOT produce a stock IOP given a stock IRL :)

Oh! One more thing.

Load != torque

Keep in mind the *torque* measurement is a % of optimal torque, regardless of current load (or size of turbos, boost pressure, etc, etc) and is (mostly) dependent on the difference between optimal timing, and actual timing.

IMHO, the best way to sort out some of remaining mysteries is by variable tracking with a datalogger. That being said, there are alot of variables that were not ouput by Setzi's ME7Info and would have to be added manually.

Again, I am not so sure it is supposed to be the true "inverse" I think the FR is a little misleading in that sense. It just doesn't make sense IMO.


Why do you believe this to be true?  


Absolutely...

Just for info... here is the maps in question for the H-box:

(http://i51.tinypic.com/1ik1ac.jpg)
(http://i55.tinypic.com/2e0iipf.jpg)

Not literal inverse. See Berttos's analysis.


Basically, if you increase IRL, it means that req load is higher for a given req torque, which means for the SAME load, act torque (IOP) needs to be lower to prevent req torque < actual torque.

Unless, like Bert, i am woefully misreading the FR

I've come to the same conclusion after reading a bit, the fr and this discussion.  so I did some testing.  Kfmirl goes up and kfmiop must go down.   I don't agree that it's the literal inverse function as the document says.   
I increased kfmirl about 25% but leaving the 4 lowest columns stock.... then i matched up the correlating columns on kfmiop and decreased them by 10%.   This took the car from "meh" part throttle to very smooth. (stage 3 b5 s4)

Actually, I want to amend my position :)

I believe the intent is for IOP to provide the *literal* inverse function that IRL provides (inverse meaning inverse FUNCTION, not arithmetic inverse).

i.e.

IRL provides load = f(rpm,tq)
OIP provices tq = g(rpm,load)

where g() = f^-1()

Like I said though, there are areas in the stock IOP that don't do this.

Oh, and one more thing: if you universally increase the output (load) of IRL by a fixed %, can you just increase the load axis of IOP across the board, rather than decreasing the output (tq)? Might be a bit easier (but you'd have to see what else shares that axis). Also, I'm still trying to figure out what affect MAF scaling has on this as well. It could be that if you underscale your MAF enough, the actual load is low enough that actual torque is never high enough to cause problems.

Oh, and one more thing: the output of IOP goes into the *actual* torque measurement (after lambda/timing adjustment)!

Great discussion gentlemen!

Nye - I have also considered simply shifting the x axis in KFMIOP.

Does anyone know the difference between KFMIOP and KFMI_UM or KFMIZUOF and KFMIZUOF_UM?  What does 'under monitoring' mean?

It is my understanding that "under monitoring" is for testing processor flow and should not be tampered with. I believe that none of it is actually used in engine control.

I need to make a correction.  To fully disable Torque Monitoring - KFMDZOF_UM is not used but rather these settings -

Table KFMIZUOF = 99.6% for all base points (I'm currently trying to id this in mbox)
Scalar TMNSMN  = -48 C (I haven't started looking for this one)
Scalar TANSMN  = -48 C (I haven't started looking for this one)

Try these out:

KFMIZUOF
Z - 11619 * 0.390625
X - 1008E * 40
Y - 1166D * 0.390625

TMNSMN
11676 * 0.75 - 48

TANSMN
11675 * 0.75 - 48

Thank you sir.  have you tried deactivating TM in this fashion?
If so what was your experience with it?

In examining the more complete Gbox here are the tables which share the x-axis with KFMIOP -

KFMDS (this table features RPM and Load. not sure what the output is. seems to have something to do with defining engine drag incl accessories for an engine. i assume this is factored into the torque calc)
KFZWOP
KFZWOP2

I also wondered about upscaling the load axis in KFMIOP, but we need to understand why the values are lower than in KFMIRL before tinkering further.

Is this to take account of the pressure drop across the throttle, intake manifold, etc.?

TTQS

iop values are lower cause they are % of output... after raising the requested in irl, the relative % output goes down under the same load columns... at least that is how I understand it.  If you changed the load axis in iop as some are saying, you could leave the table pretty much as is, but shift the loads in iop to their correct points? (said with high pitched voice at end.) ie, 190 becomes 210 so the % of output would remain relatively the same.

has anyone compared the tables in an RS4 file?

this is how i am currently understanding it.  changing the load axis seems to make more sense than to monkey with the output values in KFMIOP as it more closely resembles reality.  and it does also seem correct that it be shifted upwards in the other tables which share it.  note that this load axis for the RS4 is shifted upwards and peaks at 199.

Really great topic guys but why to mess with the torque model? Is there any reason to tune it in a stage 3 file?

Read the first post :P

I just read it again but i still can't understand the need to alter torque model at the first place. Sorry to mess your post i will read again the documents and try to understand. Thanks.

Summary: if you raise KFMIRL to get more boost, your actual tq may go over req, unless you make a corresponding change to IOP.

If you have an underscaled MAF, and you keep actual load low enough, you probably wont have a problem.

Ok now i got it. You tweek KFMIRL to get more boost. I compered a stock 1.8t 225ps file and a 1.8t 180 ps file and this map seems to be a little higher in the 225 in high load areas. I makes sense now. Thanks and sorry.

O.k. So I just compared the 265 bhp S4 maps with the 380 bhp RS4 stock maps and am seeing very little difference, certainly not enough to suggest that Audi are using KFMIRL and KFMIOP to increase output.

TTQS

Stock KFMIRL is more than enough for RS4 level boost req, which is relatively modest. Stock KFMIRL is NOT sufficient for just about any real stage 3 tune, unless you can suggest an alternate way to get req boost over 20psi.

i believe the goal in tuning the Torque Model is not to increase output but rather to alter the manner in which output is delivered and to keep Torque Monitoring from trying to shoehorn our 500 hp into a delivery scheme designed for a very refined 250 hp.  In this way we can program the personality of the vehicle as we like.  We all have seen, over the years, quite a few tunes that attempt to alter the personality of the vehicle by requesting incresed loads sooner in the rev band - with varying degrees of success.  This said - we definitely need to alter at least the last 2 columns of KFMIRL in order to achieve the power levels desired in a STG3 or greater tune.

Here are the stock tables for S4 and RS4 for us to examine.  Notice that the RS4 maps do request more load sooner and a greater peak load in KFMIRL and that the x-axis in the RS4 KFMIOP is shifted upwards to reflect this greater load for a given %Torque request.

RS4 KFMIRL
(https://lh4.googleusercontent.com/-aFk79habEa0/TmfaPt8W5vI/AAAAAAAADFY/gvca7i9MCjY/s800/RS4kfmirl.GIF)

S4 KFMIRL
(https://lh3.googleusercontent.com/-aT5pJTom3lU/TmfaQQ4OsPI/AAAAAAAADFc/pzWufd59IqA/s800/S4kfmirl.GIF)


RS4 KFMIOP
(https://lh6.googleusercontent.com/-rbX_v_2_OYE/TmfaPiPAaMI/AAAAAAAADFg/klG56Zz4t9M/s800/RS4kfmiop.GIF)

S4 KFMIOP
(https://lh3.googleusercontent.com/-0x7ZrDyqCeU/TmfaPs8Ja8I/AAAAAAAADFU/0_ruiOPza1E/s800/s4KFMIOP.GIF)

Now is a good time to think about the purpose of the Torque Model in Motronic. Here is how I am coming to understand it --

In a turbocharged vehicle the available torque varies wildly across the rev band usually with a steep torque curve which increases greatly over just a few hundred RPM.  In a traditional non-torque-managed scenario the driver compensates by applying greater throttle at the start then anticipates the onset of boost and reduces throttle input accordingly.  This may suit an enthusiast but would be considered unrefined and unacceptable for an average customer, especially in the luxury segment.  This is a particular problem in vehicles capable of more than 300 lb/ft of torque as the driver will need to carefully modulate the throttle input in all dynamic scenarios that involve load change in order to avoid violent bucking and surging with increasing loads.  ME7 addresses this particular shortcoming of turbocharged engines with the Torque Monitoring function which manages the varying engine output of the engine to match what the driver is requesting via throttle input by way of modulating ignition timing, throttle plate angle and boost.  When revs are low and engine output is low relative to what the driver has requested via the throttle ME7 will open the throttle further to more quickly achieve turbo spool and meet the requested torque.  As engine output sharply rises ME7 will close the throttle as necessary to achieve a linear power delivery, previously uncharacteristic of turbocharged vehicles.  As such, the S4 in stock form has a generous torque plateau across a broad rev range and was universally praised for its smooth power delivery.

Understanding this becomes crucial when one wishes to modify the engine for power output well beyond original levels.  ME7 was tuned by Audi to achieve a particular level of performance AND refinement.  This benchmark level of power and its DELIVERY – the target that ME7 is trying to hit – is defined by the ‘optimum’ tables.  When we attempt to ask the engine to produce more power in a more aggressive manner sooner we must also take into account the manner in which ME7 was programed to deliver this power - or what it considers optimum.  If we modify Load Requests but fail to appropriately alter the parameters that govern the rules of how it is to be delivered then the result is ME7 attempting to deliver STG 3 power using a delivery method designed for the refined delivery of ½ the power. 


when examining RS4 maps i have to remember that the RS4 was quite refined and, while powerful, was fairly conservative given its hardware. 

My goal, personally, is to understand the model enough to 'turn up the wick' not only at WOT but througout the rev range, while still maintaining the refined nature of the power delivery.  As it stands now - when I do turn things up, Torque monitoring is spoiling the fun in a variety of ways (and as an aside - I'm beginning to believe TM is responsible for the timing oscillations in very fast S4s).  If I disable TM, I suspect the throttle will be wild (it was in 1.8t cars i've driven w/o TM) and this get's old in a daily driver.  I'd ideally like to tell Motronic how I'd like the power delivered and let the TM smooth out the edges.

ok but that difference, between them... is IRL and IOP different enough to see if IOP is using smaller numbers and IRL is using larger numbers then the S4 file?

Case closed.

Berttos, thanks for the analysis. I believe you are SPOT ON. Also, I believe you are right about the timing oscillations being the result of improperly calibrated TM parameters. However, even WITH req torque well above act torque, I still see timing intervention. I have yet to discover the source.

Exactly what I thought we would find when comparing the S4 and RS4 maps...

IOP needs to be modeled to how you want the motor to react to the load... and IRL needs to be made with that in mind IMO.

I will start to do some playing around to see how it effects this all maybe this weekend... if not then not until after H2Oi as I have too much going on from now till then.

You better stop by my booth at h20 and say hi.  ;D

No guarantees I will make it to the show again this year. All depends on how hard I partied the nights before lol. Last time i woke up at 6pm on Sunday :P

But if I go I will stop by for sure.

For the sake of contributing the best that I can, would it be possible for somebody to send me the KFMIRL / KFMIOP / (misc.) including the Axis-Limits for both the S4 and RS4?  I could do a precise MATLAB interpolation to get the desired "reverse-mapping" of the RS4 setup onto the S4's tables.  Of course, if thats what we wanted...  From what Berttos has suggested, even the RS4 torque control is too buttery?

You don't have to "reverse map" the values... all you need to do is to alter the respective RPM axis for the map to have RS4 values. Almost if not all maps in RS4 have respective Axis maps associated with them so that the engineers can whip out binaries like S4 and RS4 using the same management software by just changing bunch of maps, like altering X-Axis values for KFMIRL maps for example.

TunerPro XDF has several Axis maps already defined. Defining your own is fairly easy since each map must have the axis table location defined in its specifications in TunerPro, it is just a matter of taking that address and using it for the purpose of Axis map.

Thanks to BerTTos again for top notch analysis. After posting previously, it became clear that KFMIOP/KFMIRL are indeed for tuning the torque delivery profile, not the output magnitude. I think I'm happier about that than I was before, which is good.

I have an RS4 OLS file which I will upload when I get back. All the parameters are fully defined just not grouped together into the funktionsrahmen modules.

One exercise I was going through which I felt would be informative was to trace the torque model through the diagrams from KFPED to throttle angle/intake manifold pressure, identifying the input and output variables and maps involved at each step.

I got about 8 steps in when I got confused at FUEDK. That's when BerTTos posted up his original question. I'll continue with it when I get back home then post it up in a separate thread so we can all pick over it and come to overall conclusions about where the tuner should intervene and for what purpose.

My present understanding is that LDRMX profile should be altered to increase output under WOT conditions but I'm not sure about increasing torque under part throttle.

TTQS

I agree that it's not as straight forward as simply making KFMIOP match exactly KFMIRL for given data points.  I'm sure Audi had Juergen, Wolfgang and Hans all dedicated to tuning KFMIOP for months with engine stands, dyno runs and road testing. I think for us it's going to take a lot of trial and error.  It would be nice if we could come up with a few different table combinations representing different 'personalities' that we could make available via base tunes.

Thanks All for the input and discussion.  This place is quite a change from the usual rumour and innuendo.

I have had trouble locating axis maps this way at times, how do you decide the equation values?

the conversion values are always in there if you click the 'edit' button on the axis tabs in the 'Edit Parameter XDF Info' dialog box, no? (accessible by right clicking a table in the Parameter Tree in TunerPro).

when looking to see what other tables share an axis - i use the gbox xdf -
http://nefariousmotorsports.com/forum/index.php/topic,201.0.html (http://nefariousmotorsports.com/forum/index.php/topic,201.0.html)

remove the .xdf extension and open it in Internet Explorer - then do a find and replace for the address and note the tables it appears in.

yeah i was being a moron, I failed to just check the equation of the associated map. ;D

well I've just made a program with some radical changes to KFMIRL and to KFMIOP, as well as both optimal TQ maps...

We'll see how the car reacts... I basically built the maps with what IMO makes sense for the motors perspective

Mine reacted in a questionable manner.  I need to lock down some other issues before I can decide what's faster

Well, if you've done it right, it shouldn't affect WOT at all. Its purely for part throttle drive-ability immediately above and below WG cracking pressure.

Also, PLEASE consider posting logs from setzis logger including the variables I posted earlier!

I haven't tried his loger yet, I need to.

I copied rs4 values and got lots of chop off idle and massive TC @ 5000rpm.

the RS4 maps have more data points on the x axis and obviously the axis is scaled differently for both KFMIRL and KFMIOP.  did you replicate the axis values?

also these tables likely need to be loosened up -

RLVNXN
RLVSMXN
KFMIZUFIL

and -
KFMIZUOF has different y axis scaling and output values are slightly different for 1000 RPM.

Keep in mind that while actual torque may be well below requested it still may be in violation of KFMIOP or one of the Torque filtering tables - so TM may have initially intervened to reduce torque and this is WHY it is below actual yet it may not have reduced it enough to satisfy its torque delivery goals and so it is still attempting to intervene via timing.... maybe?

I did a couple of road trips recently and noticed big-time timing intervention at cruise on the highway - to the point of running noticeably rougher and producing a few misfires.  This was with a raised KFMIRL, stock KFMIOP, stock KFMIZUOF but RLVNXN, RLVSMXN and KFMIZUFIL completely loosened up.


With RLVNXN, RLVSMXN and KFMIZUFIL completely stock I was getting noticeable intervention via the throttle at cruise (very lumpy).

1/2 way into a 500 mi trip I switched KFMIRL to all stock except for the last 3 columns and the strange interventions ceased altogether for the rest of the trip. The car as startlingly smooth and happy.

sadly - there are so many occasions that I wish i had full logs of everything but don't and so I'm left to speculate.

LDRXN is just a limiting map for requested load. For over 20psi you should scale IRL by gradually increasing the last 5 columns or so.

I will try and explain the true monitoring effects over the weekend when I have more time

Rick

Please find attached an .OLS file for the Audi RS4 2.7T 380 PS (ASJ/AZR engines) as discussed. If it is deemed to be authentic & useful, I'll also post it up in the definition files section. It decompresses to about 5 Mb.

...another one of the few already posted up here:

http://www.ecuconnections.com/forum/viewforum.php?f=126

 ::)

TTQS

thank you sir. I'll take a look today.

http://nyet.org/cars/files/8D0907551F.xdf

rlmax_w caps output of KFMIRL:
(http://nyet.org/cars/images/KFMIRL.png)

rlmax_w comes from LDRXN, and KFMIRL comes from milsol, which is from mifal... which is driver spec torque

Oh, one more thing... ECUx's labels are a misnomer. That might be the issue.

ECUx calls rlmax "EngineLoadCorrected" and rlmx "EngineLoadSpecified". Both are misnomers. To log actual req load, you're looking for rlsol, aka "EngineLoadRequested" from ECUx.

BTW you can confirm they are independent of pedal position :)

Log. You can watch them drift around, depending on things like RPM, IAT, etc. etc.... but not pedal position!

Agreed. This is also my understanding. So, to recap:

1. Part throttle torque output is regulated by KFMIRL as far as the driver is ultimately concerned.

2. LDRXN caps KFMIRL and thus will represent WOT response.

3. Adjust KFMIRL to achieve more/less aggressive part-throttle torque delivery. Alter KFMIOP too.

4. Adjust LDRXN to achieve more/less aggressive WOT torque delivery.

5. If you have adjusted KFMIRL, you must also adjust the complementary entries in KFMIOP in the opposite sense to avoid risking a torque intervention although the maps are not arithmetic inverses, just complementary as far as the torque model is concerned.

TTQS

There is no need to change the table values in IOP, only the axis so that it corresponds to your higher requested load in IRL

IRL should be scaled over a few columns to maintain a near linear throttle response. I then use KFPED to fine tune this response

Regarding timing oscillations, have you tried logging with knock control completely disabled?

Rick

I'm scared to do this on a WOT full boost run. What variables can I log that show knock corrections that aren't reflected in dwkrz*?

wkr*? wkrm*? zkrvf*?

I used the method that Rick mentioned. I haven't had any TM issues with it for about 10k miles.

I spent some time over the weekend going through the assembler code that deals with KFMIRL and LDRXN. I had one branch instruction mislabeled which lead me to believe that KFMIRL limits LDRXN, when in actuality LDRXN limits KFMIRL. So what the FR says is correct, and I was wrong in this case. Glad we could have this argument though, cause in the process I found an error in my ECU disassembly.  ;D

I cleaned up the thread so that everything stays on topic and there is no misleading information.

Also, I was right with what I was saying about KFMIRL being driven by the combustion efficiency. The axis for KFMIRL is driver requested torque percent scaled by ignition efficiency and lambda efficiency, so you can think of this as driver requested torque percent corrected for combustion efficiency.

I believe if B_kr is not set (TMKR > tmot) then KRRA is completely shut down. I think your only option would be to log knock detection in KRKE.

Have you looked at turning off torque control of ignition angle via B_zwappl? I would try this before turning off KR.

Stupid question. How? Find and modify CWMDAPP bit 0?

Also, there are a few more torque intervention flags to test

B_NOZWE - Condition flag: no ignition angle intervention on the engine torque structure

B_ZWVS - Condition flag for fast external ignition angle intervention on the torque interface
seems to only be enabled for B_llrein (idle regulation), so this is probably not active.

B_ZWVZ - Condition flag for ignition angle intervention on the torque interface

Hmm. In my case, it can't be zwsol, since my zwbas displays the crazy oscillations.

(http://nyet.org/cars/images/ZUE-zwbas.png)

This leaves:

zwgru,dzwzk,dzwbank(ZGRU) dzwwl(ZWWL) zswob(ZWOB) dwkr,wkrdy(KR)

and the various calibration variables vszw, ZWAPPL, vstdzw which shouldn't apply.

I believe zswob (overboost) doesn't apply.
I believe dzwbank doesn't apply (depends on sy_zizwv? always 0?)
I believe dzwzk doesn't apply (KFDZK is all zeros).

I have logged dwkr, and that's not it (slow CF/KR)

Which leaves dzwwl.

I can log zwgru, but haven't yet

I can log wkrdya, but haven't yet (I assume these are from trims and dont move fast enough to matter, unless we are moving back and forth between several of them)

I don't have the locations for dzwwl, dzwzk or dzwbank yet.

Comments?

(http://nyet.org/cars/images/8D0907551M_20110818_161937-timing.png)

I think setting CWMDAPP (181BD) to 1 should do it.


B_zwappl will neutralize this in ZUE and make the other bits you listed a non factor. I didn't see any way to manipulate the others easily.


zwsol will affect zwbas_array.

I have been looking at wkrdya because I am getting long term adaptation, but I don't think this could cause the problem.

I don't think it could be zwgru because all points are interpolated within and between the maps.

Any possible side effects? If it works, can I just leave it set to 1?


so zwbasar_* is not zwbas in the FR?

Do you have the ram location for zwbas handy?


Agreed. This is my feeling at this point as well.

Basically, this leaves etazws and dzws

if (zwopt-dzws) < zwbas, then zwist will follow zwopt-dzws if zwappl=0.

Im still trying to decipher MDZW.

etazws = (mizsol - dmaufer)/(miopt*etazaist) if redist == 1
etazws = (mizsol - dmaufer)/miopt if redist == 0

which goes into DZWETA to generate dzws.

So. To get a SMALLER dzws, we need a LARGER etazws. If etazws is too small, we'll get a large dzws, which might make zwsol < zwbas.

If miopt is too big, or (mizsol-dmaufr) is too small, etazws will be too small

if dmaufr is too big, (mizsol-dmaufr) is too small.

So the possible causes are:

1) miopt too big
2) dmaufr too big
3) mizsol too small

sound right?

From tony, i have:


so I hope to get things figured out by logging those. Hopefully it will be enough, or I will also need to log mizsol, miopt, and dmaufr (and possibly etazaist?)

I misspoke, I was thinking zwappl. zwsol does not affect zwbas.

Ok. That means the source is either zwgru (which I can log) or dzwwl (which I can't log)

Turns out, dzwwl DEFINITELY looks suspect. Part of it is tmot dependent (KFZWWLRL) and part is tans dependent (FZWWKRLN, KFZWWLNM). The former is zero once we are up to temp, but the latter is most definitely non-zero.

(http://nyet.org/cars/images/zwwl-zwwl.png)

What I dont get is that tans doesn't change much. Which really leaves wkrdya

Don't thunk zwwl is your issue. My guess is wkr

That would be obvious even in ECUx logs.

dzwwl also has a load dependant factor. It doesn't look like it would cause oscillations like that though.

According to this function, we should be losing ~6 degrees up top?

I have actually been meaning to start a thread about wkryda. I am getting adaptation via wkrdya through almost my entire log. The first time I hit positive map pressure the ECU pulls 1.5 degrees and it only advances to -0.75 by the end of a long log. I have not touched any of the KRAN maps. I really cannot see this causing the oscillations unless you did something weird to the KRAN maps.

wkrdya can be disabled by setting TMDYNA to an temp unreachable by tmot.

We need to go back to basics here.  I haven't used Setzi's logger yet so not sure what variables are available/known, but this is how I would approach it.

Function ZUE gives the final output to hardware, zwout.

ZUE has various inputs which define the ignition angle.  They are:

Zwguru - basic ignition angle
Zwstt - Ignition angle during start
Dzwwl - delta ignition angle from warm-up
Wkrdy - ignition retard during dyn-function of knock control
Dwkrz - cyl.-spec. ignition-timing retardation with retardation for dynamics
Zwsol - desired ignition angle from torque intervention
B_nozwe - condition no ignition angle intervention of torque structure
Zwspae - retarded ignition angle
vszw - Ignition-timing correction by adjusting system
Zwappl - Applications interface ignition angle adjustment
cvzwzyl- device control value ignition

Now some of these are irrelevant, but the others need logging to see what they are outputting.  Once you find which is causing your fluctuation you can investigate that particular function.

Rick

Rick, exactly the approach I am taking, except I don't have all the variable locations I need.

I've narrowed it down to wkrdy and dzwwl

By logging zwgru and wkryda i should be able to definitively figure out which.

Alternatively, bumping TMDYNA might help illuminate things.

Phila: I am definitely NOT always losing 5-6 degrees that i can tell, which is a bit of a mystery. I won't be able to solve that until I can log dzwwl directly. ETA: my IAT is generally max 50-60C, so i should be losing only 0.75-2.25 degrees.. definitely plausible.

Also, if you look at rl axis of FZWWLRLN you'll see it stops at 90 (iirc), so we are far past the rl dependent part in the region of logs I'm looking at. ETA: at 90+ load, FZWWLRLN is 1.0...

EDIT: my KRANH/KRALH are not stock in this file. they are 80 and 2.25 respectively (stock is 120 and 3.75). My understanding was those affect wrk[az], not wkrdy.

The fluctuations are visible in zwbas, so I believe the only two possible sources are wkrdy and dzwwl; the rest of your list are zero or post zwbas (that I can tell)... PLEASE tell me if you spot something to the contrary :)


As a side note, initially, I dismissed dzwwl because of this terminology. What threw me is that dzwwl still has an effect AFTER warm-up. The lesson is "don't rule out maps just because of their name" :)

Ok, if it's evident in zwbas it's nothing to do with torque monitoring as zwbas is an input to calculation of torque.

Zwbas is created in ZUE, it is is the product of zwgru and zwappl.

I think we can disregard zwappl, so for clarity it depends only on zwgru.

I'm not sure how you conclude zwgru is dependant on wkrdy - wkrdy isn't an input to zwgru is it?

Rick

This is exactly how I tuned my car with my RAM based data logger.

It's not. dwkrz and wkrdy are output from KR and added to zwgru as part of zwbas.

Yea,

so really those need logging.

Rick

I can't log wkrdy, but I do have zwgru and zwsol now :)

(http://nyet.org/cars/images/typical_20110915_133618-MDZW.png)

Definite progress on TWO(!) types of timing interference:

1) dzws gets big enough such that zwsol < zwbas, so sometimes zwout follows zwsol, NOT zwbas!!!! I believe my IOP needs some work..

2) zwgru is rock solid. dwkrz is steady (not show in graph). zwbas is not. so there is definite wkrdy activity.

I need to bug tony/setzi to get me locations for wrkdy and associated variables, unless some of you guys have them handy. I am also going to put KRANH/KRALH back to stock (they affect wkrdy hysteresis NOT dwkrz, like i thought!), then experiment with TMDYNA, which hopefully won't disable dwkrz, just wkrdy.

Thoughts?

You can log wkrdya_*.

Great work Nyet.

You'll probably be wanting to log variables the input to wrkdy too.

Rick

Yea, but those are just the adaptations (starting points).... i need wkrdy, B_mf/zaldy

The good news is I can probably disable it easily with DYAFVS = 0, while still keeping wkrdya.

ETA: Oh, no thats bad. That ABREGELUNG - restoration of negative wkrdya_* towards 0.

Hmm. Odd. That means wkrdy -> wkrdy_a in a single step on a certain B_rkldya/B_rkldyv

Also, this is straying into KR territory.

I may put further KR related posts here

http://nefariousmotorsports.com/forum/index.php/topic,444.msg3621.html#msg3621

rather than cluttering this thread.

I will try and get you the addresses of wkrdy and B_mf/zaldy this afternoon.

Thanks, as usual, tony!

BTW B_mf/zaldy might not be as useful as B_krldy[av]

Hell, I'm starting to think this might be a wild goose chase; I see no indication that wkrdy should be moving around terribly quickly.

wkrdy 0xF9B4 byte unsigned degrees 0.75

I wasn't able to find B_mf, zaldy, or B_krldy because none of then are closely coupled to a map lookup.

Thanks tony! I'll have more logs up time permitting.

B_krldya is bit 0x00FD8C.15
B_krldyv is bit 0x00FD8E.2
zaldy is 0x380C51 (Byte)
The FR states that B_mf exists just for representation purpose
in the documentation, but is not present in the SW.

Thanks. I'll be back on the dyno saturday, so that should speed this effort up significantly.

Any updates Nyet?

Rick

Sorry Rick. My dyno day got pushed back a week. Hopefully I'll have more this weekend.

Up for Nyet :)

I've tried to understand connection between KFMIRL and KFMIOP but failed. I've upped about half of my KFMIRL map, but don't now how to change KFMIOP. Please look at attached image and tell me if my kfmiop needs updating or not...

Yes it definitely does!

could you be a little bit more specific? Because I've read this whole thread and still don't understand how one map relates to another? I mean is there some kind of formula to calculate KFMIOP based on KFMIRL?

In IRL you are requesting 204 load for an 85% torque request.  In IOP you are saying that at 85% torque request you are only going to have a load of 140...

Rick.

sortof, but i'd reword it to say

In IOP you are saying that at load of 204, your output torque is 99%, which is higher than 85%, which results in the ECU interfering to reduce output torque.

Oh, now I understand it... sort of :) So if I update IOP X axis at 145 to 200 it should be OK? :) Can I just edit axis instead of editing table?

so if I understand correctly I have to update tables to something crazy like this (image attached)

In theory, yes :)

BTW the fact that you immediately came to this conclusion means you have the same understanding of IOP that I do, right or wrong :)!

I think some have taken the approach of editing the whole table by hand.

I was THINKING about writing a program to generate the proper inverse (along with a rescaled axis) but never got around it it.

I, personally, have not really played with IOP since my IRL is nearly stock.

Well, let's hope that we understand this right :)

Program would speed up whole process that is for sure... :) Maybe excel could do something like this? Oh and by the way, I have edited both the table and x axis because I wanted some nice numbers in table :)

So my KFMIOP and KFMIRL tables look ok to you? :) I think that now IRL will not limit my boost up to 1.4 bar or something like that...

Yea it looks like you are on the right track. Please let us know the results! BTW it shouldn't affect your boost, only timing.

Thanks, nyet :) I will post impression of drive when I'll test this ;)

Looks much better, I'd increase the values in the last column a little though.  There really is no need to calculate the inverse, you don't need that kind of precision.  Use KFPED to tune response.

Rick

Rick, what do you think if I increase column by 10 ? Or you have better suggestion?

Also, you have a built in fudge factor because actual torque will ALWAYS be lower than optimal torque (due to lamdba and timing corrections, among other things).

Exactly, which is why you never see 100% anywhere. 

I would increase the last column into the early 90's.  Double check intervention by making sure zwist=zbas.

Rick

what is zbas? because melogger doesn't show me this variable inside my created template for this ecu

Flashed the file today and results were... well... at idle my car was dying... rpm went from 760 to 880 and ignition angle was between 0 and 30 BTDC. No knock was detected so I don't know why it was pulling such crazy timing... I even tried to lower KFZW at low rpms, but it didn't help me at all... Flashed original KFMIRL and KFMIOP and problem went away. Either it has something to do with edited axis or my tables are bad.. Any suggestions?

Can you try it with less changes?

Or just IRL vs IRL and IOP?

Also, try to avoid changing low load areas in BOTH IRL and IOP

Could also be an axis interaction; I have no idea if other tables in your file share the same axis.

Ok I'll try to flash only IRL first to check

UPDATE on progress... Looks like I can't change X axis, because some other maps are sharing it also. So, I had to change whole table again. Problem is: I literally feel no difference when those two tables are changed...

I've updated them like this (image attached). If I understand everything corectly I had to lower numbers in KFMIOP to match up with KFMIRL (because axes were already predefined up to 145%)?

BTW: I have compared my previous "pro tuner" bin to stock and found out that KFMIOP and KFMIRL BOTH were RAISED! What a hell? :o

P.S> a little offtopic, but is there a map which limits torque based on gear? because right now I can't boost more than 0.7bar in second gear, but in third I can boost all the way...

You should only be changing the last three axis values in IOP.  IRL shouldn't have it's axis touched.

I haven't touched irl axis, only axis i edited was iop's (but I've edited them almost all to completely match with irl's table). So you're saying that KFMIOP only needs last three columns edited? Even if others are not matching to KFMIRL table?

Yes, exactly. 

Well it looks like I have managed to stabilize idle by leaving first 3 columns stock on IOP map. Now everything is good for few minutes and then torque monitor intervenes with dtc code "torque exceeded". Now I tried to disable monitor for testing but then I got same dtc from torque monitor 2 and my ecu shut down until I restarted engine...

Maps that I've used to disable monitor:
KFMIZUOF FFd whole table
TMNSMN  -48C
TANSMN  -48C

Also I've found these: KFMDZOF_UM, KFMPED_UM, KFMPNS_UM. They look they're are limits for torque.  Should I just FF them too? what other maps are responsible for torque limiting?

I will test these settings next: (image attached)

Post your IOP and IRL maps.

attached now  ;D P.S> Found also this map: KFMI_UM, which looks like is overall optimal torque map for torque monitor. Maybe I should match it to kfmiop?

I have split my ARMD (timing oscillation) issues to a separate thread to avoid cluttering the IRL/IOP torque monitoring topic.

http://nefariousmotorsports.com/forum/index.php?topic=1905.0title=

So if you adjust the data within the map but not the axis will that be sufficient?

If the axis aren't changed but the IRL values exceed the IOP axis is torque intervention going to occur?

yes.  But be careful

no tq intervention if done properly.

I have read this thread through 3 times now and only just starting to get my head around it lol... (at least I think I am)

From what I have seen of the maps on my car from previous tunes etc the '%' axis gets lifted to a higher figure in the last row as does the corresponding data across the RPM range to a value of up to 100%... you then lift the 99/100% row in IRL to a value some 5-8% above the '%' value added to the IOP axis... rightly or wrongly of course... but, rather than 'copy' other peoples stuff I prefer to understand the logic/benefits of doing anything with this and its context to

So... my very limited understanding (so far) is this... IRL represents a load request based on pedal position and rpm... IOP I am still not 100% on ... I understand why this is being used (having used an MBC on my car before) but not sure of changing it in context of my current level of tune..

Most of the stuff being discussed on here does tend to revolve around S4's/ME7 etc but I have a 1.8t S3/ME7.5 so trying to carry the context over as the values look different load wise to mine...

My current setup is based on a GT3071 (T3), Tial 38mm ext gate, AEB large port head and Supertech valve gear... I currently have an rpm limit of 7.8k too...

Here are my current IRL/IOP tables... all I have done is scaled rpm a tad to bring it inline with my raised rev limit (seemed a sensible thing to do)
(http://i84.photobucket.com/albums/k30/tufftybloke/Random/Car/S3/Tuning/IOP-IRL-std.jpg)

I am planning to run at least 1.6bar boost and have already reached the limit of my current MAF (292.58gs) which will be changed for an RS4 one in due course...

I am trying to understand the logic behind raising the load in IRL in context of my setup (or any for that matter) although I get the rescaling of the IOP '%' axis but not why in the case of my std IOP/IRL tables why the load scale tops at 190 and for the most part of 100% pedal in IRL its over 200...

Great thread though (even if I still don't quite get it lol)

<tuffty/>

Ok... have tweaked IRL/IOP tables but not tried this file in the car yet as I was hoping for a some advice to if I am heading in the right direction...

Std tables... (only changed rpm range as I have done on some other tables)
(http://i84.photobucket.com/albums/k30/tufftybloke/Random/Car/S3/Tuning/IOP-IRL-std.jpg)

Altered tables...
(http://i84.photobucket.com/albums/k30/tufftybloke/Random/Car/S3/Tuning/IOP-IRL-v100.jpg)

I upped IRL at 100% across the rev range by 25%, re-scaled IOP load scale in the last 2 columns to 240 (from 190) and 190 (from 175) and upped the 240 column from 3k to 95...

Anyone care to comment and advise please? the changes I made make sense to me...

Thanks

<tuffty/>

I want to mention in this thread, in case it was not mentioned before.

If KFMIOP is tuned the wrong way by raising values (instead of rescaling axis and lowering them/leaving them the same), then that has SEVERE implications on the workings of the traction control.

The traction control kicks in a lot more violently with incorrect KFMIOP. I am guessing because initially it does not reduce enough, and as it still sees high wheelspin, it gives a very strong interruption.
I had serious problems with the tune my car came with, as driving over bumps when accelerating made my car cut out violently and the power remained cut for a long time.

Now, with correct settings, driving over a bump briefly flashes the ESP sign and very slightly reduces power, and it's restored right away.

So - calibrate your KFMIOP/KFMIRL correctly!

This is what I am trying to work out... I don't know if I have missed something in this thread or just don't actually understand this at all but I am trying to understand the process here...

Most maps I have seen appear to up IRL across the rev range at 100% pedal (I have seen a couple that only up values from 3k rpm up rather than the whole rpm axis)... I am trying to understand firstly the reasoning/benefits of doing this and secondly how you derive the correct values in context of sticking a larger turbo on (in my case a GT3071r on a 1.8 20v)... I am currently driving on a map where IRL/IOP is completely std apart from a rescaled RPM axis as my rev limit is 7.8k..

I have done a version of my current map using the IRL advisor in the ME7 tuning wizard spreadsheet and done the IOP map too as well as rescaling the axis of the ignition maps... I haven't flashed this in yet as tbh rather than go in blind I really want to understand how to adjust this to suit particular setups...

Anyone care to do a bit of IOP/IRL 101 for the benefit of others? any help/advice is greatly received :)

<tuffty/>

Regarding the KFMIRL:

I calculated the exact percentage where the limit (LDRXN) is reached at each RPM.
If LDRXN & KFMIRL is altered would it be desirable to keep the percentage the same?

E.G the stock LDRXN is 135,003 @ 2000rpm and KFMIRL reaches this value (becomes limited by LDRXN) at 69,7%.
If LDRXN is raised to 142, should to 70% KFMIRL value be raised ~142,61 (70/69,7 * LDRXN). If the same scaling (70%>) is kept the KFMIRL values get quite high at the top end (%).

Any thoughts about this rescaled / calculated KFZWOP map (for KFMIOP/KFZWOP/2 X-Axis change)?

I used the matching data points (10,20,50%) to calculate the values for rescaled axis.
From 10-190% it follows the trend of original map, for 0% model from higher-end variant is used.

These values are much lower than the one "calculated" by masterj excel sheet.

The original values can be interpolated from the new data / axis so it should not be a complete mess up?

I have also understood that KFZWOP is the "goal" the ECU tries advance the timing to, until knock is detected.
So even in the worst case the timing just won´t be optimal (the delta between KFZW - OP too small) and the knock control comes to rescue if the delta is too high?

No, KFZWOP is only used for torque and efficiency calculations. It is never used for ignition timing.

When KFMIOP X-Axis (& values) is scaled is it necessary to rescale other load axises too?
According to kenmac (http://nefariousmotorsports.com/forum/index.php?topic=2160.0title= (http://nefariousmotorsports.com/forum/index.php?topic=2160.0title=)) the KFZW(/2) X-axis and values should be rescaled too to prevent ECU from trying to use too optimistic timings (and relying on KC / CF).

Would a bad Kfmirl/Iop explain why on my current map, see log below my requested and actual don't follow my specified?

From what I can tell Specified Load follows LDRXN and Requested follows KFMIRL/Iop (in part) therefore as it always takes the lower load of the 2 ( limiting load) it will as shown in the log make actual follow the requested.

If this isn't correct, could someone explain why the 2 don't follow each other. I tried a stock kfmirl/iop map in its place and specified and requested followed each other.

I used the KFMIRL excel spread sheet to create a good kfmirl/iop map but it only gave a max value which wasn't high enough for my turbo.

But it did work well, just then I was limited to max value of the map which was less than I could run

Please ignore the blips, they are knock related.....

Hey Guys ,

Does the above statement hold any validity - does KFMI_UM need to be matched to MIOP and scaled correct as well ?

RPM vs Load vs % torque ?

Thanks

You actually dont want our actual too close to specified, or you WILL get torque intervention. In fact, I doubt those blips are knock related; that is torque intervention right there.

Consider logging corrected specified load; I bet you'll see those blips co-incide to places where actual load goes over corrected specified.

just to add, I have been running with TM disabled for a few days now and I actually like the way the car responds yes it is much more aggressive but for me its perfect, this way I am able to tune everything else with out having TM stepping in.

I followed the changes in the first post

Table KFMIZUOF = 99.6% for all base points
Scalar TMNSMN  = -48 C
Scalar TANSMN  = -48 C

quick qeustion: does KFMIRL share it's RPM axis?

Or tell me how to look for it? When looking at the functions in the FR i cant tell if axis are a shared axis .only when its mentioned.

I suggest spending more time looking at the hexdump.

Thanks.

I know i can tell from the properties what the axis adres is and if they are the same(different maps) it's shared, but is there a way without going manually through all the maps and properties, like in the fully defined 018CB, when  i go to the propperties of an axis and go to that adres, is there a function in winols that shows if other maps use this same adres?

I'm just starting and have read the manual and various wiki's and tutorials,but i may have missed it..

I just hover the mouse over the axis hex, a popup tells you the rest ;)

i noticed that also(in a 032HP), but not in the fully defined 018CB. i wonder why..but im derailing this thread..i found my answer AFAIK KFMIRL doesn't share it's RPM axis.

Good! but have you also found out why it doesn't share it?

You mean the reason why? no not really,just that i cant find any (relevant)axis manually,and hovering over doesn't show it.

..love to hear it though ;D

KFMIRL has an internal axis, that's why it's not shared :P

Thanks for sharing!

great thread,so much helpful info here,i been trying to learn how me7 works until i found the forum here..i am still learning and studying
but have question
how torque modelling KFMIRL,KFMIOP can have better affect on naturally aspirated engines performance ?

Unless you've changed the volumetric efficiency I don't see any benefits on any NA motor.

fair answer,thanks for replying,
so intake/header/exhaust doesn't count?
something like adding turbo to bump the VE of the engine.

If you add in a higher flowing intake manifold/throttlebody then you'd be changing the pumping efficiency. Is it enough to warrant re-calibrating IRL and IOP? I guess that depends on how much of a change there was from stock. I can't see a simple exhaust/intake being enough.

VE can be affected very much with intake manifold and larger throttle blade
 :D

I am struggling with tuning my KFMIOP MAP. This issue I am having is I am getting torque intervention at loads around 50-60% and rpm above 3500rpm. Would it be a really bad idea to limit torque monitoring around these light load and lower rpm regions by revising map KFMIZUOF?

Attached is a log and screen shot. Any advice is appreciated.

Also,

Here are my current tables. My IOP table was created with BerTTos IOP interpolater macro.

Everyone is stuck on one sentence in the FR.

Actually tune it:
http://nefariousmotorsports.com/forum/index.php?topic=3765.msg38179#msg38179

You're tuning the car yourself now?

There is no need to raise the limit and by doing so you open yourself up to level 2 intervention.

Yes I read this in the fr.

I am now learning how to tune my self. I thought tuning kfmiop made sense. I have determined this is torque intervention by watching zwout following zwsol. Then I thought I just had to interpolate values in my kfmirl and kmiop tables and compare them against actual data (misopl1_w, nmot, and rl_w). Then I would use that analysis to adjust kmiop. I identified areas that needed tweaking in iop and I adjusted them so that irl and iop were correct in the problem area while driving (3500rpm+, 52-60% load, 28% torque), but this did not correct the issue.

Edit, thank you very much for that link above!

Here is one thing I don't get from that post:


I can't reconcile that with this:


since rlmax isn't actual load :/

What am I missing?

KFMIOP with rl_w axis outputs mibas_w and with rlmax_w axis it outputs mimax_w.

I tried to keep it somewhat simple.

Ah. The same table is used for both mibas and mimax. I keep forgetting.

Log the variables mentioned and tweak KFMIOP to follow the rules outlined.

KFMIRL should be tuned as desired and needs no consideration regarding KFMIOP or torque intervention.

Yes I see in that thread you linked. I never found that thread in searches due to the title of the thread missing the KFM. Thank you very much for your help!

Edited the topic. Hope Daz doesn't mind :)

Ok added a section to the wiki.

phila, i'd appreciate it if you took a quick peek.

http://s4wiki.com/wiki/Tuning#Tuning_KFMIOP_and_KFMIZUFIL

this is odd though


i thought mimax was checked against miszul, where mimax->mifa->miszolv...

so don't you want mimax to be LOWER (for a given rlmax), not HIGHER, to avoid intervention?

Or is it that we want mibas<mimax AND miszolv<miszul?

So mimax has to be high enough to exceed misbas, but low enough so miszolv (which is calculated based on mibas) does not exceed miszul?

No mimax is just capable of limiting mifa and ultimately milsol and desired load.

You want mimax high to not limit desired load and mifa and mibas below miszul.

Typically rlmax is high enough that mimax is never an issue.

alright. I am going to attempt to draw a flow chart at some point.

hopefully i'll get it right.

i think i got it now.

Looks good.


I would say mimax limits or caps mifa vice results in.


Should read KFMIZUFIL.

Thanks. Fixed.

Any suggested working for level 1 vs level 2 intervention?

For reference, this is what I am using

(http://nyet.org/cars/images/MontySTK_1200cc_pump_R13_log01-2.png)

Just wanted to say this is a great thread -- After reading through it about three times, the light bulb came on and I think I finally understand well enough to effectively update the following tables in "concert"...  KFLDRX(NW), KFMIRL, KFMIOP, and KFPED while avoiding (minimizing) torque intervention.

I ran into all the problems mentioned in this thread...  Raised KFMIZUFIL thinking that would keep torque intervention from being an issue, but I only caused lots of level 2 interventions -- very inconvenient "throttle shutdown".  I experienced the strange timing oscillations too -- it was audible in my exhaust note while cruising.

One piece of advice that stuck with me -- Rick said that tuned KFMIRL/KFMIOP, but then fine tuned with KFPED.  That really helped lay out the process for me...  Start with KFLDRX, then design the KFMIOP axis you need to achieve those values.  Create KFMIRL values by translating KFMIOP stock table values "through" the new KFMIOP axis.  Finally, cross-check requested load vs max requested load by processing KFPED thru the new KFMIRL and KFMIZUFIL thru the new KFMIOP.  Reduce KFPED whereever requested load is above max requested load.  I've skipped a lot of translating and interpolation steps, but you get the idea. 

Once I had this modeled in Excel (nothing fancy -- manual interpolation using freeware Xlxtrafun, http://www.xlxtrfun.com/XlXtrFun/ReadMeXlXtrFunAndSurfGen.htm), I found I could optimize my pedal response while also avoiding torque intervention.  The stock KFPED wasn't very aggressive at low pedal angles and low rpm, which makes driving a turbo standard transmission harder than it needs to be.  I also found my stock KFPED was designed to violate KFMIZUFIL (induce torque intervention), which I wanted to design around.  Why rely on a safety mechanism in normal operating conditions?

Thanks to everyone that took the time to document their issues and discuss solutions.  I don't know how I would have figured this out otherwise.

GREAT NEWS!

This is a very very tricky topic. Good to hear to stuck through it from beginning to end.

Guy, I don't know if it's mentioned jet, otherwise consider it as junk.

KFMIOP shares axis with:

- KFDZWOAGR
-KFZWOP
-KFZWOP 2

I'd have to state it otherwise, SRL11OPUW defines the axis of:

-KFMIOP
-KFDZWOAGR
-KFZWOP
-KFZWOP 2

By the way, this topic helped me a lot, and by reading and testing I figured I have al lot to learn and a lot to figure out. ;D

Nice Thread! Gonna look more into this

Question: If one just Raise boost and give more fuel and dont tough KFMIRL, KFMIOP what will happen or what will not happen ?

Load will not increase beyond highest load figure in KFMIRL. KFMIOP will just ride the last load line of the table for anything above the last figure.

Aha.. I did a test on my 1.8T  raised boost with a MBC and added some fuel.. The turbo seem to boost from 0.5 to 1.5 bar. Turbo boosted as hell but the engine seemed to just block everytging :) cool. Or maybe theres a massive boost leak.. but i dont think so.

Please, just stop.

What´s wrong with learning by doing?

MBC. Just. Stop.

You aren't learning by bolting on an MBC though.  It's honestly the worst idea ever.  I'm not being patronising with the following comment, but if you attach an MBC, what happens?

So, the boost goes up, but what does the ECU do?  Why is boost going up but it's not expecting it to?  How does it control ANYTHING?

Using an MBC is most definitely not doing.

Doing would be using the N75 to control boost.

You are absolutly correct..  this is what happened 4yrs ago. To early boost on a FrankenTurbo is fun in 2min. This happened ona tuned file.. But shouldnt torque limit prevent this from happening even if boost is really high?

Nowadays i use H-Beams. Still using MBC but i must say it runns wierd..   :)

Are you reading this thread?

Will cutting timing save your motor if you are overboosting? You tell me.

But 12 degrees is loads.

Sorry, another one little question about that all  ;D

In stock 2.7T file and others, I saw that KFPED have values where mrfa reach 100% but in the same time  KFMIOP and mimax never reach 100%, only 83 max. It is mean that when I full press throttle pedal - I always have level 1 torque intervention? mrfa > mimax!

Yes

For what purpose is it done? Stock mrfa=100 thru all range of nmot but mimax never reach 100. I'm in confused.

level1 (timing intervention) - when mrfa>=mimax
level2 (torq intervention) - when miszul>=mibas

correct?

If we need mrfa<mimax and mibas<miszul and also mimax<miszul then

If I make KFMIZUFIL equal to 100 in all ranges of nmot and wped,
Make KFPED not more then 100(say 98) where it need
Change KFMIOP where in need in way that mimax equal to 99 all "rlmax" cells

In this condition I never have any type of interventions - yes?


or I have some mistake?

You want level 1 intervention for all part throttle conditions.

You never want level 2 intervention, it means something went wrong.

But mibas<miszul and mrfa<mimax (and mimax<miszul) always! Why I went interventions?  I'm I completely confused. Please help!

Interventions are there to keep very tight control over torque, you can't do this with throttle plate angle.

Rick

Rick, Nyet! Thank you both! )

Now I understand it.

Hi guys, I spent 2 days reading this forum and  s4wiki to catch up the concept of KFMIRL/KFMIOP. There is a lot of misleading informations for a beginners which makes it really difficult to figure out how to tune it properly..Lowering KFMIOP values and other stuff which is written here is amazing but without understading how this thing really works it is useless..

None of this will help you  if you have 110kw 1.8t which from factory has KFMIOP scaled only to 145. You need to rescale the axis mainly otherwise you will receive only load of 145 from ECU (I have done this on the picture and it works without any issues).
If you compare KFMIOP from RS4/S4 you will see that the axis raises further to 200. But the levels of load for given torque are almost the same as in 110kw so what I did, is I removed 130 record from table , shifted values from 145 to the left and put another record of 165 load with eyeballed torque levels. (Change at least KFZWOP and KFZWOP2 accordingly)
So in fact I "raised" KFMIOP. That's all, enjoy your new unlocked load level.  ;D I hope this will help somebody for the future. Btw. Thanks for amazing info on this forum.