DAQmx API -- Clarify "# samples" meanings for Finite vs. Continuous Sampling

[Kevin_Price]

I've been in many threads and seen many, many more where the root issue stems from confusion about the way DAQmx Timing and DAQmx Read interpret the meaning of "# samples" very differently for Finite Sampling vs. Continuous Sampling mode.   (For example, here's just one of the times I tried to address that confusion.)

First, here's what causes the confusion:

• The 'samples per channel' input to DAQmx Timing is *crucial* for Finite Sampling tasks and usually *ignored* for Continuous Sampling tasks.
• The 'number of samples per channel' input to DAQmx Read has a default value of -1 when left unwired.  However, the *meaning* of this default value is *VERY* different,  resulting in very different behavior depending on whether the the task is configured for Finite or Continuous sampling.  (See the first link I referenced.)

While the relevant info is findable in the help, it also often clearly remains unfound.  I got to wondering whether some changes in the DAQmx API could help.

I'll describe one approach, but would definitely be open to better solutions.  The goal is simply to find *some* way to reduce the likelihood of confusion for rookie DAQmx users.

I picture adding more polymorphic instances to both the DAQmx Timing and DAQmx Read vi's, so there can be distinct instances for FInite vs Continuous sampling.

Further, I picture that the task refnum would carry sufficient type info related to this timing config, such that that downstream DAQmx functions can "know" what kind of Timing was set up -- Finite, Continuous, on-demand (the default if DAQmx Timing was never called at all), etc.

Then when that task refnum is wired into DAQmx Read, the most appropriate instance of DAQmx Read would show up.  And the corresponding input parameter names, help, default values, and default value *behavior* can all be tailored to that particular instance of DAQmx Read.  For example, perhaps the "# samples" input should become a *required* input for Continuous Sampling tasks, to force a decision and encourage further inspection of the advanced help.

Don't know how feasible something like this is, but it's definitely something that regularly trips up newcomers to DAQmx.

-Kevin P

[Etarkleson]

I have been thinking about how to ask this question. As a lets say average labview user with more experience in real time and FPGA, I have been having trouble upping my DAQ rates in MAX and sometimes unsure how to best sample for a good speed/synchronization tradeoff. 

I agree this could be better implemented and/or addressed in easy to find app-notes.

[taozhu]

I would love to ask that, When I use the NI-9476 module in a cDAQ-9189 chassis, I wrote a LabVIEW program to set the DO0 output to a high signal. However, sometimes the program runs successfully and sometimes it shows error -209836. What could be the reason for this and how can I resolve it?