MS2/extra beta 5 (20070718)

Post by **muythaibxr** » Wed Jul 18, 2007 5:48 pm

Alright, this beta does _NOT_ contain fixes for distributor mode. I'm pretty sure I know where to look for that problem, but it'll take me a little time to get it fixed, and I won't have enough time to spend on it until the weekend.

I also have not fixed any of the remaining bugs in the bugs thread (no time with the spectre meet), nor have I had a chance to add overboost protection. I'll hopefully be getting all known bugs fixed this weekend, as I think I have enough time, but if not, I'll at the very least try to get distributor fixed by this weekend.

What I HAVE fixed:

1) MAP sampling should work with all ignition modes now
2) Closed-loop PWM idle now has lockout protection based on RPMdot and MAP... it'll check to see if RPMdot is below your threshold, and MAP is above your threshold, and if those conditions are met, and the TPS is showing the throttle is closed, it'll go into the PID loop.

I'll do my best to get the rest of the known bugs in the bugs thread fixed by Sunday as well as dizzy mode, overboost protection.

Here's the beta:

http://www.msextra.com/ms2extra/files/b ... 070718.zip

Ken

natesully · Post by **natesully** » Wed Jul 18, 2007 10:01 pm

What does the lockout protection feature do? I mean, what is it for?

Post by **muythaibxr** » Thu Jul 19, 2007 6:50 am

It's to keep closed-loop idle from getting locked out of the PID loop (as can happen in some conditions).

Ken

Keithg · Post by **Keithg** » Thu Jul 19, 2007 6:52 am

Wooo Hooo! Idle is VERY nice. I tweaked it a bit, upped my dashpot adder by 1 and no stalls and no hangs! This is about as good as it gets!

Sweet! Thanks!

Ignition is 'different' I can run 0.5ms after spark now and it appears to smoothly rev through max torque (to 3500 rpm or so). I did remove all battery correction (set all bins to 100). I did not verify if it will rev to the rev limiter I set at 6500 rpm... If I run 1ms It will rev to a point and no more I was not able to determine what rpm that is. At 2ms, it rev limits to 1800 rpm.

Does my math make sense? 1800 rpm is 0.016s per spark event. At 2ms hold down (after spark event) * 2 spark events per rev leaves 0.012s to charge the capacitor. Requirement is 2.5ms per event to charge it. At 2ms hold down, it should work through 1800 rpm for sure... I would like to run a bit longer than 0.5ms as my idle quality improves a bit if it is 1ms or longer. Saab varies this 'pull down' time based on RPM and has 3ms or so at idle and ramps up making sure there is 2.5ms charge time for the cap. At 7000, I should be able to run 1ms and have 0.8ms bonus time to charge the cap per spark event.

KeithG

Post by **muythaibxr** » Thu Jul 19, 2007 7:11 am

I don't know about your spark issues. I haven't changed anything there yet.

What settings did you use for the lockout protection?

Once mattd860 gives this a shot and tells me it works for him, I'll call it "done" finally and move on.

Glad to hear it's working for you though. I just want to make sure it works for more than one person before calling it done.

Ken

Keithg · Post by **Keithg** » Thu Jul 19, 2007 7:25 am

Lockout protection. I do not have my MSQ here, but I left the MAP at at 25 for now and the RPMS/s I have at 25, I think. So far so good.

As for the spark stuff, I just thought I'd post what I found as this was significantly different than the 20070701 version I had been running.

KeithG

Post by **muythaibxr** » Thu Jul 19, 2007 7:29 am

You did make a setting change though, and as the code hasn't changed at all for generic wheel or your dwell mode since the last release, it has to be that setting change you made causing the difference.

Ken

Keithg · Post by **Keithg** » Thu Jul 19, 2007 7:39 am

It revved cleaner before I made the dwell battery correction change. I
will revert and try to characterize the limits when I go home tonight.

Were you able to verify with the jimstim that 1ms in MT is 1ms on the
line? I will drag the 'scope to the garage tonight and see myself what
is happening when I set the time to 2ms in MT and get the artificial
rev limit.

KeithG

You did make a setting change though, and as the code hasn't changed at all for generic wheel or your dwell mode since the last release, it has to be
that setting change you made causing the difference.

Ken

Post by **muythaibxr** » Thu Jul 19, 2007 7:52 am

I haven't verified that yet.

I'll be doing a lot of work on ms2/extra this weekend when I'll have plenty of time to debug all the problems, and fix them.

Ken

mattd860 · Post by **mattd860** » Thu Jul 19, 2007 10:41 am

muythaibxr wrote:Once mattd860 gives this a shot and tells me it works for him, I'll call it "done" finally and move on.

Ken

I'll be testing this around 4pm today and then immediately take it for a spin on the highway to see how that lock-out works.

Couple questions... Is it possible for this code to interfere with the PID delay? For example, when the last known + adder sits there for x amount of seconds holding a steady rpm above the target rpm and above the MAP threshold, will the lock out code interpret this as being 'locked out of PID'? Or does the lock out code get disabled once the PID timer starts?

I was also wondering, since the adder table has been done away with, if you can make the min duty for PID a table based on RPMs? This is probably highly unnecessary but I just wanted to pass the recommendation on to you and let you ponder on it for a second or two.

Thanks again Ken and I look forward to trying out the new code later.

Post by **muythaibxr** » Thu Jul 19, 2007 10:48 am

mattd860 wrote:
muythaibxr wrote:Once mattd860 gives this a shot and tells me it works for him, I'll call it "done" finally and move on.

Ken
Couple questions... Is it possible for this code to interfere with the PID delay? For example, when the last known + adder sits there for x amount of seconds holding a steady rpm above the target rpm and above the MAP threshold, will the lock out code interpret this as being 'locked out of PID'? Or does the lock out code get disabled once the PID timer starts?

I'm not sure I understand the question... basically if after you get off the throttle, the MAP is above the threshold, and RPMs are staying the same, and it's been whatever you set for PID delay seconds, the code will go into the PID loop. It'll also go into the PID loop during the normal conditions, meaning when rpm goes below the threshold, TPS is closed, etc...

I was also wondering, since the adder table has been done away with, if you can make the min duty for PID a table based on RPMs? This is probably highly unnecessary but I just wanted to pass the recommendation on to you and let you ponder on it for a second or two.

Thanks again Ken and I look forward to trying out the new code later.

What reason would there be for making the min duty for PID a curve or table?

Ken

mattd860 · Post by **mattd860** » Thu Jul 19, 2007 11:04 am

muythaibxr wrote: I'm not sure I understand the question... basically if after you get off the throttle, the MAP is above the threshold, and RPMs are staying the same, and it's been whatever you set for PID delay seconds, the code will go into the PID loop. It'll also go into the PID loop during the normal conditions, meaning when rpm goes below the threshold, TPS is closed, etc...

Just ignore this question because it's stupid and will get answered when I do some testing later today. I was just referring to the rpms staying steady during the PID timer countdown which holds the duty cycle at last known + adder. Since the rpms are remaining below the rpmdot/second threshold, will the lockout code kick in and start PID loop before the timer ends? Or is the lock out code disabled when the PID timer starts? <- again, you don't have to answer this as I am fully capable of figuring this out later.

muythaibxr wrote: What reason would there be for making the min duty for PID a curve or table?

Ken

Well, for me, which isn't the case for everybody i'm sure, when the target rpm calls for a duty cycle well above the min duty for PID, I do get some oscillation of the valve which is probably due to PID not finely tuned although it works ok when the A/C is on. Currently the min duty for PID is 32% which gives me an rpm around 800. But when then target rpm calls for 1200, I'd like it to drop right to a different min duty for PID which prevents the rpms from ever dropping lower than 1200 until the coolant warms up. During the warm up, the min duty will scale down to the lowest amount set by the user.

Again, there are much higher priorities and being that is summer time, the coolant temps rise to fully warm within about 5 minutes so the 32% duty cycle is fine within 3-5 minutes. But I just wanted to lay the suggestion on the table see what you thought about it.

mattd860 · Post by **mattd860** » Thu Jul 19, 2007 2:53 pm

Ken, so far the code works great. No problems what so ever. I also fine tuned the PID again and it works just the way I want it to. I will let know tomorrow how the idle works after a cold start. Thanks again!

-Matt

mattd860 · Post by **mattd860** » Thu Jul 19, 2007 3:51 pm

Ken I also wanted to state that my previous request to make a min pid duty table isn't worth it, which you probably already knew. I got my PID to react properly now and not over/under shoot.

mattd860 · Post by **mattd860** » Fri Jul 20, 2007 4:14 am

Drove to work this morning without any problems. Idle is smooth. Thanks Ken!

Post by **muythaibxr** » Fri Jul 20, 2007 7:34 am

Good. So I'll call this feature done!

Now this weekend I'll be able to concentrate on the list of bugs that's built up!

Ken

Post by **muythaibxr** » Sat Jul 21, 2007 3:49 pm

Alright, Distributor mode should work now, I believe I have found and fixed all the bugs.

So I'm going to go through the bug list tomorrow, and if I have time, I'll probably do some other things with EAE that I was thinking about doing.

Ken

mtlcafan79 · Post by **mtlcafan79** » Sun Jul 22, 2007 6:13 pm

My dakota runs on beta 5. Guess I should have waited a little longer for 6. lol...