I had another discussion (argument) with a friend of mine who doesn't want to get too involved (time commitments) otherwise he would register and post instead.
I also read the entire previous PID control discussion thread and finally feel I'm at a point where I know what's going on. Here's the pseudo-code he gave me which is a commonly accepted PID control algorithm:
Also I think it might be nice to delete the past posts (mine and Fred's comments) as they get us almost nowhere and were really headed down the wrong path.
I seem to have fallen into the trap of trying to make a PID controller much more complicated than it needs to be, as well as inadvertently turning P terms into I terms (led astray by VEMS's implementation which I now realize does this improperly too, but maybe not to the extent that MS did). Let's start over.
Well I wasn't really going to get involved but I couldn't take it. The code I provided Ben is readily available, it is just the simple algorithm of a PID controller, that is what I feel should be implemented. Other blocks (objects) can be later implemented such as deadbands, saturation, slew rates, etc. Code should be implemented, like building blocks, keep things simple, and if you need additional features implement them in another block.
Also, PID tuning is a PIA and any tools that can be coded to ease its implementation is helpful, such as idle tune wizard. But that's another thread.
The only way to do it effectively is to do statistical analysis on the data log. For example, the HVAC controls I work with look at the average deviation and number of set point crossings to tune the variables. Even then, it requires human logic to determine what the tuning period is (usually 30 mins for our purposes), and other limits to determine valid operating ranges and conditions.
After all of that, they actually haven't enabled the automatic functionality since they introduced the analysis ability 8 years ago.
What I am saying is it's hard to do automatically.
I personally think we could get better control/easier setup with fuzzy logic. If you guys make the PID function modular enough, I could write a fuzzy function that is interchangeable with the PID portion. Basically swap functions depending on what the end user feels more comfortable tuning.
My suggestion is, keep autotuning out of the basic building block, and keep the function very simple as far as what variables are passed in and out of it so other algorithms can be dropped in its place.
I might post some more ramblings later today.
Keith MacDonald
Control Engineering (Systems) Technologist
Wow, this thread died. And I'm 6 kinds of ass pirate for not keeping up on it since my last post.
I'm not sure if the limits belong external. Two pieces of psuedo code which call the PID control:
Idle_Output = PID_Cont(Current_Setpoint, IDLE1*note)
If Idle_Output > IDLEMAXCONST
Idle_Output = IDLEMAXCONST;
If Idle_Output > IDLEMINCONST
Idle_Output = IDLEMINCONST;
etc etc ad nasuem, all these checks would have to be written in the code, each and every time you call ANY PID function. Lame, and much more work for someone doing the coding. *note:{I dunno what this is, a struct which holds all the state information like Ki_prev, or else these variables would still be alive somewhere, current setpoint, etc}
If the limits are considered in the routine, it would be generic.
Value = Get_PID_Output(Current_Setpoint, Idle_Struct);
Check_Error = Set_PID_Output(Idle_Valve_Port, Value, Max_Physical_Val, Min_Physical_Val);
In this, you wouldn't need bunches of code before and after each call of the function. The Idle_Struct would have all the limits built in, all the current and past values, etc. The PID function would return the mathematical answer (there's still hardware limitations, you wouldn't set duty cycle to 113%) to the PID problem.
Then all the "work" of setting up ANY PID function would be in the defining of the struct. All limting, speed, etc, would be handled by this. The PID function itself would get the time and calc dt each time.
Also, this would be nice for setting up weird/complex limits, when the struct is defined at runtime, you can do your calculations once.
Am I way off on this?
edit: Keith, I'm with you on the autotune thing. It would be cool if you could have a tool to help you pick stuff out by eye. You might be able to tune DC values automatically, but even if you wanted to, I'd make it a stand alone function.
So, forgive the ignorance of someone who things object oriented is just a guy who likes a girl for all her stuff: Can we do that? Can we define a struct/variable/etc which basically just by existing
1) Defines the limits, and basic behavior of a PID control
2) Stores variables between "calls" such that we know what happened last time
Abe, now is your chance, bump from the past, this is soooo your bag baby (Austin powers style). Get going and whip us up some PID code to end all other PID implementations. Somewhere I have a good link on this stuff, I should post it here if it hasn't been already.
