DAQmx Continious Acquisition - Empty Array!

[Jack_W]

Dear all,

I have a problem with a continuous measurement with DAQmx.

Every not and than, the array that I get from the READ.VI is empty (size=0), so I get an nan after taking the mean.

When looking at the size of the array that I get from the Read.VI, I noticed the following:

lets say the array-size is constant 100 most of the time..Some random loop iteration, the size doubles and the next iteration, it is 0!

I have absolutely no idea where it comes from. So I made a stripped down version, just like in my actual code. However, in the stripped version, the problem did not occur!

So I think I have to past the actual code, which is pretty messy.

The problem is in the statemachine in the center-loop. I initialize the tasks in the "init"-state..than "start", and I read my voltages in the "messung"-state.

Thankful for any hints!! I tried playing around with sample rate, buffer size, loop timing..Nothing worked so far.

Cheers.

[vt92]

From the help file on DAQmx read:

number of samples per channel specifies the number of samples to read. If you leave this input unwired or set it to -1, NI-DAQmx determines how many samples to read based on if the task acquires samples continuously or acquires a finite number of samples.

If the task acquires samples continuously and you set this input to -1, this VI reads all the samples currently available in the buffer.

I can't tell if you have any kind of wait in your loop, but it could be that some iterations happen fast enough that no data is yet available.

BTW, I really recommend that you get rid of the flat sequence structures and reduce your block diagram so that you don't have to scroll up/down and left/right.

[JÞB]

Wow what a mess!

Your basic problem boils down to your messenging system that is trying to keep your loops in sync.  It is not going to work right at all.  Your "State machine" cannot iterate untill two different notifiers are recieved.  the enqueuers of these notifiers are in two differently timed loops.  One is in a loop with a wait till next ms multiple (10 ms) the other in a loop with a wait till next ms multiple (50 ms)  Both of those loops also do DAQmx I/O (And one of those tasks is created IN the loop! Bad Bad Bad.)

I hate to tell you but, you have gone merrilly down a very dark path and you will need to do some significant refactoring to get where you need to go.

[Jack_W]

Thanks for the hints!

I know it's very messy right now.

Jeff, I unterstand so far - the state machine loop has to wait for the notifiers in order to iterate. It makes sense that those loops sending the notifiers have to run at the same speed, stupid mistake, just like the one creating the task in the loop.

You mention, that both of the loops sending the notifications also do DAQmx I/O. Did you mention that in order to point out the mistake of creating the task in the loop or is that something I should generally avoid? If I should avoid it, could you mention why?

vt92, I had a look at the help of the readVI and had the numbers of samples per channel set to -1 before since I thought reading all the samples available in the buffer is what I want to do.

I cannot try the code until tomorrow (Europe) - anyhow, thanks for the hints, as you saw I really could use the help...

[JÞB]

IO in a loop responsible for queuing synchronization functions is probably not a robust implementation. Those timeouts WILL bite and bite you hard.

Consider using a master timing source to cordinate all loops. and really those loops shohis be in subvis with some documentation about what its responsibilities are. organized code is a good way to mand development AND debugging a lot easier