gemellocattivo.com

Today I think I got the stuff needed to turn a calculated grams of fuel into an injector time.

the simple approach is just:
time = grams /flow_rate + dead_time

...but then dead_time is a function of batery voltage and fuel proesure

and then dead time isn't really dead time its an imaginary intercept so short pulses endup wrong without a correction.

My first thought was copy motec! because they are usually right so no ned for me to reinvent the wheel, but as I got looking at what they've done it turns out they aren't right. They approach does a linear interpolation on the pressure axis with 1 bar pressure steps, but flow is a log function with pressure so that's not a very accurate system for pressure variation and eats up a lot of memory too....but injector dynamics has plug and play data for motec.......

hmmm they also have data for GM systems, lets see......much better! So I copied the GM system

There is a 1d flow vs differential pressure table 64 cells long so lots of resolution on the very non-linear pressure axis.

There is a 2d dead_time )offset) vs voltage vs differential pressure table to get the intercept right

Then there is a 1d "short pulse added" to make up the difference between the imaginary straight line and the actual injector curve. This is probably not exactly right as I'd expect voltage and differential pressure to effect the required additional time......but it's got to be pretty close.

I cut the size of the GM tables down a bit figuring anything over 15V or under 8V is not a car that should be running and I want most everything to work with o5e also whenever possible.

Now, for people who only have flow rate and maybe a dead time you can simply use all the same numbers in the table and set the added to 0 or replace the tables with simple constant inputs.

On to the hard part of actually calculating how much fuel is needed.

I've just given a very thorough read to the motec M1 manual for transient fuel corrections...it's fundamentally very similar to what I setup on the o5e project some years ago about but makes a few simplifying assumption and also adds a couple factors I didn't have. I'm thinking since theirs is tested and what I did isn't, I should probably start be just copying what they have.

Basically it's tracking fuel stored on the manifold walls at different manifold pressures and rpms and temperatures so it knows how much extra fuel is needed when you open the throttle of how much to remove when you close the throttle and fuel is condensing on the manifold walls of being stripped from them.

This is all quite a bugger to tune it looks like. The reason is you can't measure the fuel in the manifold directly.....so you need to test a lot of conditions while watching to a/f readout and then back calculate what must have come from or gone to the manifold. Below are a few screen shots from the M1 manual showing what's going on , how their system is setup and a before & after a/f changes when stomping on and letting off the throttle.....it works pretty well.

I'm also thinking I need to start writing down what everything is and way its there while its fresh in my mind or I'm going to have all kinds of trouble later...there is no way to add comments int eh enginelab files so I'll need a separate readme I guess.

Ok, raise your hands.....how many actually believed me when I said I'd just use something the way it was?


After pondering it a bit I've decided that like what I found in the motec injector flow vs fuel pressure correction, the accel/decel correction setup is not actually doing what they think it's doing and could use a little refinement as could what I did for my o5e project which I just took another look at this morning....time to mash them together!

.....after I finish creating at least basic notes on what I already have. I started working on this yesterday but still have a long way to go just to get all the variable names listed out and following consistent naming patterns which makes remembering the names SOOO much easier. The way this code works when I create say a coolant temp correction mini routine I need to know the coolant temp which was measured in a different mini routine so I say "extern:CLT [c]" and when the build script runs it knows to combine the the 2 mini routines.....unless I misspell the name, then it gets angry and tells me the variable is missing....so a list and a consistent naming method is pretty key as the program grows ever larger.

Progress continues. While going through and documenting the code I've found about 6 errors so it was well worth the effort.....hopefully I'll be done catching up and back to making progress today.

There are a couple little things I'm confused about though. I'm pretty sure the system uses "floats" meaning floating point decimal values that we're all used to seeing but they present some issues in software in the 1 in binary is EXACTLY 1 so I can say" if x=1...." and it will always work but with floats 1 might be 1.00000001 which is not equal to 1 and the if statement fails. There are a few places I need to go back and change x =1 to maybe x>0.9 AND x<1.1 or something like that so rounding errors don't matter.

There is a similar problem with enable/disable in entering the 1/0 value.....I don't want to just trust the user to enter 0 or 1 and not 1.23 or 1682 or whatever. I set a clamp in the code to only allow 0-1, but that still lets the user enter 1.5. I found I can use a slider on the user interface screen that is set to 0-1 with 1 steps to only allow the user to enter 0 or 1...but the user can add any control they please so I pondering how much I care that its not idiot proof.

Add coolant temp correction - check

I'm having a bit of a mental block on the accel/decel stuff and trying hard not to over complicate it.

I created routines to calculate the fuel error in grams between the set point and O2 reading in both banks.....this will be needed for closed loop control but once steady state is tuned it also tells me how much fuel must be going onto the port walls during accel or must be coming from the port walls during decel. Graphing Error, MAP, lambda should be the way accel/decel gets tuned.

I also created a table of stored fuel vs MAP & RPM. In theory this can be measured by cutting fuel to 1 bank, then turning the bank on and reading the Error...and this is where I'm stopped. Motec just uses this value as an offset but the actual fuel stored in the manifold is the total of the error over the time it takes to correct it and this is what I was saying about they aren't doing exactly what they appear to believe they are doing.....but what they are doing mostly works so I'm not sure how much effort to invest in doing something different.

I need to ponder this a bit more.

I made decision and started coding a bit today. I'm going to try total fuel stored vs load and rpm. I think it can be measured by shutting down a cylinder or 2 then switch it/them on and watching the lambda recovery. Motec talks about this to get an offset term for their system by shutting down a bank that they then add to another term you tune by snapping the throttle to the load point which sounds really hard so I think it makes more sense to combine them and just use a couple cylinders.

The plan is to simply track the stored fuel and let whatever the difference is between current and required drive the enrich/derich. In theory this means if you were to on/off/on/off/on.....the mixture would stay correct;.....if I can get it coded properly.

I finished coding this today and I THINK it will work. I still need to run it in simulation mode to be sure it's doing what I think it should be doing......and then on an actual engine but in my mind it works perfectly

You're doing this in an open loop mode, right? I would think the WBO2 response is way too slow to do this in closed loop.

Yes, open loop. I haven't even stared thinking about the closed loop control stuff yet.

I mentioned up in my build thread that enginelab is going to release a generic engine control model soon. They just started working on it and I'm lucky enough to be on the distribution list for input/feedback so I'll get to watch it shape up and hopefully get stuff I want on their to-do list, they've already signed up for the DBW stuff

Right now I'm trying to finish up my thoughts on fuel control so regardless of their timeline I'll be able to run an engine. I've shared my model with them and hopefully theirs will work in a similar way...but the system is very modular so things can be added/removed/changed pretty easily so swapping my whole fuel logic in would not be hard if needed.