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 Wed Jun 26, 2019 4:34 am

All times are UTC - 5 hours [ DST ]




Post new topic Reply to topic  [ 49 posts ]  Go to page Previous  1, 2, 3, 4, 5  Next
Author Message
 Post subject: Re: Injector control
PostPosted: Tue Mar 15, 2016 5:39 pm 
Offline

Joined: Thu Jan 01, 2015 6:47 pm
Posts: 2598
The math is simple so it consumes little processor time, the problem is tuning it though as there really is no way to separate the 2 factors, at least no way that has ever occurred to me. I assume that is what drove motec to go to a puddle volume???


Top
 Profile Send private message  
 
 Post subject: Re: Injector control
PostPosted: Tue Mar 15, 2016 7:38 pm 
Offline

Joined: Wed Jan 14, 2015 1:27 am
Posts: 166
Spit balling here as I did some research a couple yrs back on fluids and gas atomization with respect to triboelectro static charge effect on droplet size in varying manifold pressures. Fancy way of talking about high pressure flow thru orifices. So a couple things come to mind here, the variables that occur and how the real world is bitch to model when the variables are high, like with injector flow and varying pressures, not to mention the changing temps and property of the fuel itself. The mathematical models work OK if not only the injector flow is known but the droplet size and the distances for primary, secondary and final droplet sizes and atomization occur as that will also be useful in modeling the wall wetting and flow dispersion in the port. Though as I'm sure you can quickly note, that atomization cloud is going to vary a lot based on the RPM as the pressure pulses vary. Also highlights why things go to crap when injectors are clogged or dribbly, heck even changing them as a favorite past time with many a gear head alters all that tuning the OEM did.

A slick setup would be to have a program where one could input the data specific to the injector they are using to really hone in the tuning. But I surmise the scope of such a thing is larger then what you're looking to do. What about post fuel evap from wetting that contributes to the next cycle? That is also temp/pressure dependent as well.

If I had more time I'd probably sit and start to pencil out the equations for such a program to account for all those moving targets, but sometimes it's just easier to tune on the dyno and road and call it good.


Top
 Profile Send private message  
 
 Post subject: Re: Injector control
PostPosted: Thu Feb 15, 2018 11:29 am 
Offline

Joined: Thu Jan 01, 2015 6:47 pm
Posts: 2598
So I've been doing a kind of brute force technique to get control of the nonlinear region or the injectors.....but Jim added support for this to the most recent fw release so I guess it's time for me to get back into the fuel model and implement the new features. It's a pretty big rewrite for me so fingers crossed.....


Top
 Profile Send private message  
 
 Post subject: Re: Injector control
PostPosted: Wed Feb 21, 2018 9:44 am 
Offline

Joined: Thu Jan 01, 2015 6:47 pm
Posts: 2598
Not as easy as I'd hoped.....but I think I at least have a good plan now. More to come...


Top
 Profile Send private message  
 
 Post subject: Re: Injector control
PostPosted: Thu Feb 22, 2018 6:34 am 
Offline

Joined: Thu Jan 01, 2015 6:47 pm
Posts: 2598
So I mostly got this roughed out today....thinking more I'm quite certain it's not quite functional how I did it but its close.

What I was doing was calculating the fuel required in grams right up front and working in grams from then on. But the staged fuel function wants to make the grams calc along with the injection time calc and wants to be fed MAF and target lambda. Looking at it it wants to apply corrections to the MAF which I'm not a fan of but simple stuff like cylinder trim that's fine as there is no easy way to know where the error is coming from anyway, and it creates a global and cylinder trims too.

I moved all the % corrections to acting on the the target lambda value, that's easy. The wall wetting (acel/decel enrich/derich) is a bit harder....it was written as number of grams stored in the manifold and how many grams delivered/removed per cycle.....still not completely sure what to do with this.....


Top
 Profile Send private message  
 
 Post subject: Re: Injector control
PostPosted: Mon Feb 26, 2018 3:25 pm 
Offline

Joined: Sun Oct 11, 2015 2:07 pm
Posts: 122
I'd stick to grams as long as possible if you can.

Here's what I do for staged injection:
    1. Calculate the fuel mass desired into the cylinder total (from air mass * stoich F/A * target phi * warmup enrichment)
    2. Calculate the maximum pulse-width possible at the current RPM to maintain 80% duty on the injectors, then convert this into the maximum fuel mass request, this number may be different for each injector because the pressures may be different (in my case, one is after the ITB and one is before)
    3. Calculate the desired % to split to the upstream injector, with hysteresis so it will shut off the upstream below certain loads and switch it on again at higher loads
    4. Multiply the total fuel request by the split fraction (or zero if not splitting) and run this through the transient enrichment for the *upstream* injector. I use x-tau and have separate x and tau tables for the upstream and downstream. The transient model clips the mass it will request to the maximum fuel mass, and accounts for this limit in the puddle mass. It also calculate the actual mass delivered from the evaporation fuel and the clipped fuel request * (1-x).
    5. Subtract the actual mass delivered from the upstream by the mass requested, and use this as the request to the downstream. This is then run through x-tau again, for the downstream injector, to calc correct fueling even with switching on/off splitting. Normally I don't split until the split request is >20% (to avoid nonlinear pulses on the upstream).
    6. Convert both masses into working pulse widths, and schedule them in hardware. I told my ECU I have twice as many cylinders, and manually TDC-offset the upstreams to the TDC of their correct cylinder. I use the same injector model for both, so the curves are the same, but the downstream is calculated at manifold pressure and the upstream at throttle inlet pressure.

As for where to apply corrections, it's difficult to say. I have two separate sets of corrections, corrections on target phi, and corrections on evaporation. Target phi corrections multiply or add phi under certain cases (PdlDot-based tip-in torque for example) to add or subtract torque during transients while airflow catches up. Evaporation corrections account for fuel evaporation which does not show up as a change in phi (such as fuel not evaporating because it's cold). The difference is that target phi, after multipliers, should show up on the O2 sensor, while evaporation corrections should not. I also have a third set of corrections, VE corrections which modify airmass, based on O2 feedback, since measured fueling errors are assumed to be airflow errors.

_________________
"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: Injector control
PostPosted: Mon Feb 26, 2018 4:38 pm 
Offline

Joined: Thu Jan 01, 2015 6:47 pm
Posts: 2598
I don't actually need staged injection but there is a function called "Lambda Staged Fuel System". It didn't have the short pulse correction stuff so I ignored it until Jim asked why I was ignoring it and and promptly added the stuff I thought was missing. Using the function is quite a bit faster I'm told than programming the same thing in the model like I was doing so I figured it's a good time to convert over while I'm working on the garage and can't play with the car anyway.

But this is causing me to re-thing a few things. I was working in grams but the LSFS function wants to do that calculation right before converting to injector time...hmmmmm....why was I in grams anyway was the thought. For me it when back to the fuel stored in the intake which I track in grams becaseu I kind of liked the motec setup and mostly copied it.

But other stuff I'm not sure tracking in grams has any particular advantage. The main fuel table is lambda....then the corrections are % for ther most part to try to get O2 reading the target lambda, nothign to do with grams.

This also has me wondering if my coolant correction is right. I have a simple % from a table based on rpm and CLT. Simple...but now I'm wonderin if prehaps there aren't 2 parts to it. 1 bring fuel that doesn't vaporize so more is need to get the O2 to the target. 2 is a correction to the target. Clearly both can be done with a signle correction but the system can never monitor warmup and know what to do automatically if there are lies baked into the logic like it says lambda should be say 0.9 when it should really be 0.8 and a % correction is forcing a "wrong" value.

I'm really tempted to split warmup and maybe everything to keep the lambda targets and corrctions to get ot lambda targets separate......or maybe I'm over thinking it but that puts wall wetting (x-tua) into eht corrections to get to tartet but any desired shift in lambda during accel/decal somewhere else....like the target lambda table.


Top
 Profile Send private message  
 
 Post subject: Re: Injector control
PostPosted: Mon Feb 26, 2018 7:16 pm 
Offline

Joined: Sun Oct 11, 2015 2:07 pm
Posts: 122
In general, it's important to stick to mg as long as possible because corrections applied to mg are linear (i.e. if you say 60% of the fuel injected burns, you divide the mass by 0.6) where corrections applied to working pulse width are not if you are in the nonlinear region. Also, if you do multiple injections (i.e. closed-valve and open-valve at the same time) it's possible that both need separate nonlinear correction, but the total mass corrections should be the same. If you do end up with corrections 'baked in' to enrichment tables because of injector issues, then switching injectors will mess up everything.

I have generally used a single coolant temp enrichment table to capture both fuel evaporation and fuel enrichment, but since we now run a system where we must go closed-loop as soon as possible after starting, I split them so the phi control doesn't try to undo the fuel enrichment or compete with fuel evaporation. It's a much bigger issue with E85 since the evaporation is so low when the engine is cold (in some cases it's less than 20% when starting).

In theory, TPS-dot or PDL-dot based enrichment should affect phi since you are changing the commanded phi while the throttle/plenum catches up (so the torque request matches the torque demand sooner), while x-tau should be based on airflow and not change phi, since it's helping meet the commanded phi during airflow changes. Most engines do not need TPS-dot or PDL-dot enrichment to phi unless they have a large manifold, x-tau should keep phi correct without a TPS based modifier.

I know the EngineLab processor is pretty fast, but are you getting to a point where you're using a substantial amount of the CPU?

_________________
"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: Injector control
PostPosted: Tue Feb 27, 2018 10:46 am 
Offline

Joined: Thu Jan 01, 2015 6:47 pm
Posts: 2598
In my old model and the current version the conversion to time is the last step before firing the injector. The difference is in the old modle the first step was to convert to grams, now that is the 2nd ot last step because its part of the LSFS function. The inputs are MAF, lambda, trims(gobal and cylinder).

My thought now is that its best to play by the rules and use the system as its designed to be used. Right now I take the say 50% CLT correction and do 1/(1+50/100) the multiple by target lambda to get an "effective lambda", so I'm woring in lamdba until the last 2 calculations. A lot od division going on this way and I'm thinking I may not be doign myself any favors anyway.

My newer thought is to separate lambda so its always the number that I should see on the O2 sensor.....that is very easy to understand and work with while tuning. Then I have corrections which also are used to apply a correction to let the user get to the target lamba...so you adjust the corrections once then tune in lambda. The corrections can be applied as the last calculation to either the global trim or the very last lambda calculation, but I'm leaning to the trim at the moment since it gets rid of the nasty divisions.

Divisions are not so much a time issue as a divide by 0 opportunity which EL just HATES so I do an if=0 use .001 test at all divisions and it's just messy but it doesn't ever crash.

I am honestly not sure how I'm doing system time wise....and I need to sort that out. On the simulator I see thread times that male sense, but when I looked on the system they were very long. I asked and was told it's for debugging.....so also on my list is adding a thread time to the model that I control and see what the times are. I suspect the model based setup is not nearly as fast as c coding which is why I'm trying to use all the canned functions that are available.....but I'll know for sure the next time I work on the real he with the new model.


Top
 Profile Send private message  
 
 Post subject: Re: Injector control
PostPosted: Tue Feb 27, 2018 11:24 am 
Offline

Joined: Sun Oct 11, 2015 2:07 pm
Posts: 122
Not sure if you can do this, but one thing I can do is change the scaling of numbers in the calibration tool vs ECU. For example, I might set the calibration table for ECT burn fraction to be limited to a number between 0.05 and 1, but I might set it to have the equation e=u^1, so numbers get input into the ecu pre-divided and limited for div/0 (by the 0.05), but the tool takes care of it offline. I also use the Saturation block (or Min/Max) to avoid div/0 in some cases. I also have cases where I will multiply by 100, so it is 0-1 in ECU memory but 0-100% in the tool display. With this method I can multiply across all of the factors without adding and dividing by 100.

My model based setup has no time issues, but it gets autocoded to C by Simulink so it's just RTW/Embedded Coder inefficiency (and it's honestly really intelligent). Embedded Coder also 'inlines' everything, so it generates a single C function for each task rate. This translates into a single C function for essentially all of the engine control (at 5ms). I believe EngineLab runs a sort of virtual machine, although it might generate assembly for each block. In either case, I don't think it's optimizing across blocks. I think the EngineLab ECU has a 260Mhz TriCore (I can't remember if he said TriCore or Renesas?), so it should be about 3x faster than our 80Mhz PowerPC.

On a related note, I always use phi instead of lambda to avoid division, and because it doesn't need infinite dynamic range (I can clip it to 0-2 and use a fixed point integer type).

_________________
"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  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 49 posts ]  Go to page Previous  1, 2, 3, 4, 5  Next

All times are UTC - 5 hours [ DST ]


Who is online

Users browsing this forum: No registered users and 1 guest


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:  
cron
Powered by phpBB® Forum Software © phpBB Group