LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Optimizing DMA in Real Time Code (cRIO FPGA->RT)

Solved!
Go to solution

Howdy,

 

I am acquiring data from a microphone using the NI9234 module.  I have written my FPGA and RT code.  I am communicating data between the FPGA and RT layers using a DMA FIFO.  I have noticed that the RT layer has a hard time keeping up with emptying the FIFO, since the FPGA layer is running at a much faster rate.  I would like some pointers or suggestions on any silly things I am doing in the RT layer that are causing it to run slower than necessary.

 

Currently, my RT code simply opens up the FPGA reference and, in a loop, pulls data from the FIFO and writes it to a file.  I know that if I want to plot the data or perform an FFT on it, I should do that in a lower priority loop, so as not to slow down the data streaming from the FIFO.  Are there any simple performance enhancements that I am missing in my code?  Thanks.

 

I am attaching a copy (screenshots and VIs) of my FPGA and RT code, so that you can look at it.

Download All
0 Kudos
Message 1 of 3
(2,954 Views)

The only thing that jumps out at me is that you're writing to the file in the same loop as reading the FIFO.  From the looks of it, that's the only thing slowing you down on the RT side.  I'd recommend some sort of producer/consumer parallel loop structure to keep the file writing VI from sucking on the firehose.

 

Also, I know this is skeleton code, but you need to have a way to put on the brakes for the data acquisition, or at least the part where you're saving it to file.  If you're reading data too fast to write in real-time, you'll never catch up without putting some "start/stop saving to file" functionality in there.

 

Sorry, I totally missed out on the 'Stop Logging' control.  I'm not used to functional FP controls on a cRIO I guess since I always wind up controlling them with network shared variables or have them going completely headless ... 🙂

Also, what sort of period is that RT loop running on and how fast is your acquisition?  I'm guessing since it's acoustic it's not any faster than 44kHz or so, yeah?
Message Edited by Mike Webster on 07-01-2009 05:36 PM
0 Kudos
Message 2 of 3
(2,948 Views)
Solution
Accepted by topic author JeffKrol

I would seriously consider re-architecting the code entirely and using this reference application template. 

http://zone.ni.com/devzone/cda/tut/p/id/9196

 

There are benchmarks that show how well this template does.  With waveform acquisition, there are numerous points of optimization.  This referenace application addresses all of these to give you the best performance. 

 

 

Preston Johnson
Solutions Manager, Industrial IoT: Condition Monitoring and Predictive Analytics
cbt
512 431 2371
preston.johnson@cbtechinc
Message 3 of 3
(2,939 Views)