DAQmx Available Samples Per Channel returns 0

[AeroSoul]

Hello

I am testing compatibility of my software with NI PCIe-6321 card (usually we use NI PCIe-6341) and i'm running into an issue where DAQmx Read property node set to 'Available Samples Per Channel' returns 0 if i go above certain sample rate.

With original card the normal sample rate is 60kS/s, but with this new one i can't go above 7kS/s without running into the above issue, even though the card can go much higher in terms of sampling rates.

The card also works in NI MAX with 60kS/s without any problems and all digital I/O lines work as expected.

I tried making minimum viable application for testing, but there the problem only appears if i try to go above 100kS/s. The testing app is below.

In the original code (and test app too) the DAQ task is started without any errors, and then when sampling rate is set too high there can be a couple of seconds of data before the property node returns 0. It never returns anything else after that, until the app is restarted.

[mcduff]

The testing code does not work because the 2D array is empty in the example. The For loop never runs.

I guess in the real application it is initialized.

About not be able to keep up with the acquisition, my guess is that you have two many buffer allocations going on. You have a Delete from Array, which is terrible for buffer allocations and a constant buffer allocations on your shift register for the array.

Use Array Subset instead of delete from array, initialize your 2D array and use Replace Subset to change parts of your buffer.

You can use DAQmx Buffer functions to increase your buffer size; not sure why the node gives 0.

[AeroSoul]

This code was written by some student before i joined the company so yeah... not optimal

I'm more interested to know why the PCIe-6321 wouldn't work with this same code, if PCIe-6341 works without a problem at 10x the sampling rate.

The pinout is basically the same, it's got more than enough speed to do it, so why doesn't it?

[GerdW]

Hi Aero,

---

@AeroSoul wrote:

In the original code (and test app too) the DAQ task is started without any errors, and then when sampling rate is set too high there can be a couple of seconds of data before the property node returns 0. It never returns anything else after that, until the app is restarted.

---

The question is: why do you use this property node at all?

Why not just read the needed number of samples by setting that as "number of samples" at the DAQmxRead function? Instead you wait for 0.9*samplerate samples and then you read all available samples...

IMHO the whole statemachine is kind of overkill...

[Kevin_Price · Accepted solution]

Following the suggestions by mcduff and GerdW, I made a few simple mods in place to illustrate.  I kept the state machine structure, but combined the Acquire and Extract states.

Compare the differences, come back and ask why as needed.

-Kevin P

[AeroSoul]

This works with minimal changes to my code, thank you very much.

Couple of questions:

1. You have no delay in the while loop, i assume that is because you rely on timing of the DAQ task itself?

2. Why is it needed to have "samples per channel" 5x the value of sample rate?

3. This is in the original code, but what could be the reason that task is created when VI first runs, and then it's destroyed and recreated when acquisition is actually started?

[Kevin_Price]

1. Correct.  During acquisition, the call to DAQmx Read requesting 1 sec worth of samples will control the timing.

2. Not strictly needed, just a habit to make sure I have plenty of slack in my task buffer size (relative to my acquisition and read rates).  RAM is generally plentiful and cheap, and there's rarely a good reason to skimp.  I generally like to set buffers for continuous tasks to be 5-10 seconds worth.  I also like them to be at least 2-3x the # samples I intend to read per loop iteration.

    These are *very* conservative habits, developed long ago when DAQmx wasn't quite as smart and efficient (though they were rather conservative even back then).  You're unlikely to need anywhere near this much slack.  But on the other hand, when the cost is just a few MB of RAM, why not?

3. I can't think of a *good* reason.  Probably the original developer was either working under some misunderstanding or else changed course part way through coding and didn't clean up fully & correctly.

    I would probably look to turn this code module into something like a Queued State Machine.  The states might include (Config, Start, Acquire, Stop, Clear).  During Config, the module would need to be handed a queue to use for delivering data to somewhere as it repetitively iterates over the Acquire state.

    App-level code would queue up the Config state somewhat early, and Clear only during shutdown.  During the bulk of runtime, it would only queue up Starts and Stops.  The module itself would transition from Start to Acquire, then iterate over Acquire indefinitely while delivering data back to somewhere with the queue it was handed.

-Kevin P