LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Slow UI response with long data acquisition time

Solved!
Go to solution

Hi all,

 

I have a question to ask more out of curiosity than necessity right now. I built a program that acquires data from an accelerometer and processes it in a number of ways - filtering, FFTs, FRFs, stuff like that but the UI response is always slow because I need a frequency domain resolution of 0.2Hz for my data, which means the sample acquisition time is 5s and everything waits for this before executing.

 

My question is this: Is there a way to completely isolate the UI from the data acquisition so that it responds immediately?

 

I tried a producer consumer design pattern with queues but found that everything was still waiting for the samples to be collected. Maybe it was just the way I did it.

 

Thanks

Phil 

0 Kudos
Message 1 of 6
(2,297 Views)

Hi idt,

 

use parallel loops to handle UI separately from DAQ!

Best regards,
GerdW


using LV2016/2019/2021 on Win10/11+cRIO, TestStand2016/2019
0 Kudos
Message 2 of 6
(2,293 Views)
Solution
Accepted by topic author AliasAlreadyOnFile

If you need to sample for 5 seconds in order to have enough data to analyze, then unless you can "predict the future" and "know" the next five seconds of data, you just have to wait for the data to arrive.  Using parallel Consumer-Producer loops will allow the data acquisition to proceed (to get the next 5 seconds of data) while you are doing the analysis, but you still need to wait for data to analyze.

 

Note that the preceding paragraph assumes you are collecting data in 5 second "chunks", and want to analyze each (independent) "chunk" as they arrive.  You could also do something like having a "sliding 5 second window" that moves, say, a second at a time, giving your FFT a finer "time resolution" (at the cost of their independence).  This would entail a (slight) change in your Producer loop (you'd want to sample in 1 second chunks, accumulate 5 such chunks) and Consumer Loop (start analyzing, spitting out an FFT every second, while replacing the oldest "chunk" with the newest -- a lossy Queue can do this for you).

 

Bob Schor

 

 

0 Kudos
Message 3 of 6
(2,273 Views)

I agree with the last two posters. Look into the Producer Consumer design pattern. I strongly suggest using a Event Structure with this design pattern. I've had great success with this in the past.

0 Kudos
Message 4 of 6
(2,266 Views)

Thanks for your responses,

 

Bob, yes the data is collected in 'chunks' so even with parallel loops I found that everything is still waiting for the sampling. I thought that by using parallel loops the consumer loop could be made to loop as fast as I told it to and I could just use shift registers to have the current data going round and round until the next lot of data was collected, thereby allowing me to use the UI at a much faster rate than the DAQ in the producer loop - this was my aim but the general and producer-consumer design patterns do exactly the same thing - there's no noticable difference.

 

I think the problem is that the sample data is coming through the queue - the enqueue data is waiting for the data collection so the dequeue in the consumer loop just sits there waiting for the producer loop enqueue.

0 Kudos
Message 5 of 6
(2,236 Views)

The idea of a Consumer Loop is not that it goes "as fast as you tell it to", but that it goes, on average, as fast as the Producer Loop.  The "on average" is important, because the loops don't need to be "locked together" -- the Consumer Loop can lag behind occasionally (for example, to do a particularly long calculation every once in a while), "catching up" when the long process ends.  If there is "nothing to Consume", the Consumer Loop simply waits, allowing other processes to run.

0 Kudos
Message 6 of 6
(2,209 Views)