Perhaps someone can help me here...
I'm trying to work out what it is that turns the lambda control off above certain engine loads.
I've seen a few maps now that have lambda targets in the range of 14:1, but then the target all of a sudden drop to zero at say 10 - 16 PSI of MAP. I'm guessing the fact that the target is set to zero turns the closed loop control off at this point? I was kind of expecting to see a seperate control that would say "at X MAP turn off cll", or even a "percentage cll additive to make vs MAP" kind of thing.
Does having a straight ON / OFF make blending from closed loop to open loop coming under higher load tricky, or as this is usually covered by transient fuelling it's not a problem?
Cheers,
Tony
Closed loop lambda control
-
pat
- Syvecs Staff - Cleaner
- Posts: 356
- Joined: Fri May 23, 2008 10:23 am
- Location: Out there... somewhere
- Contact:
Re: Closed loop lambda control
Hiya Tony!
You are correct in identifying that zero means lambda control off. The interpolator is clever enough to realise it shouldn't be interpolating to zero, so your target lambda isn't affected by the drop to zero. The closed loop strategy uses some hysteresis to determine when to turn on and off. You need to get 75% of the way between a cell that has a target and one that is at zero, then it turns off. When you get back to 25% of the way it will re-enable. We could have had a separate table but it is either wasteful of memory (if you're storing 16 bit ints just to say "yay or nay"), or a little computationally intensive if you're using bit stuffing. It is far more elegant to define a table with lambda targets everywhere (since some applications DO use that) and then just a simple test to see if the target is real or not to en- or dis-able the closed loop. Hope that makes sense ?
I wouldn't recommend turning off closed loop half way into positive pressure, either run it all the time or turn it off just into positive pressure if you don't trust it. Don't forget that you can have different min/max corrections on full load and part load, so if you are nervous about letting it do its thing on full load and want to calm it down a little then you can
Hope this helps,
Pat.
You are correct in identifying that zero means lambda control off. The interpolator is clever enough to realise it shouldn't be interpolating to zero, so your target lambda isn't affected by the drop to zero. The closed loop strategy uses some hysteresis to determine when to turn on and off. You need to get 75% of the way between a cell that has a target and one that is at zero, then it turns off. When you get back to 25% of the way it will re-enable. We could have had a separate table but it is either wasteful of memory (if you're storing 16 bit ints just to say "yay or nay"), or a little computationally intensive if you're using bit stuffing. It is far more elegant to define a table with lambda targets everywhere (since some applications DO use that) and then just a simple test to see if the target is real or not to en- or dis-able the closed loop. Hope that makes sense ?
I wouldn't recommend turning off closed loop half way into positive pressure, either run it all the time or turn it off just into positive pressure if you don't trust it. Don't forget that you can have different min/max corrections on full load and part load, so if you are nervous about letting it do its thing on full load and want to calm it down a little then you can
Hope this helps,
Pat.
Re: Closed loop lambda control
Cheers Pat, that's spot on.
Further to this however, I'd like to set up a math channel in SView that tells me what the injector correction is being made by the cll control in ms.
This should be relatively easy to do (after all the calculation is shown in the help
) but the only thing that is scuppering me is that I can't log what the Corrections/Global Multiplier value being used is. Addmitedly in the cal file I'm looking at the multiplier is set to 1, but this might not always be the case.
Am I simply missing something?
Tony
Further to this however, I'd like to set up a math channel in SView that tells me what the injector correction is being made by the cll control in ms.
This should be relatively easy to do (after all the calculation is shown in the help
) but the only thing that is scuppering me is that I can't log what the Corrections/Global Multiplier value being used is. Addmitedly in the cal file I'm looking at the multiplier is set to 1, but this might not always be the case.Am I simply missing something?
Tony
-
pat
- Syvecs Staff - Cleaner
- Posts: 356
- Joined: Fri May 23, 2008 10:23 am
- Location: Out there... somewhere
- Contact:
Re: Closed loop lambda control
Hiya Tony!
You are indeed correct in stating that the global fuel multiplier is not loggable. This is somewhere between "trivial bug" and "feature", LOL. In essence you'de be logging a constant which seems both wasteful and pointless. You just look at the calibration to see what it is and then multiply by it to get your computed correction. I treat the Global Multiplier as a "get you started quickly" feature. On a new engine you can very quickly get the AFR to the point of the engine running an acceptable AFR. You can then multiply the entire fuel table by that value and reset it to 1. I try to ensure that it is always 1 on any calibrations I do.... but it has indeed caught me out in the past where I was thinking "why on earth is the pulse width so long/short ?" only to find the answer in the Global Multiplier It isn't displayed in the log or dashboard so it's not obvious. Perhaps we should add the option to log a constant, despite it being wasteful
The computed difference would simply be fuelBase1 * (fuelMltCll1 -1). I don't know why you'de need this since you could just used fuelBase * fuelMltCll1 but hey, as you say, it's easy enough to work out with a Math channel
Hope this helps,
Pat.
You are indeed correct in stating that the global fuel multiplier is not loggable. This is somewhere between "trivial bug" and "feature", LOL. In essence you'de be logging a constant which seems both wasteful and pointless. You just look at the calibration to see what it is and then multiply by it to get your computed correction. I treat the Global Multiplier as a "get you started quickly" feature. On a new engine you can very quickly get the AFR to the point of the engine running an acceptable AFR. You can then multiply the entire fuel table by that value and reset it to 1. I try to ensure that it is always 1 on any calibrations I do.... but it has indeed caught me out in the past where I was thinking "why on earth is the pulse width so long/short ?" only to find the answer in the Global Multiplier
It isn't displayed in the log or dashboard so it's not obvious. Perhaps we should add the option to log a constant, despite it being wasteful The computed difference would simply be fuelBase1 * (fuelMltCll1 -1). I don't know why you'de need this since you could just used fuelBase * fuelMltCll1 but hey, as you say, it's easy enough to work out with a Math channel
Hope this helps,
Pat.
Re: Closed loop lambda control
Cheers Pat. Wasn't sure if I was missing a trick!
In order to calculate the injector time I think I would use the following:
(fuelBase1*1*fuelMltLoad1*fuelMltEct1*fuelMltAct1*fuelMltBap*fuelMltCalSw*fuelMltCll1)-(fuelBase1*1*fuelMltLoad1*fuelMltEct1*fuelMltAct1*fuelMltBap*fuelMltCalSw)
The values in red are the constants that I've checked on the cal file.
This would tell me how many ms of injector time the cll is adding. In theory I should be able to use this to directly trim fuelbase1 so the cll doesn't have to work so hard.
Also, I'm struggling to get the same value of fuelFinalPri1 and calculated pulse width though. I've copied the calc from the help file in Scal. However I think I'm missing a variable somewhere, or the multiplication in/out of brackets is not quite right...
(fuelBase1*1*fuelMltLoad1*fuelMltEct1*fuelMltAct1*fuelMltBap*fuelMltCalSw*fuelMltCll1+fuelAddN2o*trqFuelMlt+fuelAddTfc1*1*1*fuelMltRelFp1+fuelAddVbatPri)*(1-1+fuelAddVbatPri)
The value I'm getting is about 0.6 times the fuelFinalPri1 value. The only value that is in that region is the 360 sync multiplier, but the sync state is showing as 720.
Lastly, how do I delete a math channel once it's been created?
Thanks in advance!
In order to calculate the injector time I think I would use the following:
(fuelBase1*1*fuelMltLoad1*fuelMltEct1*fuelMltAct1*fuelMltBap*fuelMltCalSw*fuelMltCll1)-(fuelBase1*1*fuelMltLoad1*fuelMltEct1*fuelMltAct1*fuelMltBap*fuelMltCalSw)
The values in red are the constants that I've checked on the cal file.
This would tell me how many ms of injector time the cll is adding. In theory I should be able to use this to directly trim fuelbase1 so the cll doesn't have to work so hard.
Also, I'm struggling to get the same value of fuelFinalPri1 and calculated pulse width though. I've copied the calc from the help file in Scal. However I think I'm missing a variable somewhere, or the multiplication in/out of brackets is not quite right...
(fuelBase1*1*fuelMltLoad1*fuelMltEct1*fuelMltAct1*fuelMltBap*fuelMltCalSw*fuelMltCll1+fuelAddN2o*trqFuelMlt+fuelAddTfc1*1*1*fuelMltRelFp1+fuelAddVbatPri)*(1-1+fuelAddVbatPri)
The value I'm getting is about 0.6 times the fuelFinalPri1 value. The only value that is in that region is the 360 sync multiplier, but the sync state is showing as 720.
Lastly, how do I delete a math channel once it's been created?
Thanks in advance!
-
pat
- Syvecs Staff - Cleaner
- Posts: 356
- Joined: Fri May 23, 2008 10:23 am
- Location: Out there... somewhere
- Contact:
Re: Closed loop lambda control
Hiya Tony!
According to the online help :
fuelFinalPri1 =
((((( fuelBase1
* Global Multiplier
* fuelMltLoad1
* fuelMltEct1
* fuelMltAct1
* fuelMltBap
* fuelMltCalSw )
+ fuelAddN2o )
* fuelMltCll1
* trqFuelMlt )
+ fuelAddTfc1 )
* Cylinder Trim Multiplier
* 360 Sync Multiplier [if in 360 sync]
* fuelMltRelFp1
* (1-fuelSplit1) )
+ fuelAddVbatPri
This may need amending because a few firmware versions ago, fuelAddTfc was subjected to multiplication by at least fuelMltEct1, and the above still reflects the old way where it got added after ECT compensation. I will need to check whether it is subject to things like ACT as well, this will determine where in that list it belongs.
You'de obviously need to reverse the above sequence to find what the actual addition from the CLL is at any given point, BUT considering that most of the multipliers should be close to 1.00 when the engine is up to temp and being driven around "normally", it should be pretty safe to just go with fuelBase1 * (1-fuelMltCll1).
If you're getting 0.6 times fuelBase then your maths has gone a bit wrong, LOL. The 360 sync multiplier is used when the ECU is in 360 sync. Twice as many injection events will occur since it is in batch fire, this will correct the pulse width for the fact there are more pulses. Typically it will be around 0.576 or thereabouts. You should be in 720 sync, so don't worry about this bit
Deletion of math channels is less than obvious. Open the Math menu, scroll down to the function you want to delete with the cursor keys (using the mouse would select it, which is not what you want!) and then hit delete on the keyboard. Like I said, less than obvious but easy enough
Hope this helps,
Pat.
According to the online help :
fuelFinalPri1 =
((((( fuelBase1
* Global Multiplier
* fuelMltLoad1
* fuelMltEct1
* fuelMltAct1
* fuelMltBap
* fuelMltCalSw )
+ fuelAddN2o )
* fuelMltCll1
* trqFuelMlt )
+ fuelAddTfc1 )
* Cylinder Trim Multiplier
* 360 Sync Multiplier [if in 360 sync]
* fuelMltRelFp1
* (1-fuelSplit1) )
+ fuelAddVbatPri
This may need amending because a few firmware versions ago, fuelAddTfc was subjected to multiplication by at least fuelMltEct1, and the above still reflects the old way where it got added after ECT compensation. I will need to check whether it is subject to things like ACT as well, this will determine where in that list it belongs.
You'de obviously need to reverse the above sequence to find what the actual addition from the CLL is at any given point, BUT considering that most of the multipliers should be close to 1.00 when the engine is up to temp and being driven around "normally", it should be pretty safe to just go with fuelBase1 * (1-fuelMltCll1).
If you're getting 0.6 times fuelBase then your maths has gone a bit wrong, LOL. The 360 sync multiplier is used when the ECU is in 360 sync. Twice as many injection events will occur since it is in batch fire, this will correct the pulse width for the fact there are more pulses. Typically it will be around 0.576 or thereabouts. You should be in 720 sync, so don't worry about this bit
Deletion of math channels is less than obvious. Open the Math menu, scroll down to the function you want to delete with the cursor keys (using the mouse would select it, which is not what you want!) and then hit delete on the keyboard. Like I said, less than obvious but easy enough
Hope this helps,
Pat.