Pages: 1 [2] 3 4
Author Topic: KFMIOP, KFMIRL, LDRXN - Clarification  (Read 48683 times)
phila_dot
Hero Member
*****

Karma: +171/-11
Offline Offline

Posts: 1709


« Reply #15 on: October 24, 2014, 12:34:54 PM »

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.

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.

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.


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.
« Last Edit: October 24, 2014, 12:38:19 PM by phila_dot » Logged
nyet
Administrator
Hero Member
*****

Karma: +604/-166
Offline Offline

Posts: 12233


WWW
« Reply #16 on: October 24, 2014, 02:00:52 PM »

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

Indeed. I stand corrected!

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

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.
Logged

ME7.1 tuning guide (READ FIRST)
ECUx Plot
ME7Sum checksum checker/corrrector for ME7.x

Please do not ask me for tunes. I'm here to help people make their own.

Do not PM me technical questions! Please, ask all questions on the forums! Doing so will ensure the next person with the same issue gets the opportunity to learn from your experience.
BDIX727
Newbie
*

Karma: +8/-3
Offline Offline

Posts: 21


« Reply #17 on: October 24, 2014, 02:08:52 PM »


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.

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.
Logged
phila_dot
Hero Member
*****

Karma: +171/-11
Offline Offline

Posts: 1709


« Reply #18 on: October 24, 2014, 02:41:20 PM »

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.

Logged
phila_dot
Hero Member
*****

Karma: +171/-11
Offline Offline

Posts: 1709


« Reply #19 on: October 24, 2014, 02:53:24 PM »

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.
Logged
BDIX727
Newbie
*

Karma: +8/-3
Offline Offline

Posts: 21


« Reply #20 on: October 24, 2014, 03:46:39 PM »

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.



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.

Logged
BDIX727
Newbie
*

Karma: +8/-3
Offline Offline

Posts: 21


« Reply #21 on: October 24, 2014, 04:03:43 PM »

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.

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.
Logged
phila_dot
Hero Member
*****

Karma: +171/-11
Offline Offline

Posts: 1709


« Reply #22 on: October 24, 2014, 05:12:09 PM »

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.
Logged
BDIX727
Newbie
*

Karma: +8/-3
Offline Offline

Posts: 21


« Reply #23 on: October 24, 2014, 06:04:30 PM »

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.
« Last Edit: October 24, 2014, 06:07:02 PM by BDIX727 » Logged
ddillenger
Hero Member
*****

Karma: +638/-21
Offline Offline

Posts: 5640


« Reply #24 on: October 24, 2014, 06:07:04 PM »


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


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......
Logged

Please, ask all questions on the forums! Doing so will ensure the next person with the same issue gets the opportunity to learn from your experience!

Email/Google chat:
DDillenger84(at)gmail(dot)com

Email>PM
phila_dot
Hero Member
*****

Karma: +171/-11
Offline Offline

Posts: 1709


« Reply #25 on: October 24, 2014, 06:20:25 PM »

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.

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 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......

I think that I need to use more of these  Grin

Logged
nyet
Administrator
Hero Member
*****

Karma: +604/-166
Offline Offline

Posts: 12233


WWW
« Reply #26 on: October 24, 2014, 08:03:31 PM »

I'll continue to lurk and do my best to help others via PM, I'm done posting here.

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 Sad

Guys, please. Step back a second and take a deep breath.
« Last Edit: October 24, 2014, 08:06:38 PM by nyet » Logged

ME7.1 tuning guide (READ FIRST)
ECUx Plot
ME7Sum checksum checker/corrrector for ME7.x

Please do not ask me for tunes. I'm here to help people make their own.

Do not PM me technical questions! Please, ask all questions on the forums! Doing so will ensure the next person with the same issue gets the opportunity to learn from your experience.
BDIX727
Newbie
*

Karma: +8/-3
Offline Offline

Posts: 21


« Reply #27 on: October 24, 2014, 09:21:45 PM »

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 Sad

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.
Logged
nyet
Administrator
Hero Member
*****

Karma: +604/-166
Offline Offline

Posts: 12233


WWW
« Reply #28 on: October 24, 2014, 10:00:18 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

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.
Logged

ME7.1 tuning guide (READ FIRST)
ECUx Plot
ME7Sum checksum checker/corrrector for ME7.x

Please do not ask me for tunes. I'm here to help people make their own.

Do not PM me technical questions! Please, ask all questions on the forums! Doing so will ensure the next person with the same issue gets the opportunity to learn from your experience.
phila_dot
Hero Member
*****

Karma: +171/-11
Offline Offline

Posts: 1709


« Reply #29 on: October 24, 2014, 10:10:34 PM »

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. Grin
Logged
Pages: 1 [2] 3 4
  Print  
 
Jump to:  

Powered by SMF 1.1.21 | SMF © 2015, Simple Machines Page created in 0.036 seconds with 16 queries. (Pretty URLs adds 0.00099999999999999s, 0q)