Yet another mapped points question

[junits15]

So if I'm understanding this right:

As long as we don't add any additional air the torque model relationship still holds. The actual output torque of the engine may be different from what the model is saying, but the discrepancy will not effect throttle position as the load will be right.


When we add extra air, the discrepancy in the torque model will cause a throttle position to be commanded which will result in an unexpectedly high load. That causes the error.

[engineermike]

I think you want your torque model to be fairly accurate. Things like traction control and shift torque modulation won’t work right (or at all) if the engine is making more crank torque than the logic is aware of.

[junits15]

And the only way to do that is with a dyno, correct?

[murfie]

So if I'm understanding this right:

As long as we don't add any additional air the torque model relationship still holds. The actual output torque of the engine may be different from what the model is saying, but the discrepancy will not effect throttle position as the load will be right.


When we add extra air, the discrepancy in the torque model will cause a throttle position to be commanded which will result in an unexpectedly high load. That causes the error.

Load comes from the MAF sensor, the engines RPM, the number of cylinders, and the cylinders air mass at STP/ corrected for actual baro and temp. For cars with MAP sensors its slightly different and depends on the speed density.

The torque to load model is for specifically stoich, MBT spark,and cylinder airmass at STP. No you can't come up with it from a dyno. A dyno might give you an idea of what to set your driver demand too, but even that is more appropriatly set to what the ECU is calculating the engine torque output as. Manual cars are slightly different than auto cars in this because of the Torque convertor slip and torque transfer to the rear wheels.

So again, it depends on which "load" you are talking about. The actual air load changes day to day with the weather. The entire purpose of the TTL model is to have a consistent enough model that a plausability check can be used. Dangerous situations like a stuck throttle can then be determined and acted upon.

Lots over look the baro correction, and it leads to wacky TTL models and poor throttle control in boosted applications. Espeacially when the ECU inffers the Baro from the throttle body model. Using a copy of roush or whipples TTL model is very popular.

[RobCat030]

This is good to know, and for me its a useful clue in understanding the torque model. From what you're describing, it almost sounds like the absolute modeled torque value isn't important, more just that the torque and inverse tables cover the full range of loads you will see in operation?



I don't plan on re-enabling it, more just trying to understand the rationale behind turning it off. What did they gain by disabling that logic? At least for now, I'm planning on leaving the OP cam path (as I have been calling it) stock, so maybe as a learning tool the OP tables could prove useful. thoughts?

Just to qualify my statement, I think it's good if you can make the torque model accurately reflect the actual torque the car is making. It just doesn't seem to directly backfire on you (ie. Throttle closing) as long as there's a plausible correlation. Using a torque-based shifting model with an automatic also makes that important. Almost every OEM torque model I've seen has a 100% quadratic fit (although many are 99.9% linear as well). A dyno can be useful for ball parking a torque model when you've scaled the load and torque far beyond the factory tune, but what I do is take the dyno values on a scatter plot and generate a polynomial (inspired by Murfie's method of looking at speed density).

[junits15]

At times the, part throttle mostly, the throttle body model and the driver demand table agree on the airflow.
At times, WOT, its beneficial to allow them to vary. Boosted OEM cars, usually they are calibrated not to vary as the TB model will have an inlet pressure sensor instead of assuming constant barometric pressure.
At other times, Idle, the throttle body model is in sonic flow and the model isn't accurate so the engine is controlled mainly by the driver demand and torque to load model. The torue to load and load to torque model is used at all times.This definitely falls into what we are discussing with mapped points weight being the physical cam positions, and snap to lines and points tring to make calculations simpler.

Its confusing because it is complex with the numerous feedback loops and feedforward models. Definitely can be a can of worms because it varys with what you are talking about. Theres three "Torques" you want to familiarize your self with. Scheduled/ indicated torque(TTL/LTT model), Driver demand/ ETC torque(Driver demand table/ throttle body model), and Engine brake torque(calculated based on actual conditions).

The indicated/ scheduled torque is directly controlled by the driver demand/ ETC torque. It is indirectly controlled by the ECU controlling the engine brake torque (like idle, traction control, IPC and other limits).
Unless you are in one of these indirect situations, your goal should be to make engine brake torque equal driver demand. Just like des MAF = MAF sensor. And everything in between including cam actual and desired. The less the system has to fight to correct error, the more "tuned" it is and the better things will perform.

Attachment 131591

This picture shows how it takes the engine brake torque(calculated via driver demand/ throttle body model) and determines the desired airflow through the MAF.
It may not be exactly like this, but very close.

Load comes from the MAF sensor, the engines RPM, the number of cylinders, and the cylinders air mass at STP/ corrected for actual baro and temp. For cars with MAP sensors its slightly different and depends on the speed density.

The torque to load model is for specifically stoich, MBT spark,and cylinder airmass at STP. No you can't come up with it from a dyno. A dyno might give you an idea of what to set your driver demand too, but even that is more appropriatly set to what the ECU is calculating the engine torque output as. Manual cars are slightly different than auto cars in this because of the Torque convertor slip and torque transfer to the rear wheels.

So again, it depends on which "load" you are talking about. The actual air load changes day to day with the weather. The entire purpose of the TTL model is to have a consistent enough model that a plausability check can be used. Dangerous situations like a stuck throttle can then be determined and acted upon.

Lots over look the baro correction, and it leads to wacky TTL models and poor throttle control in boosted applications. Espeacially when the ECU inffers the Baro from the throttle body model. Using a copy of roush or whipples TTL model is very popular.

Ok so these replies have been very insightful, I've added some torque parameters to my log and pulled some to see if I can work it out. From your explanation the three torques are:

Scheduled - the torque from the model in the tune, ideal torque at MBT and stoich, this is like a mapping of the engine's abilities
Driver demand - this is how much torque the driver is requesting and it is used to call on a scheduled torque, the tune factors in losses.
Engine brake - the estimated output torque of the engine, should match scheduled assuming the model is good

Driver demand -> scheduled which is compared to engine brake torque.

In general this is a way to link engine output torque to a load, since load is linked to throttle position, I command a torque, the ECM calculates what torque we need to hit what I request, then commands a throttle angle to achieve the right engine load to generate the requested torque. The critical part is the model that links torques and loads together.

From this it sounds like I don't need to change the scheduled torque tables, since I'm NA, and the tables are at MBT and stoich, as long as I don't change the MBT timing that mapping will cover anything I could do without adding a blower.

Is that right?

Just to qualify my statement, I think it's good if you can make the torque model accurately reflect the actual torque the car is making. It just doesn't seem to directly backfire on you (ie. Throttle closing) as long as there's a plausible correlation. Using a torque-based shifting model with an automatic also makes that important. Almost every OEM torque model I've seen has a 100% quadratic fit (although many are 99.9% linear as well). A dyno can be useful for ball parking a torque model when you've scaled the load and torque far beyond the factory tune, but what I do is take the dyno values on a scatter plot and generate a polynomial (inspired by Murfie's method of looking at speed density).

This is good to know, at least it wont explode on me lol

[junits15]

Is there any need to change anything in the torque model at all? It seems like since the mapping covers all the way to MBT and 1.1 load, if you don't go beyond either of those two things, the stock torque model should be adequate.

No?

The scheduled model is good for anything up to MBT and 1.1 load
Driver demand already asks for more than the engine can generate
Engine brake torque is calculated


What needs to be changed on an NA tune?