PID not functioning as it should.

[VckdVj]

Hi,

I am trying to use PID function to control the position of stepper motor with load as feedback. When I execute the vi, PID output control variable keeps increasing irrespective of set variable. I let it go on for some time, but it was just going further. I read through other post stating similar problems, those solutions aren't either applicable or showing no difference in my case. 

Attached is the vi with its subvi's. Let me know what am I missing or going wrong.

Thanks

Vijay

[GerdW]

Hi Vckd,

Let me know what am I missing or going wrong.

There are some missing items (LabVIEW tries to load them from your DropBox folder)…

In Load.vi:

- you are reading 25k samples at 25kHz samplerate, so it takes 1s to read the data

- you are filtering those data with a cutoff-frequency of 25kHz (?)

- you forgot to wire a sampling frequency value to the filter function!

- why do you convert the filter result to a DDT wire when displaying in the chart?

- then you calc the average of the filtered data…

In PID_Trail.vi:

- the filtered average is used as pv for the PID function

- why do you wire a 0.01 as dt for the PID? You DAQ needs 1s to read data!?

- you use the default PID gains: did you do any analysis of your system? (Ever heard of Ziegler and Nichols?)

- the output range of the PID is limited from 200k to 230k (?)

- why do you negate the sp of the PID?

- why is there no wait in the smaller loop to the left?

In ZaberTrail.vi:

- all those missing subVIs…

- why do you use a FOR loop here? Why not just sequence those two subVIs with their error wire? THINK DATAFLOW!

[VckdVj]

The PID cycle continuous in the increasing or decreasing trend not depending on process variable, it overshoots the set value and just keeps going on.

Load1 and Zabertrail were working well individually, so not expecting problems with them.

I was unable to go to lab today. I answered all your questions below. I should try changing frequency of the PID or DAQ. I will post here as soon as I get to try some changes.

In Load.vi:

- you are reading 25k samples at 25kHz samplerate, so it takes 1s to read the data

- you are filtering those data with a cutoff-frequency of 25kHz (?)

That was intended for sampling rate, corrected it now.

- you forgot to wire a sampling frequency value to the filter function!

However, it is definitely filtering. Sensor noise was reduced.

- why do you convert the filter result to a DDT wire when displaying in the chart?

LabVIEW did it. 

- then you calc the average of the filtered data…

 I didn't understand what value is being output, hence average of filtered data as process variable.

In PID_Trail.vi:

- the filtered average is used as pv for the PID function

- why do you wire a 0.01 as dt for the PID? You DAQ needs 1s to read data!?

Missed it. Unable to test after the change, will post here as soon as I try it.

- you use the default PID gains: did you do any analysis of your system? (Ever heard of Ziegler and Nichols?)

Read a bit into it. I thought it is something to do after system responds to PID

- the output range of the PID is limited from 200k to 230k (?)

That is the range of positions on zaber steppers, where required load could occur.

- why do you negate the sp of the PID?

For convenience in control, the load sensor outputs negative signal from compresive load

- why is there no wait in the smaller loop to the left?

Didn't think it was necessary. added wait.

In ZaberTrail.vi:

- all those missing subVIs…

Separated the functions from the source, didn't get to try if works, let me know if it doesn't work.

- why do you use a FOR loop here? Why not just sequence those two subVIs with their error wire? THINK DATAFLOW!

Want to change the loop to while and to be able to modify sequence of read/write or wait etc., Loop will let me call action anytime 

Let me know if I need to give you more information

Thanks,

Vijay

[GerdW]

Hi Vckd,

you are filtering those data with a cutoff-frequency of 25kHz (?)

That was intended for sampling rate, corrected it now.

Now you set the sampling frequency for your filter (to 25kHz), but you also set that filter to lowpass at 0.005Hz. Really? 5mHz???

You also set that filter to init with each call. Why did you do so for your continuous data acquisition?

(For simplicity/readability you should use the expected enum constant when selecting the filter type, not just a numeric value…)

why do you convert the filter result to a DDT wire when displaying in the chart?

LabVIEW did it. 

Why did you accept that? (LabVIEW usually doesn't change datatypes on its own…)

then you calc the average of the filtered data…

 I didn't understand what value is being output, hence average of filtered data as process variable.

You apply a lowpass filter on your data, just to add more lowpass filtering by averaging the data!?

(Ever heard of Ziegler and Nichols?)

Read a bit into it. I thought it is something to do after system responds to PID

No, you can apply ZN before activating the PID control loop.

why do you negate the sp of the PID?

For convenience in control, the load sensor outputs negative signal from compresive load

You can also negate the P gain to get the same effect.

Again: apply ZieglerNichols on your system!

why do you wire a 0.01 as dt for the PID? You DAQ needs 1s to read data!?

Missed it. Unable to test after the change, will post here as soon as I try it.

You still set a dt of 10ms for your PID while "Load1.vi" needs 1000ms to execute!

That doesn't fit…

THINK DATAFLOW!

Want to change the loop to while and to be able to modify sequence of read/write or wait etc., Loop will let me call action anytime 

Change this loop to either a simple chain of function calls, with DATAFLOW directed by error wire.

Or implement a statemachine when you plan to add new states…

[VckdVj]

Haven't got to work on it for a while and Now I am back. 

I realized the mistake I was using the position as the control variable. Now, I consider the number of steps to move as control variable.

It was working in the earlier way as well but it takes a lot of time to arrive at set point.

Thanks GerdW.