PID control - why is the overshoot so long?

[adamkse]

Thank you very much for the reply.

I have a few questions for some suggestions.

3) I am not quite sure what you mean? Do you want me to have the daq read the samples in a time faster than I send pulses? For example I want to send pulses at 38 Hz so I would need to read less than 26 samples at 1khz so that it has all the samples before one pulse is over?

5) If I make the limits 180 and -180 then when I get one of these extreme values, e.g.. -180 then this will give me a 0% output which I cannot write. Do you not mean that I should have the limits higher to 222 and -222 so that it never reaches these values and can only get within the 10-90% range? Another problem is that I have no idea what the max and min outputs can be.

I think I can manage the rest ok. I will do this tomorrow and let you know.

Thanks again

Adam 

[gsussman]

Adam,

Your counter code (PWM generation) is set up to generate a continuous PWM pulse train. If you just started it and did nothing else, it will generate that frequency and duty cycle train forever. While it is desirable, you don't have to be there to change the pulse train on every single iteration. 

If you want your system to update at a 38 Hz rate, then everything inside your loop must complete in under 26ms.

You want every iteration of the loop to have to stop and wait on the DAQ Assistant to acquire enough samples to return. If you get to the DAQ assistant and it already has the required samples in the buffer and returns immediately, you are trying to run the loop faster than your computer is capable of and will result in significant jitter of your control system.

As it is set up right now, your DAQ Assistant vi alone will require 100ms to complete (100 samples @ 1 kHz) so this is really gating the response of the loop to a maximum of 10 Hz. Add in the Wait until next ms multiple of 20, the Wait ms of 10, their indeterminate execution order and the time required to execute the rest of your code and your loop response could be significantly different than what you think you have.

Set the number of samples to acquire in your DAQ Assistant to 20 and leaver the freq at 1000 Hz.

5) If I make the limits 180 and -180 then when I get one of these extreme values, e.g.. -180 then this will give me a 0% output which I cannot write. Do you not mean that I should have the limits higher to 222 and -222 so that it never reaches these values and can only get within the 10-90% range? Another problem is that I have no idea what the max and min outputs can be.

I had an error in my math, what you want is to use 160 and -160 as the output limits (cluster input into the PID.vi). When the PID is generating a 100% signal, it will come out as a value of 160. This is then passed into the EGU to percentage.vi with max and min limits of 200 and -200. An input value of 160 will generate a 90% output signal. -160 will generate a 10% output signal. This will ensure that the output of your PID will always generate a change in the output signal for any change in in the PID controller output AND, never be able to go outside of the 10-90% duty cycle limit.

Another simpler approach would be to simply get rid of all of the scaling code between the PID and the DAQmx Write.vi and make the PID output 0.1 to 0.9. If you want to perform the scaling so that you can display the data on charts and graphs, do this seperately. When you get things working correctly, you can put a case or diagram disable strcutre around your display code to further remove processing from inside the loop.

Message Edited by gsussman on 03-30-2010 01:48 PM

[adamkse]

gsussman,

I tried to set the number of samples to 20 @ 1khz but it freezes my computer and I have to restart to be able to use labview again. I do not know why this is.

For the PWM, I did as you said and I get values between 10% an 90% which is good. The PID output does saturate thought, it can output values around -200 min and 200 max but I am not sure of the precise values. I cannot change it to output to between 0.1 and 0.9 because it just jumps between these values. I think it is supposed to be used for saturation limits, not for scaling. I think this because when I set the limits to -1000 to 1000 then I still only get around the -200 to 200 max and min outputs but when I lower is it reaches the max and min limits I specify.

I have attached the vi again with the graphs fixed and what I think shows the change in loop time. The samples are still 100 and the indicators are still there for the moment. I cannot get the graphs to scroll along automatically unless I click autoscale but then it just squashes it all up as time goes on. I think that they are now against real time. 

 

Message Edited by adamkse on 03-31-2010 01:24 PM

[gsussman]

Adam,

I am not sure what is going on with your data acquisition and the system lockup. That is something that is probably better handled through NI technical support.

Before going any further, there are some parameters that would be helpful to know.

1) Your requirement for a 38 Hz rate on the output, it appears that this is really the frame rate for the servo and not really a requirement of the control loop speed. Setting your counter frequency to 38 Hz  accomplishes this task. If your control loop is running slower than 38 Hz then the counter will continue to generate pulses at 38Hz with the last specified duty cycle until you tell it differently or stop it.

Another thought on that is that the output rate of 38 Hz seems a bit odd. Common servo frame rates are 40 and 50 Hz. Where did this 38 Hz requirement come from?

2) Is the 10-90% duty cycle an output limit that your have imposed to keep from saturating the loop or is this something that the manufacturers specifications list?

3) What is the actual range of the position sensor read by your DAQ Assistant code? This is not the input range of the channel (+/-10V) but the actual sensor values when the servo is at the 0% and 100% positions.

I also changed the DAQ Assistant code to acquire 100 samples at 1 kHz, as your original code did. This should provide a control loop rate of slightly less than 10 Hz. When you get the loop working at 10 Hz if you want to go faster, you can modify the samples to achieve this.

I have modified your code a bit and scaled all of the inputs and outputs from the PID.vi to deal with signals in the 0-100% range. This should provide tuning numbers that are normalized to the system operation.

Take a look at the vi and input your input (sensor range) and output (PWM range) values. Run the VI and start your tuning process again starting with a Kc = 1. I think you will find that your results are more consistent with standard PID operation.

[adamkse]

gsussman,
 
Thanks for taking a look. I see what you did and it is very good. I have these results that work quite well:
P=0.73625
Ti=0.06892
Td=0.01378 
 
 I read multiple different values for the frequency of the servo motor, some say 50hz and some say 33hz. As fas as I know it does not really matter too much what the exact frequency is, only that you give it the correct high pulse time.
 
the 10-90% is actually 1-9% for the duty cycle. labview likes to receive the duty cycle other than the high time and low time. through experimenting, at 38Hz i found that 10% was fully one direction and 1% was fully the other. 
 
the sensor readings can range from 0.24 to 5V, this is why the setpoint slider goes from these values but i guess it doesn't matter if i compare them as percentages, they will just need different limits.
 
I still have the problem with the overshoot lasting very long but it may be due to the loop time issue.

Message Edited by adamkse on 04-01-2010 03:32 PM

[adamkse]

I managed to get the program to run with 20 samples @1khz with your vi but i get this error:

 Error -200301 occurred at DAQmx Write (Counter Frequency 1Chan 1Samp).vi:1

Possible reason(s):

Cannot update the Pulse Generation property.

The pulse generation with previous property settings must complete a full cycle before the property can be updated.

Task Name: _unnamedTask<41>

I guess I have to put some kind of wait to allow the pulse to be written before I write again?

Message Edited by adamkse on 04-01-2010 04:04 PM

[gsussman]

This error means that your control loop must allow the counter at least 1 full period of the base frequency before it will allow you to update the duty cycle again, thus the maximum rate of your control loop will be constrained by the frequency of the counter.

I think if you stick with 100 samples (.1 sec) then you should get adequate performance from the control system. Additinally I don't think the overshoot is a funciton of the control loop rate. It appears like a tuning issue, like not enough "I"

What method did you use to get your tuning values? Generally if one method does not work to your satisfaction then try another method. I have found that I will often get different answers for my tuning using the different methods.

If you had been using the Ziegler Nichols method, try the trial and error method. I have found that on most systems this will yield me the best results. (http://zone.ni.com/devzone/cda/tut/p/id/3782#toc2)

Also remember that the I and D terms are in terms of intergral and derivative time so smaller numbers  =  more integral or derivative.

[adamkse]

Ah OK I see.

I have been using the Ziegler Nichols method, trial and error and the autotune in the vi. The current value is from the autotune but no matter what, I can't seem to get rid of it. I will try again on Tuesday because that is the earliest that I can get back to it.

Thanks again for all your help.

Adam 

[Soroush]

Hi again,

I had some time to catch with the messages here. There were informative replies and I made and attached a possible solution.

All the required explanations are written in the block diagram as a rather long comment.

Soroush 

[adamkse]

Hi Soroush,

Thanks for the vi, I will take a look at it on Tuesday, unfortunately that is the earliest I can get access to labview.