NefMoto

Hello all, one of my first posts here but I think I have done a lot of reading before hand so just looking for some clarification.

I can't find (easily, in layman terms) the relation between KFMIOP, KFMIRL and LDRXN.

I know they all affect each other and I think I've figured it out but would like to confirm. Below are my thoughts...

LDRXN - this is the absolute maximum, regardless what the other tables are set at, the boost (load) will not exceed this.

KFMIRL - this is possible requested load.

KFMIOP - this is the actual requested load from the driver as such. It appears to be a percentage.

So it goes like this example...

KFMIOP requests 92% (based on driver requested load/pedal pressure/something) of KFMIRL (210 / 100 * 92) = 193.2 which can be capped by LDRXN in the end.

So if LDRXN is set to a crazy number like 240, then still the max will be 193.2 = ~1.2bar (193.2 + 30 * 10), not taking into account any overboost/hardware issues on the car.

If we want more than 1.2bar then KFMIOP and/or KFMIRL need to be adjusted accordingly, another example...

KFMIOP requests 100% (based on driver requested load/pedal pressure/something) of KFMIRL = 210 which can be capped by LDRXN in the end. The max possible here would then be 210 rather than 193 (if LDRXN allows for this).

Am I on the right track?  :)

Don't forget KFLDHBN, pressure ratio limitation.  Often the limiting factor.

Kfmiop is the inverse of kfmirl. It is used for torque monitoring.

Kfped = requested torque %
Kfmirl takes the value from kfped and turns it into a requested torque value.
Kfmiop is used to monitor that value and should always be the inverse of kfmirl. Ie; @50%  kfmirl = 100 ---> @100 Kfmiop = 50%.

Me personally I use kfldhbn to limit my load. I set ldrxn to the highest load value I've tuned the car at. This way if I were to go down in altitude I wouldn't push the engine into higher untuned loads.

I see, great, cheers guys!  ;D

I'll look into how best to be using KFLDHBN

Ugh... Wat

That's way off. The purpose of kfmiop is not at all related to torque monitoring. If there's serious errors within kfmiop, there will be torque monitoring conditions met but kfmiop's job isn't too detect it. The purpose of kfmiop is to take a torque % and make it relative to load.

As far as using kfldhbn for a load cap, it doesn't cap load. It caps absolute pressure and doesn't care what altitude you're at. If you want to adjust how the ecu reacts to altitude changes look at BGPLGU module. There's also considerations for elevation specifically in LDRLMX. The ecu wasn't designed to use kfmirl as a load cap, that isn't it's purpose but if one were to use it that way, then I suppose moving ldrxn out of the way would work.

Yes, you're on the right track.

Do not try to think of load % as boost pressure. It's cylinder filling. There's no one formula to try to relate load % to a given boost pressure because it changes depending engine to engine basis. There's also a map to scale plsol relative to load and it's far from a linear relationship.

Trying to relate kfmirl to kfmiop by making it a literal mathematical inverse is a no go. It's the relationship between torque and load so the ecu can determine X% load = Y% torque.

KFMIOP takes the max permissable load and translates it to max permissible torque. If this max torque allows desired torque to be too high, then torque intervention will be triggered. It is also used to calculate indicated torque from current load, which again, if too high will trigger torque intervention and corrected to optimum torque for other forms of intervention.

You are also all wrong about KFLDHBN. This map defines the max permissible pressure ratio, but is then multiplied by ambient pressure giving an absolute pressure. So yes, altitude is definitely a factor here. This absolute pressure is then translated to load and used to limit the max permissible load.

LDRXN is max DESIRED load, but desired load can exceed this because there are corrections that can raise the desired load limit. Also, actual load can exceed desired load.

KFMIRL is desired load, it is limited by the max desired load from %LDRLMX

KFMIOP translates load, actual and max desired, to a torque value for use in the torque model


This is correct for the most part, when you see inverse in the FR, it is an inverse relationship i.e. torque to load, load to torque or air mass to throttle angle, throttle angle to air mass.

I understand his position, though. Tuning the load limit via HBN does make more sense in some ways than LDRXN.

Firstly, like, he says, altitude.

Secondly, all the random corrections to LDRXN don't affect HBN limited boost, since the main correction (fupsrl) is applied to generate load, then again to generate boost again, so IAT corrections cancel themselves out ...

Same with many of the silly VVT based corrections...

I tune max boost via LDRXN out of habit, but I may try HBN on my next tune.

Why does everyone act like it's one or the other?

Everything works together

Aaaannnnd...

If you max LDRXN and strictly use KFLDHBN, then you lose valuable load limitations from some of the silly corrections.

Also, vvt correction is not avoided by using only KFLDHBN. That correction is applied during the desired load to target pressure conversion well after %LDRLMX.

Depends on what load limitations are more important to you. For stock, since there is a ton of headroom in the boost, the IAT corrections make sense.. higher temps, more boost to keep the driver experience consistent... but running near the compressor limits is more common in tuned files, so HBN makes more sense as the "usual" limiter. That said, get hot enough, you still want LDRXN to intervene via KFTARX.. but in this case, REDUCE requested boost on high IAT, and maybe even increase requested boost on low IAT.

That is to say, stock, generally LDRXN limits boost more often than HBN... but IMO that approach does not make sense if you want to run at or near the compressor map limits.

In a performance based tune, you may want the opposite. It obviously isn't about choosing one or the other (absolutely), and never using the other.


IIRC VVT correction (like IAT correction) is in fupsrl, which cancels itself out in the HBN->load->boost path.

I could be wrong.

KFTARX isn't the only correction KFLDHBN bypasses. You would also be bypassing interventions based on ignition retard and coolant temp.

No, vvt correction is applied seperately in %FUEDK as desired load is converted desired manifold pressure. KFLDHBN limits desired load, so it is still subject to the correction. Also, fupsrl_w is the factor that converts load to pressure and vice versa, including when KFLDHBN is converted to load.

IIRC fupsrl is used to convert HBN to desired load limit... then back again.. so any corrections in fupsrl (VE, including VVT corrections) get canceled out. Lets put it this way: why should VE be relevant to compressor limits?

If vvt correstions aren't in fupsrl, then you are right, of course.

How is what you're saying about kfmiop any different than what I said? Although kfmiop is not at all set to be taken as a maximum. There's a KL that caps KFMIOP. Regardless, the point I was making is that kfmiop's function isn't torque monitoring.

If you want to take elevation into account, kfldhbn isn't the optimal way of doing it.

I don't know of any other ways to limit req load (or boost) dependent on ambient pressure... please elaborate?

Also, this isn't outlook. Ditch the top replies ;P

Not fupsrl_w, it's fpbrkds_w. (Edit: the vvt correction)

It's not related to compressor limits, but the pressure required to meet desired load.


You're wrong.

Not a maximum, look at mimax_w.

What KL?

What do you think level 1 torque monitoring is?

You're also wrong about BGPLGU. This is used in load realization, not desired load or target boost pressure.

Indeed. I stand corrected!


Which imo, makes no sense... if the correction is in desired load->requested boost, it should be in PR limit -> load limit...

I think fpbrkds *should* affect PR limit -> load limit, because the resulting requested boost limit should be constrained by PR limits, regardless of anything else ..

But I assume the motronic folks are smarter than me, so i guess there is a reason they omitted it from the PR limit->load limit path.

Look inside the MDZUL module if you'd like to see why KFMIOP isn't designed to be used as a maximum. It's merely the ECU's way of making torque relative to load, it's not designed to be a limit. When the OEM sets it up, it's job isn't to limit indiziertes Moment.

Depending on which ECU we're talking about, the feed forward map for boost control has a critical axis that is directly correlated to KFPLGUB's output. Look at how KFDPLGU relates to KFPLGUB. Look at how KFLDIMX uses plgru_w. This is how altitude is taken into account with regards to boost control.

If you want to take in account altitude's changes on turbo work, there's KFLDIOPU.

This is all MED9 btw. MED17 uses BGPLGU in a similar fashion, but the feed forward map is vastly different from KFLDIMX. The entire torque model is different but KFMIOP still has the same purpose in that ECU as well.

Still wrong. You are reading text translations and assuming you understand concepts.

mimax_w from KFMIOP is CLEARLY the desired torque limit. It limits mifa_w in MDFAW.

MDZUL sets the torque monitoring limit that you decided doesn't exist.

You neglected to provide this KL that caps "KFMIOP".

You did however prove my point regarding BGPLGU. This is used in the boost PID and has no impact on desired load.

Are you saying that the proper way limit boost for altitude is in the PID!?

No, the PID should always work to make the process variable equal the setpoint. The function that you're referring to needs to be tuned properly for that to happen, but it will not do anything to prevent the turbo from overspinning.

The proper way to compensate desired load/target boost pressure for altitude is KFLDHBN. This will allow a lower desired load and ultimately may limit target boost pressure in response to a lower ambient pressure.

Also, if you read my original response you will see that mimax_w is not the only output from KFMIOP.

It outputs mimax from rlmax, which is max permissible torque from max permissible load. This is used to limit mifa, which is desired torque.

Also, mibas from rl, which is indicated torque from indicated load.

These both need to be less than miszul, which is the torque threshold for level 1 torque intervention.

There is also miopt, which is optimum indicated torque and only really used during intervention.

So here we go.. This is what I said:

"That's way off. The purpose of kfmiop is not at all related to torque monitoring. If there's serious errors within kfmiop, there will be torque monitoring conditions met but kfmiop's job isn't too detect it. The purpose of kfmiop is to take a torque % and make it relative to load."

In which way is this wrong, specifically? Is kfmiop a 'watchdog' for torque monitoring? no. The purpose of kfmiop is to take a torque % and make it relative to load. Seriously, that's it. Forget about the Funktionsrahmen and picking apart variable names, look at how the theory of how the ECU works.

This torque % is used within the torque model. Without kfmiop being the 'inverse' to kfmirl, the ECU would have no way of modeling a torque value vs a load %. From a given % of load, there is a % of torque. This % torque is multiplied against a value within the ECU, in this case MDNORM and this is where the ECU gets it's actual torque output in Nm. This is especially critical in MED17. This is how any modern ECU operates. Look at SIMOS8/10/12/18 and you'll see it has it's very own version of kfmiop/kfmirl.

----------------

Alright, so here is what I said - "As far as using kfldhbn for a load cap, it doesn't cap load. It caps absolute pressure and doesn't care what altitude you're at. If you want to adjust how the ecu reacts to altitude changes look at BGPLGU module."

This is your response to me mentioning the BGPLGU module. -

"You did however prove my point regarding BGPLGU. This is used in the boost PID and has no impact on desired load."

When did I ever say BGPLGU had anything to do with load? plgru_w feeds into LDRPID. You want to change boost pressure based off of altitude? The maps/methods to do it are right there in what I said in the previous post. Ironically, on 2013+ B8.5 A4/A5 there is an actual cap for N75 based off of ambient pressure.

What if I told you I had as much experience as any of the knowledgeable posters? What if I have hundreds of MED9/MED17 tuned cars (1.4TSI,1.8TSI,2.0TFSI,2.0TSI,2.5TFSI,4.0TFSI) on different continents (at different elevations)? I don't have any real experience with ME7, but in this case the core concepts are the same. I'm not insulting your intelligence, I'm not being arrogant or pounding my chest with accomplishments. I corrected a post to help the OP. You're getting incredibly defensive and assuming a lot of things I never actually said. So just to reiterate, I'm not insulting. Perhaps I did insult the guy I corrected earlier in the thread but that =/= you.

I think part of the misunderstanding here is we're thinking differently. Nothing you said above is incorrect. You're quoting me variable names and flow of events in the FR, that stuff is great and all but it's useless in the grand scheme of things. The torque model in med17 =/= me7 in any way shape or form. Memorizing variable names isn't going to get you anywhere when looking through Bosch's progression of ECUs. Understanding the full process is invaluable, however.

Let's take a step back and forget variables. Let's look at how Motronic is supposed to function and it's basis of operation in an OEM application.

1) Based off of the driver's input, a torque request is made.
2) This torque request needs to be translated to a desired filling to achieve this torque. Let's say the driver requested 75% torque. We go over and look at what 75% torque means in desired cylinder filling.
[This is where KFMIOP/KFMIRL relationship is important]
3) Does this 75% torque = a desired filling that exceeds LDRXN? Will it result in a pressure ratio higher than what is permissible in KFLDHBN? What will KFTARX do with it based off of the current IAT? Is there continuous knocking? Based off of camshaft position, how is this going to change VE and then scale req. boost pressure off of load?

There's a bajillion things made to alter/scale/limit torque but KFMIOP is not one of them. KFMIOP in theory, does nothing but translate a torque % to load. This ECU is so complex, you can limit power in a bunch of ways. I'm talking of how the OEM limits power, and KFMIOP is not one of the ways it does it.

Oh BDIX727...

Let me start by saying that I am in no way defensive or feel insulted. I'm just correcting inaccurate information.

Also, you being a founder of all modern engine management has no relevance to this discussion.

On top of that, I haven't simply memorized variable names. I think I've clearly displayed a knowledge of the big picture and functionality of these processes. I only used variable names, along with description of origin and purpose, to be specific.

Picking apart sentences in a vacuum does not work. Read the thread again and it will all make sense. You're quoting things way out of order.

KFMIOP is definitely related to torque monitoring. Yes, looking at basis of the map, it converts differing forms of load to equivalent forms of torque. No, it is not s watchdog itself, however, this output is directly used in torque monitoring.

KFLDHBN was mentioned regarding limiting load vice LDRXN. You proceed to say that it doesn't limit load (which it does), claim that it limits absolute pressure (huh?), and it doesn't care about altitude (ambient pressure is literally a factor). Then go on to speak on the base boost pressure maps used in the boost PID, as if the setpoint and not the target value should be adjusted.


Come on man, I'm not gonna sit here and mince words with you. You were wrong. It's ok. I'm wrong sometimes too, but that's not what's important. The only thing important is that accurate information is posted in the end.

KFLDHBN = LDR-Hohen begrenzung (max. Verdichter druckverhaltnis)

At it's core, it's there to limit absolute pressure. There is no axis regarding ambient pressure in KFLDHBN, afterward it's value is multiplied by ambient pressure. But it's output and it's axises has zero to do with ambient pressure. KFLDHBN does not limit load, it limits absolute pressure. Seriously, it's in black and white. Using this to work as a substitute for a load cap is inherently flawed.

KFMIOP relates torque to load. Torque monitoring is not done within KFMIOP. If KFMIOP/KFMIRL has a screwy relationship, torque monitoring will happen.

EDIT - Nothing's being quoted out of order. I'm quoting my initial response that got you all in a hissy.

The fact that this is even being argued, is... interesting. I'll make sure to keep my incorrect understanding to myself though. Let's not allow another experienced voice to offer their view or say anything without flexing our l33t me7 forum rep muscles. I'll continue to lurk and do my best to help others via PM, I'm done posting here.

I can count the number of posts here that have made me go "oh shit" out loud on one hand. This is one of them.

BDIX727:

It's very obvious you have a better than average grasp of what's going on here. Please don't take offense where none is (or at least was) intended.

Phila:

As far as I'm concerned you can say/do whatever you want. Same thing applies though. Perceived attacks!=actual attacks. I think we've all been a bit smug at one point or another.

Bottom line:

The nature of this site as it is, there's always going to be a bit of dick measuring. It's all in good fun. I don't think any of us is done learning. If you believe you have......

Disagreeing with you shouldn't stifle you.

Your still wrong, but that doesn't mean that you have nothing to contribute and shouldn't post anymore.

Nothing is personal, I enjoy this myself.


I think that I need to use more of these  ;D

This is exactly what I want to avoid. PM only is a gigantic waste of time and effort (read my sig why I feel this way), and brings us back to where we were 20 years ago. I can't stress this enough. Glass bead trading and secret handshakes. It is terrible that people with the biggest egos are the ones who so quickly get them bruised and play the "I'm taking my ball and going home" game :(

Guys, please. Step back a second and take a deep breath.

That statement doesn't make much sense. If it was secret handshake type of stuff I wouldn't be giving free advice away to help an enthusiast dial in boost control via pm. I wouldn't be talking at length about motronic theory in the open or posting on the only vag tuning open source site anywhere.

I made that comment for 1 simple reason, why bother posting if it's going to be a headache and you end up having to argue simple points.

Yes. This is a unique place BECAUSE people often forgo PMs and discuss things openly, IMO. As far as I know, no other place exists like it (at least for tuning european cars). The tendency is to get into an argument, then eschew any public discussion, and suddenly, only tiny closed cliques end up exchanging information, and none of it is ever documented or explained publicly.

To that extent, any toxic atmosphere and unnecessary drama discourages open communication. I'm hoping that with that in mind, we can keep it positive and constructive.

It doesn't do any good if the information posted is inaccurate and there is no discussion.

This is how information gets dragged out and it is what people learn from. Not only the people involved in the discussion, but everyone reading along.

It's perfectly fine to be wrong. I've been wrong plenty of times and I'm happy to admit it. The goal is truth, not portraying omniscience.

Don't play word games, bring facts to the table, and have a real intellectual discussion. ;D

Sure man, a map that restricts max pressure ratio is designed to cap load and should be used for that purpose. Kfmirl is used for torque monitoring. That will help everybody.

I'm all for it. This place was where I found the MED9 FR and it allowed me to make my first file. I don't really do me7, so I won't be of too much help but wherever I can I'll chime in.

By what means do you think KFLDHBN opererates?

Either you don't know what a pressure ratio is or you don't understand how desired load is related to target boost pressure.

These are not simple points, but fundamental concepts.

A simple point would be your argument that ambient pressure isn't an axis or output of the map. That is irrelevant. The pressure ratio output is converted to absolute pressure (multiplied by ambient) and then to a desired load limit. The absolute pressure is only converted to the desired load limit and not used for anything else. It isn't even written to RAM.

Desired load is converted to modelled intake manifold pressure and finally target boost pressure at the MAP sensor. KFLDHBN limits desired load to keep target boost pressure within the max pressure ratio. Ambient pressure is the main variable influence here.

i would like some info on the newer MED17 etc... will pay i.e modules please reply here
my email: abid@chiptuners.co.uk

To me it seems that KFLDHBN is mainly to put an upper limit on turbine speed (although you could also say that it limits torque as an EFFECT because it will cause intervention to keep the turbo from spinning too fast). In a stock tune it seems that the only time this could happen is at high altitude/high iat combination at high rpm. Pushing our turbos to the limits means we come closer to max pressure ratio much more often than a stock tune, especially when all cf are included. If the combination of requested torque and altitude/IAT correction factor request cause a pressure ratio > KFLDHBN it will follow KFLDHBN curve instead of requested to cap turbine speed. In a sense you are both right.

Max pressure ratio (KFLDHBN) should follow the compressor map when tuning at the limits or so it would seem.

Under most circumstances LDRXN will cap/follow torque request at WOT -- UNLESS the request + factors cause total load to be outside the range of the other maps. Its like there are many limiters all working together for a huge range of situations?

Torque intervention happens when anything causes torque request to be unfullfillable inside of the ranges defined by all or any of the maps. Does this sound reasonable to you folks? Just wrapping my head around the KFMIRL/KFMIOP thing for my Stage 1 tune on a 2001 AWM 1.8t.

So load request comes from pedal position % > translated to load by KFMIRL table (tells the car how much torque to make for any given pedal position % and rpm) > load capped by LDRXN max load request for given rpm > load is turned into a torque percentage by KFMIOP (always a fraction of max. permissible load) and this is what the ecu tries to achieve via ignition timing, N75 duty cycling, and injector duty cycling, using O2/MAF/MAP/knock sensor as feedback?

Whew.

So for a stage 1 going to max. LDRXN 170 (about 1 bar) load at 3k rpm tapering to 145 at 6k I really only need to adjust LAMFA from 90% and up, scale KFMIRL for higher load across the whole table (maybe use the BAM KFMIRL, what would you recommend?), adjust KFLDHBN so that max pressure ratio stays slightly above LDRXN psi across rpm range (to keep things safe but will allow ecu to follow LDRXN curve normally)? It seems that even though my stock file has last column of KFMIOP at 145 load, that just means anything over 145 will be interpolated on that curve, it doesn't actually limit anything right? The only reason to rescale KFMIOP axis is to give better resolution at higher loads (more useful for stage 2-3?)

I'm thinking adjusting LAMFA and leaving BTS fueling as it is will be fine?

Mainly not sure about KFMIRL at this point (and how to generate a new table that works well with a stock 1.8t AWM). Thanks and hope that I'm making sense of this.



Sent from my LG-D852 using Tapatalk

Also, why does my stock file have max LDRXN at 145ish when KFMIRL has many cells with 180+ on my stock file? What am I missing here?

Sent from my LG-D852 using Tapatalk

Hi.
In my file LDRXN is lower than KFMIRL too. But i do one test. I want 1.1 bar boost (stock is 0.8) and I only up cells in LDRXN with calc it to mbar and mine boost now is 1.1 bar as I want. Only when I ride with my leg in the floor I have misfires and i think it's because torque monitoring is present and ECU give me that dtc. But in summarize only LDRXN map changes is enough to up desired boost.

A log would tell you for sure the issue... Include logging misfires.

Yes i know I must do log.But when I back LDRXN to stock everything back to normal work and no errors present.

Less boost, less spark blowout

As said by Contrast, it could be simply you have a weak coil... Could be you're running out of fuel due to a bad pump... Maybe spark plugs... Maybe TM after all... Point is, you'll never know unless you log or start pissing around randomly with stuff.

Sorry if that's not what you wanted to hear, but that's how it is.

Of course.  It's load limit.  This is in the Wiki.

Does fueling match requested?  Have you asked for more? 

Pic I posted a while back R Belt did;

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

I have new coils NGK U5003 and new spark plugs.So I know its a noob question but what is the best for log?

Seriously?

I mean what i must log for more accurate information not which program to use.

https://s4wiki.com/wiki/Tuning#Logging_utilities

ok thanks for help and please be patient because I learn still:) but I have a question. Is possible when my boost is over 1Bar something wrong is happened with my spark? So maybe I must have a bigger gap on spark plug? Now my gap is 0,8mm (0,031 inch).

Misfires? Does not belong in this subforum. Find a mechanic.

check plugs, coilpacks, icms in that order.

Bigger gap will cause more misfires.

Are you adding fuel? 

Yes I add fuel in driver request map.