LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

9234 input %27hopping%27

I have a strange issue with a 9234 module, and I am not sure if it something I am doing / didn't do, or what.

 

The setup is along the same lines as the Adapative Filter examples for the cRio and the NI 9234.  

 

The system runs fine, then for some reason the inputs shift, meaning AI0 is represented by the graphs and data stream that was AI1 at the beginning, AI1 is represented by the graphs and data stream that was AI2, etc.

 

In a version of the program, I wired an indicator to the 'Elements Remaining' of the FPGA Invoke Method in 'Audio Processing'.  The error / issue arises when this value hits 22526.

 

I am beginning to wonder if I need to flush the buffer or something, but I am not sure which end this should be carried out, the cRio or the PC?

0 Kudos
Message 1 of 3
(2,030 Views)

Hi rbergs, 

 

Is your FIFO buffer filling up?  Are you pulling the elements out of the buffer fast enough on the Host side?  I wouldn't be surprised if there was some overwrite behavior happening once the buffer fills up.  The "Audio Processing" VI has a ton of processing happening in the same loop that the FIFO is being read.  This could bog down the loop enough that it isn't reading samples from the buffer fast enough to keep up with the target.  If your "Elements Remaining" variable is increasing, then this is likely to be exactly what is happening, and you might want to set it up to read as much of the FIFO as possible on each iteration.  I don't know for sure if this will work, but try the following:

 

Have 2 "Audio Signals.Read" Invoke method nodes.  The first one, you read 0 elements and wire the "Elements Remaining" output to the "Number of Elements" input on the second one.  This might ensure that your FIFO buffer is not filling up.  Since you are multiplexing your channels, you will want to round your "Number of Elements" to read input to the nearest multiple of 4 (you have 4 signals).  Give that a try and let us know how it turns out.

0 Kudos
Message 2 of 3
(1,993 Views)

I think you are correct, in that the buffer is getting being overloaded.

 

I tried something like what you recommended, but backwards.  I grab the expected amount of data points with the first read, then hae a second read that takes what is left.  However, this only seems to buy time.

 

I'll give your idea a shot and see if it helps.

 

As for the processing, strangely it seems that the XY graphs are the 'power hogs'.  I took out all of the processing, but left two graphs, and it still had issues.  I took out all the XY graphs, but left the processing, and it ran well.

 

Ultimately, it will not use all the stuff that is in there.  To begin, we aare trying to figure out what we need to look for.

0 Kudos
Message 3 of 3
(1,984 Views)