View unanswered posts | View active topics It is currently Thu Sep 19, 2019 10:29 pm



Reply to topic  [ 106 posts ]  Go to page Previous  1, 2, 3, 4, 5, 6, 7 ... 11  Next
PID control discussion 
Author Message
Moderator
User avatar

Joined: Tue Jan 15, 2008 2:31 pm
Posts: 15332
Location: Home sweet home!
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.

_________________
DIYEFI.org - where Open Source means Open Source, and Free means Freedom
FreeEMS.org - the open source engine management system
FreeEMS dev diary and its comments thread and my turbo truck!
n00bs, do NOT PM or email tech questions! Use the forum!
The ever growing list of FreeEMS success stories!


Fri Apr 25, 2008 3:45 pm
Profile WWW
LQFP112 - Up with the play

Joined: Thu Apr 10, 2008 5:51 pm
Posts: 205
Admin wrote:
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.

_________________
Keith MacDonald
Control Engineering (Systems) Technologist


Fri Apr 25, 2008 6:01 pm
Profile
LQFP112 - Up with the play

Joined: Thu Apr 10, 2008 5:51 pm
Posts: 205
ca7 wrote:
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%.

_________________
Keith MacDonald
Control Engineering (Systems) Technologist


Fri Apr 25, 2008 6:12 pm
Profile
Moderator
User avatar

Joined: Tue Jan 15, 2008 2:31 pm
Posts: 15332
Location: Home sweet home!
thebigmacd wrote:
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 :-)

_________________
DIYEFI.org - where Open Source means Open Source, and Free means Freedom
FreeEMS.org - the open source engine management system
FreeEMS dev diary and its comments thread and my turbo truck!
n00bs, do NOT PM or email tech questions! Use the forum!
The ever growing list of FreeEMS success stories!


Fri Apr 25, 2008 6:16 pm
Profile WWW
Post Whore!
User avatar

Joined: Sat Feb 16, 2008 12:11 am
Posts: 629
Location: Sunny San Diego
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.

thebigmacd wrote:
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. :-)


Fri Apr 25, 2008 9:04 pm
Profile ICQ YIM
Moderator
User avatar

Joined: Tue Jan 15, 2008 2:31 pm
Posts: 15332
Location: Home sweet home!
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.

_________________
DIYEFI.org - where Open Source means Open Source, and Free means Freedom
FreeEMS.org - the open source engine management system
FreeEMS dev diary and its comments thread and my turbo truck!
n00bs, do NOT PM or email tech questions! Use the forum!
The ever growing list of FreeEMS success stories!


Sat Apr 26, 2008 1:07 am
Profile WWW
LQFP112 - Up with the play

Joined: Tue Apr 08, 2008 9:14 pm
Posts: 160
You said it chief ;)


Sat Apr 26, 2008 1:18 am
Profile
LQFP112 - Up with the play

Joined: Thu Apr 10, 2008 5:51 pm
Posts: 205
8InchesFlacid wrote:
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.

_________________
Keith MacDonald
Control Engineering (Systems) Technologist


Sat Apr 26, 2008 2:59 am
Profile
LQFP112 - Up with the play

Joined: Thu Apr 10, 2008 5:51 pm
Posts: 205
8InchesFlacid wrote:
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.

8inchesFlacid wrote:
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.

_________________
Keith MacDonald
Control Engineering (Systems) Technologist


Sat Apr 26, 2008 3:12 am
Profile
Banned!

Joined: Sat Mar 08, 2008 3:57 am
Posts: 92
Location: Sydney, NSW, AU
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.

_________________
previously: ca7


Sat Apr 26, 2008 9:03 am
Profile
Display posts from previous:  Sort by  
Reply to topic   [ 106 posts ]  Go to page Previous  1, 2, 3, 4, 5, 6, 7 ... 11  Next

Who is online

Users browsing this forum: No registered users and 5 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
cron
Powered by phpBB® Forum Software © phpBB Group
Designed by ST Software for PTF. ColorizeIt.