Over Run Fuel Cut bug? (X-Tau tuning issue?)

[Ryephile]

Hello MSEXTRA. I've been a lurker for many years, and just signed up to ask about a potential pair of bugs regarding Over Run Fuel Cut.

The hardware setup is: Miata turbo running 36-2 crank and NB cam sensor, with MS Labs MS3, was on 1.3.4 firmware, currently on 1.4.1b2. The problem is identical on both firmware versions. WBO2 is an LSU 4.2 over CAN to MS3.

The fault is: After lifting completely from a WOT, fuel cut will fail to reengage according to its parameters and the engine will stall unless you touch the throttle. Also, occasionally and non-repeatably, when engaging the Rev Limit the ECU will "crash", causing the tach-out, fuel, and spark all go to zero, all while the engine is freewheeling in-gear. The ECU will come back after a few seconds and continue operation.

Neither of these faults appear in an exhaustive search of the forum. I'm wondering if it's Miata 36-2 code specific, since there are very few of us running that. The code runs perfect with Over Run Fuel Cut turned off, and the faults are repeatable with O.R.F.C. turned On.

MSQ and zipped datalog attached. I've also posted a picture to show within the datalog a perfect example of the post-WOT engine braking failing to reengage fueling with no TPS intervention.

2016-02-07_13.30.52.zip

. Perfect example at 2971 seconds. ORFC was turned Off for the first half of the datalog. Amusingly when the engine dies, the datalog claims a few seconds of about 200 RPM, which is erroneous.

2016-02-07_13.06.25_newCLboost.msq

OverRunCrash by Ryephile, on Flickr


Thank you and hopefully we can figure this out.
Cheers,
Ryan

[jsmcortina]

Can you capture a laptop datalog of this. The log you posted only has some of the log fields in it.

James

[Ryephile]

The log is zipped from a Windows 10 laptop running the latest rev of TS. Perhaps the zipping messed something up. The site won't let me attach anything bigger than 1MB, so I put the original log file on my Google Drive.

https://drive.google.com/file/d/0B1m4Eb ... sp=sharing


*edit* I just tried DL and unzipping the log in the original post from a different PC. Unzips fine and shows all the sensor plots.

[Ryephile]

Can you capture a laptop datalog of this. The log you posted only has some of the log fields in it.

James

Hi James, thanks for your help. Do you mean that you want additional sensor data? If so, which ones (e.g. TPSdot)?

Also, I just read the update notes for 1.4.1 beta 3, and it mentions unexplained crashing with Miata. Perhaps that's related? I'm running 1.4.1 beta 2

[jsmcortina]

The log you've posted is presumably from an SDcard datalog, it has hardly any data fields in it (columns.)

As I asked, please take a regular datalog (Datalogging -> Start) on your tuning laptop that demonstrates the issue and attach it.

James

[Ryephile]

No, it's not from an SD card. Seriously, it's an actual laptop datalog. Are you looking at it with a current version of MegaLogViewer? I even said what time in the datalog to observe the problem (at 2971 seconds) that correlates with the screencap in the OP. All the sensor data is in the datalog, however I don't typically record the calculated outputs like the TPSdot, MAPdot, and RPMdot. Is that what you're looking for?


I can even see the data opening the MSL in Excel. It's all there. Something is up on your end.

[Ryephile]

Here's a screencap of the MSL open in Excel.

[jsmcortina]

The file you linked has only got 22 columns of data in it. Not enough.

See attached.

James

[Ryephile]

The file you linked has only got 22 columns of data in it. Not enough.

See attached.

James

Ok, so you have been able to see it all along. It comes back to my question from earlier; what do you want to see?

[jsmcortina]

The file you linked has only got 22 columns of data in it. Not enough.

See attached.

James

Ok, so you have been able to see it all along. It comes back to my question from earlier; what do you want to see?

All of the other columns that are missing. I can't support you until you do this.

James

[Ryephile]

Ok, all of them it is. I'll do another set of datalogs soon.

[Ryephile]

Here you go.

ORFCoff = Same tune file as original post and with Over Run Fuel Cut kept off.
ORFCon = Over Run Fuel Cut turned on, same tune otherwise.


The log captures from today vary from every other time I've had ORFC Off, where it had never stalled post-WOT, implying there's something else going on to force the engine to stall solely in this post-WOT trans-neutral engine coast-down scenario.

orfcoff.zip

orfcon.zip

[jsmcortina]

The log certainly seems to show unexpected behaviour.

I'm testing with a simulated 36-1 wheel and I'm not seeing your problem. It seems unlikely that the wheel pattern would alter things as the code is somewhat abstracted/modular and the fuel code doesn't care about the type of wheel in use.

However, as a test, try disabling the progressive fuel cut and return.

James

[Ryephile]

Thanks. Assuming we don't get a snowstorm tonight, I should be able to get another log this weekend.

Your comment makes me wonder however. Does having Over Run Fuel Cut feature Off, yet the Progressive Cut and Returns both On [but still grayed out], make a difference in the code? My hunch is there's a combination of settings that is tripping up the code. The TPS being over 100%, followed by about 0%, is that a problem condition in the fueling calculation?

With ORFC Off, shouldn't the PW calculation be the VE table in combination with the sensor data? I'm trying to think of a scenario where the PW would ever be zero post-WOT and at very low load. It's still on the VE table....or is it? How does the PW calculation handle values greater or lower than the entered values on the VE table? ...and is there a decel [XTAU?] setting that would zero out or error the PW calculation?

[jsmcortina]

Your tune results in a very low pulsewidth (likely near zero fuel) when you let off the throttle. Beyond that I can't guess until I've seen a complete datalog.

James

[Ryephile]

Pulsewidth data for the issue is in all the previous datalogs, even in the OP. The issue is why the fuel calculation stops working post-WOT and subsequently 0% TPS and fuel doesn't come back and lets the engine die unless I "wake it up" with any TPS input. The logs from yesterday clearly show both scenarios. 0% TPS post-WOT = fueling is zero. Any TPS post-WOT = PW operates normally. This is irrational with ORFC turned off, unless Off doesn't equal Off.

[jsmcortina]

I can't guess until I've seen a complete datalog.

[Ryephile]

I can't guess until I've seen a complete datalog.

Here you go. First two datalogs are with ORFC "off", along with progressive fuel cut and return both "off". There's some fascinatingly undesirable behavior with PW.

2016-02-14_11.52.51.zip

2016-02-14_11.53.32.zip

[Ryephile]

I then flashed the S12X with pre1.5 and then ported the same tune, with ORFC at Off / Off / Off, same as above

The behavior is slightly different, though it still fails, just not as often, along with visible datalog failures when the engine dies, it does not magically levitate its RPM at 222. Also when I bump start it after it fails, it takes way longer to "wake up" than 1.4.1b3, and it's not nearly as graceful.

2016-02-14_12.25.54.zip

2016-02-14_12.27.53.zip

[jsmcortina]

As you are seeing this behaviour with over-run turned off, then it is unrelated to over-run.

Checking your settings again, I see that you are using the X-Tau wall-wetting accel/decel algorithem. With this incorrectly tuned it could easily cause the problem you are seeing. In the situation when you go to low MAP it will pull fuel (down to zero) which it does and keep it there until it thinks the wall fuel is exhausted.

Try turning off X-Tau as a test.

James