LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Good morning, Good afternoon, Good evening LabVIEW users! What do you think about this configuration on DAQmx Timing and DAQmx Read in this code?

Solved!
Go to solution

I have a question the configuration on DAQmx timing and DAQmx read in the code below.

GRCK5000_1-1671469118787.png

 

Can someone please help understand the best way to configure the two VIs?

This is someone else code. On the DAQmx, he has samples per channel = 1000

Sample rate = 1000

Isn't sample rate supposed to be lower than samples per channel on the DAQmx Timing?

Also,  on DAQmx read isn't the  "number of samples per channel" supposed to be equal or less than "samples per channel" on DAQmx timing?

 

Let me know if this configuration is right, if not how can we be corrected?

 

Thank you!

 

GRCK5000

 

~Your homework is my homework. Haha~

 

0 Kudos
Message 1 of 4
(1,243 Views)
Solution
Accepted by topic author GRCK5000

When using the "Finite Samples" configuration:

  • The "Samples Per Channel" on the DAQmx Timing sets how many samples the task will read before it is complete.
  • DAQmx Read should use -1 as the number of bytes to read, which will read everything from the task.

 

When using the "Continuous Samples" configuration:

  • The "Samples Per Channel" on the DAQmx Timing actually sets the buffer size.  Generally speaking, this should be left unwired.
  • DAQmx Read should, generally speaking, be set to read ~100ms worth of data per read.  This is a general rule of thumb.  Additionally, the DAQmx Read would be in a loop so that data is constantly being read.

 

With all of that said, what I see in your code is a task set to 1k samples and then told to read 10k samples.  I honestly don't know if this should throw an error.


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
Message 2 of 4
(1,207 Views)

Thanks crossrulzz! This is a great explanation!

0 Kudos
Message 3 of 4
(1,172 Views)

Just a couple more tidbits:

 

  • Consider kudos for my complaint/suggestion about the confusing dual use of "# samples per channel" on DAQmx Timing and DAQmx Read.
  • I recommend to always wire the "samples per channel" value to DAQmx Read, even if the value you wire is the default value of -1, just to form the habit of being intentional and thinking about it.
  • When DAQmx Timing is set for Continuous Samples, the "samples per channel" value you wire sets a *minimum* buffer size.  DAQmx may override you by making the buffer bigger depending on sample rate, according to this table.  (Note: the table actually has a couple off-by-1 errors where the default buffer size is ambiguous for a sample rate of either 100 or 10000 exactly.  Until recently, a google search for "daqmx buffer size" returned links to both this ambiguous table and another one that correctly identified the sample rate bins as 101-10,000 and 10,001-1,000,000.  Looks like NI kept the wrong one active.)
  • I agree that the most typical starting point for Continuous Sampling is exactly as crossrulz suggested -- specify a # samples that represents ~0.1 sec worth.  This almost always works out very well when nothing else in the loop needs more than 0.1 sec to execute and thus the loop iteration rate is controlled by DAQmx.  Just be aware that there *are* less common occasions where the loop iteration rate needs to be controlled according to some other consideration (such as interaction with some other hardware).  Since it's important to have one (and only one!) mechanism controlling loop timing, in such cases you should wire a -1 to the "# samples per channel" input of DAQmx Read.  In Continuous Sampling mode, that'll immediately give you all available samples (meaning anything DAQmx has put into the buffer that you haven't previously read out of it) without waiting.  Whatever has accumulated while something else has been controlling loop timing, you'll retrieve all of it.

 

Addressing your specific questions:

  • No, there's no need for sample rate to be less than "samples per channel" in the call to DAQmx Timing.
  • Yes, when doing Finite Sampling, the "samples per channel" input to DAQmx Read should always be less than or equal to the "samples per channel" input to DAQmx Timing.
  • To fix the code you received, I'll start by assuming that the sample rate and finite sample mode are correct.  Then the "samples per channel" input to DAQmx Timing should be the entire amount of samples you want your app to capture.   The call to DAQmx Read can either specify the same # samples or you can wire the special (and default) value -1 to tell DAQmx you want all the samples the task was configured to capture.  Same result either way.   I would also form the habit of calling DAQmx Stop before calling DAQmx Clear.  It isn't always strictly necessary, but there are many circumstances where one would Stop and re-Start without ever clearing.  Again, calling Stop explicitly helps form a useful habit.

 

-Kevin P

 

ALERT! LabVIEW's subscription-only policy came to an end (finally!). Unfortunately, pricing favors the captured and committed over new adopters -- so tread carefully.
Message 4 of 4
(1,070 Views)