Reasons To Cut Injection/Ignition With Hysteresis
Posted: Wed Apr 27, 2011 11:41 pm
I've put this thread up because I thought of a couple of cuts that SHOULD be performed that aren't the norm recently.
Obviously there is RPM based fuel and/or ign cut. These shouldn't be able to be turned off, just raised up to a level that won't get hit.
For boosted apps there is excess manifold pressure based fuel and/or ign cut. Likewise, always there, just tunable to an unreasonable level.
Less settings, simpler, better, easier to understand and diagnose.
But additionally:
If duty cycle exceeds some percentage, then the engines operating conditions are no longer under control, we're playing Russian roulette with your engine's AFRs, which is BAD in a boosted application. This hysteresis could be done on time, or on requested duty or perhaps something else. I'd quite like to make this compulsory such that anyone with a marginal setup is forced to upgrade their equipment (or just increase the pressure a little) to avoid hitting it. Allowing engines to run leaner than they want to will allow engines to blow up. I'd rather keep the number of user engine deaths down in situations where they could turn around and try to blame us. With this, they would have no choice but to acknowledge the deficiency in their system and correct it. I personally know people that have cooked engines running them on 100% duty. I myself ran my truck on 100% duty for a long time, but knew the risks, and ran with it. More ignorant users may not even be aware that they have a fuel supply issue unless you forcably bring it to their attention. At the very least, the default should be ON, and MAYBE the ability to over-ride it (without code change, someone determined could always disable in code...) could be provided in some advanced tab or similar.
If sync loss occurs, and is regained too quickly, then you can get the case where some fuel events are missed out, and others aren't, ditto for ignition. This can create a lean condition without a hysteresis, and I think it's unreasonable to leave it to the decoder authors to handle this, it's a common-to-all-decoders issue. in the event that you fire more than one injection of fuel per cycle (all non-sequential applications) then you can easily go lean. Say you're running a super rich 10:1 AFR in boost, and you miss one of your two injections in a cycle due to brief sync loss, you'll get a lean, but (barely) combustible mix of 20:1 in the chamber at massive pressure, and quite possibly damage the engine. The situation is worse if you have 4 injections per cycle and miss only one, then you might go from a healthy 12:1 to a devastating 16:1 which will definitely ignite and explode and destroy something. Such hysteresis could be done with time or with engine cycles (using last known RPM and time). This one should not be able to be switched off, as it's a design thing, not a user setting. The time limits should also not apply to initial sync which should be instant if possible. Only to "was running, now isn't" situations. We could have a minimum level that users cant go below, with a more aggressive default to alert users to their issues. That way they can make it more benign if they want to live with it, but can't put themselves in danger of lean conditions due to part cycle sync loss.
These have been thought through pretty well, but feedback is still welcome. More so, though, what ELSE needs a similar treatment?
For all of these, it will be done through scheduling or not based on conditions. IE, for the sync loss one, the decoder could regain sync, but no outputs would be fired due to nothing being scheduled. This is nice and clean.
Fred.
Obviously there is RPM based fuel and/or ign cut. These shouldn't be able to be turned off, just raised up to a level that won't get hit.
For boosted apps there is excess manifold pressure based fuel and/or ign cut. Likewise, always there, just tunable to an unreasonable level.
Less settings, simpler, better, easier to understand and diagnose.
But additionally:
If duty cycle exceeds some percentage, then the engines operating conditions are no longer under control, we're playing Russian roulette with your engine's AFRs, which is BAD in a boosted application. This hysteresis could be done on time, or on requested duty or perhaps something else. I'd quite like to make this compulsory such that anyone with a marginal setup is forced to upgrade their equipment (or just increase the pressure a little) to avoid hitting it. Allowing engines to run leaner than they want to will allow engines to blow up. I'd rather keep the number of user engine deaths down in situations where they could turn around and try to blame us. With this, they would have no choice but to acknowledge the deficiency in their system and correct it. I personally know people that have cooked engines running them on 100% duty. I myself ran my truck on 100% duty for a long time, but knew the risks, and ran with it. More ignorant users may not even be aware that they have a fuel supply issue unless you forcably bring it to their attention. At the very least, the default should be ON, and MAYBE the ability to over-ride it (without code change, someone determined could always disable in code...) could be provided in some advanced tab or similar.
If sync loss occurs, and is regained too quickly, then you can get the case where some fuel events are missed out, and others aren't, ditto for ignition. This can create a lean condition without a hysteresis, and I think it's unreasonable to leave it to the decoder authors to handle this, it's a common-to-all-decoders issue. in the event that you fire more than one injection of fuel per cycle (all non-sequential applications) then you can easily go lean. Say you're running a super rich 10:1 AFR in boost, and you miss one of your two injections in a cycle due to brief sync loss, you'll get a lean, but (barely) combustible mix of 20:1 in the chamber at massive pressure, and quite possibly damage the engine. The situation is worse if you have 4 injections per cycle and miss only one, then you might go from a healthy 12:1 to a devastating 16:1 which will definitely ignite and explode and destroy something. Such hysteresis could be done with time or with engine cycles (using last known RPM and time). This one should not be able to be switched off, as it's a design thing, not a user setting. The time limits should also not apply to initial sync which should be instant if possible. Only to "was running, now isn't" situations. We could have a minimum level that users cant go below, with a more aggressive default to alert users to their issues. That way they can make it more benign if they want to live with it, but can't put themselves in danger of lean conditions due to part cycle sync loss.
These have been thought through pretty well, but feedback is still welcome. More so, though, what ELSE needs a similar treatment?
For all of these, it will be done through scheduling or not based on conditions. IE, for the sync loss one, the decoder could regain sync, but no outputs would be fired due to nothing being scheduled. This is nice and clean.
Fred.