NefMoto

My grasp on this isn't as solid as I'd like either.

As for PRJ, I like him being critical. The only issue I have is I sometimes fear people won't post good information for fear of looking foolish.

I'm going to edit to add this:

Shane,

If someone asks me for a referral on a tuner, PRJ gets my vote every time. If phila were doing this commercially it'd be a draw between them. To say I value their opinions would be an understatement.

There is nothing much to discuss about IOP and IRL, it's just as the FR says.
IOP has to be the inverse of IRL, it also has to have the axis rescaled and go as high as needed, or otherwise mrfa_w will read the rightmost column and spec load will be limited.
But really, if you just generate KFMIOP with stock values using excel, you will be within 0.1% tolerance of the factory values and see that they do it exactly the same way.

KFMIRL is used to request load through MRFA, and KFMIOP is used to look up the inverse, simple as that.
The reason it's done this way is just because it saves computational time...

If you mis-tune KFMIOP, like raising values, then the ECU won't be able to reduce torque properly.
So all kind of torque intervention, such as gearbox or ESP will be off and cause heavier torque intervention in some cases...

this is PRECISELY what I tried, except that I had to put all the low load areas back to stock (which isn't the strict inverse of IRL in those areas!).. btw all my low load areas are bone stock in IRL as well.

At minimum, I'm glad my understanding of IOP lines up with yours (esp the comment about saving computation time by having complementary maps) :P

Absolutely concur.

There's a lot of bad stuff about indeed. There's a lot of bad stuff even from this forum by some people claiming to be "pros".
My advice when looking for someone who tunes stuff is looking how many successful high powered cars they've done on stock ECU.
Maybe have a look at their website etc... because the higher powered stuff is what is hard to tune, stage 1 stuff is quite easy.

Most "pro-tuners" don't have any clue about assembly code, they just use hex pattern matching.
To have someone who can do custom assembly stuff as well as understand the internal combustion engine very well takes just the right mixture of computer science geek and petrolhead, and this is usually quite hard to find as they tend to be mutually exclusive.

Down low, you might want to have the IOP a little bit lower to allow some tolerance for overshoot. The internal combustion engine is a messy and imprecise thing, so mathematical models that go to the last decimal point don't always quite line up due to overshoot and undershoot :)

I usually don't touch the lower areas of KFMIOP, I just rescale the axis from 90-100 load up and provide a smooth gradient, so the interpolation can do it's job.
There's really no point in replacing the entire IOP table, and for many Stage 1 tunes you don't even have to touch IRL and IOP.

Forgive my ignorance, but whic maps share an axis with IOP?

My understanding is:

Rescale the IOP axis to match up with IRL. Recalculate IOP under the rescaled areas. Do the same with KFZWOP/2. Is there anything I'm missing? I'm just getting comfortable rescaling axis'.

That's all I do.

ETA: there is one more map that shares it: KFMDS

I dont have it defined in M-box. Not sure if we care.

KFMIOP KFZWOP KFMDS

I don't really feel like debating right now, but I would love for someone to speak specifically on this subject because I tend to disagree with everyone on this subject.

The only concern is keeping mibas and misolv less than miszul and mifa less than mimax.

KFMIRL translates torque request (milsol) to spec load.

KFMIOP gives mimax from rlmax which basically caps mifa, mibas is torque from rl corrected by ignition and lambda efficiency, miopt is used in intervention, and miist is output to other controllers.

KFMIZUFIL is torque limit from wped. This is the check and balance, but pedal axis maxes at 60% and anything over is basically unchecked. This is backed up by "Level 2" which will intervene if this map is adjusted. I don't see a need to touch this map or the UM maps.

mimax_w is what could cap spec load by capping the torque request, but the load axis is rlmax, so your basically working with the last column all the time. This should never be an issue.

mrfa is that base value for mifa, but that is the extent of it's influence here.

All of the external interventions are basically percentage reductions, so unless mifa is abnormally low, you can't really mess them up.

Didn't mean to write all that...

KFMDS drag torque speed and load dependence

0x1E302

Factor X*0.001526

Time to search the FR I guess. If noone bothers to recalculate it after an axis change, I'm curious to know it's significance.

I think the idea is that unless you scale the load axis UP in IOP, for a given load, mifa might be too large. Your point is that if you don't touch IOP, you are always in the last cell for rl>191, so mifa will never be too large?

Makes sense.

IRL has to be inverse of IOP, end of.

Example, if you are running 220 load and your IOP axis only goes to 170 and the last value is 99%.
Then anytime ME7 would like to request over 170 load it'll request 220.
It's especially bad with 1.8T where IOP caps out at 140.

This means, that it is unable to have a fine granulation from 170 to 220.
This gives problems on any sort of torque intervention as it is impossible to ramp up the torque gradually.

Side effect of this is that ESP becomes unusable on the RS4 if entire IOP map is bumped up, as a light intervention does absolutely nothing and it goes instantly to the hard cut where it cuts all your power.

Any chance you can post an example of a file (or the matching IOP/IRL) that has been done correctly? I understand this in theory, but experience has shown different results, particularly at low loads. It would be even better if we had the software number so as to compare the changes to the original. I know what I'm asking for is dangerously close to spoon feeding, but I really feel that my understanding would be increased given the benefit of your experience here.

As for KFMDS, are the effects of rescaling the axis without recalculating negligible as others have suggested? I assume (never safe around here) if it's involvement were significant we wouldn't get away with ignoring it when rescaling.

Except that KFMIOP doesn't have that strong of an influence on spec load, unless mifa is greater than mimax. Which would trigger torque intervention from mifa != misol anyway.

DD if you rescale the axis, then you have to fix the tables, KFMDS included.

Just an FYI, this is a split from the discussion that was happening inside the thread of "Tuned ECU files"

Carry on :)

I don't see how torque intervention would be triggered if mifa is greater than mimax.
It can be greater than mimax all it wants to, nothing will happen, req. torque will just be limited to mimax.

If mifa != misol then B_zwnget is set (%MDKOG)

Actually I remember from logs, that mifa_w gets limited as well if KFMIOP axis ends too soon.
And if I look at MDFAW it becomes clear why.

Meaning mifa_w can not exceed mimax regardless, so this situation is not going to happen.

Sorry, I got that mixed up, mifa != misol happens if mifa > miszul.

I was thinking B_mdein from mifa > mimax causing misolv > mifab.

Edit: I will have to check some logs I have where I was playing with KFMIOP to trigger torque intervention where I had mifa > mimax

I'd do it just to be thorough, but why has noone reported issues with this? Obviously Nye has rescaled the iop/zwop axis without doing KFMDS.

LOL. That means nothing :)

It is used to offset for torque loss all over the place.

Just because there are no reported problems doesn't mean it shouldn't be corrected IMO.

lol

I wasn't saying it must be right because you were doing it, but rather that you're thorough (anal?) enough to have sought a solution had you noticed negative effects. Ergo, the effects were negligible.

Agreed 100%

But for the sake of completeness, can you guess where we MIGHT see the problem?

KFMDS probably influence Nm torque calculation at 120 block , if we increase iop and irl we get decresed values of NM in 120block what else idk - Maybe prj could tell more about kfmds

Off the top of my head...

Idle speed control, ASR/MSR, goes out over CAN (ABS, TCU?), torque refinement

Block 120 is for tester only, but both miist and mdverl go out on CANBUS

Idle speed control - shouldn't be an issue, since we're talking about changing the last few load cells.

ASR/MSR - generally have it turned off. My car runs like crap with ESP on (and I haven't put any effort into fixing that). Perhaps this would be a good start?

ABS - heh. not on the brakes at those load levels ;)

TCU - could definitely be an issue with TIP trannies?

torque refinement - again, talking about load levels you really only reach at WOT..

Yeah, I don't have ESP, or a TIP.

Is it just me, or does it only take 5 minutes?

I would fix it.

I plan to, just wondering about what side effects I might see.

Look at MDFAW, specifically DMFABEG again. mifa can not be larger than mimax, ever.

I'm very familiar with the function.

I have a log I'll have to check when I get home. One of the intervention bits in there may have been set.

Anyway, the original point was that spec load won't be limited unless mimax is capping mifa.

Hmm...something strange going on here. I'm going to try to recreate the conditions in a new log.

At WOT between 2k - 4k RPM there's a handful of records (14 total not all sequential, but same pull) where mifa > mimax. Most of them (10) mifa > mivbeb, but a few (4), mivbeg, mivbeb and mifa are all equal and > mimax.

There was no reaction at all though, ECU couldn't have cared less.

Since I've been bouncing around so much and even confusing myself a little trying to recall the details, I wanted to summarize what I can state as facts:

- any part of KFMIOP (load/speed range) that cannot be reached below 60% wped_w is basically unrestricted and can be raised to keep mimax_w high

- the load input to KFMIOP for mimax_w is rlmax_w which means mimax_w will always be calculated from the high load portion of the map. This means mimax_w will typically be safely high enough to never limit the torque request

- care must be taken to ensure that mifa/misolv and mibas/mizsolv remain below miszul to avoid intervention. This mainly becomes a concern in the middle of KFMIOP.

- KFMIRL translates a torque request to spec load
- KFMIOP translates actual load to torque value (mibas)
- KFMIZUFIL checks that the torque value from actual load doesn't exceed the max torque value allowed for a given request from driver's pedal

I'm going to bump this. Without the ability to rescale the IOP axis for the increase in IRL (8 bit limitation FTL), how are people with (strong) stage3 cars not getting intervention? Underscaled MAFS? Disabling torque monitoring altogether? It would seem that without the ability to properly scale IOP to reflect changes in IRL actual torque>requested torque which would in turn trigger intervention.

I've begun the task of transferring my work to the K-box with 5 bar support to avoid this, but I'd like to understand the solution.

I think this is the relevant sentence:

"the load input to KFMIOP for mimax_w is rlmax_w which means mimax_w will always be calculated from the high load portion of the map. This means mimax_w will typically be safely high enough to never limit the torque request"

The *input* to KFMIOP is rlmax (not current load request), so unless your rlmax is unusually low, you should not see torque intervention via mimax cap...

really, the best way to see this is to make sure that mifa/misolv and mibas/mizsolv remain below miszul

Just always log those 5 things, and if you see that rule violated, look at rlmax and determine where in KFMIOP you are.... and then see if mimax is resulting in an unusually low miszul or an elevated mifa

At least, that is how I have been interpreting phila's posts.. and so far my logs have lined up with those expectations. YMMV..

IOP axis is 16 bit, rlmax_w for mimax_w and rl_w mibas_w.

Rescaling the load axis is not the answer to intervention however.

I don't know if I can explain any better than I did in the post above yours.

You basically need to use KFMIOP to keep mifa and mibas in check (below miszul) under 60% wped without limiting air charge via mifa/mifal.

Log the variables and tweak as needed.

Ask any specific questions you have after reading this post and the one above yours.

The main trigger outside of KFMIOP is dmar_w != 0.

Safe to assume I have to add those variables to the ecu and config files manually?

Anyone have the addresses handy? I assume Nye has some sort of repository containing them, but I haven't found it.

http://nefariousmotorsports.com/forum/index.php?topic=3039.msg30034#msg30034

Thanks phila. That's exactly what I was looking for.

I keep these a bit more up to date

https://github.com/nyetwurk/ME7L/tree/master/ecus

LOL at your github profile pic ha.

Ok, so I am attempting to tune my KFMIOP. I see that mibas is exceeding miszul in my logs.

Nyet says: "Just always log those 5 things, and if you see that rule violated, look at rlmax and determine where in KFMIOP you are.... and then see if mimax is resulting in an unusually low miszul or an elevated mifa."

I am going to have to assume my miszul is unusally low (not sure what "unusually low" refers to?) since my mifa is in check.

I am seeing an rlmax = ~210-252 where the mibas exceeds miszul which puts me in the 191 and 225 load columns in KFMIOP. RPM is going to be in the 3000 and 3520 rpm rows. So my KFMIOP values of concern are 69.2, 69.9, 76.1, and 77.3.

I have a few questions. I understand the KFMIOP map uses a fit and interpolates the data it needs.

1. Do I need to adjust cells in KFMIOP outside the 4 that I have identified in my IRL/IOP screenshot image? Should I just scale both columns?

2. Reviewing the FR, I see KFMIOP's output miotl1_w multiples by etazwb to become mibas_w. So when I adjust KFMIOP, my goal is to lower mibas so that it is below miszul?

In your plot, notice that mizsolv follows mibas (current torque) unless mibas exceeds miszul (torque limit), in which case mizsolv follows mifa/misolv

So you need to make sure mibas does not exceed miszul by lowering KFMIOP in those regions. I think :(

Hopefully phila can correct me if i'm wrong.

I'm currently working on this section in the tuning wiki

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

and i'm hoping to get something together which makes sense.

Thanks nyet.

Since my issue is with mibas and not mifa, I assume I need the be concerned with rl_w, not rlmax_w correct? So my actual load areas are the problem columns in KFMIOP, not requested load. Or am I missing something?

Yes. I *think* you have it right. Again, I don't trust myself on this right now, I'm still trying to study the FR and come up with something easier to read in the wiki.

Ok, if my understanding is correct (I'll wait for philadot to approve or tell me I'm an idiot  :)) then my final area of concern is how much of the KFMIOP table needs to be modified surrounding the RPM/LOAD areas that are causing the issue? I'll do some testing and report back. I'm going to start by reducing my load columns by 5% at 62.25, 74.25 and 97.5 from 3000-6520rpm.

Yes, reduce those individual cells in the problem load/RPM areas in KFMIOP.

It doesn't take much most of the time.

Any idea what this is in his log?

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

Excellent, I'll test this out asap.

I also noticed that after modifying my IOP load axis my zwout is 5-10 degrees lower at idle depending on vehicle speed and clutch state. Should I look into modifying KFMRES/K to bring my idle ignition angle back where it should be?

phila disagrees with adjusting the IOP axis, so you might try putting the IOP axis back to stock instead?

YMMV.

Well, whether I leave the load axis stock or not, the IOP values can not be left stock with my modified IRL. So with my 271 upper load limit in my IRL, I get very small values in IOP near idle when I use the Mbox IOP interpolater workbook, which iirc will still screw with my idle ignition angle. I guess since at idle torque monitoring is null due to miszul=100, I can get away with stock values in this area. I'll try that.

IRL has NOTHING to do with IOP.

KFMIRL takes an input torque and converts it to desired load. That's it.

You are good as long as the torque value at the current load and RPM is below the max allowed for the current pedal position.

There is absolutely no need to touch anything anywhere near the idle areas.

Unfortunately there is a lot of misinformation here on Nef about that (and sadly most of it from myself).

Now that I actually understand IOP i should go back and edit all my posts, but it is a bit late for that. I will try to update the wiki appropriately, and the IOP/IRL workbook thread should probably be edited/deleted etc accordingly :/

phila: I am open to suggestions on that front.


This mirrors my experience 100%

So I guess I should go back to stock IOP and tune from there rather than using this Mbox interpolated IOP based off IRL...

Looks like dmar != 0

Look how mizsolv is straying from mibas

I feel like I might have to take this route with my tune as well.

Since I have a 1.8t AWP, my load axis are much lower in a most maps, at least the ones discussed in here.  The IOP/KFZWOP axis caps at 160.  KFZW axis max is 150.  For this reason, I have adopted those maps from the BAM (191 and 185 max respectively) as a base to go off of that had higher load values.  I don't know if that's the right thing to do, or if I should stick with the stock AWP maps and bump the last few columns of irl and decrease the last few of IOP.  What would this mean for the KFZWOP maps?  Should the KFZW map still be scaled with reference to the changes in IRL?

Update,

I am still having the same issue after lowering my IOP cells by 5% and then 10%. I will continue to lower them by 15% and more today.

Finally! Torque intervention gone in the logged rev range! I had to lower my IOP values by about 20%, and I had to lower my 50.25 column as well as the other 3 columns from 3000rpm+. I still need to run the revs up higher to make sure I am in the clear in the higher revs, but I am very happy with how things are progressing!

Good work and thanks for keeping us all informed in here.  I am going to be messing around with this weekend as well.

I wish I knew the memory location for all of those variables that you are logging on my 032PL.  Can anyone help with that?

jmont, you know what would be super duper awesome?  When you finish this part of your tuning, maybe you could post screen shots of the stock irl/iop vs your new irl/iop and any other maps that you have changed due to the scaling of the iop load axis.  This would be a great help to me and many others for sure.  I will surely do the same when I figure something out with my tune.

Now that iop has been described as the reverse lookup to save cpu time, the actual purpose of this table makes clear sense to me.  This makes the concept click with me, vs just reading it as... iop being the inverse of irl.  WTF does that mean anyway?  :)

Basically the torque->load mapping from IRL should (more less) result in a lower torque if you feed that load into IOP for load->torque.

so

1) the driver requests a torque via pedal
2) requested torque is converted in to a requested load via IRL
3) ME does its thing, opens the throttle plate, picks a timing, attains a boost level. The motor responds accordingly and the ECU calculates the resulting actual load using MAF readings, etc.
4) now the actual load goes into IOP and gets converted to actual torque

torque monitoring now needs to make sure the resulting actual torque does not exceed the requested torque.

So you don't really need to log, you can guess at the required IOP values by looking at the areas of IRL that you increased. Make sure that the increased resulting load (when fed into IOP) does not result in torque higher than the torque that generate that load in IRL.

So is the ECU looking at a few surrounding load/rpm and torque/rpm cells and interpolating values or is it drawing a fit through entire columns/rows in IRL and IOP?

I have created new IRL and IOP maps that are only modified in the highest load/torque columns (stock IOP axis as well) to try an fix this idle timing issue that I am having, but I am still getting timing intervention due to mibas>miszul in areas of the maps that are completely stock?

Also as a side note, notice my issues with dmar !=0 in this log. I have added all the torque variables and condition bits from the "ARMD inerventions (anti-bucking) final solution for WOT" (may want to correct the spelling in that title :)) thread to help diagnose this for future logs, however these variable and conditions are not in this log :( and I didn't have any dmar !=0 in my logs this morning. Anyways, I don't want to derail this thread with ARMD interventions. I'll try to stay focused on the IOP/IRL tuning issues at hand.

thread URL referenced above: http://nefariousmotorsports.com/forum/index.php?topic=3039.0title= (http://nefariousmotorsports.com/forum/index.php?topic=3039.0title=)

Looks like your iop is way off for your given irl. 

Example:

In IOP's 191 column @ 6000 rpm, you have 99%.  This value should be more like 82-83% (eyeball value, no math involved). 

I come up with around 82 because in IRL 191 would be part way between 182 and 230, referencing your 80 and 90 columns @ 6k.

Someone please correct me if I am wrong.

Said another way: any part of KFMIOP (load/speed range) that "can" be reached "above" 60% wped_w is basically unrestricted and can be raised to keep mimax_w high.


This is why my IOP 191 column is not an issue, but see how most of my IRL/IOP maps are stock and I am still getting tq intervention in loads/tqs towards the mid to lower end of the IOP/IRL maps. Not sure how this is possible if stock s4s don't get intervention unless the higher load/tq areas of the maps affect the mid and low areas of the map...

HA HA! I just reworded it the EXACT same way in the wiki. It took me about 30 minutes to decide they meant the same thing.

Regarding interpolation:
http://nefariousmotorsports.com/forum/index.php?topic=5525.msg58989#msg58989

This is very helpful! Thank you sir! Can you please help me understand why I am getting intervention with stock values in most of my IRL/IOP map if this is indeed how these maps are interpolated?

Not can be reached above 60% pedal, but can ONLY.

Torque management needs to be balanced in one way or another.

With a stock KFPED, the initial torque request does not change from stock. What we are working around for the most part is an elevated rlmax_w from raising LDRXN lifts mimax_w. This is unavoidable.

Actual load still equals the same actual torque if you don't touch KFMIOP at all, but mifa_w is no longer restricted as it originally was because mimax_w is now raised.

You should be able to eliminate all torque intervention without disturbing the torque request output milsol while maintaining all of the original safegaurds.

Torque intervention is supposed to occur sometimes and you should make sure that you are not trying to tune these out. You will never have to touch any idle areas or anytime that wped_w is zero.

Here's a stock BAM irl/iop next to the changes that I made.

I raised the irl and iop axis to match near my max ldrxn values.   I then interpolate the new values for iop based on the values in irl.

kfzwop(2) values didn't vary much towards the end of the map so little work was needed there.

Is this right?



AWP original for reference.

Ok I have been reading for so many days even my dogs eyes hurt. SO.... i am trying to tune my 2.7t ME7.1.1 to a stage 1 or 2 level. amd I was starting to think I had the hang of things... seemed like I was suppose to start with the KFMIRL and IOP... but now after reading this post I do not know where to start at.  My thoughs were that fueling should be good, maybe a light increase. I know I need to increase boost and im am sure the load as well. What about timing>?

and my biggest issue so far is not being able to find some tables..   Mainly so far I can not find the LDRXN....    I only have LDORXN,   LDRXN_0_A,   and, LDRXN_1_A.


The XDF I am using is the 551R

LDRXN_0_A is LDRXN.
LDRXN_1_A is LDRXN for variant coding (allroad)

Actually one is for automatic and one is for manual, for 4Z7907551R at least.

_0_A is for manual
_1_A is for automatic

That very well could be, just going from memory :)

I'm not sure about it. I disassembled r-file and didnt find any references to LDRXN_1, found only to LDRXN_0. Also if I remember correctly, LDRXN_0 sets max rl for AT also, from my experience ) 

When my A6 was auto I had modified all the _1_A maps, then after I did the 6 speed swap & recoded the ECU for manual via VCDS I'd go WOT and almost immediately get throttle cut. After logging I saw it was only requesting the stock load curve (because LDRXN_0_A was still stock). After moving my changes over the _0_A maps it was all good again.

Thanks for this info) That means I'm blind because I can't find reference to LDRXN_1. Please someone who knows assembler, help me to find reference to LDRXN_1.
I found the reference to LDRXN_0: Seg0x229@8a4000:4ABE

But there is no LDRXN_1...   :-\

Thanks a lot for yours and everyone else's help!!!  I really feel like I am getting the gist of things.

OK, so I wanted to post up a screenshot of what I have so far.  plus.... How do I change The values in the x axis of KMIRL or IOP?
(http://[url=http://postimg.org/image/poxndh67n/][img]http://s5.postimg.org/poxndh67n/First_Try.jpg)[/url][/img]

(http://s5.postimg.org/poxndh67n/First_Try.jpg) (http://postimg.org/image/poxndh67n/)

It's unfortunate that TunerPro doesn't allow you to just change axis values in the map you are working with.  winols does.

You'll have to define a new map for the axis you have to change.  Just look in the columns/rows area of the map definition and use those offsets and equation to define your new axis map.