PID control - why is the overshoot so long?

[Soroush]

The zoomed charts are very interesting. I have modified and attached the PWM remedy vi. The comments are in the block diagram just like before.

Soroush 

Message Edited by Soroush on 04-08-2010 08:33 PM

[adamkse]

Thanks guys, I will do these both tomorrow but I was originally using it without the PWM remedy block and it was happening.

[Soroush]

Just a comment before you tell us about the new result.

In the third chart, in message # 49, the PID output is between 45 and 50 all the time. Since you have updated the high and low limits to 150 and -150 (I just noticed that) the percentage would be about 65%. Therefore, the PWM remedy vi will not have any effect if you are still using 45 and 55 inside its block diagram!!!

Make sure that when the position freezes, PWM remedy vi gets into action.

Then either of the PWM remedy VIs might work.

The first one is suitable if your motor driver has a predefined fixed deadzone, and the second one is suitable if your driver detects zero speed crossing and remains off until the desired speed is more than a prescribed value in either direction.

Soroush 

[adamkse]

Yes i know what you are saying but i think that it should still work because it is wired directly after the PID output% which is around 50%, the PWM remedy block output is then wired to the EGU block to generate a duty cycle based on the fixed PID percentage. All that is happening is that it is been scaled and offset. The 65%(really 6.5%) on the graph is my horizontal position duty cycle which is the 50% PID output(zero error). I hope this makes sense.

I added you new block and it seems to do what it is supposed to. It seems to work but i think i may have to move the limits to 40-60%?

Graphs are below: 

 

 The %span in and out correspond to the in and out of the PWM remedy block. The EGU output is the actually duty cycle and is the red line on the graph.

I also ran it again with the PWM remedy block disabled. And I had the same problem again with a long lasting steady state error:

 

[Soroush]

You're right. My mistake. It should work.

Regarding the new remedy block, I expect to see a saw tooth control signal after remedy block when it is active. Don't you think so? Probe the wires and see if it gets into action.

Have you tried 40-60%?

Soroush 

[Soroush]

Here comes the third version with a different idea!

Soroush 

[adamkse]

Hi again,

I tried to change the values to 60-40% and it does give the saw tooth control signal and the process variable oscillates around the setpoint.

I tried your new PWM Remedy and it works quite well but both of them seem to only work sometimes. The graphs below has the new PWM Remedy but when the controller is gradually increasing or decreasing the fixed control signal sometime follows it and sometimes sits on 50%. 

I tried 55-45 and 60-40, both having similar results.

 

[gsussman]

Based on what I see, it appears that the issue might be with the starting torque vs. the running torque of your system. When the system is sitting still, it will take more torque to get it turning (starting torque) than to keep it moving (running torque). This can often lead to what appears to be happening in your graphs.

After the inital overshoot and return, the motor comes to a stop as the error signal is no longer large enough to overcome the running torque of the system. Once the drive train is stopped, it will now require a larger error signal to overcome the starting torque. As the error signal builds, the motor stays motionless until the starting torque is reached. Immediately after starting, the torque drops off to running torque and the motor overshoots the position due to the magnitude of the error signal and the cycle repeats.

Try this test.

Start with the load stopped. Similar to the sine wave test for the gear lash determiniation, replace the sine wave input with a manual control for the PWM percentage. Start increasing the PWM signal in small increments from 50% to determine how much error signal you need to get the load to start moving. Once it is moving, start decreasing the PWM to determine the lowest PWM signal required to keep the load moving. 

 Try the PWM Limiter.vi attached in place of the PWM remedy3.vi and see what it results are.

You will need to set the values of the torque cluster with those values you determined in the starting and running torque tests above. If you need 55% PWM to get the motor moving then the starting torque is 5. If it takes 53% PWM to keep the motor moving, the running torque would be 3.

The inputs to the VI, both PWM and position are in percentage (%) so you will need to convert your inputs accordingly.

Message Edited by gsussman on 04-09-2010 01:27 PM

[adamkse]

Thanks for the reply and the vi. I will try on monday.

The Test you suggest will be very hard because the angle changes of the motor are extremely small and I cant see how I can manage to reduce the PWM signal fast enough to see the difference between running torque and starting torque. I will try it though.

Adam 

[adamkse]

Hi again,

Sorry I never posted yesterday.

I tired numerous values in the PWM Limiter but I could not get it do work. Sometimes the limiter signal would wind up just like the PID control signal other time it will sit constant while the PID control signal winds up. I was playing with the duty cycle and very small percentages seem to get it to move, around 0.5% moves the load very slightly.

Here are some graphs. One of then shows the limiter and pid signals being different and the other shows them being the same. On the one where they are the same, when t seems to be stuck in steady state error I increased both the starting and running torques gradually and by the time that the load began to move these values were extremely high causing the oscillations you see.