Ken,muythaibxr wrote: In any case, it works as well as it can given the PWM output problem, so I'm done arguing it. The wonderful thing about PID controllers is that they can be done different ways. I chose the way I chose, it works for everyone who's tried it aside from you and the odd few who recently ran into bugs that were unrelated to the PID loop itself, so I'm done discussing it. If you don't like the way it works, go write some code that works the way you want it to. My code is a PID controller, and it does work the way it's supposed to. I'd fix the code if anything you said made me think it was broken, as I don't want bugs in my code.
Ken
I want to second everyone else's comments, thanks for taking the time to talk through this - between here and MS forums, I know there is an awful lot of time invested. It's my own fault since I don't let things go if I'm not convinced, but I feel this (in the end) creates the best output of any development project.
One more thing before the meat of it, I'm not saying this is a 'bug' in that the code is broken, and does things which it shouldn't. I'm saying it's not a PID controller, and (in my and others' experience) tuning your three "P, I, and D" constants as you would in a genuine PID controller doesn't yield the right results. I've done it 'by feel', and it didn't work too well, and then I did it 'by the book' and again I had issues. And the math doesn't support it either.
I'm appreciative for the help in getting my own car working. And if there's more to it, then I'd like to know, for my own edification.
I don't want to repeat myself from the other forum, but the very first part of any PID lesson saysmuythaibxr wrote:That doesn't matter, the point is that no matter how much engine speed changes, eventually with only a P term set, the delta will reach 0. The only reason it wouldn't is if your P term is too high, and it overcorrects, overshooting the target. This is EXACTLY what can happen with a P term that's too high.OK so next iteration of the loop, I now have a valve position of 54%, and lets say RPM dropped to 1200, because the valve closed some on the last iteration..
Now you have to be kidding me. Your motor was at 1600 rpm. That's 26 revolutions per second, or 37milliseconds per revolution. Now I forget if you run 200 ms loop time or 100, but either way, you expect me to believe in 5 revolutions you dropped 400 RPM, all from cracking a valve a couple percent? I can kill the ignition and my motor won't drop 400 revolutions per second.
output = Kp * error
for a P controller. It's inherently not going to settle, except for 'drag' in the system (say fluid resistance, heating of a spring, etc, dampening energy out). Changing P should only effect the magnitude. P is your spring in a harmonic oscillator.
And, think about it, what's the purpose of the "I" term? The I term is in there to remove DC offsets from the P term controller.
The point is, with a proper proportional controller, you get a quick response, as well as a natural braking as you approach your setpoint. Not 'prediction', just what you would naturally do. If you have your foot on the throttle, and you're trying to get to 50 mph, as you get from 40 to 45 mph, do you back off, or press harder? I back off, since my error is now small.
OUTPUT += Kp * error
Will press harder.
And this will allow a rapid response to something like a sudden unexpected load (turning on headlights or AC), by having a much larger P term. I'm pretty convinced now that P is MUCH smaller than it should be, because in order to make something stable with your system, if must have a small P to work.
When you have a system TOTALLY timescale independent if Ki and Kd are = 0, then you'll be in the ballpark.