Greg G

I thought I had it set to about a second, but looking at the logs, I had it at 3 seconds! Gotta lower that. Looks promising though!

JasonC SBB

Now that you have an idle up solenoid, use a bigger one. The objective is for the duty cycle to be the same without AC and with AC and solenoid active.

Brain, exactly.

Braineack

iTrader: (62)

greg, what is your min max rpm?

Greg G

Min 600 max 2200
Idle valve open duty: 60.2
Idle valve closed duty: 30.9
Min duty for pid: 30.9
idle activation adder: 300
Dashpot adder: 14.8

I set min to around where the droop goes. And max is the rpm at 60.2 idle valve duty. Still a relative mystery how to adjust min max. I know reducing the gap will dull the reaction of the closed loop code.

Greg G

Was thinking the same thing. Looking for a solenoid that opens fast, and lets in a bit more air.

Greg G

This shows the difference of changing max rpm, 2000 vs 1600 (ghost). It dampens the entire response. Thought it was interesting, and would help people understand it more...



I found the sweet spot for my car was 2000 rpm (from 2200).

Braineack

iTrader: (62)

It makes it less senesitive when you widen the rpm range. The trouble I was having once I hit my target was holding the RPMs steady, the valve was constantly making small adjustments. My step size is 0.4%, just that amount can cause my idle speed to move 50-75RPM. So the idle was smooth with the way I had it set, but there was alway a delay to find the target when turning off the a/c or flipping up the headlights because there was no P code to get it back to target, I had to do all the work and slowly work the valve to target.

Like I said eariler, I pretty much used the feedforward code as my P value and didn't care about it in any other situation. I realize how wrong I was with it.

P will never "find" the target, only get you there faster. I is what tracks and holds the target. D slows P down when it gets close to the target.

I dialed in at 500-2500 (from 700-1300), so close to yours, but my PID is sitting pretty at 20 | 16 | 4.

It does a much better job reacting with a higher P. When I flip on my headlights and cause a sudden change in load, the code actually does a great job preventing RPM loss. It doesn't dip per say, but the rpms hold just a little lower, then it creeps back up...so I know I can get a little more agressive with it.

Greg G

OK, that's different from what I saw. Lowering max rpm (effectively narrowing the range) made it less responsive? The ghost graph shows the response of the 1600 value.

From the MS3 tuning guide:
What gives?

Hmmm, looking closer shows that, while the relative value of the response is lower, the peaks seem to be higher! Perhaps it is more sensitive, if the PID values are adjusted!

Braineack

iTrader: (62)

It doesn't change the response, but the sensetivity, just as the manual says. P is all about the response.

Think about the sport of dominos:

Say you have 30 dominos (dc% range). 30-60% = 30% range to work with.
and you want to stack them in such a way that they reach point A to point B (rpm range).

If point B is further away from point A you have to space the domnios out much further from each other...maybe so far that they cant even hit each other when they fall.

Ok not the best way to put it, but apply that to the min/max rpm range:

Pretend the way you stack them in a row is not from toppilng over, but the point on a tachometer and the range in which each dc% change is made.

If the DC% stays the same and the rpm range is tighter, then the code will make the smallest of minute changes in the dc% as it tries to hold your target. Since it has a lot of DC% range to work in, but your telling it it works within a smaller RPM range, you're telling the MS that smaller changes in DC% affect the idle speed less.

By expanding the rpm range you space you make your DC% steps much more realistic to the actual RPM speed change.

so to summary (numbered pulled from air):

tight rpm range (700-1300) - megasquirt thinks a small 0.4% change in DC% equals 10RPM speed change.

wide rpm range (500-2500) - megasquirt thinks a small 0.4% change in DC% equals 50 RPM speed change.

so with a wide range it's less likely to hunt around and make the changes that cause the idle to oscilliate around.

Greg G

Ah. Thanks, that was a pretty good explanation-- makes it a lot clearer in my head. Just to add another example-- this is max rpm 2000 vs 1800 (ghost).



It is more reactive, judging from the peaks of the response, whereas the one for max 2000 seem more blunted at top. I suppose that shows a need for D to dampen P it as it reaches target. More PID tuning is in order once you adjust the range.

Moving to another topic...I also logged different settings for the compressor delay, documented as follows:

2.2 seconds


1.5 seconds


1.1 seconds


0.8 second


I think it's a toss up between 1.5 and 1.1 seconds for the delay. Probably longer than for the MS3 because I don't have the instant response from either the idle control valve or the extra air solenoid.

I will also increase the idle timing for spark table 3- I think MAT correction is pulling it down a bit, unlike when I used the idle advance feature.

JasonC SBB

A few things I notice now. I see a couple of problems.

First about halfway through the bottom screenshot your idle duty maxes out even though the RPM hasn't reached the setpoint, and hardly moves as the RPM oscillates. This tells me the engine is oscillatory even if your idle duty were running open loop. Part of that is the huge "throttled volume". Part of that is you *still* have wimpy amounts of P. One piece of the solution is, you need to make the idle timing correction slope much more aggressive (more later).

2nd, your solenoid isn't doing squat. As soon as the a/c request comes in (which I can see by the timing jump), the MAP isn't even bumping up to show that it's letting air in. You need to use a much bigger solenoid.

The initial RPM dip, when it bottoms out, doesn't produce a large aggresive peak in duty cycle. That's what a large P would do. A large D would add to it, adding duty% as the RPM is sloping downwards - the net P+D should cause the duty% to peak before the RPM reaches bottom. This is what I mean by D being "anticipatory". Because the duty% appears to ramp up at a relatively constant rate, it still appears to have weak P and D, and lots of I. i.e. the initial ramp up of duty% appears to be driven by I and not P+D. Either that, or the code somehow limits the rate of rise of duty%.

Second, looking at the "0.8 second" screenshot, the duty% doesn't even react at all until well after RPM is on its way down. The code has huge lag. You can't have a control system control something if it sits there for some time after the controlled output has been disturbed, before even beginning to react.

HST, there is some visible D effect visible in the "1.5 second" shot. The duty cycle initially ramps, then flattens, then ramps again. This 2nd ramping up begins while RPM is dropping - the dropping RPM is what drives duty up.

As for the oscillation even while duty% is relatively flat. It is obvious that this system has huge lag due to the throttled volume. That is, even without a PID closed loop system, if you abruptly open the solenoid, it takes a long time to fill the throttled volume with air and thus it takes a long time for the engine to react. It needs help. The idle timing slope needs to be aggressive, because an engine will react instantly to a change in timing. What I want to see is that the timing changes aggressively with RPM oscillations.

However in order to make it effective the engine has to be running at an average timing of ~10* with AC on. This is because at 20* timing, there is very, very little additional torque if the control loop decides to advance the timing to 22*. A change from 10-12* will have a much greater effect. What this means is, no more table switching to 20* with AC, but rather, have a large slope, circa 10* timing change for every 300-400 RPM error.

Overall, Greg's efforts are a bit futile here unless the following points are addressed:
- the code has to react more quickly
- there needs to effectively be much more P and D
- his add'l air solenoid needs to be much bigger, the goal is that the duty% needs to stay flat as AC comes in and out.
- idle timing control needs to be more aggressive

JasonC SBB

Here I drew in orange how a strong PD would react to the initial drop in RPM. The duty% would rise up very quickly and peak *before* the RPM reaches bottom. And would begin to react as soon as the RPM begins to drop. Compare against the white trace.



Of course if the PD were actually that strong the RPM wouldn't dip as far, and the resulting duty% trace would be different....

Greg G

Well that's a big piece of meat to chew on!

1. regarding the timing adjustment. The general consensus is to have flat timing and flat AFRs, to avoid disturbing the system. Anyway, you want me to try aggressive timing changes at 750 and 500 rpm/30/35/40 kpa, like a hill from 950rpm/30kpa to 500rpm/40kpa?

Roughly:
1000 rpm- 12 degrees
750 rpm-- 14 degrees
500 rpm-- 16 degrees

Like that?

2. Re: throttled volume. Is it like the air seen at the intake manifold is out of phase with the relocated throttle body? Cos I have no tps just yet. Or is it like a big can where the small volume of air from the solenoid is just absorbed, as opposed to a small can?

3. Code. Well that i can't do anything about. Other than give suggestions

JasonC SBB

1. That's the general idea, but more aggressive than that. You are able to run 20* timing with AC on, so perhaps make it go from 10* at 1000 RPM, to 20* at 500 RPM.

2. When the solenoid opens, it needs to not just feed the engine, but fill up that entire volume. That's a lag in the system. With a smaller volume, there's less lag from having to fill up the volume. In a control system with lag like that, big D is needed to counteract it. And the timing thing.

Greg G

Todays objective was to get the code to drive the idle valve as aggressively as possible. I reduced max rpm to 1800, as discussed in the posts above, to make the code more sensitive. This required a retuning of the PID values. After over 30+ logs, I found that any P value over 85 was uncontrollable even at max D (200). At that P, I could run a max I of 20, any more would destabilize it. Strangely, if I lessened I, it also destabilized it.

Anyway, it looks like the goal has been met-- idle valve is being driven more aggressively (compare it to the graphs in previous posts). The high D is also apparent in the blunting of the peaks. As far as the idle droop is concerned, it seems to have been decreased by 100 rpm.

P85 i20 d150


P85 i20 d200


Looked almost there, but the P was still high. Not wanting to lower it, I tried increasing the hysteresis of the PID target from 30 to 40. And this happened...

P85 i20 d200 hysteresis 40


The hysteresis I think helps soften the overshoot by giving a "fatter" target. So a hysteresis of 40 will make the target 975 +/- 40 rpms. A range of 935 to 1015 will tell the code that it has reached target. It effectively acts like more D...

My curiosity piqued, I logged the hysteresis of 40 vs 10 (ghost). The peaks of the idle duty have been chopped off as compared to 10 hysteresis.


And 40 vs 50 (ghost) apparently stops the PID action too soon. Too much chopped off the peaks. Somewhere near 40 is the sweet spot. For my car at least. Will work on that...maybe it'll allow me to run just a bit more P...

JasonC SBB

Hmm, looks like a lot of P but very little D. The duty% sinusoid is out of phase with the RPM, and doesn't "lead" it. With enough D, the duty% sinusoids will be shifted a bit to the left relative to where it is now.

Greg G

That's max D already.

I was gonna say I wish there was a way I could shift the curve to the left...I suppose the only way to do that is in the code, in 2 ways:

1. tweak the closed loop PID implementation to make it do that, or
2. allow a hardware trigger (PE1) to raise idle duty (% adder) with the signal to the AC relay. That arbitrarily shifts it way left.

Does Ken visit MT? Matt, Ben, care to weigh in?

Braineack

iTrader: (62)

Ken visits here sometimes. just PM him at msextra and ask him to visit this post.

JasonC SBB

Greg, the shift left I was talking about, was about the sinusoids/oscillations. With strong D, the duty% will peak while the RPM is dropping. This is what makes D "anticipatory". It produces a correction, while the RPM is dropping, rather than producing duty% when RPM error is largest (bottom of dip) as P does. When the system has a lag, the only way to stabilize it and have decent response speed, is to use enough D.

Here's a control system analogy.

Imagine you stretch your arm out and you are holding a long rubber band. At the bottom of the rubber band is a small platform hanging in the air, with a weight on it. You are trying to maintain the platform at constant height, moving your hand up and down as needed.

Firstly, this weight likes to oscillate up and down by itself even if your hand isn't moving. A large throttled volume is like having a very soft rubber band (as opposed to a stiffer one). A softer rubber band tends to oscillate up and down more, and at a slower speed, than a stiffer one. Additionally, as you react to move your hand to correct the height of the platform, it responds slower than if you had a stiffer rubber band, and you need to move your hand more aggressively.

You can see this in your earlier logs where the RPM oscillates even though the duty% isn't doing much.

Now imagine someone suddenly adds weight to the platform - this is the AC turning on. You need to raise your arm to compensate. More so with a soft rubber band, because it stretches more from the added weight. And as you raise your hand to compensate, it wants to oscillate.

In order to kill the oscillation you have to move your hand up and down in a manner that kills it; you need to "lead" the oscillation - kinda like "leading" the target when clay shooting. D does this - you raise your hand as the platform is dropping even though it hasn't dropped far yet - you don't raise it only when it bottoms.

In idle control, D does this by increasing the duty% based on the rate at which RPM is dropping, as opposed to how far it's dropped (which is what P does).

And your larger throttled volume requires more D.

The D in your plots is not sufficient to kill the oscillations, because it has very little "lead" - the duty% sinusoid is merely an upside version of the RPM sinusoid. This is P acting. D would cause the duty% to be shifted to the left some - this is the "leading" action.

There is a fly in the ointment. If the code has a large, fixed time lag - e.g. if the reaction always comes 200 ms later, and 200 ms is > 1/10th of the period of the oscillation, it will be near impossible to fix the oscillation. IOW the presence of a fixed 200 ms lag cannot quell oscillations with faster than a 2s period. Also, if the code clamps the rate of change of duty%, this is like placing a lag on the reaction of duty% when it needs to react big. Period is the time from one point on the sinusoid to the next, such as the time from one peak to the next. Looking at the plots, at the time from when the RPM begins to dip, to the time the duty% begins to rise, it appears marginally OK.

From how I understand the code, the way to increase D further is to narrow the RPM range. It will act like an overall multiplier. If you're at 500-1600 now, try tightening that to 700-1300; you will have to halve your P and I, but keep D. Also increase your max duty% to 100%. This will also increase your gain by making your duty% swing wider for a given PID output. Keep the minimum duty% if you are sure it is equivalent to fully closed.

Greg G

In idle test mode, anything over 60% duty didn't change the rpm. Or does changing it to 100% affect scaling?

Am at 600-1800. Will try tightening the rpm range for more sensitivity, and retune PID accordingly ( or rather keep D and retune p and I.).

Thanks for the tips!