Fuel Pump Output Behaviour Discussion

[Fred]

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.

[thebigmacd]

Sounds good to me, I find it annoying that MS shuts off the fuel pump when it loses sync.

[Fred]

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... :-)

[nitrousnrg]

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).

[Fred]

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.

[nitrousnrg]

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.

[jharvey]

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?

[Fred]

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.

[Fred]

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.

[nitrousnrg]

it will still take a second or two to turn off. Is that correct?

Yup, correct.

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.