AbeFM

iTrader: (3)

This type C thing bothers me. I just don't get calling that a "proportional" controller. It's an integral controller. Which is semantics and there's no reason to get my panties in a bunch over it, but it sure is annoying. I know you didn't invent the term. :-)

I'm very curious about getting all the lock outs working, I had this issue, too, all the time. It made NO sense, before, when I thought the controller contained a P-term... It would be impossible to get stuck at 3000 RPM with a P-term in the equation. If you were idling many times higher than the target, the valve would close. And I-term would cause... the valve to close. And D-term wouldn't come into play, except to slow the fall.

I'll have to read the other thread to get the answers about "what do you do when the closed and open idle values have nothing to do with where the engine idles with the valve closed or open.

Mark, what do you idle at with the valve closed? What do you idle at with the valve open?

Marc D

iTrader: (7)

Ken,

I tried the settings you suggested, it seems to be working ok, but I still get "locked" out occasionally, if thats what you call it. It would idle the highest setting for "open valve" and it wouldn't settle, but idle would oscillate at that idle speed. Its getting annoying.

It was worse when I had set my RPM adder to about 200, so I set it to 400 and it wont do it often, but it will till occasionally lock out.

Another thing I noticed, the target RPM is never really "reached." I have it set at 850 for fully warmed up, but it always idles around 1000-900. I've stopped messing around with the PID's but I will try to work on them some more.

One more thing that bugged me is when I came to a stop, the idle didnt directly "drop" to the right RPM i specified, It always drops about 100-200 rpm higher, goes up a little bit, then finally rests. Sometimes after very heavy load changes, the idle oscillates quite a bit. I guess I gotta keep working on those PID terms.

Abe,

If you're referring to settings in the MSQ, I set my closed idle to 700, and my open idle to 1700-1800, cant recall (on my mac right now). With my bleeder set, I idle at 750-800 with the valve completely closed. My DC on the idle is always around 32-35% DC. I may loosen the bleeder valve a bit 'til the idle settles at 800-850 with my DC at 28%

AbeFM

iTrader: (3)

Ah, makes sense. My car is controlled entirely by the idle valve, i.e. closed valve is stalled, and open valve is ~5,000+ rpm. I think you just have to pick arbitrary numbers.

AbeFM

iTrader: (3)

How bad is the buzz, frank? I run it at a multiplier of 8, and it doesn't bother me at all.

muythaibxr

Can you post a datalog of this occurring? I want to see specifically what's happening, and see if it's PID engaging while you're in overrun, or if it's PID not engaging when it should. Either way, I should be able to suggest good settings for the lockout stuff if I have a datalog that shows the bad behavior.

If you have the min and max RPMs reasonably close (500 and 1800 are the settings I use for most engines), you should be able to get very close to the target by increasing the I term. I would not mess with the D term at all as it tends to dampen the P and I term and make them less sensitive. I don't use D term at all on any of the engines I tune.

It's not going to drop directly... that is what the PID delay setting is for, and as I was telling Abe, the behavior I was going for here was to match most OEM setups. Those do not go immediately back to the idle RPM either. They sit a little high for a few seconds, then slowly drop back to the target. This is to "catch" the engine when it's decelerating and keep it from stalling.

If a very heavy load change is causing a lot of oscillation, you may want to use the idle advance setting to help add timing when load increases or take out timing when load decreases. This can help the idle code not have to change the valve position as much, allowing you to tune a slightly lower P term to get rid of oscillation.

Also, You can get into oscillation if the area that you idle in is not "boxed in" both for timing and fuel. When the load goes up does the AFR go leaner? richer? After it starts oscillating does the AFR bounce around? IF you answer yes to either of those questions, then you have some fuel table tuning around idle to do. Otherwise the idle code will start fighting with the changes to AFR that the extra load causes and you'll get into an oscillation. Running a lean AFR around idle can make this worse, as can running too much advance at idle.

The code tends to work a bit better if you set your idle screw so that the engine idles 200-300 RPM lower than the your lowest target RPM. Changing the bleeder to give more air may hurt.

Also, an exercise that will help get better response is to see at what duty does the valve actually start affecting RPM. The way I figured this out on my rx7 was to purposely open my idle screw a bit so that it would idle at 900 rpm (100 above my target) with the idle valve all the way closed. I then turn on something that drops the idle below the target (headlights in my case) and watch the idle valve duty and RPM. I then make a note of the duty where RPM starts to go up again. That is the lowest duty you should ever let PID go to. This test is best done with cool IATs.

Ken

muythaibxr

With a multiplier of 8, PID idle will be nearly impossible to tune correctly. Having Jean's frequency multiplier is a must if you have to set the frequency that high.

Ken

WestfieldMX5

Pretty bad actually, I tried different numbers, but it would always be there. That and the slow starting were the key factors to remove the MS. Does an NB start better on full sequential injection?

muythaibxr

Plenty of people who are smarter than I am are using it. If it works for them it works for me. It's not an integral controller, it's proportional. It only makes a difference if the conditions change where an integral controller would continue making a change as long as the target doesn't match.

There are only 2 lockout settings. The RPM one and the MAP one. All the other settings are for controlling when it gets into idle in more normal situations. If the lockout settings are causing a problem, you'll never even get into PID, which means that PID has nothing to do with the problems you had. It was never engaging! Please read the thread over at msextra about what each of the settings do.

The controller DOES contain a P-term. It only affects the valve position when the RPM changes. This is exactly the same way that the kind of standard P controller that you are talking about works, except that its response becomes smaller the closer that you get to the target. I chose the type-C controller so that things like AC coming on would result in a large response from the controller, keeping the engine from stalling. Did you read the page I linked about the different types of loop? All of it?

I could easily give the P term the behavior you're looking for but then the response to sudden load increases would be bad. For boost I'm going to switch to a type-B loop to more quickly account for target changes, but in idle the target does not change often or quickly, so there's no need.

I labeled them that because for 90% of the cars out there, setting them that way works fine. That said, they really just bound the conversion to unitless percent, and therefore affect the sensitivity of the algorithm.

Marc D:

Have you had a chance to get me a datalog yet?

Ken

muythaibxr

Just a couple more tips for tuning PID:

1) Tune I first with no load on the engine. Set it as high as you can without getting oscillation. Do this with P and D set to 0. This should get you very close to your desired target.
2) Set P between 50 and 100, and turn on your air conditioning. If it stalls, set P higher, if it catches the idle and keeps it from stalling, but oscillates a lot, set it lower. Repeat until the behavior is what you want.

It's really that simple. Sometimes setting the control interval too low can make tuning a bit more difficult, I usually recommend using a setting between 50 and 100 (I use 70).

Make sure that the CL idle indicator is coming on in the tuning software. This will help a lot in telling what is causing whatever issues you're having.

Ken

AbeFM

iTrader: (3)

You're right, it would continue to change, and an integral would be proportional to the amount of error. It's a D-term, I did the math once a long time ago, about what your D-term really was (not an attack, calling it "yours", I just mean the one you are implementing)....

But traditionally, a derivative term is something which reacts to the instantaneous change in RPM from sample to sample. At first glance, when RPM makes a rapid change (a drop, let's say) it looks like you respond proportional to the rate that the RPM changed in a fixed amount of time, i.e. d(pv)/dt.
Which tells us that the equation should reduce the the difference between the current RPM and the original RPM, and the valve position should be the valve position it started at plus a difference proportional to this initial RPM.

Which makes me think that to really do this right, you would want to seed R0 with the target RPM, and C(0) with the baseline valve position (I'd recommend the PWM-warmup positions, or some other number to be supplied by the user)... Then you would have a system which is a P-controller when used in P-only. It sure looks weird, but it would work. The only issue is not taking the RPM from when the PID loop first gets activated to seed this R(0), but to use the target RPM, and the best guess (i.e. the previous valve opening, minus the adder - which you could add in but not in the equation, let the controller recover that difference)....

Then I bet the thing would behave better.

Of course, lockouts (Again, Kudos for the CL indicator!) are more my problem than the rest, still, I think this would help it to behave. Its a bit counter intuitive, but the math doesn't lie. As I said, the only weird issues is coming in and out of PID, which I think means reseeding the R(0) each time.

Does it do this? Could you make it? Maybe I'll upgrade to the latest beta and try it, but I'd much rather you wrote it, Ken, since you actually are good at that sorta thing and I just scribble on whiteboards a lot.

Ah, here's what I was always wondering (and if it's just a label, fine!)... Do those have to be the limits? If I could just give you two points (or even just have the computer grab it like setting the TPS), but allow the valve to go further? Can I set "what valve position gives me 1800 RPM", but allow the valve to go further than that?


Yeah, that's one thing - you often don't notice how something works (i.e. a stock car) until you have messed with it, then you think how it SHOULD work, not how you've seen it work.

Certainly that catching is the biggest issue I've seen.

Ken,
Can you use this even with PWM warmup mode? I'm sure I could lose 800 rpm that way. I've sort of built that into my fuel/timing maps... Actually, its based only on MAP? Then is there a difference between that and tuning your ign maps...? Just curious.


So you DO want a flat response down there? For my non-CL idle, richening and advancing down low keeps it from stalling, but I could run a flatter map in order to make the CL work better.


I'm sure I have way too little...


Is this what the (as I understand it, broken but will work) idle valve test mode does, so you could do it more slowly?



That's something that never made sense, probably a question for the MS forums. Certainly I've had the motor catch and run for a revolution or two if there's fuel in the runners, then stall (being run by the starter), then fully start, telling me the MS knows when to spark (I'm in banked mode), but is choosing not to fuel. It's very strange and seems eminently fixable.

muythaibxr

So which is it Abe? A D-term or an I-term (like you said before).

Abe, there's nothing wrong with how it behaves now. In all your explanation, you're leaving out the fact that I add the output of the PID loop to the current valve position (or rather you gloss it over), which means you have to take the derivative of the actual PID math. The derivative(integral(x)) gives you x in this case. If I was using my current math without adding to the current position, then yes, what is now my P term would be a D term, the I term would be the P term, and the D term would be a 2nd derivative term. But since I'm already integrating the whole equation by adding the output of the previous time through to the current output, I had to take the derivative. This is exactly what is detailed in the typeABC link I provided (by someone who has a very large amount of experience in the industry working with control theory). If I switched the loop to a typeA loop (still taking the derivative of the entire thing, esentially change 2 lines of code), it would behave exactly as you think it should. The problem is that the behavior you're looking for is undesirable because it would make it difficult to actually catch the idle when the AC or other load is added.

The code is always seeded with the current RPM when going into the PID loop so that you have a smooth transition into it.

You're right, the math does not lie. Because I'm adding the previous position to the current PID output, it is necessary to take the derivative of the entire equation in order for it to be a proper PID loop. It is further modified to make the P term respond equally to changes in PV (RPM) regardless of how close to the target you are. I made the decision to do this in order make response to sudden load changes faster.

No, It's actually better to take the current RPM as the position because then you don't get a violent response when PID is enabled. You get a nice smooth ramp to target. The current code also has a ramp-to-target feature that will take whatever rpm you're at when the code is engaged and make that the target, then slowly ramp the target down to the final target. This allows you to set a very large P-term, which makes catching idle speed decreases much faster.

Again, the numbers are just the bounds for the conversion to unitless percent. You can go above (or below) these numbers without hurting anything. I labeled them this way because in most cases setting them the way they're labeled provides a good balance of tunability and sensitivity. The actual affects to the PID loop are that making the closed and open duties further apart makes the code more sensitive. Making the rpms closer together makes the code more sensitive. Setting the two so that the lower RPM matches the lower valve setting and the upper RPM value matches the upper valve setting makes them usually makes one balance the other out. You can change either of them further apart or closer together arbitrarily in order to help response.

Why should it work differently? The way the factory does it is best for catching the engine when RPM is falling (push in the clutch for example), and is best for catching situations when load or IAT increased since the last time their "learning" (in our case PID) algorithm was active. This also saves time on the ECU since the PID algorithm does not have to be active when RPM goes up and accuracy on other parts of the system are of utmost importance. The factories know what they're doing, they spend millions of dollars and man-hours figuring it out. We modify our cars because we like to tinker, or we want more power, but that does not invalidate the algorithms the factories use to control their engines. Therefore, I believe the right way to go is to emulate what they did. There are reasons for what they did.

You don't want stalls, so it's best to catch the RPM a little high, and slowly drop to the target.

Try it out, idle advance is completely independent from closed loop idle speed control.

You don't want to have differences in AFR that can make RPM change on their own. Otherwise the PID code will fight with the changes that the varying AFR are causing, and create unrecoverable oscillation.

I'm not sure what you mean here. Idle valve test mode is fixed in the latest 2.1.1 beta (which we're not going to update any further) and in the latest 3.0.x alpha.


The MS starts fueling at the same time it starts sparking. There are other factors, like how much fuel does the engine need to actually fire for example that can cause issues. When I've seen the behavior you describe, increasing the cranking PW at that CLT has helped.

If you want to continue to argue about the PID code, please take it to msextra.com. There are people in this forum who just want it to work and don't necessarily care what we think about whether it's correct or not. I'd like to stop cluttering this thread with our argument and get back to helping the users get their closed loop idle working.

Ken

AbeFM

iTrader: (3)

Sure, and I'm not trying to bash, but to better understand and suggest what improvements I think will genuinely help. I'm learning a lot. :-)

Just to be clear, to understand how to set it up (I'm sure many of my problems come from this).. The valve will or will not go outside those bounds? If I set a valve position that idles at, say, 1,500 RPM (call it 30%), I'll never see the PID code set the valve to 31%?


That's what I was getting at, if poorly. The average person doesn't try to understand how something works until it becomes a problem. These behaviors (not rushing directly to target) are there in the factory control, but people don't notice it, so they expect your code to do something else - i.e. how they think the factory behaves, not how it actually behaves.

Most certainly will. Is it more than advance verses MAP?

Makes sense, though I'm a bit confused - how do I determine an AFR change that makes RPM change? I increase load to get RPM to drop, then they do, and if AFR goes up, or down, how do I know what's wrong?

Could you try to explain that in more detail?


So there will be no V2.x release version as the final? Pardon my ignorance, will the V3 code run on MS-II?

That qualifies as fixable. If that's really the case, awesome! I will definitely be looking at this, I've had to crank two rotations all the time.

muythaibxr

That's all well and good, but many of the changes you are suggesting will not actually improve things, but instead will make them worse. For example, I already tried the ideal PID (I had a curve of "start values" and pid always modified the start value) and had several people test it. It didn't work. It wouldn't respond well to large changes in load, and as MAT climbed, the values needed changed.

I switched to the current method of adding the PID output to the last known position but with type A, and it had less problems, but still would not respond well to the AC coming on. I settled on a type C loop after finding that it essentially does exactly what is needed.

Your suggestion to change the "seed" of the P term is also not good. I tried it the way you are suggestion in my development, and had a user report that every time PID engaged, the valve would open before closing... RPM would go up every time it engaged. The fix I added was to seed the P term with the current RPM.

That's the last I'll say of it here. If you want to continue, we'll continue in the proper forum for such things (and anyone who is interested can come look).

The upper and lower bounds for the valve position are just that, upper and lower bounds, the valve will not go above or below those values. However, the upper and lower RPM are not hard limits. They are used only for the conversion to unitless percents. If your valve opens to a point that takes it to 2000 rpm, and your upper RPM setting is 1500, the code will not stop the RPM from going to 2000 rpm.

OK, I misunderstood what you were saying there.

That's how I usually set it up, although you have to be careful here too, getting the AFR steady all around will help. You can get into oscillations due to idle advance as well as AFR changing.

I can usually tell by fixing the AFR change while the oscillation is happening. If by fixing the AFR change the oscillation goes away, it was the AFR change that was causing the issue. Generally you can tell this is happening by just looking at the AFR and valve duty in a datalog. You'll get a situation where both change in a sine wave fashion but opposite to each other (AFR goes up, rpm goes down, PID corrects by increasing the valve duty, AFR goes down, rpm increases more, PID corrects by decreasing valve position... oscillation).

The final official release of ms2/extra 2.1.x is 2.1.0b. I had originally planned a 2.1.1 release with a bunch of stuff backported from the ms3 1.0 firmware, but decided that in the interest of time, I would not do that. So now all ms3 1.0 changes that I'm going to backport are backported to ms2/extra 3.0.3.

I recently saw issues like this on my rx7 as it got colder. I fixed them by increasing the cranking PW. Be careful not to go too high though. Increasing the cranking RPM to 100-200 above where you actually crank can help too, as well as tinkering with skip pulses (making it lower usually helps).

Ken

AbeFM

iTrader: (3)

Marc,
Any updates from the Real World? :-) Very interested in this.

AbeFM

iTrader: (3)

Ken,
Er, where is the beta? I can only find the release? My old links might have broken when the board was down....

Heh I found it but closed the window and lost the link. Will post the firmware in the first post of the baseline MSQ thread once there is one. It's really confusing because "version 2.1.0" can actually refer to several incompatible versions, so you have to have the date code.

Marc D

iTrader: (7)

Still trying to figure it out.

Im getting a datalog of it tonight. Didnt really have time to lug around my laptop with me, but its friday night, and theirs plenty of time.

Zaphod

@Abe - here you go:

MS3EFI • View topic - Firmware

he original link was lost at the big crash at msextra.com.

Greets

muythaibxr

PMing you my phone number in case you have any questions.

I'll be out of service on and off tomorrow (doing a little rock-climbing in an area with a bad signal tomorrow for part of the day), but if it rings, I'll answer, and I'll be back home in the afternoon (EST).

Ken

AbeFM

iTrader: (3)

Awesome, thanks, that's a big help. A very handy thread.

Beware the "latest" beta is not the latest, and it actually has a bug. There's a 10/27 (that is, october) release which I think is the real latest. If it wouldn't step on any toes, I'd rename it "2.1.2" and post it on there so the world has a "go to" version. :-)

Marc D

iTrader: (7)

Ok, I was able to grab a datalog of the "lockouts" ive been getting, ive also included my MSQ.

Hopefully we can figure something out.