daqmx and while loops.

[JanEgilGlaestad]

im quite new to labview. the code is for illustrating my question, i know it has many faults. I only have a trial version on the computer which write this topic, so i dont have daqmx vi's, so i made a subvi to illustrate the daqmx that gets the samples.

-the lower loop is free running

-ive set sample rate to 40khz

-the upper loop i use to log data from 29 AI channels and draw fft for 1 AI channel every 1 sec

-the intention behind the two loop strategy is to get the necesary sample rate for fft (i need to detect up to 10khz), while using as little resources as possible

-the queues is meant to be a fifo, storing X number samples (havent done the math yet to how many needed)

my question is this: 

if the lower (free running) while loop is running faster than 40khz, will i then get several element with the same timestamp in the fifo? 3 element of timestamp 1.000, 3 element of timestamp 1.002 etc etc.

[Bob_Schor]

I'm not sure if I don't understand your question or if you don't understand how Data Acquisition works, or both (I'm pretty sure at least one is correct).  I'm going to ignore your code pictures, and try to explain some things.

• A DAQ device, if it is any good, has a very accurate clock, so all of the samples are acquired at sequential (and unique) times.  [I'm only talking about a single channel -- for multi-channel DAQ, the samples can be acquired simultaneously or sequentially across channels, but even there, for a single channel, all of the acquisition "instants" are different and sequential.
• You should have no difficulty acquiring 29 channels at 40 kHz from a modern DAQ device (check its specs).  You do not want to use the Dreaded DAQ Assistant (ever!), nor its Evil Twin, the Dynamic Data Wire, even if you don't know enough LabVIEW -- get someone to set up DAQmx for you using MAX to create a Task that sets the Specifications (or, even better, do your work inside a LabVIEW Project and let Project configure the Task for you).  [If you don't know what this means, ask.  You definitely want to use LabVIEW Project -- I wonder if they teach that to students?]
• To save to disk, you want a Producer/Consumer design (which I see you are trying to show) to your Stream-to-disk loop.  If you also want to do an FFT on one channel once/second, the easiest way to do this might be a second Producer/Consumer originating in the Streamer loop (you can concatenate Producer/Consumers without worry).  Note that you won't need to send every Channel 0 to the FFT, just once/second (so you might not even need to "export" it, but can do it "in house" ...).

Bob Schor

[JanEgilGlaestad]

i think my question was unclear. ill use this code i found online instead.

lets say we set sample rate for the sample clock to 1hz (local variable "rate"). and the free running while loop turns out to be running at say 100khz. will we then write the same measurement to local variable "measurement" 100000 times each second? and with a fifo of 1000 element, would i then get 1000 identical elements for most of the time.

[Bob_Schor · Accepted solution]

If the Sample Rate is 1 Hz, and the number of samples is 5, the "free-running While Loop" will run at one iteration every 5 seconds!  As I tried to explain, if you tell a DAQ Device to read 5 samples at 1 Hz. it will take it exactly 5.000 seconds to do that, and until it finishes doing what you told it to do (and it has the accurate clock).

If you don't understand the Priinciple of Data Flow, you don't understand what LabVIEW is all about.  Also, time is a very important quantity in LabVIEW.

Bob Schor

[GerdW]

Hi Jan,

lets say we set sample rate for the sample clock to 1hz (local variable "rate").

There is no "local variable rate". There only is a control terminal labelled "Rate".

and the free running while loop turns out to be running at say 100khz.

What is a "free running loop"? There is only one while loop in the image - and it surely is NOT "running free"…

will we then write the same measurement to local variable "measurement"

Again: there is no local variable. There only is an indicator terminal labelled "Measurement"…

100000 times each second?

Why should the loop iterate 100k times per second when the sample rate is set to 1S/s?

and with a fifo of 1000 element, would i then get 1000 identical elements for most of the time.

There is no "fifo" in the image - and you tried to use some queues in your first message.

Why should there be "1000 identical elements" in a queue? A queue just stores what you write into…

To summarize: Please take those Training resources offered in the header of this LabVIEW board. You seem to miss "Think DATAFLOW" (as stated by Bob), and also don't understand/know about other basic stuff in LabVIEW…

[JanEgilGlaestad]

Hi gerdw

i think people being used to other programming languages and not labview, will see my question as fair. and bobs second answer gave me the info i was looking for.

lets say we set sample rate for the sample clock to 1hz (local variable "rate").

There is no "local variable rate". There only is a control terminal labelled "Rate".

Ok but that doesnt really change anything

and the free running while loop turns out to be running at say 100khz.

What is a "free running loop"? There is only one while loop in the image - and it surely is NOT "running free"…

this goes to the core of my question, how does the DAQmx read VI behave when asked for data. will it give you the last data aquired from HW, will it tell you that no new data exist and give void answer somehow or will it (as it turns out) wait until new data is read. I have read a bit about dataflow, still i dont see that the behaviour described  in previous sentence as impossible within the labview realm.

will we then write the same measurement to local variable "measurement"

Again: there is no local variable. There only is an indicator terminal labelled "Measurement"…

Ok but that doesnt really change anything

100000 times each second?

Why should the loop iterate 100k times per second when the sample rate is set to 1S/s?

Ok so it wont since code doesnt move on until new data exist. if however the read DAQ vi just gave you the last aquired value and code moved on, then 100khz or more would be feasible.

and with a fifo of 1000 element, would i then get 1000 identical elements for most of the time.

There is no "fifo" in the image - and you tried to use some queues in your first message.

Why should there be "1000 identical elements" in a queue? A queue just stores what you write into…

The fifo is not in the code. it was a thought example, what if there was a fifo instead of INDICATOR labeled measurement. 

And if the read DAQ vi just gave you the last aquired value, then a FIFO would fill up with identical values. And maybe there would be some strategy to avoid this which i needed to know about. turns out, this is not the case.

Best regards Jan Egil Glæstad

[GerdW]

Hi Jan,

Ok but that doesnt really change anything

Exact terminology will make it much easier for all to provide better answer (or to understand your questions)…

people being used to other programming languages and not labview,

That's why you are told to learn about DATAFLOW: LabVIEW has a very different concept about (any kind of) "variables"!

how does the DAQmx read VI behave when asked for data.

It will give you what you are asking for!

It can give you the samples already acquired, a fixed amount of samples to be acquired - or a TimeOut error when there are no (or not the requested amount of) samples…

will it give you the last data aquired from HW,

No, not at all. Each sample can be acquired only once: once you read that sample you cannot read it again in the next iteration! (Also some kind of THINK DATAFLOW!)

Ok so it wont since code doesnt move on until new data exist.

Again: THINK DATAFLOW!

[Kevin_Price]

It sounds like you've gotten past your immediate obstacle.

The behavior of the DAQmx driver API *can* take a little digging and getting used to.  While I know there's a ton of useful info in the help and here on the site, I didn't quickly find anything that would have clearly addressed your original question.  I'm sure it's out there, but I couldn't quickly point to it.

I'll try to summarize a few key points about buffered tasks.  Please note that these things are applicable to Continuous Sampling tasks.  Some of them are definitely not applicable to Finite Sampling tasks.

1.  When you call DAQmx Timing, there's an input for 'number of samples'.  Guess what?  DAQmx might ignore you and make a bigger buffer than what you asked for.  See this message and follow my links there.  Also be sure to read some nice overview info by cbutcher one message earlier in the same thread.

2. The behavior of a DAQmx Continuous Sampling task centers around the concept of delivering a lossless stream of samples.  DAQmx manages most of the "dirty work" of delivering each sample once and only once, no matter how often you call the DAQmx Read function.

   The driver takes care of moving samples from the board into the task buffer.  The buffer is circular, so when it gets to the end it just wraps back around to the beginning.  The driver maintains pointers to identify:

• read pointer.  Each time you call DAQmx Read, this gets reset to point to the next buffer location *after* the last sample you just read.
• write pointer.  Each time the driver moves data into the buffer, it advances the write position to point to the location where the next samples should be stored.  If it finds that it's about to overwrite samples that your app hasn't yet read, it'll throw a buffer overwrite error.
• trigger pointer (if applicable).  This lets a task free-run and be in a special mode where buffer overwrites are allowed until the trigger event is seen.  The driver keeps a pointer for the trigger position and your subsequent buffer read will know how to retrive samples in the proper order with respect to the trigger position.

3. These things happening in the driver make application programming simpler.  You can call DAQmx Read at a higher rate than the task is sampling and DAQmx won't return duplicate data to you.  A more common usage is to call DAQmx Read at a slower rate and rely on DAQmx to deliver a lossless stream.

4. There are some advanced DAQmx property nodes that allow you to change some of these default behaviors and do some other fine-tuning.  Most users don't need to use them most of the time.

-Kevin P