A (should be) simple DAQmx question - take finite samples in software timed loop

[JÞB]

---

@Blokk wrote:

Question: can we consider the above behavior as a DAQmx bug?

---

I don't think so.  There is probably an order of operation error in the P node prior to the loop.  I don't thing you should need to keep resetting the offset in the loop but since you do reading an additional property probably adds just enough delay to stick the new "same" value which never changes.

Then again, if you really must use external timing per 

---

So you are right that the DAQmx part executes always with the same speed, but I cannot exactly fix the execution time of the non-DAQmx part, thus the loop time might vary too much occasionally.

Therefore, I need to "round up" the total loop execution time to 1000 msec using that "Wait Until Next ms Multiple"...

---

wire -1 to the read count and all of Kevin's advice (excellent though it is!) is moot.  

Spoiler

I told you to just do it my way

[Blokk]

---

@JÞB wrote:

---

@Blokk wrote:

Question: can we consider the above behavior as a DAQmx bug?

---

I don't think so.  There is probably an order of operation error in the P node prior to the loop.  I don't thing you should need to keep resetting the offset in the loop but since you do reading an additional property probably adds just enough delay to stick the new "same" value which never changes.

Then again, if you really must use external timing per 

---

So you are right that the DAQmx part executes always with the same speed, but I cannot exactly fix the execution time of the non-DAQmx part, thus the loop time might vary too much occasionally.

Therefore, I need to "round up" the total loop execution time to 1000 msec using that "Wait Until Next ms Multiple"...

---

wire -1 to the read count and all of Kevin's advice (excellent though it is!) is moot.  

Spoiler

I told you to just do it my way

---

I can test the idea the next week, so I configure to read 100 samples with 1 kHz before the loop, and I will read all available samples using the DAQmx Read VI with the "-1" value for number of samples inside the loop. The problem with this is, it will output varying number of results I guess...?

--------

EDIT: Actually, I could just take the last 100 values from the result, so it can work. Hopefully the DAQmx Read will not bump into the maximum required iteration time, which is 500 msec in my above example snippet. Hmm, I could just setup the timing to 100/200 Hz, so I get less values. I will test the idea next week...

 ---------

"There is probably an order of operation error in the P node prior to the loop. "

I still do not understand, and the whole thing feels not consistent. I even tried to swap the order of properties in the property node before and also inside the While loop, did not change anything. But that extra "available samples..." prop. node just did the trick.

You see, this is my problem with DAQmx, I just feel I play with it intuitively, and I cannot predict what I get 😞

[Kevin_Price]

---

@JÞB wrote:

---

wire -1 to the read count and all of Kevin's advice (excellent though it is!) is moot. 

I agree for this app, but I had half my focus on giving advice that could be applicable for more general situations.  There are some advantages available when you always read and process in fixed-sized packets.  I also often incorporate this kind of approach into apps where I fire off a read request based on some software-detected event.  This way I can instantly retrieve the most recent 1 second (or whatever) worth of data.  As I recall, wiring -1 also doesn't play nicely with apps that aren't regularly reading from the buffer to prevent overwrites.

To Blokk:  I've never seen the behavior you reported but then again I pretty much avoid USB boards and use direct desktop plugin boards.  That said, the times I'm using this kind of technique are also ones where the task starts and the buffer gets overwritten in the background many times before my first read request comes in.   Consequently, I don't particularly recall scrutinizing the early starting behavior before.  My suspicions lie with something related to the USB bus, but I can't prove it.

   That said, wiring -1 as Jeff B suggests is very likely gonna be a better immediate solution for you.  Less mucking around in general and the extra flexibility of the stuff I posted doesn't seem necessary for your app.

-Kevin P

[Blokk]

Thanks for the explanations!

"That said, wiring -1 as Jeff B suggests is very likely gonna be a better immediate solution for you.  Less mucking around in general and the extra flexibility of the stuff I posted doesn't seem necessary for your app."

I will test it. Since I allow buffer overwrite, and with the -1 wiring I only read the available number of samples, I guess it should run safe, not resulting in DAQmx errors. Actually it is not a big problem if I read 80 or 120 samples instead of 100...

The motivation of this whole thing came from an application where I just wanted to simplify this software timed loop, and accommodate both the DAQmx task and the RS232 (etc) reads in it, plus have a constant (with some jitter ok) loop time. I just want to read about 100 samples from DAQmx and average it, and I do not mind losing data.

Now I really think it would be just more simple if I created a separate DAQmx loop exclusively for it, and get the most recent data arrays via a Notifier simply in the other loop. In this way I can just setup the DAQmx acquisition in the conventional way.

[Kevin_Price]

Below is a snippet to illustrate Jeff B's "wiring -1" suggestion.   Much simpler, and more likely not to have odd quirks on USB b/c it's a much more common DAQmx config for NI to support.

Further comments:

- by sequencing the msec multiple and the DAQmx Read, you don't necessarily need to do a pre-read before the loop

- reading "all available samples" by wiring -1 gives you the *option* of a lossless and non-redundant data stream.  The method I showed serves up chunks of data that may be discontinuous or may be partially overlapping.  No realistic shot at a lossless stream.

- no more property nodes to set "Offset" or "RelativeTo"

- I purposely did *not* configure to "allow overwrite."  As I mentioned earlier, I have a memory from many years ago of that setting not working well with the notion of reading "all available" samples.  After a buffer overwrite actually happens, I'm not sure what you get back when requesting "all available" samples.   Some of the ones that the driver *wanted* to consider as available have already been overwritten...

-Kevin P

[JÞB]

Frankly, I did like Kevin's approach and would use it in the cases he elaborated on.  Thanks for teaching an old dog a new trick.

The choice between Serving up a DAQ data notifier and reading -1 inside the same loop as other things happen in comes down to how closely related the DAQ data and other things are.  i.e. a software side closed control loop or just all acquisition.  You never mentioned the other things going on but, I know you can make the right choice.