LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Timed loop runs slower than anticipated

Hi All,

 

I have a bit of code that is running slower than I would expect. I would like to save two analog inputs with the corresponding time, while adjusting the duty cycle of a counter based on one of the inputs. I have a variable to allow me to set loop speed, but it runs at 1/3 the speed specified. I have tested this with 50Hz, 100Hz, 250Hz, and 500 Hz. All run almost exactly 1/3 that frequency. I tested this by analyzing the average time gap between data points. (This statement breaks down for 750 Hz acquisition and 1000Hz). The fastest acquisition I can get is 332.7Hz.

 

I am using LabView12, a PCIe-6321 and Window 7. 8 GB RAM, 3.2GHz i5.

 

This program holds a specific temperature, which is measured by a thermocouple, by pulsing a infrared lamp. The PID intelligently adjusts the duty cycle of the pulse train to better maintain a more narrow temperature range ( http://en.wikipedia.org/wiki/PID_controller if a explanation is desired).

 

Anyone have an idea as to why this is? And is there a way to do this more efficiently?

 

I can post the program if requested. It is a good bit larger than this loop.

 

Regards and Thank you.

0 Kudos
Message 1 of 4
(3,484 Views)

Hi Adrian,

 

several problems with your code:

- the TWL is set to use the "1kHz" clock. Atleast running at 750Hz will not work due to rounding problem (you can't set 1.33ms loop rate).

- you acquire data using "n channels 1 sample" mode. That's the slowest mode available: asking for just 1 sample of data is just waste of resources...

- you set your CTR-out each iteration. Do you really need to adjust the PWM at 1kHz?

 

Change your programming style:

- Right now you try to set speed by setting the TWL. This will not work as long as your code in the loop takes longer than the expected/wanted loop rate allows.

- Use the DAQmx functions to set the sample rate. Now when you ask for data the speed is determined by sample speed. (Don't use a TWL, a normal while loop will do.)

- Get rid of "1Sample"-mode of DAQmxRead. It will never be fast enough (on Windows) to allow for 1kHz loop speed.

- Get rid of all those locals...

- Using a TWL with ElapsedTime to determine the number of loop iteration is "funny": Why not calc the needed iterations before and use a FOR loop? They are more efficient when it comes to array autoindexing too...

Best regards,
GerdW


using LV2016/2019/2021 on Win10/11+cRIO, TestStand2016/2019
Message 2 of 4
(3,463 Views)

Thank you for the swift response.

 

Makes sense. Still doesn't quite explain the result for all below 500Hz which divide to integer value ms.

 

As you can probably guess, I taught LabView to myself. I am not terribly suprised that my style leaves something to be desired.

 

I used the 1 sample because I need to know the temperature and it need to be fed to the PID. That only really needs to happen at around 5Hz.

Everytime I have used continuos samples it doesn't allow me to see the input being read until acquisition is finished, which is problematic for using anysort of feedback loop.

 

Can I acquire continously and run a loop that acquires the thermocouple and adjust the PID after simultaneously?

 

Thanks again.

0 Kudos
Message 3 of 4
(3,448 Views)

Hi Adrian,

 

I would use (atleast) 2 parallel loops:

The first one would do the DAQmxRead for the AI channels. This can run in it's own speed set by sample rate and number of samples to read.

The 2nd one would do the PID and PWM output. This one could run much slower (at 5 Hz) and only takes the current value of the AIs. As you already use local variables (which I would try to avoid though) you could use them to store the latest AI value and transfer them from one loop to the other...

 

Best regards,
GerdW


using LV2016/2019/2021 on Win10/11+cRIO, TestStand2016/2019
0 Kudos
Message 4 of 4
(3,426 Views)