TQ Req. Lean at WOT

[CCS86]

Does anyone know why the PCM would do this?

This is on a 2017 and I have never seen this behavior on earlier model Coyotes.

WOT TQ REQ Lean2.jpg

You can see that when it hits this fuel source, the STFTs go offline, and the injector PW becomes very erratic.

I can see that I hit a TRANS TRUNC just before this and am working on that. But, the torque source returns to DRIVER DEMAND before the fuel source change.

Log section attached also.

[engineermike]

I don’t have hpt in front of me, so what’s your fuel TR table look like?

I’ve seen this as well on a Whipple 2018. I assumed it was using enleanment for torque reduction. I’ve changed my fuel TR table to all 1.0 and even changed the enleanment settings to ensure it doesn’t inadvertently run lean at wot.

[CCS86]

I don’t have hpt in front of me, so what’s your fuel TR table look like?

I’ve seen this as well on a Whipple 2018. I assumed it was using enleanment for torque reduction. I’ve changed my fuel TR table to all 1.0 and even changed the enleanment settings to ensure it doesn’t inadvertently run lean at wot.

This guy?

[ECM] 44169 - Cylinder Cutoff Lambda To Achieve Desired Torque Reduction

I haven't changed those values yet, but I think you are right. Those lambda values of 1.10 are what is being commanded. As a worst case, I could just set them to my desired WOT EQ of around 0.78. Setting them all to 1.0 wouldn't help too much because I definitely don't want to run stoich at WOT under boost.

I'll take another pass at removing the attempt to reduce torque via mixture first. Thanks!

[atakdefense]

I'm actually having the same problem on a gen 3, but I get fuel source TQ Req Lean immediately off of idle. Subbed

[engineermike]

No, I'm talking about table 44775. It should all be 1.0 to prevent enleanment torque reduction. But...check out 44170 for min lambda for enleanment TR. If you check out the GT500 cal you can see that even though enleanment shouldn't be allowed due to 44775, they still reduced it to .75 in boost *just in case*. I followed suit. And finally, if table 44585 is set up correctly, it shouldn't hurt it even if it does go lean. Keep in mind some ecoboost motors run 1.0 lambda at WOT and are perfectly safe doing it due to the lambda timing retard.

[CCS86]

No, I'm talking about table 44775. It should all be 1.0 to prevent enleanment torque reduction. But...check out 44170 for min lambda for enleanment TR. If you check out the GT500 cal you can see that even though enleanment shouldn't be allowed due to 44775, they still reduced it to .75 in boost *just in case*. I followed suit. And finally, if table 44585 is set up correctly, it shouldn't hurt it even if it does go lean. Keep in mind some ecoboost motors run 1.0 lambda at WOT and are perfectly safe doing it due to the lambda timing retard.

Gotcha. Those values were already all set to 1. Having them set below 1 would allow some amount of actual fuel enleanment before injector cutting takes place. Since they are set to 1, we go straight to injector cut. Which is why we see the commanded EQ go to 1.1, as defined here:

[ECM] 44169 - Cylinder Cutoff Lambda To Achieve Desired Torque Reduction

Setting those values to say ~0.75 in an attempt to maintain good WOT fueling under boost worries me though, because this could mess up DFSO based on Steven's description below:

Attachment 73154

If your desired reduction via fuel methods is GREATER than this value, it attempts to use A/F enleanment to reduce torque, using the vehicles calibrated A/F Ratio to Torque multiplier. Typically the authority you have here is only a few percent so enleanment is rarely enough on its own. Any left over reduction will need to be satisfied by cutting 1 or more injectors. I recently updated the description of this table to clear up something the old description led people to believe: Fuel cut may not be avoidable even if you set this to 0, because enleanment and spark can only do so much.

Most factory calibrations you will notice have the fuel cut torque ratio set to 1.0, meaning any kind of of fuel torque reduction must happen with injector cutout only.

This should make it pretty obvious how somethings like DFSO work. DFSO calculates its own torque ratio that it ramps (using the ramp on rate variable) down. Above 0.75 torque ratio, its using spark only. Below that it starts cutting injectors until ultimately you're at 0 Torque Ratio and all injectors are cut. This is part of what makes DFSO a smooth operation, as the TR continually decreases, the engine pulls power first with just simple spark, and then 1 injector, 2 injectors, etc.

As well, I should note some things do have special bypasses around this logic. I.e. Engine Speed Limit. Spark only set at 0 would lead you to believe it isn't allowed to cut fuel (Spark only!), but it bypasses this requirement. Fuel cut for engine speed limiting for example is always a possibility, no values you put in will make it use just spark or enleanment, etc. If your RPM goes over the fuel cut limit, it happens regardless.

Hopefully that clears up how you can set these tables up to achieve what you want.

[CCS86]

Are these types of corrections governed by:

[ECM] 3334 - CLIP/ADD Switch: Master switch that controls the Closed Loop Intervention Prevention (CLIP) and Adaptive Driver Demand (ADD) logic.

Or is that a separate monitoring system?

[engineermike]

I thought clip/add were a torque feedback loop that is generally disabled on the new stuff. The newer stuff just has an airflow feedback loop, not torque.

[engineermike]

Setting those values to say ~0.75 in an attempt to maintain good WOT fueling under boost worries me though, because this could mess up DFSO based on Steven's description below:

There shouldn’t be a reason to change the TR enleanment lookup table because it shouldn’t be used to begin with. Even still, I changed the combustion stability limit table because a) it’s a function of load and I only want to prevent enleanment at high load, and b) the gt500 is already done that way so ford gave us an example to go by.

[CCS86]

I thought clip/add were a torque feedback loop that is generally disabled on the new stuff. The newer stuff just has an airflow feedback loop, not torque.

This factory file was set to "ADAPTIVE". What do you mean by newer stuff being airflow, not torque? Everything still seems to revolve around torque: "desired torque", "torque ratio", "ETC torque". From there is converts torque into airflow with other tables, but everything seems to start as torque.

There shouldn’t be a reason to change the TR enleanment lookup table because it shouldn’t be used to begin with. Even still, I changed the combustion stability limit table because a) it’s a function of load and I only want to prevent enleanment at high load, and b) the gt500 is already done that way so ford gave us an example to go by.

Did you notice this note about that table and change the cat protection lambda too?

[ECM] 44169 - Cylinder Cutoff Lambda To Achieve Desired Torque Reduction: This is the commanded lambda translation based on the desired torque reduction ratio. It is used when torque control requires fuel enleanment to reduce torque. It will be used only if lower than all other lambda targets, and higher than the catalyst protection lambda limit.

[engineermike]

My understanding was that clip/add was *feedback* torque control. In other words the torque request will be modulated to correct brake torque if it’s not the same as driver torque request. I thought newer cals disabled the torque feedback and rather modulate airflow such that the throttle is modulated to make the MAF reading match desired airflow. Could be wrong. The whole strategy still revolves around torque though. It’s just which is on the pid feedback loop; torque or airflow?

On the torque control lambda, do you interpret lower as richer?

[CCS86]

My understanding was that clip/add was *feedback* torque control. In other words the torque request will be modulated to correct brake torque if it’s not the same as driver torque request. I thought newer cals disabled the torque feedback and rather modulate airflow such that the throttle is modulated to make the MAF reading match desired airflow. Could be wrong. The whole strategy still revolves around torque though. It’s just which is on the pid feedback loop; torque or airflow?

Isn't all this stuff "feedback torque control"? If delivered torque is higher than commanded, it uses spark, then AFR, then injector cut to reduce it.

I think there is really only a torque PID loop. Airflow is just a conversion step to allow control of the loop. If there was actually a PID control on airflow, you would never have steady-state mismatch of DESIRED MAF and ACTUAL MAF, which is very common.

On the torque control lambda, do you interpret lower as richer?

That was my interpretation. Of course, it is possible that this description is wrong. Maybe even likely since the GT500 values would be "non-functional" by that restriction.

[engineermike]

Ok, I think I see the issue. The clip/add stuff isn't even defined in the gen3 strategy. I've never seen any indication in logs that it's active. However, I have verified numerous times that the feedback on throttle angle works. In fact, in order to calibrate the TB model, I have to disable the PID control because it will hide the error. In the cases where you saw steady state airflow mis-match error it was simply outside of the somewhat narrow span of control. When airflow feedback is active, my actual and desired airflow match extremely well.

[engineermike]

And if in "It will be used only if lower than all other lambda targets, and higher than the catalyst protection lambda limit", lower means richer, then they are saying if the enleanment torque reduction lambda is *richer* than all other lambda targets, and *leaner* than catalyst protection lambda, then that would make no sense because you'd never want it leaner than cat protect lambda. The wording makes it more confusing than it needs to be.

[CCS86]

My understanding was that clip/add was *feedback* torque control. In other words the torque request will be modulated to correct brake torque if it’s not the same as driver torque request. I thought newer cals disabled the torque feedback and rather modulate airflow such that the throttle is modulated to make the MAF reading match desired airflow. Could be wrong. The whole strategy still revolves around torque though. It’s just which is on the pid feedback loop; torque or airflow?

Isn't all this stuff "feedback torque control"? If delivered torque is higher than commanded, it uses spark, then AFR, then injector cut to reduce it.

I think there is really only a torque PID loop. Airflow is just a conversion step to allow control of the loop. If there was actually a PID control on airflow, you would never have steady-state mismatch of DESIRED MAF and ACTUAL MAF, which is very common.

On the torque control lambda, do you interpret lower as richer?

That was my interpretation. Of course, it is possible that this description is wrong. Maybe even likely since the GT500 values would be "non-functional" by that restriction.

[engineermike]

Isn't all this stuff "feedback torque control"? If delivered torque is higher than commanded, it uses spark, then AFR, then injector cut to reduce it.

I think we're talking about two different things. There's the SAI torque reduction system that you are referring to, but I do not think the SAI system activates if the torque is simply more than driver demand. I believe the SAI system only works when torque reductions such as shift torque, traction control, deceleration, etc. are active, not driver demand.

I think there is really only a torque PID loop. Airflow is just a conversion step to allow control of the loop. If there was actually a PID control on airflow, you would never have steady-state mismatch of DESIRED MAF and ACTUAL MAF, which is very common.

I'm 100% certain there is an airflow PID loop, at least on the Gen3. Turning it off is the only way I was able to calibrate the TB model. I've observed des airflow vs MAF near-exact match with the PID loop on, then a steady-state error with it off. This has been repeatable on 3 different cars. The steady-state mismatch you mention could be due to a poorly calibrated TB model combined with not-enough span of control of the PID loop (there are limits). Or perhaps the Gen2 logic is different.

hat was my interpretation. Of course, it is possible that this description is wrong. Maybe even likely since the GT500 values would be "non-functional" by that restriction.

After typing all this up, I realized this appears to be a double-post.

At any rate, if it were to say "It will be used only if *leaner* than all other lambda targets, and *richer* than the catalyst protection lambda limit" makes way more sense. The GT500 layer of protection also adds up with a .75 limit. It will basically sandwich the lambda between COT lambda and .75 if somehow enleanment were mistakenly commanded.

[CCS86]

I think we're talking about two different things. There's the SAI torque reduction system that you are referring to, but I do not think the SAI system activates if the torque is simply more than driver demand. I believe the SAI system only works when torque reductions such as shift torque, traction control, deceleration, etc. are active, not driver demand.


I'm 100% certain there is an airflow PID loop, at least on the Gen3. Turning it off is the only way I was able to calibrate the TB model. I've observed des airflow vs MAF near-exact match with the PID loop on, then a steady-state error with it off. This has been repeatable on 3 different cars. The steady-state mismatch you mention could be due to a poorly calibrated TB model combined with not-enough span of control of the PID loop (there are limits). Or perhaps the Gen2 logic is different.

I would agree with that. I think SAI also kicks in when IPC TQ error is too high (and not in a nice way).

Interesting. I have only tuned Gen1 and Gen2 so far, and they definitely don't have PID control there. I'm looking forward to working with a Gen3 at some point.