Application pauses for up to 4 seconds at random places in processing loop.

[Sorooshster]

COsiecki,

How did everything turn out?  Did fixing your data flow through that notifier work?   

[Chris.Osiecki]

Unfortunately, no. I will get the function posted here later today for people look check out. I have everything else running right now to see if it really is just this one function. At least I think I am finally getting close to figuring this out.

[Sorooshster]

COsiecki,

That sounds fine, I'd be happy to take a look at the piece of code that is causing the problem once you get it narrowed down.  Thanks and have a great day!

[Chris.Osiecki]

I've been tracking down my problem some more. Is there any known problem with Extract Single Tone Information.vi? Using the profiler, it seems that a sub-vi of mine is what may be locking up, but the only thing in that sub-vi is a Preview Queue Element >> Index Array >> Build Waveform >> Extract Single Tone Information. I am using the Extract Single Tone without advanced search criteria, but that shouldn't matter. I am feeding it a square wave that's ~100k samples long. I have another sub-vi that is essentially the same, but it doesn't seem to be experiencing the same condition. It uses advanced search criteria.

[Chris.Osiecki]

Here's a link to the sub-vi I just referred to:



I realize there's no error catching for the queue preview timing out, but this is only run after the calling vi gets a notifier that there is new data in the queue. Even if it does time out, it just passes an empty array to the tone vi which returns an Inf. I did some testing and an Inf speed doesn't cause any other running functions to do anything different, just give bad results.

I'll have the whole vi up in a bit.

[Chris.Osiecki]

I am running a test where I have replaced the Extract Single Tome Information.vi with a randomized value. The rest of the sub-vi, as well as the calling vi, are unchanged. So far the test has not errored out. I am leaving it to run overnight.

[Sorooshster]

COsiecki,

That sounds good, it seems like the culprit might be the Extract Single Tone Information vi.  Let me know if you can verify that we can try to figure out why that vi is causing the problem.  What version of LabVIEW are you using and what is your operating system? 

[Chris.Osiecki]

I'm using 8.5 on XP Pro. My application still errored out last night, but I was running the profiler and it showed the FFT fuction has hung. This is the same FFT function used in Extract Single Tone Information.vi, but I also use it directly in 2 other functions as well. It was the only function in the profiler results that showed abnormally long maximum execution time (5 seconds). I am calling it a lot, but with fairly small data sets. It runs 3 times once a second on 100k sample data sets (1 second of data for 3 channels), and 7 times every 50ms on 5k  sample data sets(20Hz data for 7 channels). The 20Hz data processes in a For loop, so it does the FFTs serially. I originally had it execute in parallel, but the CPU hit was too big. Since the data is small, it only takes ~10ms so they still finish in plenty of time for the next data.

[Chris.Osiecki]

I have attached the profile from the most recent series of lock-ups. When you look at it, the functions that froze all refer back to the FFT function. I messed around with it some today to see if I could get the FFT to do the same thing by feeding it weird, or just bad, data and I couldn't get it to lock up. Later, I was trying to show someone how to use it, so I was interacting with the UI a lot and it froze 10 times in 5 minutes. Usually I leave it running overnight, so I'm not interacting with it, but in use, there will be quite a bit on interaction.

[Captain_Kirby]

Hi COsiecki,

From looking at the profile you posted, it definitely seems that your trouble is stemming from the FFT functions employed throughout your program. The FFT function is very computationally intensive and scales exponentially as samples increase. The hangs you are experienceing may be a function of running these computationally intensive operations in a processor that is already burdened with the overhead of your programs other functions (such as UI and data control.) Also, looking at your previous posts, the ammount of samples you are operating on could be considered high depending on your computer hardware. And when you think about the posibility of running into parallel FFT operations at the same time, the posiblility of the machine hanging to finish a complicated FFT operation isnt that far fetched.

There are some steps you can take to try and reduce the impact of the FFT functions. I would first try disabling or replacing the FFTs with benign functions to ensure that the FFTs truely are your problem. Then, if it is feasable, you could try running the FFT on a smaller number of samples. If maintaining your window is critical, you may also try decimating the input samples to keep the window the same. Besides that, you may try limiting your other functionality (like the UI) in order to maximize the ammount of processor your FFTs are able to utilize.

If you need any more advice, please list your hardware configuration as well (processor speed, physical memory, number of cores, etc.) Hope this information was helpful.