LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

FFT function doesn't get activated after stopping the while Loop

Solved!
Go to solution

Some Background: I am using the Producer/Consumer structure to get some data from the producer loop and dequeue it in the Filtering (Consumer) loop and then apply a fourier Transform to check the signal in the frequency domain.

The problem I'm having is that after stopping the while loop by pressing the '' Stop Acquisition and Logging Loop'' the data doesn't get fed to the FFT function as I expected.
I have done the same exact thing in another subvi of my program but I applied the FFT directly after the acquisition. The only difference is that in the direct analysis FFT loop I activated the stop button by using a message queue, which I have also tried in the Filtering loop but it didn't work so I thought of trying the shared variable to stop it. Neither of them led me to the solution though.

 I added Snippets of the Filtering Loop and the direct FFT analysis loop, you wouldn't be able to run them but maybe you could point out a mistake that I overlooked.
Filtering LoopFiltering LoopDirect FFT AnalysisDirect FFT Analysis

0 Kudos
Message 1 of 7
(1,277 Views)

Hi amr,

 


@Amr95 wrote:
The problem I'm having is that after stopping the while loop by pressing the '' Stop Acquisition and Logging Loop'' the data doesn't get fed to the FFT function as I expected.

When the FFT isn't executed in that "Filtering loop" version then it probably isn't called - due to THINK DATAFLOW!

 

Does the loop even recognize the SharedNetworkVariable value? What exactly do you "press"?

Did you debug that VI? Does the loop stop iterating when the SharedVariable is written (somewhere else in your code)?

Best regards,
GerdW


using LV2016/2019/2021 on Win10/11+cRIO, TestStand2016/2019
0 Kudos
Message 2 of 7
(1,263 Views)

What do you see when you drop a probe on the input of the FFT function?  Also what about running in highlight execution/lightbulb mode to observe the data flow? 

----------------------------------------------------
Studying for CLA.
LabVIEW, inherit from social media habits!
0 Kudos
Message 3 of 7
(1,242 Views)

Hi GerdW,
thanks for your response. 


@GerdW wrote:

 


When the FFT isn't executed in that "Filtering loop" version then it probably isn't called - due to THINK DATAFLOW!

 

 


That's clear to me but I can't figure out what's causing the problem.

Does the loop even recognize the SharedNetworkVariable value? What exactly do you "press"?

Yes it does and the loop stops when I press the button. This button stops the Data from being enqueued on the Data Queue in the producer loop (which later gets dequeued in the "filtering loop") so subsquently the signal filtering stops and by using the Probe watch the stop button in the filtering loop turns to true as I hit this button. As I said I also tried to do stop it with a message Queue like in the "Direct FFT analysis Loop" but the data doesn't reach the FFT function somehow using both methods, it works in the Direct FFT Loop though. I thought the error could be obvious to the readers and I may have overlooked but it doens't seem like it from your response.

0 Kudos
Message 4 of 7
(1,233 Views)

I wonder what the "Use Default If Unwired" tunnel might give You if the last iteration does not enter the "Filter" case.

0 Kudos
Message 5 of 7
(1,231 Views)

@CDuck wrote:

What do you see when you drop a probe on the input of the FFT function?  Also what about running in highlight execution/lightbulb mode to observe the data flow? 


The input doesn't get updated at all, it just stays blank. I need to try the highlight execution mode tomorrow when I'm at work again.

0 Kudos
Message 6 of 7
(1,230 Views)
Solution
Accepted by topic author Amr95

Hi amr,

 

you really need to cleanup your VI!

 

There is no need for two tunnels to transfer the same data!

You should not use the TimedWhileLoop on a plain Windows, a simple While loop with a wait function will do the same…

 

Like this:

 

Your problem most probably comes from all those "default if unwired" tunnels! Wire them in all cases to retain the values in the shift registers…

Best regards,
GerdW


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