M
Hi Chetan,
I think you've just made yourself responsible for the PID controller module.
If you think you might need help integrating it with the smm, just send me an email and maybe I could help you out there. The smm interface isn't
all that complex if you're willing to go it alone.
It seems that nowadays what people call a PID controller is much more than a PID controller; it has all sorts of other transfer functions associated with it.
What I had in mind was to take advantage of the smm and do each transfer function independently. Thay may all be in the same module, but by using the smm each user could connect the transfer functions as they wish.
Some of the transfer functions you have mentioned:
PID controller filter (I assume low-pass, but could be other as well)
Lag function
Ramping
Some that other people have mentioned:
dead-band
limiting function
An example of what I am going on about.
Say you want a PID controller with a filter function for the input, a ramp function for the
setpoint, and a dead-band function for the output.
Say the sensor is connected to P0 and the setpoint
is set by some other algorithm and stored in P1.
This could be achieved by configuring:
Input Output
filter P0 P2
ramp P1 P3
PID P2,P3 P4
deadband P4 P5
Maybe we could even go to the extreme of extracting the summation function out of the PID controller (I mean the function subtracting the feedback signal from the setpoint, and outputting the error for the PID controller). Like this we could have every kind of feedforward/feedback controll architectures.
If somebody finds that they need a new transfer function, they could just implement that missing function and run it in another module without having to either re-implement all the other transfer functions, or having to dig into the source code of the beefed up PID controller to change it.
Could it be that I am just daydreaming? Could it be that the same control architecture is always used and that nobody is interested in this flexibility?
Mario.
P.S.
I'll be doing a little bit more of cleaning up in the smm, but I am open to suggestions as to what
other people would like to see implemented in there.
"Chothani, Chetan" wrote:
> The function arguments shown were for the sake of simplicity and example
> only. I haven't really put enough thought into it yet.
>
> I'm still struggling with a lot of questions on the algorithm and features
> such as:
> 1) Should we include a Filter for measurement noise reduction ?
>
> 2) Should the algorithm be PID Series or PID Non-Interacting ?
> 3) Output Tracking and Integral tracking ?
> 4) Anti-Reset Windup ?
> 5) Feed-Forwards ?
> 6) Internal Gain and Lag for Feed-Forwards or external functions ?
> 7) Setpoint Ramping ?
> 8) Setpoint Tracking ?
> 9) Built-In Cascade hooks ?
> 10) Self-Tuning ?
>
> and so on ...
>
> Anyway, didn't mean to hijack the discussion from the important stuff. If
> anyone has any opinions on the above questions please let me know.
>
> chetan
_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
I think you've just made yourself responsible for the PID controller module.
If you think you might need help integrating it with the smm, just send me an email and maybe I could help you out there. The smm interface isn't
all that complex if you're willing to go it alone.
It seems that nowadays what people call a PID controller is much more than a PID controller; it has all sorts of other transfer functions associated with it.
What I had in mind was to take advantage of the smm and do each transfer function independently. Thay may all be in the same module, but by using the smm each user could connect the transfer functions as they wish.
Some of the transfer functions you have mentioned:
PID controller filter (I assume low-pass, but could be other as well)
Lag function
Ramping
Some that other people have mentioned:
dead-band
limiting function
An example of what I am going on about.
Say you want a PID controller with a filter function for the input, a ramp function for the
setpoint, and a dead-band function for the output.
Say the sensor is connected to P0 and the setpoint
is set by some other algorithm and stored in P1.
This could be achieved by configuring:
Input Output
filter P0 P2
ramp P1 P3
PID P2,P3 P4
deadband P4 P5
Maybe we could even go to the extreme of extracting the summation function out of the PID controller (I mean the function subtracting the feedback signal from the setpoint, and outputting the error for the PID controller). Like this we could have every kind of feedforward/feedback controll architectures.
If somebody finds that they need a new transfer function, they could just implement that missing function and run it in another module without having to either re-implement all the other transfer functions, or having to dig into the source code of the beefed up PID controller to change it.
Could it be that I am just daydreaming? Could it be that the same control architecture is always used and that nobody is interested in this flexibility?
Mario.
P.S.
I'll be doing a little bit more of cleaning up in the smm, but I am open to suggestions as to what
other people would like to see implemented in there.
"Chothani, Chetan" wrote:
> The function arguments shown were for the sake of simplicity and example
> only. I haven't really put enough thought into it yet.
>
> I'm still struggling with a lot of questions on the algorithm and features
> such as:
> 1) Should we include a Filter for measurement noise reduction ?
>
> 2) Should the algorithm be PID Series or PID Non-Interacting ?
> 3) Output Tracking and Integral tracking ?
> 4) Anti-Reset Windup ?
> 5) Feed-Forwards ?
> 6) Internal Gain and Lag for Feed-Forwards or external functions ?
> 7) Setpoint Ramping ?
> 8) Setpoint Tracking ?
> 9) Built-In Cascade hooks ?
> 10) Self-Tuning ?
>
> and so on ...
>
> Anyway, didn't mean to hijack the discussion from the important stuff. If
> anyone has any opinions on the above questions please let me know.
>
> chetan
_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc