DAQmx not correct number of samples read

[Harlequinade]

I was trying out some code on my developer pc. I don't have access at the moment to a real DAQmx card (DAQmx 9.5.5 installed), so I simulated in MAX 5.3.1f0 the PCIe-6353 card.

But I got in LV 2012 some unexpected behaviour and was wondering if that is by design or if it is a bug.

When I set for the Sample Clock a new value for the amount of samples, this number of samples is not read. Only when I set also a new value of sampling rate the correct number of samples is read. 

I made some code to test this. For example I first set the number to 1000 samples, then 2000 and finally 3000. For the sampling rate I set it to 100,000; again 100,000 and finally a new value of 200,000. The amount of samples read is: 1000, 1000 and 3000. Thus when setting to 2000, this is not used somehow ...

Using different numbers has no effect.

Output

Attached is also the code

[Norbert_B]

First off, this could be an issue with simulated devices, so a test with real hardware is necessary.

That being said, there are several questions i want you to answer:

1. Is for the first increase of #samples (1000=>2000) also the result of the property node "Available Samples Per Channel" still 1000?

2. Is there possibly a warning which you dont display currently?

3. Can you include a property node after setting the new timing setting querying the buffer size?

Norbert

[Harlequinade]

Thanks for your prompt response. Perhaps tomorrow I could try out on a real DAQ board and let you know.

That's the thing, I don't know if it's only for simulated cards ...

Regarding to your questions:

1. The amount of samples is given correctly: 1000, 2000, 3000

2. No, no warnings nor errors are produced

3. Sure, those are given correctly

[Norbert_B]

Hm, looking at the screenshot, we learn two things:

a) The buffer is resized correctly (InputBufSize)

b) The amount of available data does not change properly (available)

That being said i am wondering if forcing DAQmx Read to fetch the #samples instead of "available" will create an error....

It seems to me that DAQmx erroneously does only resize the buffer but does not instruct the task to sample this amount of data.

@All: please note that this issue is only valid for acquisitions with the following constraints:

- Not destroying the task inbetween and re-create it

- Finite acquisition

- Obviously only changing the #samples using the DAQmx Timing VI

Possibly, it is also connected to "Is Task Done" returning falsely after too few samples. Maybe you want to replace this with a static wait time configured to a little longer than the acquisition should take. Does the "available" still stick at 1000 for i=1?

Norbert

[Harlequinade]

By replacing "Is Task Done" by long waiting time, no difference.

By replacing the amount of sample to read to "-1" at "DAQmx Read", no difference

[Yamaeda]

Why do you check number of samples and read that, instead of simply wiring "Read 1000 samples"?

Would it make a difference?

It seems the buffer isn't resized as it should.

/Y

[Harlequinade]

If I wire the number from the array directly to the DAQmx Read method, there is no difference.

The whole point is that the values in available and samples read is the same if you wire at DAQmx Read a) the number of samples in the buffer, b) -1 or c) the number of samples it should have. 

For me it was surprising that when I changed the number of samples to read, nothing happened, only when I changed the sampling rate simultaneously it would set the new values.

I'm afraid it has something to do with the simulated device, but perhaps someone with a DAQ card installed could check it quickly ...

[Norbert_B]

Did you already check for reading the desired #samples directly? Does DAQmx Read create an error when trying to read 2000 samples in i=1?

Norbert

EDIT: Ok, it seems that reading 2000 samples in i=1 does not return an error, but the array is still only 1000 values per channel long. Correct?

[Harlequinade]

Indeed no error is given and it's still 1000 long.

[Norbert_B]

OK, i just tested it with a simulated X-Series device using LV 2013 and DAQmx 9.7.5 and i can reproduce the issue.

Changing the #samples for DAQmx Timings is only modified for actual "reading" if the rate also alters (tested with .001 more which was already sufficient).

Another thing i tested is to explicitely include a "SampQuant.SampPerChan" property AFTER DAQmx Timing writing the same amount again. It also works, but i got the feeling that the loop is slowed down by that.

What i am wondering about:

DAQmx Timing.vi is only a single stacked property node. When a property fails to write, it will create an error. As this property node does NOT ignore errors, it should be passed on. All properties below the offending property will be skipped using this option (default option for property nodes).

So we can assume that SampQuant.SampPerChan is executed within DAQmx Timing.vi (buffer resize confirms this), but obviously the task is not updated correctly. I guess it is some timing race condition on the configuration of the task and proceeding to the next property in the stacked property node.

Please let me know if real hardware also encounter this issue.

Thanks,

Norbert