When you click on links to various merchants on this site and make a purchase, this can result in this site earning a commission. Affiliate programs and affiliations include, but are not limited to, the eBay Partner Network.
Hi folks,
The car is running fantastic - except for an intermittent AFT safety shutdown issue. Approx 1 out of every 5 pulls, the AFR safety system is triggered. Looking at the logs, the reading from the Spartan2 wideband spiked, causing the shutdown. So I replaced the sensor. But it is still doing it, even on a brand new sensor.
Would be incredibly grateful if someone could lend some wisdom here, apart from a faulty O2 sensor, what could cause a spike in the EGO log that would trigger the AFR Safety System intermittently? On the pulls where it doesn't happen, all the logs look peachy to me - nice stable AFRs. Have put a bookmark called "AFR CUT" in the attached log where it happened. You can then see me pumping the throttle in vain, waiting until the RPM drops below 2000 to end the Safety period! If the bookmark doesn't work, it's at 151 secs.
Thanks heaps
99 NB8A MS3 Pro PnP, forged, GTX2867R.
Seems like a lot of advance. What fuel are you running? 23 BTDC at 200kPa and 5k seems high to me with pump gas. Coupled with 12.5 AFR looks dangerous to engine. No expert. Interested to see what more knowledgeable folks say.
Many thanks for the replies, Ryansmoneypit: you are correct - realised I have the AFR safety system enabled for WOT and full boost. Current AFR safety settings below. I remember Savington saying somewhere he was not a fan of AFR safety after 90kpa, So I will change "Active above TPS to 70% (instead of 105%); and enter zero in the Authority table after 100kpa - and will report back. Would be a lovely simple fix if this is what is causing it!
Mattrussell122: You are also correct - I had the "D" in the PID set to 10, which might mean that it was predicting an overshoot, rather than an actual one. After searching PID EGO control, it also seems that my P and I values are too high to start with. Will change the P to zero first, if it persists, then I'll try turning down the P and I values. I also read on the Megasquirt forum that the EGO PID is a "type C" PID, and apparently that means that the I acts like the P, and the D acts like the I - just to simplify things!
DNMakinson- my apologies, I should have mentioned that it is an E85 only, 99% track and 1% road car. Thanks for having my back
However, your understanding of EGO and AFR Safety, I think, is not complete. I believe that Andrew suggesting not using EGO in boost. That is not the same as using AFR safety.
I also don't think there is any anticipation involved. You were clearly at 12.5 when you call for 11.8. This over by 0.7 and your safety is set at 0.5. You can do a rough calculation of the change in VE table: New Value = Old Value * Actual AFR / Target AFR. OR, in this case:
New = 107.9 * 12.5 / 11.8 = 114.3. Increase the cells around 180 - 220kPa and 5kRPM on you VE table by about 7 (really it is ratio-metric, but near 100, you can just add.)
The "D" in the EGO is in a sense an anticipatory function, but it is to prevent overshoot of the EGO control loop, or for really slow systems. Still, the issue here is AFR safety, not EGO.
EGO is an active adjustment of fueling to try to hit your AFR targets. AFR Safety is a spark and / or fuel cut when AFR is leaner than your target. There is one other thing I still don't understand, and that is why your EGO was not trying to correct your AFR. You have 10% authority, yet your EGO is nearly 100%. I can only share my EGO PID settings, which follow pretty well error: P=20, I=30 D=2.
I suggest a longer wait time before tripping AFR Safety, about 1.5 seconds, so you don't trip on acceleration. But more important, I suggest that you tune your VE table. Add more fuel in that area and get the AFR where you want it. A safe way to tune is to take a little at a time, make it a little rich, then move leaner. Then you can leave your AFR safety in place without tripping it. Also, put your over-boost protection just above where you are running so if you make a fat finger on the EBC, you don't go into an un-tuned region.
Generally, and I think you know this, your VE table needs a lot of work and smoothing.
I hope I have been of service.
Ted - I just put the PW diving before the AFR spike down to the delay in the O2 sensor?
DNM - thanks for taking the time to advise. Andrew's comment was at Post #5 here: https://www.miataturbo.net/megasquir...oop-ego-93971/
"I am not a fan of EGO at WOT. Too much reliance on an O2 sensor which will eventually fail/stop reading correctly (as they all do, eventually). I sleep better with a ~90kpa limit on EGO and ~10% authority everywhere else. YMMV".
I was assuming that the AFRs were okay, and an over-zealous EGO correction was unnecessarily triggering the AFR safety system. So then if EGO was off in boost = no AFR Safety trigger. But after reading your post, that could be a pretty dumb assumption. I need to address why the AFR spiked, and I do that be refining the VE table. And you were right - when I loaded the spiked log into MLVHD, and ran VE analyse, it did just what you said - added 7-9 in precisely that area.
So I will NOT turn off AFR safety, will increase the wait time to 1.5 secs, and then tune the VE table in the offending areas...
Thank you.
Righto, so after a test drive with a very slightly tickled VE table, and the AFR safety step time & wait times increased a little - it seems like the shutdown issue is gone,. At least I could not get it to happen tonight on the same road, time, and temp as last time. Attached is a log of some 3rd gear road pulls.
But I think the EGO PID is still not right, as there is a huge oscillation in AFR & EGO Correction after you snap the throttle shut. Perhaps I need to turn the P down from 100 to around 80, the I up a touch from 40 to 60, and introduce just a little D, up 10 from zero..
the RPM has almost no change at WOT for an extended time, the a little dip feature of some sort, but it pops back up, no tps change. So WOT doesn't budge RPM, but you can get some sort of a transient event that has both falling and rising RPM?
I see no evidence of 0.5 sec of spark kill prior to fuel cut...
are we sure AFR safety is even kicking in here?
edit: Does AFR safety kick in 0.5 sec to the left of the cursor position? IOW, is the whole pull after AFR safety has pulled timing? If this is the case, would we not expect a lean spike when fuel gets pulled?
I see no evidence of 0.5 sec of spark kill prior to fuel cut...
are we sure AFR safety is even kicking in here?
edit: Does AFR safety kick in 0.5 sec to the left of the cursor position? IOW, is the whole pull after AFR safety has pulled timing? If this is the case, would we not expect a lean spike when fuel gets pulled?
No, right at the cursor position in the first post is where the spark is cut. There is no pulling timing. Just cutting.
Looking at his posted log, it happens consistently each case: Status 2 goes from "0" to "32", which indicates a spark cut. That, along with the fact that he is definitely in the AFR error range that AFR Safety should cut spark, I still think that is the root cause.
Sequence is indeed, Hit Safety, cut spark, turbo spins down, MAP drops, and PW with it; then in 0.5 more seconds, fuel is also cut. MS is doing what he told it to.
EDIT: On Log after adding fuel, The only time there is spark cut (Status 2 = 32) is when he hits 7438 rev limit; where he also, properly, get immediate fuel cut as well.
Ahh, I was looking at the Spark table line thinking it was advance, I see now, thanks.
why is the RPM trace dropping before the event?
I think the RPM drop is unrelated. In his new log, it occurs sometimes but not others. Perhaps a missed pulse in PU, or too little smoothing? Not sure. But I do not think it material to this particular conversation.
I don't know, it seems pretty dramatic and potentially correlated. Possibly Indicative of a larger system issue? Like alternator cut out or something? If the ECU thinks the RPM is dropping and it isn't, how can it fuel properly? Does he have a fast sample rate SD log for an event like this?
Grateful for the help gentlemen, also quite useful to see the "process" used to diagnose.
DNmakingson - yep, that was the first time I touched the VE table, its pretty grainy, so this is the tail I will chase for now.
Ted - I'll do a high speed log and report back on the RPM drop. Wondering if a dodgy TPS could d that - I have a spare I could try.
Andrew - just save the accosting for a future stupid move, not if, but when
01-15-2019, 04:53 AM
Intermittent AFR safety shutdown
0
