Pages: 1 [2] 3
Author Topic: LAMFA and ZKLAMFAW  (Read 14951 times)
The_Gimp
Newbie
*

Karma: +2/-0
Offline Offline

Posts: 11


« Reply #15 on: April 15, 2013, 06:07:27 AM »

hey you tubes! lol, i do MAF table revisions real gerd.
ok, so on subject.  what do you think of this LAMFA table?  please note the revised RPM and load points.
obv would like input from el trooperino from near cupertino on this table:



I would only modify the last two columns.  Beyond that, your requested should be richest around peak torque.  (B5S4: ~3500-5000) and taper off to ~12.5:1 as the curve gets furthest from that point.  There's probably no need to be at .8 at 7000RPM.
Logged
phila_dot
Hero Member
*****

Karma: +157/-11
Online Online

Posts: 1704


« Reply #16 on: April 24, 2013, 08:05:21 PM »

I am using 0.001525902 as the conversion for ZKLAMFAW.

It is (sorta) the percentage of change per cycle (0-100). Better understanding here:

current value +- ((|new value - current value|)*constant)

I am currently using a value of 50 for rapid change.
Logged
automan001
Full Member
***

Karma: +35/-0
Offline Offline

Posts: 147


« Reply #17 on: June 30, 2013, 01:29:40 AM »

Has anybody tried to configure ZKWLAFWL (Time constant weighting offset engine target lambda)?
What influence does it have on target lambda? I guess it's related to KFLAFWL (Offset engine target lambda)
It's currently defined as a byte with value FF = 255 s
And i doubt it's correct definition.
I thought it should have been similar to ZKLAMFAW.
In FR LAMFAW 7.100 (Driver's Requested Lambda) it's default value is similar to
ZKLAMFAW
:
ZKLAMFAW: 2 s
ZKWLAFWL: 2 s
« Last Edit: June 30, 2013, 01:34:34 AM by automan001 » Logged
automan001
Full Member
***

Karma: +35/-0
Offline Offline

Posts: 147


« Reply #18 on: July 03, 2013, 07:59:20 AM »

I halfed it and there is still a slight delay, but I haven't had a chance to really play with it further.

I am using 0.001525902 as the conversion for ZKLAMFAW.
It is (sorta) the percentage of change per cycle (0-100). Better understanding here:
I am currently using a value of 50 for rapid change.
To increase the speed of change, the value has to be increased? FFFF is fastest change?
Logged
nyet
Administrator
Hero Member
*****

Karma: +417/-48
Offline Offline

Posts: 9253


WWW
« Reply #19 on: July 03, 2013, 11:32:21 AM »

No, it is a time constant, so decreasing it makes the response faster.
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.
julex
Hero Member
*****

Karma: +77/-4
Offline Offline

Posts: 923


« Reply #20 on: July 03, 2013, 11:41:20 AM »

Are you sure? The formula above would indicate that the value would actually make faster change the higher the number is and what phila_dot states above, along with his set up for this value, would make sense in that light.
Logged
phila_dot
Hero Member
*****

Karma: +157/-11
Online Online

Posts: 1704


« Reply #21 on: July 03, 2013, 12:57:39 PM »

The formula that I posted is directly from the code and is exactly how it works.

The conversion is my device and how I prefer to realize it.
Logged
nyet
Administrator
Hero Member
*****

Karma: +417/-48
Offline Offline

Posts: 9253


WWW
« Reply #22 on: July 03, 2013, 01:40:01 PM »

The formula that I posted is directly from the code and is exactly how it works.

So to confirm: the FR is incorrect, and it is not a time constant?

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

Karma: +417/-48
Offline Offline

Posts: 9253


WWW
« Reply #23 on: July 03, 2013, 01:48:38 PM »

$ grep ZKLAMFAW *.csv
4Z7907551R.csv:"ZKLAMFAW","0x1edac","Zeitkonstante Filterung Anfettung durch Fahrerwunsch","1x1","16 Bit (LoHi)","-","s","-","-","1.0","1.0","1.0","13107.0","13107.0","0x3333","0x3333"
8D0907551F.csv:"ZKLAMFAW","0x1ca4c","Zeitkonstante Filterung Anfettung durch Fahrerwunsch","1x1","16 Bit (LoHi)","-","s","-","-","1.0","1.0","1.0","65535.0","65535.0","0xffff","0xffff"
8D0907551G.csv:"ZKLAMFAW","0x1c3f0","Zeitkonstante Filterung Anfettung durch Fahrerwunsch","1x1","16 Bit (LoHi)","-","s","-","-","1.0","1.0","1.0","65535.0","65535.0","0xffff","0xffff"

so 2.7t F and G box (stock) values seem to be zklamfaw = 0xffff (100%), and R box 0x3333 (20%)

phila: does this jibe with your understanding?
« Last Edit: July 03, 2013, 01:50:14 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.
phila_dot
Hero Member
*****

Karma: +157/-11
Online Online

Posts: 1704


« Reply #24 on: July 04, 2013, 10:22:54 PM »

So to confirm: the FR is incorrect, and it is not a time constant?

Yes, at least that is the case in our ECU's.

so 2.7t F and G box (stock) values seem to be zklamfaw = 0xffff (100%), and R box 0x3333 (20%)

phila: does this jibe with your understanding?

Yes, 100 (0xFFFF) would be no filtering. The value will jump to the desired value in the same cycle.

50 (0x8000), will take 11 cycles to reach the desired value going 50% of the difference each cycle.

Stock value of 20 (0x3333) would take (alot of) cycles to reach the desired value.

0, becomes 1 IIRC to avoid preventing change.

Edit: corrected error in number of cycles
« Last Edit: July 05, 2013, 08:58:09 AM by phila_dot » Logged
julex
Hero Member
*****

Karma: +77/-4
Offline Offline

Posts: 923


« Reply #25 on: July 05, 2013, 07:17:42 AM »

Yes, at least that is the case in our ECU's.

Yes, 100 (0xFFFF) would be no filtering. The value will jump to the desired value in the same cycle.

50 (0x8000), will take two cycles to reach the desired value going 50% each cycle.

Stock value of 20 (0x3333) would take 5 cycles to reach the desired value.

0, becomes 1 IIRC to avoid preventing change.

Any idea what the "cycle" is then?

On the side note, I see that LAMKR is also filtered via this which has huge ramifications to anybody using map KFLAMKRL for enrichment on knock. This explains my experience with delay in fueling enrichment on knock I was experiencing to date which I always attributed to interpolation in the map itself, not the filter. It would make sense to me to switch filter to "100%" - no filtering.
« Last Edit: July 05, 2013, 07:26:28 AM by julex » Logged
phila_dot
Hero Member
*****

Karma: +157/-11
Online Online

Posts: 1704


« Reply #26 on: July 05, 2013, 08:30:55 AM »

Ecu cycle

This occurs everytime the code is run. The output filtered value is adjusted towards the input desired value whethers it's toward enrichment or enleanment.

Yes, this is applied at the end of LAMFAW and will effect desired lambda from the entire function.
Logged
phila_dot
Hero Member
*****

Karma: +157/-11
Online Online

Posts: 1704


« Reply #27 on: July 05, 2013, 08:50:56 AM »

Ok, so I'm slightly an idiot.

It will take alot more ECU cycles because it recalculates everytime.

So with ZKLAMFAW set to 50%, enriching from lambda 1 to 0.80:

1st cycle  : lamfa_w - 0.90
2nd cycle : lamfa_w - 0.85
3rd cycle : lamfa_w - 0.825
4th cycle .....

Logged
phila_dot
Hero Member
*****

Karma: +157/-11
Online Online

Posts: 1704


« Reply #28 on: July 05, 2013, 09:27:49 AM »

I should add that I was also running DLAMFAW at 0.008 to get back to lambda 1 and closed loop faster, but that might not be necessary if you FFFF ZKLAMFAW.
Logged
nyet
Administrator
Hero Member
*****

Karma: +417/-48
Offline Offline

Posts: 9253


WWW
« Reply #29 on: July 09, 2013, 09:51:41 PM »

BTW i don't see that anybody posted the ME7.1 m-box location... i am using 0x1c3ee (hopefully I have it right)
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.
Pages: 1 [2] 3
  Print  
 
Jump to:  

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