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 12:44 pm

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: Fri Oct 02, 2015 6:06 pm 
Offline

Joined: Thu Jan 01, 2015 6:47 pm
Posts: 4251
mk e wrote:
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 :)


I realized on the drive home it would not work....one more thing then it should work. I wish I had an engine siting on a dyno to just plug in and play with.


Top
 Profile Send private message  
 
 Post subject: Re: Injector control
PostPosted: Fri Oct 16, 2015 8:36 am 
Offline

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

I realized on the drive home it would not work....one more thing then it should work. I wish I had an engine siting on a dyno to just plug in and play with.


I've started running it in enginelab's simulation mode and found a lot of things that I buggered up....most of which are now fixed....counters that didn't count because a function doesn't work the way I thought it did and stuff like that mostly.

But then other stuff like I had a cranking enrichment and a post start enrichment.....that I realized could product a a discontinuity in mixture when it goes from cranking to running so I combined them into a single function.

Right now I'm work on the wall-wetting (x-tau) stuff some more.... I need to build in something that tells it when it's close enough and it should stop trying to help. Not hard but something it needs.


Top
 Profile Send private message  
 
 Post subject: Re: Injector control
PostPosted: Fri Oct 16, 2015 8:53 am 
Offline

Joined: Sun Oct 11, 2015 2:07 pm
Posts: 134
We don't have any cranking enrichment per se (we have a separate crank fuel table and after-start enrichment is handled by a coolant temp modifier). This will probably change in a future revision because the after-start isn't very good. OEM uses accumulated charge (total grams of air into engine since start) by ECT in a surface to determine after-start enrichment. OEM puddle also counts the fuel injected during cranking so puddle is active right off starting and is quite accurate (it has to hold open-loop to a roughly 1 AFR window until the O2 sensor is hot)

We don't do anything based on time, it's all based on engine cycles. We based our code on a MotoHawk example, which used engine MAF as the input. Since they rearranged their website I can't find that download any more. It calculates the mass of fuel in the puddle as a state variable. We aren't very aggressive with our accel enrichments and usually prefer to dampen everything, so there could be issues I am not seeing.

_________________
"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: Fri Oct 16, 2015 11:27 am 
Offline

Joined: Thu Jan 01, 2015 6:47 pm
Posts: 4251
I have a coolant correction but also cycle count based correction figuring the fuel stored takes time to come to steady state before it's purely coolant based and this correction is to account for that....but accumulated charge is probably more correct.

Currently I'm not turning x-tau on at start-up. I have it on a time delay (which maybe should be cycles of accumulated charge) and then I simply set "current stored = desired stored" and the system is off and running.

What I'm working on now is a "good enough" factor that says if current stored gets within x% of desired stored its close enough and "current stored = desired stored". This will prevent small errors from ever triggering the system to make corrections....or so my logic goes.

I'm not planning on any other accel/decel corrections just the x-tau.


Top
 Profile Send private message  
 
 Post subject: Re: Injector control
PostPosted: Fri Oct 16, 2015 8:52 pm 
Offline

Joined: Sun Oct 11, 2015 2:07 pm
Posts: 134
If the errors are small, then the correction will be small, and overall it won't make a difference?

Most gas engines are never truly steady state.

_________________
"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: Sat Oct 17, 2015 6:20 am 
Offline

Joined: Thu Jan 01, 2015 6:47 pm
Posts: 4251
apalrd wrote:
If the errors are small, then the correction will be small, and overall it won't make a difference?

Most gas engines are never truly steady state.


Yes, true on both. My thought is I'm just using a simple proportional decay so it will oscillate, hopefully not with much amplitude but it will. But unlike most things we try to control, this system is inherently stable and will damp itself if the control just stops trying to help so why not let the controller work to keep the error low and let the system itself to the rest?

Its a simpe thing I''m talking about...

if error < x% then correction = 0

basically....very simple. If you set x% = 0 the sytem runs all the time, or set it to 1 or 2 say and you should void overshooting if its happening without going to a full PID with tables of values.

...and it works perfectly in my mind :)


Top
 Profile Send private message  
 
 Post subject: Re: Injector control
PostPosted: Sun Oct 18, 2015 10:24 am 
Offline

Joined: Thu Jan 01, 2015 6:47 pm
Posts: 4251
The more I test the more I realize that I am REALLY good at writing bugs into the model! :oops:

....that's why we bench test first though. Most things are looking pretty good now I think other than the x-tau (accel/decel enrichment) which is working other than not tracking by cycles like it should be.

Once I think everything is working I'll post a new copy for any of you to play with.


Top
 Profile Send private message  
 
 Post subject: Re: Injector control
PostPosted: Mon Oct 19, 2015 2:22 pm 
Offline

Joined: Thu Jan 01, 2015 6:47 pm
Posts: 4251
I've got the x-tau linked properly to cycles now (you can see the steps at cycles count) but I need to change the way I pull out fuel on decel so the numbers allow the fuel to come completely from the walls because while I can add all the fuel needed in 1-2 cycles, decel is taking many cycles.

Notice too the osculation that happens when aggressive numbers are used.....I that gets fixed with the turn it off near zero code I want to add.

Red is MAP - I do a simulate throttle bank open/closed and watch the fuel react
Green is the target fuel stored
Gold is actual fuel stored
pink is calculated fuel needed (before accel/decel)
Blue is fuel delivered once accel/decel is applied - again I have crazy be correction rates on it which cause massive oscillations


Attachments:
x_tau 2015_10_19.JPG
x_tau 2015_10_19.JPG [ 196.12 KiB | Viewed 15659 times ]
Top
 Profile Send private message  
 
 Post subject: Re: Injector control
PostPosted: Mon Oct 19, 2015 2:26 pm 
Offline

Joined: Sun Oct 11, 2015 2:07 pm
Posts: 134
What is fuel stored target?

The fuel stored should be a calculation which should find a happy place when the engine reaches steady state, where fuel going into and out of the puddle match. But, according to the model, fuel is continuously going into or out of the puddle. It's not really triggered by anything.

_________________
"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 Oct 19, 2015 2:49 pm 
Offline

Joined: Thu Jan 01, 2015 6:47 pm
Posts: 4251
Fuel_Stored_Target is table value of what is stored in the manifold under specified conditions.

Fuel_Stored is a calculated running total of what is actually stored in the manifold

The oscillations come an overly aggressive correction....using more reasonable numbers (mostly) eliminates it but I'd like to make oscillations impossible if I can.


Attachments:
x_tau 2 2015_10_19.JPG
x_tau 2 2015_10_19.JPG [ 190.56 KiB | Viewed 15663 times ]
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 6 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