Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Saturation in PID
#1
Hi All
I am having a strange problem on an actuator. My actuator is a positioner, so its work is to move from a position to another (the motion time is ~1 sec), wait 30 s to 1 min and then restart.

Occasionally, after few minutes (or hours) that the actuator is performing such motions, it does not arrive correctly at the target position, but start to oscillate. We don't think is a temperature effect, because the temperatures of the actuator or the motor are only at +1.5 deg C than the environment.

In the attached plots you can see the position and the current flowing into the actuator, gathered at 2250 Hz. The blue line (actual position) of the position plot is a bit misleading: the mean value is centered to the target value (green line).

We have few candidates to this effect:
1) friction: we are developing some different models in order to replicate this effect, but at the moment none of them is working

2) saturation: is there some variable in the PID loop that can saturate and lead to effects like this one? The Integral Gain of this loop is quite high (i133=120000), as well as the the resolution of the encoder (131 counts per micron). Because the oscillations starts after some hours of operation, I think it could be a saturation on the integral path of the PID that can trigger events like that. Moreover, I can add that the frequency of these oscillations depends on the Integral Gain (the lower the gain, the lower oscillations frequency).

Is there a way to reset the register (in case it exists) that contains the integrated following error? I would like to try to set the integrated error to 0 when I am waiting in position in close loop for the 30seconds, avoiding too much integration in the waiting phase of my duty cycle.
I found the register "X:$000xA0/20 Motor PID integrated error residual", but apparently it is read-only.

Any suggestions?
thanks
gigi


Attached Files Image(s)
   
Reply
#2
If this is saturation setting Ixx63=0 will zero the integrator.
Reply
#3
Just to add to what Steve said. Setting ixx63=0 will zero the integrator. Setting ixx33=0 will freeze the integrator at the current value.
Reply
#4
(06-19-2013, 11:50 PM)bradp Wrote: Just to add to what Steve said. Setting ixx63=0 will zero the integrator. Setting ixx33=0 will freeze the integrator at the current value.

I understand that ixx63 = 0 set to 0 the output of the integrator and ixx33=0 freeze the integrator. But what I would like to test is to reset the input of the integrator (ixx63 reset also the input?)

I am currently running the tests and something strange appears: it seems that this strange behavior is accumulating during time. You can clearly see from the attached plots: the red line is the actual position, the black line is the commanded position and the blue line is my external reference. You can see that the overshoot at the end of the step is increasing and, at some points, it triggers the oscillations. During this test, I tried to set ixx63=0 and then again to its nominal value, hoping that this will clear the variable that is accumulating, but nothing changes.


Attached Files Image(s)
   
Reply
#5
A few more items. You should be using d:$9E as this is the integrated error. There are no read only registers just perhaps the servo puts a value quickly back in the register. Error residual means the fractional part of the error.

When you set i163=0 you will clear $9E. When you replace i163 the integrator starts from zero. You can test this by placing a small gain in i133 once $9E has a large value. Set i163=0 then back to its value. You will see $9E slowly change from zero based on the position error.

As we discussed in the office about this problem, i believe something else is happening. Each time the blue line finaly stops increasing is when there is a jump on the red. It looks like something is sticking and then releasing. Then when it goes unstable the values on red and blue seem to get somehow out of phase which is what will happen when you drive the system with a large integrator and the integrator goes unstable. My feeling is that your system is being driven mostly by integrator and not much by proportional gain. Then something happens and the response of the integrator which must wind up and wind down and this happens too slow (as is normal in such a configuration) and it goes unstable.
Reply
#6
(06-20-2013, 10:21 AM)bradp Wrote: A few more items. You should be using d:$9E as this is the integrated error. There are no read only registers just perhaps the servo puts a value quickly back in the register. Error residual means the fractional part of the error.

When you set i163=0 you will clear $9E. When you replace i163 the integrator starts from zero. You can test this by placing a small gain in i133 once $9E has a large value. Set i163=0 then back to its value. You will see $9E slowly change from zero based on the position error.

ok, thanks, I can try later this.

(06-20-2013, 10:21 AM)bradp Wrote: As we discussed in the office about this problem, i believe something else is happening. Each time the blue line finaly stops increasing is when there is a jump on the red. It looks like something is sticking and then releasing.

Sorry, I forgot to mention that this particular test has been performed with the backlash compensation ON (however, the one that I showed you last week was OFF); the little jump that we can see here on the red line is the backlash comp kicking in; however, the effect of "gaining" errors (or similar) is independent from the backlash comp, the behavior is the same with the backlash comp OFF.

(06-20-2013, 10:21 AM)bradp Wrote: Then when it goes unstable the values on red and blue seem to get somehow out of phase which is what will happen when you drive the system with a large integrator and the integrator goes unstable. My feeling is that your system is being driven mostly by integrator and not much by proportional gain. Then something happens and the response of the integrator which must wind up and wind down and this happens too slow (as is normal in such a configuration) and it goes unstable.

Ok, understood. As you suggested last week, I took some time to re-tune the controller. Yesterday I came up with a new PID gains, where I drive the actuator mostly via proportional and feedforward, with less integral action. So far, (~10h of continuous motion), the actuator does not see any degradation on the steps. Hope this will solve that issue.

Thanks a lot for your kind help
gigi
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)