PID control discussion

[Fred]

Nice, now, how would you two guys go about dealing with the engines rpm being outside the range you intend this to occur?

I'm guessing that because the output is calculated freshly each time that the fact you were just at 7k on the limiter and released the throttle doesn't matter? Or do you need to do the lock out stuff that Ken talks about with regards his solution for ms2e?

Tell me how you guys would do that.

Admin.

[thebigmacd]

Nice, now, how would you two guys go about dealing with the engines rpm being outside the range you intend this to occur?

I'm guessing that because the output is calculated freshly each time that the fact you were just at 7k on the limiter and released the throttle doesn't matter? Or do you need to do the lock out stuff that Ken talks about with regards his solution for ms2e?

Tell me how you guys would do that.

Admin.

Yes by all means lock out the PID control when outside of the idle window. If you want to get tricky, an easy trick is to make the requested rpm equal the actual rpm as soon as the system leaves the window. What this does is "freeze" the PID in its current state, so the integral keeps its same sum until the controller is re-introduced into operation, and the output stays at the last value that was calculated before the control was released from operation. There is no point in having the PID try to control something that it cannot. The output will drift and saturate unpredictably if you leave it in the loop.

[thebigmacd]

If you know your output needs to respond a certain way to an outside disturbance, you can model that response in the bias of the control loop. For example, A/C turned on, idle valve bias can be increased from 40% to 60% to compensate for the extra load. You know the load is going to increase when you turn on the A/C so bump up the output now before you measure the rpm slowing.

Right on the money. It is possible to initialize the output with the bias value on "startup" of the loop and get the same result, but if the bias needs to change while the loop is already controlling the system as in the example you give, the bias term needs to be tacked on the end so the entire PID isn't reinitialized every time the bias changes.

Bias is also really handy for translating an output to one where 0% is a negative output, 50% is a neutral output, and 100% is a positive output. You just apply 50% bias and even if you have Ki = 0, the output will still control around 50%.

[Fred]

If you want to get tricky, an easy trick is to make the requested rpm equal the actual rpm as soon as the system leaves the window. What this does is "freeze" the PID in its current state, so the integral keeps its same sum until the controller is re-introduced into operation, and the output stays at the last value that was calculated before the control was released from operation.

Perfect :-)

[AbeFM]

Man it's nice not to have everyone standing around looking at me like I'm an idiot when I say something valid. While better written, everything you said I've said over on MS-forums and been told I don't understand what I'm talking about.

Including the bit about using an input to determine the offset for the motor. My simple (input limited) way is using an A/D, putting all your devices on there, so each adds some voltage to the pin on the ECU, and the ECU adjusts offset based on that. It would work even for 'uncontrolled' "warm up" style idle valve control, just a straight offset. My guess is, in real life, that would totally work. But most things on modern cars have this output - my power steering, AC, and others have outputs to tell the rpm to kick up. You could even account for alternator load by looking at battery voltage verses RPM, and at some level decide you need more oomph based on it.

Yes by all means lock out the PID control when outside of the idle window. If you want to get tricky, an easy trick is to make the requested rpm equal the actual rpm as soon as the system leaves the window. What this does is "freeze" the PID in its current state, so the integral keeps its same sum until the controller is re-introduced into operation, and the output stays at the last value that was calculated before the control was released from operation. There is no point in having the PID try to control something that it cannot. The output will drift and saturate unpredictably if you leave it in the loop.

This I don't 100% agree with. Well, depending what the 'leaving the window' is. If it's RPM based that's bad, since you'll be too far out. If it's TPS based, then yes, you're golden.

I think with a good controller, the issues I've had with MS wouldn't be a problem, where most of the time I press the gas it's to save a stalling motor, so as soon as it gets back into "PID" control, it's got horrid values. Even worse when it's idling too high (from a warm up, I think), it will "idle" at 6,000 rpm since it was the too-opened start value, plus the 'dashpot adder' (could we PLEASE name our variables less cryptically, at least on the front end?).. I dunno, I haven't thought it out much yet, but I can tell you from the driver's seat it doesn't work right. Too many pockets of bad control, in whatever you might call it. Control space?

Also, your diagrams would be better if the left side were labeled "set point". Heh... An arrow going to nothing is weird. I love that controller though - only I don't know if it would work for something like idle, you don't really choose a "acceleration", you choose a valve position. It seems like that loop would generate the input to a PID for awesome control.

[Fred]

Fix the ms2e code and prove your point in hard facts!

"dashpot" whatever the fuck that is and all other arbitrary names from ms land are gone. new or industry standard names will replace them. names chosen by the people (including me :-p) that mean what they are. I want the code to make sense and naming of variables and associated tuning fields (which should match 1:1) should be correct or at least as best we can make them.

It's not hard to build a new s19. Put your math in there, and reuse the tuning vars and whatever else can work, and see how it works. If you can tune your version and post a datalog of it working mint, $5 says James and Ken at least are reasonable blokes with the best intentions and will take your patch as they have taken others fixes.

Make it so scotty! (can I call you 5" !flacid?)

Admin.

[GartnerProspect]

You said it chief

[thebigmacd]

But most things on modern cars have this output - my power steering, AC, and others have outputs to tell the rpm to kick up.

Subaru have an output to disable the A/C. Even better than this, as far as I can tell this is used at WOT to allow more power to the ground, but it is also used at idle: it won't let the A/C run until the exact moment it adds the corresponding bias to counteract it.

[thebigmacd]

This I don't 100% agree with. Well, depending what the 'leaving the window' is. If it's RPM based that's bad, since you'll be too far out. If it's TPS based, then yes, you're golden.

TPS for sure.

But depending on the answer to the following question, perhaps TPS and RPM.

The question is, is engine braking stronger with a closed idle valve or an open idle valve? If it is stronger when open, you may want to freeze the PID when decel fuel cut is enabled so that the valve doesn't shut trying while bring the idle down.

Some OEMs do it like this: if decel fuel cut is not on, and if the throttle is shut, and either the clutch is in or the transmission is in neutral, THEN enable idle control.

Also, your diagrams would be better if the left side were labeled "set point". Heh... An arrow going to nothing is weird. I love that controller though - only I don't know if it would work for something like idle, you don't really choose a "acceleration", you choose a valve position. It seems like that loop would generate the input to a PID for awesome control.

Sorry, threw that together in a hurry. The output from the inner controller to the motor is the valve pulse width/position. It treats the valve position as an acceleration control. Remember there is an outer loop to tell it how it should be accelerating based on what the rpm currently is.

I have a neat program somewhere that i wrote that shows how it all works out, but im not sure where.

It would work but I don't think it should be implemented. I was just trying to show how a PID is just one of many types of controller that will do the same thing.

[Costa]

If the PID is “frozen” and the output is changed by other code, as soon as you “unfreeze” the PID the output will jump back close to its last calculated position. PLCs have a handy feature called Set-Output in the PID function. Set-Output back-calculates the integral term, to allow the PID to continue working smoothly when “unfrozen” for the new output.
(a PLC is a Programmable Logic Controller) http://en.wikipedia.org/wiki/Programmab ... controller

Smith-Predictor is great when you have a delay in your input (process variable/PV) and you want a fast acting PID loop. Not used much as it can be difficult to implement. The Smith predictor requires a delayed output (control variable/CV) for the predictor/corrector calculations. This is achieved in digital systems by sampling the current output and loading the samples in to a FIFO (first in, first out) queue. As you can see this can take a lot of memory.