Why is the DAQmx Read VI so slow?

[12489]

Hello everybody.

I'm using Labview 8.5.1. and NI DAQmx 8.6 and I'm wondering what the DAQmx Read VI is actually doing.

What I want to measure is a 1kHz signal. To do this, I'm using a VI similar to the attached one (a pulsed 1kHz signal serves as trigger and as sample clock).

The time the DAQmx Read VI needs to perform is 250ms longer than the acquisition time you would expect (e.g. instead 100ms to measure 100 samples at 1kHz the time is usually around 350ms, for 1000 samples it is ~1250 ms). The time does not depend on the number of channels in the task.

So my question is what actually happens when the DAQmx Read VI is called. What I would like it to do is: Wait for the next trigger signal, then acquire the specified number of samples, then read the samples from the buffers and return them. Is there any way to force this behaviour?

Thanks a lot for your answers, I highly appreciate any help!

[Phanuel]

Hello,

please install the DAQmx Driver 9.2.2:

http://joule.ni.com/nidu/cds/view/p/id/2214/lang/en

If this update doesn't solve your problem, please tell me what hardware do you use.

Do you get this behaviour in every PXI slot?

Best Regards,

Phanuel

[12489]

Hi.

Thank you for your reply. Updating to version 9.2.2 unfortunately didn't change anything.

The hardware I have is a PXI-1033 Chassis with two PXI-6255 data acquisition cards in (located in slots 2 and 3). The time measured with the VI I attached in my first post doesn't change when switching from one PXI slot to another and also stays the same when data from both cards is read at the same time.

The problem I actually have is not that the DAQmx Read VI needs so much time to perform but that I'm not able to tell the data acquisition card to begin the acquisition exactly when the next trigger signal is detected. I have an arbitrary waveform generator which is able to do that and therefore I'm almost sure that most of the time the DAQmx Read VI is using gets lost before the data acquisition (since the first ~235ms are not acquired by the data acquisition cards).

Thanks again for your help and best regards,

Rene

[Mcdan · Accepted solution]

Rene,

For your application and hardware, you should be using DAQmx Control Task.vi to commit your task before your while loop.  Inside the loop, then you'd start/read/stop the task.  DAQmx uses a state machine to control task configuration and run time.  As written, when you cal DAQmx Read, DAQmx will see that you have a task which has never been configured.  As such, it will look at all the settings you make on the task, verify their correctness, reserve all resources necessary, write the configuration to hardware, then start your task.  Once the data specified has been read, it will unwind this state machine to put the task back in an unconfigured state.  As such, every time you call Read, DAQmx if going through all of it's state transitions.  If you were to commit your task before the loop, DAQmx would not re-verify your settings or need to re-program hardware each time through your loop.  That being said, there will still be some addition time each iteration of the loop where you will need to stop and restart your task, and during this time you could miss a trigger.

If it is truly not acceptable for you to miss a trigger, you might consider moving to a design in which you continuously read data, and then use software triggering to  keep track of the relevant sections of data.  One other alternative would be to look at the X Series line of DAQ devices, as these devices support retriggering in hardware (ie... They can retrigger without you needing to stop and restart your task).

Hope that helps,

Dan

[12489]

Dan,

thanks a lot for your detailed response. I will have a look into it in the next days.

Best regards,

Rene

[John_P1]

Hi 12489,

I think Dan pretty well answered why your loop was taking longer than expected--you can minimize the overhead of the software calls by explicitly committing the task like he mentioned.

However, I'm not sure if this is what you actually want to do.  From what you wrote...

---

@12489 wrote:

What I want to measure is a 1kHz signal. To do this, I'm using a VI similar to the attached one (a pulsed 1kHz signal serves as trigger and as sample clock).

---

If you just want to sample off of this 1 kHz signal, then you don't need to trigger the task, you could just use the 1 kHz as a sample clock without a trigger.

If you do need to re-trigger the task and not miss any samples, you could do this by using both of the on-board counters to generate a retriggerable finite pulse train to be used as the sample clock.  The AI task would still be configured as continuous.  You might start with this example.  If you actually need to configure an Analog Trigger, you could use the Analog Comparison Event as the source for the trigger of your counter.

It's worth noting that X Series boards support retriggerable analog input directly.

[12489]

Hi John,

Thank you too for your comment. As far as I can see,  Dan's suggestion improved the performance a lot. Since my computer died after I saw that, I was unfortunately not able to test if or how many triggers I miss when starting the task. I hope that I'm able to check this soon.

I guess the question why reading took so much time is solved no. You helped me a lot. Is there any documentation for DAQmx? So far, I only found some tutorials dealing with very specific tasks but I would like to have something more general (like a "manual") if it will be necessary to work with software triggering or other approaches.

Thanks to everybody again!

[Mcdan]

Rene,

If you have DAQmx installed, you should also have the NI-DAQmx Help installed.  This should be located at Start Menu->Programs->National Instruments->NI-DAQ->NI-DAQmx Help.  This file does cover the concept of the DAQmx task, and documents the DAQmx Task State Model.

Dan

[nabs_nu]

i am having a similiar issue and any guidance will be much appreciated. I use a PCIe 6361 to acquire voltages from 7 AI s and the rate of acquisition is an order of magnitude less than expected.
Following is what I did where avg is the number of samples read per channel.

DaqStart=Timer ();
DAQmxReadAnalogF64(collectHandle,avg,10.0,DAQmx_Val_GroupByChannel,rawdata,avg*7,&numRead,NULL);
DaqEnd=Timer() – DaqStart;

For instance, with 1000 samples per channel (total of 7000 Samples from 7 channels) the time it takes to read is 0.07 seconds. I.e. 0.1 MS/sec. I get the same rate for any number of samples read. I am wondering why this is the case when the PCIe-6361 is supposed read 1 MS/sec in multichannel acquisition.

Specs of the PC : AMD 3.5 GHz 6 core, 16 GB RAM, ASUS M5A97 LE R2.0 Board.

Thanks in advance!

Naba

[RavensFan]

You are replhing to a 5 year old thread.

And you posted in the LabVIEW forum.  Your example is text-based code and certainly not LabVIEW.

You should post in the LabWindows/CVI forum