Attachment

[KevC]

Hello.

I have build a basic PID controller, using the trapazoidal rule (see atatched).

However my appliaction requires an anti windup feature to prevent the integrator from.......winding up!

When there is a large error applied to the integrator, the integrator stored value will grow (wind up) until the sign of the error changes.

I am having difficulty building the vi.

Having problems with items being a member of a cyle, and am not sure what to do.

I would appreciate some assistance, or alternatively does the PID block vi have this feature? 

Regards

Kevin

[KevC]

Apologies.

Here is the attachment.

[Kevin_Price]

I don't have LV on my network PC and can't open your file.  However, what I've done in the past was to simply implement saturation and reset features into my integrators.

For reset, I'd have a boolean input that I'd logically OR with the "first call?" primitive.  On a True result, I'd reset the integral to 0.  Most of my apps never wired the input so reset only happened at the beginning of the run.

For saturation, I'd use the "in range and coerce" primitive.  The Max and Min values would usually be +/- maximum allowed integral gain term.  The output is coerced to stay within that range, thus preventing excessive windup.

Another control scheme you may evolve into is "progress-based" gains.  For example: start your control loop with Ki = 0 until your error term becomes sorta small.  Then you can kick in an integral term since you won't accumulate as much error from this nearby starting point.  The general rationale for progress-based gains is to try to produce more favorable response characteristics than you could get from purely constant gains.

As for "items being a member of a cycle", I suspect you aren't using a shift register in a loop to pass your feedback signals to your controller.  If this sounds unfamiliar, search on "shift registers" and become famiar with them.  If you've programmed in C, they are sorta like variables whose scope is the loop they're defined in.  If you haven't, then nevermind.

-Kevin P.

[KevC]

Hi Kevin.

Thanks for the reply.

I had another look at the PID.vi

Is the range and coerce on the top left using Ki performing the same action as your described?

Thanks again.

Regards

Kevin

[Kevin_Price]

Is the range and coerce on the top left using Ki performing the same action as your described?

No.  Two problems.  First is that the Min & Max limits are infinity, i.e., no limit at all.  Second is that its in the wrong place.  It looks like it should go right after the + operator which is just after the 3-input multiply.  Thats where the accumulation is occurring, so that's where you should limit the value to prevent windup.

I don't immediately understand the extra manipulations inside the inner case structure and don't have time for more than a quick glance.  It may be ok for you, but it has a pretty unconventional look about it...

-Kevin P.

[KevC]

Thanks Kevin.

Thanks for the excellent answers.

So if I take the coerced value out of the multiply, and multiply this value by that coming out of the plus operator.

What values could I use for this aplliaction, is it something I need to test on the system and tune, or is it something that I can calculate somehow.

Regards

Kevin

[KevC]

Alternatively, would this work, I have added the comparison, and signal connect block.

I am using simple logic here, so that when |u|=100 (Max), Ki=0.

This should disable the integral action when the controller output saturates.

Regards

Kevin

[Kevin_Price]

Sorry it took so long to reply -- I lost track of the thread somehow.  I occasionally check the page that lists the threads I'm involved in, but it seems to sort them based on the start date of the thread rather than the date of most recent activity in the thread.  I'll have to see if I can change an option or something...

Anyhow, I'm afraid the last attachment doesn't look like a good solution either.  First and foremost, the "= 100" floating point comparison is a definite no-no.  Search threads here for floating-point equality.  You should definitely change that to test for ">= 100", and then probably change the 100 constant into a front-panel control named "saturation limit" so you can more easily vary it for experimentation.

It appears your method for limiting the integral term is to set Ki=0 when the saturation limit is detected.  This may be a problem depending on how the integrator vi is implemented.  There's a chance that once you achieve of windup >= 100 units, setting the Ki term to 0 may cause the integrator's output to remain constant at >=100 forever (until the reinitialize? boolean goes True).

I don't have the PID vi blocks available to look inside, but some of the wiring into the Integrator looks strange by comparison with the wiring into the Derivative.  I would expect wires going to similarly-placed terminals would have similar meaning, but that doesn't appear to be the case.  You wouldn't normally feed the result of the P gain and the D gain into the vi that calculates the I gain.  Not that it couldn't work if implemented properly, but it's pretty unconventional looking.

-Kevin P.

[KevC]

Hi Kevin.

Thanks for the reply.

I have finished this project. The very crude solution I posted earlier, worked, and I was able to attain some more than satisfactory results.

Thanks again.

Regards

Kevin