PID speed control

[GerdW]

Hi Silver,

I feel speed estimation is good.

How do you determine speed?

Is it time between pulses or do you calc number of pulse per time interval?

- When you measure the time between the pulses you should increase the loop rate in the FPGA to minimize errors from time measurement.

- When you measure the number of pulses per time interval you get errors due to a fixed time interval.

- As you only (seem to) get one pulse per revolution you can only calculate a new measurement value after the next revolution has finished. At 3000rpm you have an uncertainty of 20ms, at 300rpm its already 200ms, at 60rpm a full second…

[Silver_Shaper]

Hi Andy

I have tested with smaller step-down (2000 to 1000 rpm) and overshoot was not there and the response is good. Regarding feedforward am still not familiar with the implementation, might take some more time.

Today had a chance to test the PID with setpoint profile and as guessed the lag was very high with the current gains. So, increased the gain values to get the desired response. I have a doubt that why this difference in gain needed when using setpoint profile. What is the use case for setpoint profiling? Just curious to understand.

[Silver_Shaper]

Hi Gerd,

I am measuring the time between the pulses. I understood the uncertainty. Thanks for the info and Kudos.

[AndyClegg]

Hi - I am not sure what exactly you have tried with setpoint profile. Your original graphs show you used step changes to setpoint, and the LV Setpoint Profile Generator looks to just give a ramp type setpoint. That doesn't change the dynamic response of the tuning you have (i.e. the control loop's lag is identical whether using a step or ramp), it is just that a slow setpoint ramp will naturally give a slower PV response. It is clearer to see the effect of the controller's tuning parameters if you use a step input. Once you are happy with the speed of response/overshoot, you can put the ramped setpoint back in if needed and set it to the maximum speed of response you want as that makes it less demanding on the controller, especially if doing big set point changes or if you have significant derivative action in your controller.

By the way the various problems you mentioned - speed of response / tuning; noise/quantisation; undershoot on large step down - are all different things so you need to solve each one separately to get the overall response you are looking for.

The point made by GerdW around the resolution of the speed measurement is important. If you look at your speed response the size of the quantisation changes with speed - i.e. it is big when the speed is high and small when the speed is low, so this is clearly related to how speed is measured rather than the number of bits in an ADC or DAC.

[Ben]

---

@StevenD wrote:

As borjormy said, reduce interval time. From my experience the faster you can run a PID loop the better control you will have.

...

---

Please let me share a small tidbit. I once read a study that indicated that there is a limit related to how fast a PID can be updated beyond which more frequent updates do not make a difference. That limit is related to the nature of the system being controlled. If you think about it, if the system can only change so fast, telling it to change more often will not make a difference.

Done with the trivia,

Ben

[Borjomy]

---

@Ben wrote:

---

@StevenD wrote:

As borjormy said, reduce interval time. From my experience the faster you can run a PID loop the better control you will have.

...

---

Please let me share a small tidbit. I once read a study that indicated that there is a limit related to how fast a PID can be updated beyond which more frequent updates do not make a difference. That limit is related to the nature of the system being controlled. If you think about it, if the system can only change so fast, telling it to change more often will not make a difference.

Done with the trivia,

Ben

---

The limit is determined by the transport delays in the execution of the command. The decrease in the polling interval is only one of the ways.

[AndyClegg]

For the avoidance of doubt - the effect of the time delay due to the 50msec sample time on a system with a rise time of 10+ seconds is very very small. That is why I said it sample time would only become a limiting factor if the systems speed of response is made a lot faster <1-2seconds.

The sample time should be at very most 0.2x the time constant (*) of the response you want get, but as a guideline I would always aim for 0.04x just so that it can be negligible. (*) - note time constant here is for first order response, so for a more general system rise time = 4 x time constant.

Related to this application, even with a much faster response, e.g. rise time = 2 seconds, a sample rate of 20msec would be my target but even 50msec wouldn't have too much of a negative impact on performance.

[Silver_Shaper · Accepted solution]

Dear Andy and Gerd,

Sorry for keeping this post open for the long duration. 

I have finally done with my PID Speed control and please find the result in the image (sorry for bad quality - its captured in mobile). I am happy with the rise time, overshoot, undershoot, step response (not shown here), ramp response and oscillation/quantization errors.

Speed (RPM) in Y axis, time in X-axis

Thanks for all your help and suggestions. I am closing this post. Kudos

[GerdW]

Hi Sasikumar,

while its fine to have a solution in your thread I don't think the solution is just that image…

Can you provide more information how you solved your problem? Maybe someone else is getting to the same problem like you and will be annoyed to find just a blurry image of two colored lines as "solution"…

[cli21]

Hi Ben, 

I am facing a problem which focuses on finding out the "limit" of how fast a PID can be updated. And I think the study you mentioned is exactly what I need. May I ask where did you find this study? Is it a science paper or some scientific blog? 

I would be very grateful if you can remember how to find out this study. 

Thanks.