View unanswered posts | View active topics It is currently Sun Apr 05, 2020 8:03 pm



Reply to topic  [ 14 posts ]  Go to page 1, 2  Next
Fuel Pump Output Behaviour Discussion 
Author Message
Moderator
User avatar

Joined: Tue Jan 15, 2008 2:31 pm
Posts: 15347
Location: Home sweet home!
This seems like a simple thing, but as per usual, I want to get it exactly right.

Clearly the pump should come on with the ECU and stay on for a second or two or three (perhaps configurable) to prime the fuel lines and pressurise the system that has probably bled down since the last switch off.

The next reason for it to be on would be any RPM input signals received. It should come on as soon as any pulses are received and stay on for some delay (reuse start up fuel pump pulse config? or seperate?) after the last pulse is received.

The fuel pump output probably should NOT care if the engine is synced or not. The fact that pulses are coming in should indicate that something is happening and that fuel pressure is required to help it happen more.

The above behaviour seems sufficient to produce good results. Can anyone see any problem with my logic? Either practical or safety stuff?

Now, in order to implement that, we need some sort of counter to know what the RPM inputs have been doing. Possibly a new counter variable in the RT clock that just ticks up and never overflows and gets reset by the RPM ISR? We'll sort something out. The simple logic can reside in the RT ISR anyway.

An 8 bit configuration var will allow up to 255 seconds of on-ness after init and 1 second granularity should be enough. 255 should be plenty to do fuel pump testing too, ie, make sure things are working well leak wise etc.

Thoughts?

Fred.

_________________
DIYEFI.org - where Open Source means Open Source, and Free means Freedom
FreeEMS.org - the open source engine management system
FreeEMS dev diary and its comments thread and my turbo truck!
n00bs, do NOT PM or email tech questions! Use the forum!
The ever growing list of FreeEMS success stories!


Thu Nov 25, 2010 6:13 am
Profile WWW
LQFP112 - Up with the play

Joined: Thu Apr 10, 2008 5:51 pm
Posts: 205
Sounds good to me, I find it annoying that MS shuts off the fuel pump when it loses sync.

_________________
Keith MacDonald
Control Engineering (Systems) Technologist


Thu Nov 25, 2010 9:14 pm
Profile
Moderator
User avatar

Joined: Tue Jan 15, 2008 2:31 pm
Posts: 15347
Location: Home sweet home!
Absolutely!!! This is what I observed on the JimStim with MS2 3.0.3x yesterday, and what prompted me to write this thread, along with the fact that I need to finally implement this if I'm going to run it on my truck soon... :-)

_________________
DIYEFI.org - where Open Source means Open Source, and Free means Freedom
FreeEMS.org - the open source engine management system
FreeEMS dev diary and its comments thread and my turbo truck!
n00bs, do NOT PM or email tech questions! Use the forum!
The ever growing list of FreeEMS success stories!


Thu Nov 25, 2010 11:31 pm
Profile WWW
LQFP144 - On Top Of The Game
User avatar

Joined: Tue Jun 24, 2008 5:31 pm
Posts: 468
This is what I did:
* Key "ON" -> turn pump on.
* if RPMs are still in 0 after 3secs, turn pump off
* otherwise, keep it on until rpm goes to 0. And, if rpm reaches zero, wait a couple of seconds before shutting it down and recheck, just in case it was a rpm misread.

IMO it should't be in the ISR, the pump control isn't time-critical at all. I don't know... but if there is some information about time (hours,minutes, or seconds) going out through the communication protocol, that time could be reused to count how many seconds passed since the last zero-rpm event. You'd be controlling the pump based on RPM and system time, both variables available in the main loop (in case you know what time it is, of course).

_________________
Marcos


Sun Nov 28, 2010 8:17 am
Profile
Moderator
User avatar

Joined: Tue Jan 15, 2008 2:31 pm
Posts: 15347
Location: Home sweet home!
But, Marcos, what if you have intermittent sync? The REAL RPM is 200 the entire time, but the ECU thinks that it is 0, and turns off the pump, and when sync briefly appears there is no fuel pressure and the engine fails to kick and increase in RPM, the main loop misses this event as sync is lost and rpm set to 0 again. The pump should be on the whole time the engine is turning, sync or not. Sync is required to have RPM > 0. The argument here is about whether you should recognise the crank signal before turning the pump on. I disagree. The pump should fire up the instant the engine moves, well before sync is obtained such that the fuel pressure is high when sync arrives and the injectors start firing.

Make sense?

We're not talking about putting the fuel pump control in the ISR, just getting enough info out of the ISR (and no more) to be able to determine that the engine is moving.

Fred.

_________________
DIYEFI.org - where Open Source means Open Source, and Free means Freedom
FreeEMS.org - the open source engine management system
FreeEMS dev diary and its comments thread and my turbo truck!
n00bs, do NOT PM or email tech questions! Use the forum!
The ever growing list of FreeEMS success stories!


Sun Nov 28, 2010 8:39 am
Profile WWW
LQFP144 - On Top Of The Game
User avatar

Joined: Tue Jun 24, 2008 5:31 pm
Posts: 468
Well... in my case, if ANY crank pulse was detected, then RPM != 0.

So if real rpm was 89, it can't be measured it but I still put RPM = 1 (oh, that happens in the isr), after 200 or 300 real rpm, the RPM variable starts to make sense. The thing is, it should react to tooth pulses, with some hysteresis.

Mine has a delay slight delay in turn-on time, 3msec max after the first tooth detection, 1.5msec typical. I've consider it adequate, since the pump lag is quite big. You may disagree with it, I didn't care a lot about it, and didn't have lots of flash to play with.

_________________
Marcos


Sun Nov 28, 2010 9:02 am
Profile
1N4001 - Signed up
User avatar

Joined: Tue Jun 10, 2008 5:17 pm
Posts: 1607
nitrousnrg, I understand you consider the fuel pump as not critically timed, which might imply that after a loss of tach, it will still take a second or two to turn off. Is that correct?

I guess I'm a bit ignorant why we would use the tach to determine the fuel pump. I guess I can see how that might function as a safety feature, but don't most cars hardwire this with out the EMS being involved? If freeEMS had an accelerometer or other such device that could be included for input as a safety device, I can see why we want the pump on the EMS, but right now I would probably code it to be on when the key is on, and get the other critical features working. Then modify it later to include better decision making relative to when the pump should be on.

If I were to use the tach (or other inputs) as an input that makes decisions about the pump being on, I would want the default to be on, and only turned off if specific conditions are meet. I would probably turn it on when the key signal showed up, and when ever the tach goes from 0 to anything. When tach goes from 0 to anything, tick would also be set to null, or similar flag. Then if it went from anything to 0, I would store tick, and then if tick + 1 second happens, turn the pump off. Turn off could be done in the main loop so it may take more than 1 second to turn off. The turn on, would either need to be low latency, or done via logic such that the injectors don't have low pressure. Low latency would probably mean an ISR's some how with a higher priority than most other code. However if we use an injectors on flag, such that we could not allow the fuel injectors to deliver if the pump hasn't been on long enough, we could code that in main with other less critical items. Is an injectors on flag handy for other purposes?

If this is done via state machine or similar logic in the main loop, will the main loop be processed fast enough for start conditions?


Sun Nov 28, 2010 12:14 pm
Profile
Moderator
User avatar

Joined: Tue Jan 15, 2008 2:31 pm
Posts: 15347
Location: Home sweet home!
No no, I'm not criticising, I'm just trying to determine what the BEST behaviour is, irrespective of resources and implementation details etc. Then once we know that and agree, we can go ahead and find an implementation for it, or cut it down a bit due to resource constraints etc.

On the volvo crank pulses meant rpm != 0 too, but that code wasn't robust IMO. In FreeEMS most decoders will have a concept of sync that is enforced, and thus what I said above makes sense.

I can interpret your post in two ways. If the ISR is setting 1 as a special value, and a flag, then you're doing much the same thing that I'm talking about anyway.

We probably agree on this, by the sounds.

Fred.

_________________
DIYEFI.org - where Open Source means Open Source, and Free means Freedom
FreeEMS.org - the open source engine management system
FreeEMS dev diary and its comments thread and my turbo truck!
n00bs, do NOT PM or email tech questions! Use the forum!
The ever growing list of FreeEMS success stories!


Sun Nov 28, 2010 12:19 pm
Profile WWW
Moderator
User avatar

Joined: Tue Jan 15, 2008 2:31 pm
Posts: 15347
Location: Home sweet home!
Jared, parallel posts, I agree with your "default is on" sentiments, however not the "leave it on and code for it later", the key should be able to be left on without draining the battery in minutes (my pumps draw around 25 amps).

Main loop is the place to decide if it should come back on, or go off, it can be set in the init code to start out as being on, though. Then it'll come on with the key, and turn off some time later, or not.

Fred.

_________________
DIYEFI.org - where Open Source means Open Source, and Free means Freedom
FreeEMS.org - the open source engine management system
FreeEMS dev diary and its comments thread and my turbo truck!
n00bs, do NOT PM or email tech questions! Use the forum!
The ever growing list of FreeEMS success stories!


Sun Nov 28, 2010 12:23 pm
Profile WWW
LQFP144 - On Top Of The Game
User avatar

Joined: Tue Jun 24, 2008 5:31 pm
Posts: 468
jharvey wrote:
it will still take a second or two to turn off. Is that correct?

Yup, correct.
Fred wrote:
I can interpret your post in two ways. If the ISR is setting 1 as a special value, and a flag, then you're doing much the same thing that I'm talking about anyway.

Think of it as a flag, I just didn't had enough ram for more flags so I reused almost everything.

So, a flag setting in the crank-related ISR, and the main loop deciding when to turn it on/off?

It also can be turned on from the ISR, with a rising edge interrupt from the key.

_________________
Marcos


Sun Nov 28, 2010 4:30 pm
Profile
Display posts from previous:  Sort by  
Reply to topic   [ 14 posts ]  Go to page 1, 2  Next

Who is online

Users browsing this forum: No registered users and 2 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

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group
Designed by ST Software for PTF. ColorizeIt.