LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Odd Simulated Device Behavior

Hi Steve, 

 

I am still not sure I understand what you mean by, " It DOES NOT REPORT samples that should be there." Can you please clarify? To which test from above are you referring?

Best Regards,

Thomas B.
National Instruments
Applications Engineer
0 Kudos
Message 11 of 13
(525 Views)

It's not that complicated - look at the very first graph I posted, labeled "What I see is this".

 

I'm asking it to read one sample.

 

It tells me there are NO samples available.

It tells me there are NO samples available.

It tells me there are NO samples available.

It tells me there are NO samples available.

It tells me there are NO samples available.

It tells me there are NO samples available.

It tells me there are NO samples available.

 

Then it tells me there are TWENTY samples available.

 

That doesn't correspond to my definition of CONTINUOUS.

Steve Bird
Culverson Software - Elegant software that is a pleasure to use.
Culverson.com


LinkedIn

Blog for (mostly LabVIEW) programmers: Tips And Tricks

0 Kudos
Message 12 of 13
(521 Views)

Hi Steve, 

 

I still believe what you are seeing is expected behavior. When you invoke the Available Samples in Buffer Property Node it tells you how many samples are in the RAM memory buffer on your CPU, not the FIFO on your DAQ device. Similarly, when you invoke the DAQmx Read.vi, you are telling the VI to read samples from the RAM memory buffer on your CPU, not the FIFO on your DAQ device. That being said, you did not appear to have any sort of timing VI in the loop in which you called these two VIs, which meant they were called as quickly as the CPU could run the loop. Also, you did not wire anything into the "Samples to Read" input of your DAQmx Read.vi, which means it defaults to "-1" which will read all of the samples from the RAM memory buffer of your CPU. 

 

Setting a task to Continuous Samples does not ensure that you will have a continuous stream of data being sent to you RAM memory buffer as the samples are taken, but simply means your acquisiton has no definite end, as does a finite acquisition. With a continuous acquisition, your DAQ device will take samples at approximately the rate you specify (depending on integer divisor values and your base clock rates) but will not transfer the data to your CPU's RAM memory buffer every time a sample is taken. It will wait until 2 samples are taken, at the very least, before it dumps the samples onto the CPU RAM, unless Hardware Single Point is selected as your Sample Mode. When Hardware Single Point is selected, no hardware buffer is allocated, which means the data points are transfered to the CPU RAM buffer more quickly, and one at a time. Otherwise, the hardware will dump samples onto your CPU RAM buffer at fairly regular intervals, but not every time a sample is taken. This is why when you acquired data at a rate of 1000Hz you saw 20 samples get dumped into the CPU RAM buffer at a time, and when you acquired at 100Hz, they arrived in 2 sample increments. 

 

Hopefully this all makes sense. If it does not, you may want to read through the follow KnowledgeBase articles, and their related links. 

 

Why Do I Have to Specify a Number of Samples to Read When Continuously Acquiring Data?

Samples Per Channel Input of -1 On the DAQmx Read VI

DAQmx Timing and Sample Rates

 

If you have any more questions, let me know

 

 

 

 

Best Regards,

Thomas B.
National Instruments
Applications Engineer
0 Kudos
Message 13 of 13
(500 Views)