Post start enrichment/warmup too short time/cycles

[mk e]

I'm looking through the warmup options and finding options that look like they will work. This is kind of a follow-on from my post on charge temperature because manifold temp, that kind of controls low rpm charge temp significantly lags CLT on every engine I've ever worked on and that is true on the frankenferrari as well. Sitting warming up at idle it takes about 5-6 minutes on a 70F day to get the coolant up to temp and CLT correction to 0% (I guess 1.0 factor in rusefi speak), but the mixture takes 10-12 minutes to stabilize as the intake manifold heats up. That is about 1.25E4 cycles but the post star enrichment ends at 1E3 cycles. How are you guys handling this, I'm just not seeing anyway to fix it in TS? I really don't want to start hacking at the code because hacking is the only way to describe my coding skills so I'm hoping I'm missing something?

post start.JPG (106.19 KiB) Viewed 15727 times

[mk e]

I made the decision to just go into the .ini and change the max value to 10000. Its an F32 type so hopefully the ECU FW doesn't mind and the 1000 was a random choice that seemed big enough but isn't, at least not for my engine.

post start fixed.JPG (123.87 KiB) Viewed 15624 times

[AndreyB]

Its an F32 type

Float for engine cycle counter? That's weird, just changed it https://github.com/rusefi/rusefi/commit/53bf3da0e4fa937f9eb0caa1e01490779cd93063 you are now limited at 64000

i guess the relatively low number in the limit is related to the intention of this feature used for relatively short term enrichment, with CLT-based logic taking care of the 10 minute scale?

[mk e]

Float for engine cycle counter? That's weird, just changed it https://github.com/rusefi/rusefi/commit/53bf3da0e4fa937f9eb0caa1e01490779cd93063 you are now limited at 64000

i guess the relatively low number in the limit is related to the intention of this feature used for relatively short term enrichment, with CLT-based logic taking care of the 10 minute scale?

Thanks!

Yeah, it sounds like whoever wrote it was thinking about right after start as extra on top of the CLT correction....but if you need software stress-tested I'm your guy

I made a post about the clt/iat logic and this is connected to that. Inside the engine the coolant flows mostly around the combustion chambers and exhaust ports so they don't melt which means it gets up to temp pretty fast, way before the intake port and manifold are hot, and its the manifold and port temp that heat the charge, and determine when lambda becomes stable. On my engine at idle, CLT is stable at about 5-6 minutes but lambda takes 10-12 and no doubt that is the time the mass of the head and intake take to get to a stable temperature. This is another place where a time (or cycle) based correction is needed...and the only thing I saw that could do this was the post-start enrichment.

I personally f'n HATE table switching logic because it causes discontinuities in the system. I don't really speak C but the names cranking enrich and post-start enrich make me believe they are engine state controlled and at the run threshold cranking is switched off and post-start on meaning they need to match for the 1st few cycles snice there is no way to know when it switches over. I WAY prefer stuff that decays to 0 so if it was up to me it would be start enrichment that begins at cycle 1 and goes until its no longer needed. In the age of use define axis values there is no reason in the world for 2 separate state based tables, but there is a need for 1 cycle/time based table and 1 clt based table. At least in my little world, which I admit might be semi-delusional

[mck1117]

the effect you’re describing is EXACTLY what the charge temperature estimation is for. No OEM uses an after start fuel correction table longer than maybe 30 seconds.

[mk e]

the effect you’re describing is EXACTLY what the charge temperature estimation is for. No OEM uses an after start fuel correction table longer than maybe 30 seconds.

no doubt post start is meant for post start and disappears quickly normally but charge temp estimation (as implemented) is not time or cycle based so I'm not sure how it can preform a warm-up function? I know I've seen longer time based warm-up tables in OEM stuff, it can take 15-20 minutes for the intake system and air temp to stabilize so the charge estimation can be done correctly.

I'm also pretty the way its written charge estimation not estimating correctly. Its probably close for whatever air is sitting in the runner but once that air is pulled in and the charge is moving the heat transfer will be a function of runner length and charge velocity, not density or mass really. The assumption being the thermal mass of the runner is very large compared to the air and acts as an infinite sink so the problem collapses to time and heat transfer rate, both of which are functions of velocity. This is also why spraying the fuel into the moving charge makes a little more hp, the cooling from the vaporizing fuel cools the air charge by 10C ish usually but spraying into a sitting charge the port is cooled rather than the air. Its complex for sure.

[mk e]

Talking generally about charge temp….its really hard to tune because on any given day it looks the same as VE effect wise. A buggered charge temp estimate gets mostly corrected while tuning the VE table. It will show up with the mixture looking different as ambient temp changes which kind of shifts the steady state points of everything, but the go-to to fix it is usually the IAT corr table rather than go for the root cause of charge temp estimation.

In the engine simulation software I use has recommendations for charge temp based on intake manifold type, based on I think a standard 68F day. A V engine type plenum intake they say 180F, so basically coolant temp. For ITBs they say 120F. In-line engines with runners and a plenum some distance from the engine would be somewhere in-between. For a carbonfiber manifold they say 70F so basically no temp gain and I would guess any polymer intake is similarish. Then there is charge cooling based on fuel vaporization and type.
Really hard to know what is causing what exactly without buckets of instrumentation so how to tune it? Just guess based on manifold type I suppose like the engine sim sw does but their number is for WOT on a 68F day, the hotter the day, the lower the Temp delta and the lower the heat transfer rate so the apparent % bias changes.

Maybe just make the IAT correction table 3D so IAT v RPM and call it a day? Don’t know but that seems the most straightforward?

Different from a longer term time/cycle based warn-up though.