PID control - why is the overshoot so long?

[adamkse]

Hi,

I just got a chance there to try out the vi. I understand what you tried to do and I think that you might on the right track but unfortunately it did not work. After observing what is going on I don't think that there is a deadzone specifically at 45-55%. I was reading more information on these type of motors and from what I understand there are deadzones between each possible position. I have a large stepdown gearbox so I did not think this would be a big problem. I tried changing the resolution of the duty cycle but still couldn't get it.

[Soroush]

Ahh, I was really hoping that it could solve the problem. Could you upload the new charts when using the dead zone remedy vi? I would much like to compare them with the charts you had already posted in the beginning of this thread.

Soroush 

[adamkse]

Here are the new graphs. It does stick as much as it did before, it is more jumpy as you would expect but it still takes far to long for it to come down to the setpoint.

In case you are wondering I convert the PID output to a percentage then because to a number for the duty cycle, this is why the actual PWM is offset on the graph.

I have tried changing the numbers but it either causes sharp changes in control signal making the output oscillate around the setpiont or it pretty much goes back to the way it was before.

Adam 

[Soroush]

These are quite different from the other charts, posted in the beginning! The problem I was addressing is not here anymore. I wonder why you are still complaining!!

Anyway, the only thing that I can think of now, is to use a low pass filter on the measured data. If you already have it, try reducing the bandwidth considerably until the ripples in the "position" disappear.

Soroush 

[gsussman]

Adam,

Your most recent graph looks like a "relatively" well behaved PID response. The tuning may not be optimal but it does not look horrible.

A couple of things that might improve your response:

1: Increase the filtering on your position signal: When using the derivative term, noise such as exists on your position signal, will cause the derivative term to bounce around and cause the postioning to be more jerky. You want to preserve the general shape, but get rid of all of the high frequency stuff. Your position graph should look like the purple one I freehanded in.

2: Once the extra smoothing has been added, try to increase your derivative a little more. This should minimize the first overshoot and get you on position a little faster. You could also probably increase your "I" term a little as well.

3: You will need to know how much lash you have in your gearbox. If there is a significant quantity of lash between the servo and the load, it will cause the system to behave in a more jerky fashon. When the servo reverses direction, it may need to turn a degree or two before the lash is taken out, thus allowing your "I" term to wind up a bit, causing either over or under shoot.

One way to test this would be to get your load at the 50% position. Use a low frequency sine wave as a direct injection to your duty cycle signal (values from 30% to 70% duty cycle) and plot the position and the PWM% on the same graph. If gear lash is an issue, the top and botton of your position signal will be flat for a portion of time. The longer the plateaus are, the more lash you have in your system and the more difficult it will be to control your load (think about trying to steer a car with really loose steering).

[adamkse]

Soroush, 

I was not complaining I was just saying that I am still having the overshoot problem, which I am. Thank you for your help with this but I am pretty sure that it has not solved it. I was using a median filter before but I removed it in case it was causing any problems but I added in a low pas filter with a bandwidth of 2hz which smooth out the signal really well but as you can see in the graph below the overshoot still lasts for several more seconds than I would like.

 

gsussman,

thanks for suggestion, I have no idea how much backlash I get because the system was pre-existing when I started using it. I will try you suggestion and see what I get.

Adam 

[gsussman]

I would stick with the median filter. I looked at the response of it and a low pass filter and liked the median better. Just increase the rank to provide a smoother output.

[Soroush]

In the above setpoint vs. position chart, from time 4.5 to 8, the position is frozen. Could you take a very close look at your control signal (duty cycle of the PWM) during this interval? If you attach a picture of the zoomed in control signal, it would be great.

Moreover, I really would like to have a look at the vi that has created the above chart. Could you upload your current code too? 

Soroush 

[adamkse]

Here is the graph of the backlash test. I fond it very hard to have the ball in the centre but  managed to get a sine wave to oscillate the ball and there doesn't seem to be flat tops/bottoms.

 

Here is a zoomed version of that exact graph from the last post. I had not run the vi since I copied the graph. 

 

The vi is quite messy because I have been changing lots of things. 

[gsussman]

The problem seems to be occuring when your contol signal is right around the 50% mark, this also is where the PID Remedy vi is active.

For the time being case it out and allow the signal to be sent to the counter unaltered. I think that this might be what is causing your slow response.

The PID remedy is holding the output steady while the input is slowly dropping. This causes the process to not react to a change in the output, thus the PID continues to wind up until we get outside the threshold for the PID Remedy vi and the system reacts with too much error and thus overshoots.