gemellocattivo.com

Which means "Evil Twin". Lets see your projects where you change boring into fun or create the fun from scratch.
It is currently Thu Mar 28, 2024 9:05 am

All times are UTC - 5 hours [ DST ]




Post new topic Reply to topic  [ 16 posts ]  Go to page Previous  1, 2
Author Message
 Post subject: Re: Load sense method(s)
PostPosted: Mon Oct 12, 2015 3:25 pm 
Offline

Joined: Thu Jan 01, 2015 6:47 pm
Posts: 4251
apalrd wrote:
With ETC, the driver request isn't tied to what the engine is actually doing, so we needed to split the driver intent off from the engine load. Once we did that, using the split load method on mechanical throttle engines made a lot of sense and we did it there too.

We actually have transient enrichments twice. One is charge based (x-tau) and one is pedal load based. The charge based enrichment is calibrated to hold a fixed AFR through engine transients. The other is calibrated to add or subtract AFR target during pedal transients as ETC catches up. This is done so we can dune charge based enrichment once for the engine, and tune pedal enrichment several times in different eco modes (for better fuel economy or performance). Eco cals don't enrich at all, and we even dampen the throttle response intentionally for them.



I can understand damping throttle opening response in ECO mode and having user selectable performance and eco AFR tables but I'm having trouble understanding why your Driver intent is not complete captured in a load v rpm AFR table(s)?

I'll need to ponder this a bit......


Top
 Profile Send private message  
 
 Post subject: Re: Load sense method(s)
PostPosted: Mon Oct 12, 2015 5:28 pm 
Offline

Joined: Sun Oct 11, 2015 2:07 pm
Posts: 134
mk e wrote:
I can understand damping throttle opening response in ECO mode and having user selectable performance and eco AFR tables but I'm having trouble understanding why your Driver intent is not complete captured in a load v rpm AFR table(s)?

I'll need to ponder this a bit......


If we take Charge or MAP as Load, then it is possible that Charge does not follow driver intent with a turbo as boost builds - Charge will be low until boost catches up, but we would prefer to go rich before this happens (we target a gas equivalent AFR of about 17-18 under almost all conditions, including map=baro for turbo engines). So the target fuel/air table is based on driver load. This is much more important on more heavily boosted engines which could be cruising at map=baro or more, and that run very lean. A slightly unfortunate side effect is that the spark code needs to take target AFR into account now.

Driver load also drives:
-Decel fuel shutoff (when driver load goes less than about 3% we trigger DFSO if the RPM/speed conditions are met)
-One cylinder mode - Below about 10% driver load at low RPM (especially idle)
-Tip-in enrichment - Targeting a richer/leaner AFR based on rate of change of driver load
-ETC position - Driver load determines (indirectly) ETC position
-Power-off spark - Forces spark to be retarded above idle RPM below 3% driver load - This is used to control vehicle creep

Driver load is also guaranteed to be between 0 and 100 % and the relative values don't change with RPM like MAP or Charge would.

_________________
"Sometimes, the elegant implementation is a function. Not a method. Not a class. Not a framework. Just a function." ~ John Carmack

"Any sufficiently advanced technology is indistinguishable from magic" ~Arthur C. Clarke


Top
 Profile Send private message  
 
 Post subject: Re: Load sense method(s)
PostPosted: Mon Oct 12, 2015 9:57 pm 
Offline

Joined: Thu Jan 01, 2015 6:47 pm
Posts: 4251
apalrd wrote:
mk e wrote:


I'll need to ponder this a bit......


If we take Charge or MAP as Load,


After pondering a bit I've come to this. It's interesting how you've arranged things.

Load (MAP/Baro or TPS or a mixture of the 2) is independent of RPM, but "Charge" is a function of Load & RPM. Load & RPM are sufficient to fully characterize engine state because because they are independent of RPM.

Charge is a function of RPM so Charge v RPM can not fully characterize the engine state, so you've had to add TPS, which is independent to gain the missing information. What you have is a fully functional system and it sounds like you've got it working quite well....and with a turbo setup you normally need both MAP and TPS involved because you also have boost to think about which adds another dimension to things and MAP alone can't separate out turbo effects from driver input on the throttle.....interesting how you've split it up.


Top
 Profile Send private message  
 
 Post subject: Re: Load sense method(s)
PostPosted: Tue Oct 13, 2015 12:13 am 
Offline

Joined: Sun Oct 11, 2015 2:07 pm
Posts: 134
mk e wrote:
After pondering a bit I've come to this. It's interesting how you've arranged things.

Load (MAP/Baro or TPS or a mixture of the 2) is independent of RPM, but "Charge" is a function of Load & RPM. Load & RPM are sufficient to fully characterize engine state because because they are independent of RPM.

Charge is a function of RPM so Charge v RPM can not fully characterize the engine state, so you've had to add TPS, which is independent to gain the missing information. What you have is a fully functional system and it sounds like you've got it working quite well....and with a turbo setup you normally need both MAP and TPS involved because you also have boost to think about which adds another dimension to things and MAP alone can't separate out turbo effects from driver input on the throttle.....interesting how you've split it up.


It's always an interesting dance of what tables we need to and how easy they are to calibrate.

We based our design on an OEM system which we had access to. Since OEM systems run strict stoichiometric for emissions reasons, Charge and RPM alone are enough to fully characterize the engine. Whenever they enrich (which changes spark), they are at high load and hugging the knock limit with knock control so the exact values in the spark tables aren't as important. Charge also correlates really well to indicated torque (assuming MBT spark) which helps in torque modeling, and Charge can be used with other airflow models also based on the ideal gas law or nozzle flow equations.

Our first gen system was implemented exactly as the OEM system. We run very lean since fuel economy is prioritized more than emissions in our competition (sorta..) so we added a pair of fuel/air tables indexed by Charge and RPM, one for eco and one for performance. However, we had to manually copy cells between the tables in some regions and it was a PITA. The second gen system had a single charge-based lean limit table which defines the leanest the engine is allowed to run and a number of lower resolution driver demand tables. The idea is to make separate tables for engine characterization which are all charge-based and tables for driver intent which are all pedal-based. If we had functions which required it, we could insert software which produces a pedal-load from something other than a pedal, such as cruise control or traction control.

Once we split the software in half, it was much easier to go into the engine test cell and calibrate all of the engine surfaces with all 0's or 1's for the driver surfaces, then go into the vehicle and ride around and trim the driver surfaces without worrying about interactions to the engine or going out of the engine's operating range. There are some cases where we have overlapping tables but it all works very well in the end.

_________________
"Sometimes, the elegant implementation is a function. Not a method. Not a class. Not a framework. Just a function." ~ John Carmack

"Any sufficiently advanced technology is indistinguishable from magic" ~Arthur C. Clarke


Top
 Profile Send private message  
 
 Post subject: Re: Load sense method(s)
PostPosted: Tue Oct 13, 2015 10:29 am 
Offline

Joined: Thu Jan 01, 2015 6:47 pm
Posts: 4251
apalrd wrote:

It's always an interesting dance of what tables we need to and how easy they are to calibrate.


It's the how to calibrate it easily question that I drives most of my thoughts these days.

apalrd wrote:
We based our design on an OEM system which we had access to. Since OEM systems run strict stoichiometric for emissions reasons, Charge and RPM alone are enough to fully characterize the engine. Whenever they enrich (which changes spark), they are at high load and hugging the knock limit with knock control so the exact values in the spark tables aren't as important. Charge also correlates really well to indicated torque (assuming MBT spark) which helps in torque modeling, and Charge can be used with other airflow models also based on the ideal gas law or nozzle flow equations.


Charge makes great sense on an MAF based system since it matches the data type and probably where emissions are the primary concern......but I'm not sold that it makes good sense for ease of tuning or performance applications where high load and hugging the knock limit are the whole point. I'll need to think on it a bit more but I'm leaning away from it...but it might be handy to do something with it for traction control. More thinking.


Top
 Profile Send private message  
 
 Post subject: Re: Load sense method(s)
PostPosted: Fri Oct 16, 2015 7:34 am 
Offline

Joined: Thu Jan 01, 2015 6:47 pm
Posts: 4251
apalrd wrote:
We actually have transient enrichments twice. One is charge based (x-tau) and one is pedal load based.


Do you decay your x-tau based on time or engine cycles?

I've got it coded by engine cycles thinking the injector needs to spray for any change to occur but MoTec is using time.....which I think is because the code is based on their old deltaTPS enrichment scheme but....what are you guys doing?


Top
 Profile Send private message  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 16 posts ]  Go to page Previous  1, 2

All times are UTC - 5 hours [ DST ]


Who is online

Users browsing this forum: No registered users and 5 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Jump to:  
Powered by phpBB® Forum Software © phpBB Group