PID, was OPC, PID

M

Thread Starter

Mario de Sousa

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
 
Hi,
I am new to this as well. I have been wathching
the mails and some are very interesting. While
I have seen a lot in algorithms and PID controllers,
I have not seen anything on the user interfaces or
is this not a part of this project or am I just too early!!

My particular interest is distributed I/O on Linux. I used Opto22 stuff in the past and about to start a design of it on RedHat based on AC28 PCI card. I also have one question as what is the target code ?
Are we planning to use Ladder in iterperated mode
or generate some kind of compilable code to run
(I like this more as it is a lot more efficient).
Thanks for your thoughts.
Bob-


_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
C

Chothani, Chetan

Mario,

Your vision for the Plug-And-Play Lego blocks kind of approach is definitely possible and I'm sure quite desirable. The only question this raises is that of sequence of execution. If the final run-time engine is designed like a ladder, the user would have to place the individual algorithm blocks in proper sequence to ensure correct execution order. This adds a lot of
responsibility on the user. If some of the Oft used algortihms are built into the PID the user is freed of this responsibility and the chances of
error are minimized. The individual algorithms within the PID may be turned on or off from the configuration.

Both approaches have their own pros and cons. We can all mutually agree on a certain approach and go forward with it.

chetan

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
C

Chothani, Chetan

PID Update:

It seems there is a lot of interest in the PID Algorithm and a lot of good suggestions have been made. I'll take the lead in compiling the
specification for the PID Algorithm and send it to the list for comments. Based on the responses to the comments I'll compile the first-cut spec and we can add it to the documents directory in the CVS. As a by-product of this discussion we might also be able to define some other functions such as Filter, Ramp, Gain+Lag etc.

Implementation:
My boss from my day-time job who is an absolute wizard at controls has agreed to help me with some of the Algorithm definitions and so on. His
specialty is Model Predictive control, however I'm sure he will be able to give me good guidance for the PID Algorithm. I'll include this info in the specification I send out for comments.
As for the actual coding It depends on my work schedule with the day time job. I have to travel quite a bit with my day job. However once the spec is finalized It will be easy for others to collaborate with the final coding.

Hope this plan of action is agreeable to all.

cheers

chetan


_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
M

Mario de Sousa

"Chothani, Chetan" wrote:

> Your vision for the Plug-And-Play Lego blocks kind of approach is definitely
> possible and I'm sure quite desirable. The only question this raises is that
> of sequence of execution. If the final run-time engine is designed like a
> ladder, the user would have to place the individual algorithm blocks in
> proper sequence to ensure correct execution order. This adds a lot of
> responsibility on the user.

Yes. I started thinking about this on my way home. Maybe we could include several sample linuxplc.conf files that could show how to configure normally used configurations for everyday users.

> If some of the Oft used algortihms are built
> into the PID the user is freed of this responsibility and the chances of
> error are minimized. The individual algorithms within the PID may be turned
> on or off from the configuration.
>
> Both approaches have their own pros and cons. We can all mutually agree on a
> certain approach and go forward with it.

Maybe we can go with both approaches? Have the module implement each individual block but also include a super-block that has all these often used features.

--
----------------------------------------------------------------------------
Mario J. R. de Sousa [email protected]
----------------------------------------------------------------------------


_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
C

Chothani, Chetan

> > If some of the Oft used algortihms are built
> > into the PID the user is freed of this responsibility and the chances of
> > error are minimized. The individual algorithms within the PID may be turned
> > on or off from the configuration.
> >
> > Both approaches have their own pros and cons. We can all mutually agree on a
> > certain approach and go forward with it.
>
> Maybe we can go with both approaches? Have the module implement
> each individual block but also include a super-block that has all these
> often used features.

Does this mean we implement all blocks separately such as Filter, Ramp, PID and then implement a block called Super-PID ?

This approach is probably the best. We can call the other block functions directly from the Super-PID and thus the footprint of the codebase won't
increase significantly. This will accomodate all classes of users.

Chetan


_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
R

Ralph G. McDonald

Hi Chetan:

I believe that you are on the right track to implement each block ( Filter, Ramp, PID, etc.) as a separate function.

This will allow greater flexibility for the end user, but will also allow each function to be thoroughly and independently tested.

This will also allow for future expansion of the "super function" block, and allow for some reuse of tested functions in new or custom "super function" blocks.

Some of the blocks that you are coding may be useful outside of the PID loop, for example the filter block in signal conditioning.

Keep up the good work:

Ralph

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
>I have not seen anything on the user interfaces or
>is this not a part of this projet or am I just too early!!

Too early, mostly... though there is a beginning of a text-based MMI in the CVS if that's what you are after.

Other than that, you're too early :)


>I also have one question as what is the target code ?
>Are we planning to use Ladder in iterperated mode
>or generate some kind of compilable code to run
>(I like this more as it is a lot more efficient).


Right now it's generating compilable code, but (like the MMI) it's just an interim quick-and-dirty thing, just so there's something there. It's in logic/il if memory serves.

Eventually - who knows?

Jiri <[email protected]>

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
Top