DAQ Available Samples per Channel Property Returns 0 on First Read

Issue Details

• I have configured a continuous acquisition on my Ethernet CompactDAQ (cDAQ) device. When I connect the "Available Samples Per Channel" property to DAQmx Read, the first iteration always returns 0 samples. How can I prevent this?
• I have a USB DAQ and want to connect the AvailSampPerChan property to DAQmx Read so that my VI reads all available samples each iteration. The property always returns 0 on the first iteration. What is causing this?

Solution

This behaviour is expected and can occur with Ethernet or USB DAQs due to latency on the communication bus. Refer to the Additional Information section for further explanation.
To workaround this issue, consider the following points.
 

1. Configure the DAQmx Task for Finite Samples instead of Continuous Samples whenever possible.
   • This is set in the DAQmx Timing VI and will ensure that a precise amount of samples are acquired.
2. Set the number of samples directly on the DAQmx Read VI instead.

3. For USB DAQs:

   1. Place the AvailSampPerChan property in a separate, parallel loop to DAQmx Read.
      • This forces the driver to send a short packet across the USB bus each time the property is called. The packet grants the driver access to a buffer where samples are stored. By continuously calling this property in a separate loop, an event can be configured to only pass the AvailSampPerChan value to DAQmx Read when it returns a non-zero value.
      • This approach will cause lots of short packages to appear on the USB bus. This will lower the overall throughput of the bus and increase host CPU usage, which is up to the end-user to balance.
   2. Change the USB Transfer Request Size property to a smaller value so that DAQmx is notified of available samples sooner.
      • The default value is 32KB, and the smallest possible value is 1KB (1024).
      • Reducing the USB Transfer Request Size will notify DAQmx of available samples sooner, but even a value of 1KB may still result in long wait times at low sampling rates.

4. For Ethernet cDAQs:

   1. Add a small delay and perform a "dummy" read.
      • Immediately after the DAQmx Start Task VI, add a time delay of 1 second.
      • Place the AvailSampPerChan property and perform a "dummy" read as shown below.
      • When the execution enters that loop that contains DAQmx Read, AvailSampPerChan will start from a non-zero value.

Additional Information

USB DAQ devices can only transfer data when addressed by the host controller driver, which is different from how a PCI/PCIe device operates.
The DAQmx USB data transfer driver requests 32 KB of data from the USB DAQ by default. The driver can only publish the data when one of the following criteria is met:

1. All 32 KB of the chunk has been acquired.
2. The USB DAQ device explicitly sends a "short packet" across the USB bus.
   • The "short packet" allows the driver to access a buffer smaller than the requested USB data transfer size.

If the user requests 0 samples to read (that is connecting a value of 0 to the DAQmx Read Number of Samples per Channel input), no "short packet" is requested. In this case, data will only be published when the full 32 KB chunk has been acquired.

When the AvailSampPerChan property is queried, any data that has accumulated on the USB DAQ's onboard buffer is immediately flushed across the USB bus with a "short packet". This causes the data to be published as soon as it's received at the host PC. However, a race condition occurs between when the data arrives at the host PC, and when the driver checks the buffer for available samples.

In knowing that the driver does not wait for USB data to arrive at the host, and that modern host PCs are fast in comparison to USB buses, it is expected that AvailSampPerChan will return 0 on the first iteration.

These race conditions and latency issues affect Ethernet cDAQs in a similar way.