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

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


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.



 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?

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. 

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

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.

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

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: the output of IOP goes into the *actual* torque measurement (after lambda/timing adjustment)!