PID control - why is the overshoot so long?

[adamkse]

Soroush, I am not quite sure what you mean about the resolution of my pwm converter. do you mean it should have more samples? i have tried up to 10k but it makes no difference.

I have a attached my vi. it is quite messy but you should be able to see what is happening

in the mean time i will try again wth the ziegler nichols method.

Adam 

[Soroush]

When you increase the frequency of a PWM converter you will lose resolution of the pulse width provided that your hardware has a strict bandwidth limitation. Could you try low frequencies for the "DAQmx Write.vi"

Soroush 

[adamkse]

Yes I understand that. My PWM is for a servo motor so it needs to be 20-50Hz. Surely this is low enough for a good resolution when using 1-10k samples? Is there a way I can view what I am writing to the ctr0 pin? 

[Soroush]

I do not know, but it is a good idea. I am still pretty sure that the answer to your problem is not a golden secret set of PID parameters since the output of your PID is not driving the motor as it should and as you expect.

[adamkse]

I guess you are correct.

I will try and see what I am doing with the PWM later on today to see if I can improve it.

[adamkse]

I just had a thought. Could this possibly be happening when I enter large step responses because the controller output will give a PWM signal that is in the saturation range meaning that the problem is due to a non-linearity error?

[KF_]

As long as you have anti-integrator windup in your PID, saturation is not really a problem. I think standard labview PID's have this, although you need to put the right maximum controller values, i.e. 0-100%.

[adamkse]

I do not have the anti-windup feature wired at the moment but I have done it before so I can try again with that. My PWM duty cycle is around 1-9% so I am unsure how to do this? How can I know what the max and min controller outputs will be? I know that you can put a limit on them but I assume that I do not want it lower than what it can produce or there will be saturation, but if I have it higher then some duty cycles will never be reached.

[BlueTwo]

Hi Adam,

Have you checked you have the linearity input set correctly (as gsussman posted earlier). The PV shown in the graphs does look similar to what i have seen, as described by  gsussman.

Only running 8.6 so couldn't open your vi.

b 

[gsussman]

I just took a look at the code you posted.

I have a couple of observations regarding it's basic operation

1) The comment regarding the linearity I posted earlier is N/A. The VI you are using does not have the Linearity or Beta inputs at all.

2) Get some graphs of what your loop speed is doing as the VI runs. You have a timer, but you really have no idea of how much jitter you are getting as the code runs.

3) Your DAQ read is set up for continuous samples (100 samples @ 1kHz), but you have possibly up to 30ms of wait (due to the Wait until next ms multiple and Wait ms). Additionally you have no way of controlling the execution order of the wait vs. the DAQ read. I would get rid of the wait code completely and set the DAQ read vi up so that the acquistion of data is what gates the speed of the loop. It is not the perfect approach as the non-deterministic nature of Windows will introuduce jitter, but it is better than what you are currently running. Tailor the number of samples to acquire to set your loop rate (nominally you want the VI to have to wait on the DAQ read for the specified number of samples to be acquired). If you get more samples than you want, throw away the oldest samples and use just the end of the array.

4) Get rid of the property nodes inside the loop. Move them outside the loop and set them before the loop starts running. This will further minimize things inside the loop that required the OS to continually burn up time and introduce more jitter.

5) On the output of your PID.vi, you scale the output -200 to 200 = 0-100% but in the code immediately following, you further limit the output to 10-90%. Essentially your system will saturate (no change in output for change in input) when you hit 90% duty cycle, but your PID controller will continute to "wind up" for another 10% before it actually saturates. This will make it much more difficult to control the process as you have 10% of saturated response on either end of the PID. If you want the output to only be 10-90%, then set the PID up so it's output range is scaled to only give you an output that is -180 to 180 and get rid of the In Range and Coerce alltogether.

6) Get rid of the DAQmx Is Task Done.vi inside your while loop. The task is set up for continuous samples so by default it will never be done. It is simply wasting time inside the loop, possibly introducing more jitter.

7) Get rid of the charts on your panel. They are plotting the response of the system vs. loop iteration (NOT ms). Use a waveform graph or an X-Y graph to show the response fo the system vs. actual time. This will give you a much better idea of the true response of the system. The charts are distorting your data along the X axis because the loop iteration speed is not constant.

Of all of the suggestions above, I think #5 is probably your biggest problem.