High-speed data read from onboard DAQ memory (non-NI product)

[VEEDAY]

I have a non-NI DAQ that does acquisition at 250 MSPS and stores data on the DAQ board memory (4 GB). The DLL releases data stored from the memory in 1 MB blocks FIFO. However, I am unable to retrieve the data at acquisition rate even though I have high-end desktop, SSD, 64 GB RAM etc.

I noticed about 5 s delay to read 250 MS in LABVIEW 64 bit. The DAQ driver is in 64 bit. 

I heard from another person that the same DAQ even at lower system configuration can display data at much faster rate than the LABVIEW. They are using C++ and a regular desktop.

Any pointers?

Thanks

[Spicy_Mystery]

Hi RYADAV,

I could use more information about what you're doing before I can begin to diagnose your issue.  Please answer the following:

1) How is your DAQ connected to your computer?  The latency there could have an effect.

2) Are you doing a finite acquisition of 250 MS or is this continuous acquisition at 250 MS/S?

3) What DAQ are you using?

4) Which drivers are you using?

5) What version of LabVIEW are you using?

6) What operating system are you using?

Also, feel free to post a picture of your code (with comments), that would help as well.  If you're using one of the built-in LabVIEW examples, say which one.

[VEEDAY]

Hi Julian,

1) How is your DAQ connected to your computer?  The latency there could have an effect.

  -- The DAQ is connected to PCIe express slot 8GSPS bus speed. Motherboard is LGA2011 with 8 core intel processor, 64 GB DDR3 RAM, Samsung 840 SSD and has on board memory of 4 GB.

2) Are you doing a finite acquisition of 250 MS or is this continuous acquisition at 250 MS/S?

I am doing finite acquisition of 250 MS ( about 1 GS). 

3) What DAQ are you using?

Its a PCIe DAQ build in-house basedon our requirements, but programmed by a third party vendor who is our collaborator. They tested and demonstrated us the execution speed via their VC++ project.

4) Which drivers are you using?

The drivers were developed for 64 bit Windows OS and 64 bit LABVIEW.

5) What version of LabVIEW are you using?

I am using Labview 2013 64bit.

6) What operating system are you using?

Windows 8.1 64 bit.

Please find the required image of the block diagram.  I cannot share full details due to restrictions. I hope you understand my problem. The control loop was designed following multiple producer consumer example found here: https://decibel.ni.com/content/docs/DOC-26558

Thanks

[Prickly_Pear]

I believe that it would be helpful to narrow down which subVIs are slowing down the acquisition so much. You can use the VI Profiler as a tool to help you benchmark the performance of the VI. This document talks about how you can do this: http://digital.ni.com/public.nsf/allkb/9515BF080191A32086256D670069AB68

Also, this presentation package contains a lot of information about memory and performance analysis in LabVIEW. It would be good for you to skim through this so that you are more familiar with the kinds of things that slow down LabVIEW as well as how you can identify problem areas. http://www.ni.com/white-paper/7606/en/

Jeremy P.

[VEEDAY]

Thanks Jermey, I will profile and look which VI is causing an issue. FYI, I also tried experimenting with the GigaLabview example. My system tends to result similar performance for GigaLabview and DAQ acquisition.

Let me profile and update you more. Thanks

[VEEDAY]

After profiling the VIs, I see the maximum amount of the time consumed is by the convert RAW binary  32 bit data to physical channel data. Please see the screen capture of the conversion routine. Could I improve the execution speed of this VI?

Thanks

[Prickly_Pear]

I'm not sure what is causing the problem exactly. Nothing in that VI stands out to me as being a poor procedure for processing the data quickly.

You may find this knowledgebase article helpful: http://digital.ni.com/public.nsf/allkb/862567530005F09C862565D40010CA3D?OpenDocument

This document gives some suggestions for changing the VI settings to improve performance: https://decibel.ni.com/content/docs/DOC-17432

It would be good to try to experiment with different processing algorithms (if there are any). Just try out different algorithms and use the VI Profiler to see which one is the best.

Jeremy P.

[VEEDAY]

Thanks Jermy, I am working on alternatives and will update if I can do some speed up.

Thanks