Input buffer and parallel processing

[SSTBRG]

Hi, 

I am gathering data from an external board.

The data is structured like so: every iteration inside a 'while' loop I get a matrix of NxM where N is the channel number (1,2,3.. etc) and M are always 60 data samples (in milivolts). This is a matrix of type 'double'.

Currently this matrix is fed into a queue using a while loop.

The queue is read by another while loop where I do a simple FFT and decompose the matrix into N 1xM vectors - each vector is displayed in a chart.

My goal was not to lose data packets and create some sort of an input buffer.

This does not work - the data is arriving slowly and the onboard FIFO fills up quickly - this means that the external board is not being probed quickly enough which is very strange, since I isolated the while loop responsible for this probing. The FFT is calculated in another loop.

I tried calculating the FFT in the same while loop with the data collector - that is without using a queue at all and using a single while loop - and this works fine display-wise but I sometimes lose data packets.

What am I doing wrong and how should I approach this?

Thanks

[Norbert_B]

Please post your current  VI and state what rates you are looking for.

[Ben]

collection loop should be very tight consisting of only  the code required to empty the buffer from the hardware and then push same into a queue that is not of fixed size.

If you collection code requires a dll that is running in the UI thread...

Ben 

[Chase.E]

Since this sounds like a performance issue, these might also be some good tricks to keep in mind:

http://www.ni.com/newsletter/51495/en/ 

[SSTBRG]

Hi,

I've made some progress and currently the attached basic VI works very well. I'm posting it for reference purposes and further remarks from you.

I will have to look further into my (much) more complicated old one-loop VI to see what may cause the delay. 

 Chase, thanks! I will look into it.

For further information on the hardware I'm using, see here: http://intantech.com/RHD2000_evaluation_system.html 

[Ben]

Property nodes require the UI thread.

Better to do the property node stuff conditionally, only when required.

Each property nodes requires a switch to the UI thread. One improvement would be to combine the X and Y axis property node settings to use a single re-sized property node. That would cut down the number of UI thread swaps.

Ben

[SSTBRG]

Ben, thanks, but can you please elaborate on how to do that?

Regarding the conditional change of the property nodes - I thought about it myself, but I'm lacking labview experience to accomplish this.

Regarding the combination of X and Y axis properties - this sounds like a really good idea, but I also fail to see how it's done. Do you have an example by any chance? 

[Ben · Accepted solution]

That property nodes stuff only has to happen when a user changes a setting or the chart scale changes.

Use a event structure to do that work and configure events for value change of the controls or scale change on the charts.

Ben