LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

PID speed control

Solved!
Go to solution

Hi folks,

I am working on speed control of 3 Phase AC motor using PID and having troubles in the output response.

Details of my setup, CRIO-9035, NI 9263 module (0 to 10V output for the drive) and proximity sensor for speed estimation. 

Controller gains are P (Kc) = 0.282 ,I (min) = 0.018, D (min) = 0.004; Iteration rate - 50ms.

 

Full cycleFull cycleHow to reduce the rise time?  The current one is ~13.5 secondHow to reduce the rise time? The current one is ~13.5 secondHow to reduce this oscillation?How to reduce this oscillation?Why overshoot when reducing speed? How to avoid this? (Surprised not happens when increasing speed)Why overshoot when reducing speed? How to avoid this? (Surprised not happens when increasing speed)

 I got the gains with PID Autotune vi using Z-N Method. Also observed that when derivative gain increased to a higher value, the desired output (MV) switches very rapidly like on/off pulse from 0 to 10 and I don't want this behavior to happen (with current D my output is stable as shown below).

 

 Output (MV) enabled in graphOutput (MV) enabled in graph

I am not sure what is wrong. Please answer for all the above-mentioned queries

Thanks in advance 

---
Silver_Shaper | CLD
0 Kudos
Message 1 of 24
(7,547 Views)

1. Decrease the iteration time, 50ms is too slow. Strive for 10 ms, and ideally up to 1 ms.

2. It is desirable to perform speed measurement also with a smaller interval. By the way, it can be filtered, but with a time constant about 10 times shorter than the transient time
3. Increase Kp to overshoot, then decrease slightly.
4. The parameter KD does not make sense at all.
5. You only need the KI parameter when working under load.

Labview 4.0, 5.0, 6.1, 8.6, 2009, 2011, 2012, 2014
If you do not know something, ask me.
Message 2 of 24
(7,506 Views)

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

 

"How to reduce this oscillation?"

That looks more like your A2D resolution than oscillation. If that really is the case, that's about the best steady state control you can expect. PID loops need some error to actually work. 

 

"Why overshoot when reducing speed?"

 

Difficult to answer without knowing what you are actually controlling. My guess is going up there is some resistance that will dampen any inertial movement in the system that is not there or less when going down.

 

Message 3 of 24
(7,490 Views)

Just my comments on this:

  1. With the existing sample time of 50msec, you should be able to get a faster response through faster tuning, and it won't be the limiting factor. However, it will become a limiting factor when rise time is <2sec.
  2. Looking at your controller output (i.e. it does not saturate), it looks like there is still some scope for getting a faster response through tuning alone. You can try tuning manually - increasing proportional gain and making I smaller (i.e. faster integral action). Or you could use a different tuning method like IMC / lamda tuning which allows you to specify how fast a closed loop responds.
  3. Agree, the "oscillation" looks like it is due to the resolution / quantisation in the system somewhere (probably A2D) - sometimes you can't do much about that, but sometimes you can change the range of signals so that the quantisation effects become smaller.
  4. The reducing speed response is a straight line since the controller output is saturated (low) - that is the fastest it can reduce the speed by due to a fundamental limitation (you will need a bigger actuator), though check the saturation isn't being introduced artificially in software - though probably more to do with output being clamped at low value.
  5. The overshoot is because it isn't really under control by the PID controller - so to remove overshoot you need to slow the response. However, it could be being made worse if you haven't got anti-windup operating in your controller. DO CHECK THAT.
  6. Derivative control will amplify any noise. Industrial PID controllers typically have filters on the derivative action, so check that is implemented in your LV PID controller - that will improve things. But as has been suggested you could sample a lot faster and run a high speed filter to get a cleaner signal going in a lower sample rate controller. This very much depends on the measurement technology you use for measuring speed and the ability to get a clean signal (free of noise, minimal quantisation)

Hope this helps,

Andy

Consultant Control Engineer
www-isc-ltd.com
Message 4 of 24
(7,470 Views)

Looking at your graph I think Anti-windup is engaged, so not much you can do about the overshoot on the speed reduction other than de-tune. Of course that overshoot is arising since you are doing a big step reduction in speed. Do a smaller speed step down, and it should look more like the rising speed response.

 

Another (better) idea to get faster response would be to use feedforward in conjunction with your PID - and that will help getting rid of the overshoot in the big step down in speed.

Consultant Control Engineer
www-isc-ltd.com
Message 5 of 24
(7,466 Views)

Dear Andy and Steven,

Thank you so much for your suggestions. Let me apply the learnings and will revert the feedback.

Regarding A2D resolution NI-9263 has 16-bit output resolution, wondering will it not sufficient?

---
Silver_Shaper | CLD
0 Kudos
Message 6 of 24
(7,455 Views)

Hi Silver,

 

Regarding A2D resolution NI-9263 has 16-bit output resolution, wondering will it not sufficient?

- The NI9263 is an AO module, so it does D2A.

- You surely use a VFD - most often they have lower resolution than your NI9263 (like just 10bit ADC for the 0-10V input signal)…

 

proximity sensor for speed estimation

- How do you read in your speed signal? How fast can you detect changes in speed here? Which resolution?

 - How good is your "estimation"?

 

Best regards,
GerdW


using LV2016/2019/2021 on Win10/11+cRIO, TestStand2016/2019
Message 7 of 24
(7,446 Views)

@Silver_Shaper wrote:

 

Regarding A2D resolution NI-9263 has 16-bit output resolution, wondering will it not sufficient?


That would give you 0.0015% resolution on the full range (1/2^16). I'd say that should be enough if you are using the full range.

0 Kudos
Message 8 of 24
(7,431 Views)

I'd also check if the fluctuation isn't simply electrical noise. Might have nothing to do with the PID controller. I'd verify that before worrying about the PID.

 

I've seen these signals a lot, especially when frequency converters are used. Higher signals get more noise... Hope you're using twisted pairs and have separated high power motor control from those accurate data signals... (I'm no electrical engineer, but I've seen my share of problems).

0 Kudos
Message 9 of 24
(7,428 Views)

Hi GerdW,


GerdW wrote:

 

proximity sensor for speed estimation

- How do you read in your speed signal? How fast can you detect changes in speed here? Which resolution?

 - How good is your "estimation"?


I feel speed estimation is good. Pulses are captured in FPGA with 1 ms loop iteration rate using NI 9421 module (which has max update rate of 100us). 

 

How fast can you detect changes in speed here?

I have tested up to 20ms (which is max speed of my motor).

---
Silver_Shaper | CLD
0 Kudos
Message 10 of 24
(7,419 Views)