LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

FPGA host DAQ rate slower than DAQmx

THE SETUP:  I am using a PXI-7841R Card to acquire data simoultaneously at different rates for different channels.  The FPGA target VI is set up such that it has three while loops.  One is simply a counter and uses a the Loop Timer VI to establish how often the counter increments.  This loop also outputs the I16 counter value to an analog output (AO) channel on the 7841 for each loop iteration  The second uses a digital channel as a source clock and acqires, for each rising edge of the digital input, one sample on two analog input (AI) channels, a edge counter signal and the current counter value from the first loop .  It packs the two 16 bit AI channels together and the edge count and counter values together and inputs the two elements into a DMA FIFO (DMA 1) for transfer to the host.  The third loop uses a loop timer to control the data acquistion rate for 6 AI channels, the current edge counter value from loop two, and the current counter value from loop one.  It packs these 8 channels into 4 elements and inputs them into a DMA FIFO (DMA 2) for transfer to the host.  These three loops run in parallel on the target.
 
On the host side I have a while loop reading the data from DMA 1, unpacking the data and saving to a file.  I also have a parallel while loop that is reading the data from DMA 2, unpacking and inserting into a queue.  A third parallel loop dequeues the data and saves it.  A fourth parallel loop is set up to acquire data from a USB 9215 module using a 9162 carrier at the same sampling rate as the third FPGA Target loop and saves the data to a file.  One channel of the USB DAQ is aquiring the AO signal from the 7841. For troublshooting, I have split the AO signal and am aquiring it on one AI channel of the 7841 as well.  I have used the Get Date/Time In Seconds VI with shift registers in the while loops to determine the amount of time the acquisition has elapsed.
 
THE PROBLEM: For given amount of acquisition time (e.g. 2 seconds) at a given sample rate (e.g. 10 kHz).  The FPGA aquires 1/4 the number of samples the USB DAQ is acquiring.  So if we take the 2 second, 10 kHz aquisition; the USB DAQ will acquire approximately 20000 samples (which seems right) while the 7841 is acquiring only 5000 (which seems wrong).  The FPGA target is set up such that it resolves the number of ticks needed to achieve a given sampling rate and, for the FPGA time clock of 40 MHz, this number of ticks matches what would be expected for a given sampling rate (in the case of 10 kHz, the number of ticks is 4000).  This discrepency by a multiple of 4 is consistent regardless of aquisition time or rate.  Interestingly, this discrepency can be seen in the counter value acquired by the USB DAQ and the 7841.  So in essence the USB DAQ is acquiring 4 samples for every one sample the 7841 aquires.  Is this lag from the target to be expected?  Any suggestions/help is appreciated.  Thanks.   
0 Kudos
Message 1 of 4
(2,825 Views)

Massey,

After reading your description the first thing that comes to mind is that the FPGA loop appears to be running at the right rate for the data acquisition; however, it is only recording 1/4 of the samples, which means that for some reason there is data lost between the input node on the FPGA and the FIFO read on the host. How are you implementing the FIFO between your FPGA and host in order to place four elements in the FIFO every loop iteration (this value of 4 elements and missing 3/4 of the data may have a correlation) ? Please include a screen shot of this implementation if possible as well.

Cheers,

Jonah
Applications Engineer
National Instruments

Jonah Paul
Marketing Manager, NI Software
0 Kudos
Message 2 of 4
(2,801 Views)
Johah:
 
Thanks for the reply.  I actually figured the problem out yesterday afternoon.  I had DMA FIFO in a for loop with indexing enabled.  So it would input the four elements from an array into the FIFO in the order they were inserted into the array.  The problem was that I had a number constant of 1 wired to the N terminal of the for loop.  My theory was that I only wanted the for loop to execute once before terminating.  I don't understand why, but when I removed this constant, "poof" , everything worked.  As for the host side, it is simply reading the FIFO with a DMA read method in a while loop.  Again, it is all working correctly now, but if you could explain why the constant of 1 wired to the for loop would create a multiple of 4 data loss, I would appreciate it. 
 
Thanks,
 
Jeff
0 Kudos
Message 3 of 4
(2,795 Views)

Hi Jeff,

What was occuring was the N terminal was conflicting with how many times the for loop needed to run to index all of the array elements. When an auto-index is used, the for loop automatically calculates how many times it needs to iterate to get through every element of the array (i.e. array size = 4, the for loop will automatically iterate 4 times). Since a one was wired to the N terminal, the for loop only iterated once (a for loop always runs the least amount of time if there is conflicting iteration data) and therefore only placed one element of the four into the FIFO at a time. As a result you would only see one out of every 4 data points on the output of the FIFO.

Let me know if this helps!

Cheers,

Jonah
Applications Engineer
National Instruments

Jonah Paul
Marketing Manager, NI Software
0 Kudos
Message 4 of 4
(2,773 Views)