LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

DAQmx continuous acquisition

Solved!
Go to solution

Thank you Rodrigo.

 

When you talked about "samples per channel" I thought you where refering the "samples per channel" input in DAQmx Timing vi, which sets, as I realize now, the buffer size when "sample mode" is continuous.

 

I realize now that when sampling at a rate of 1000S/s the smallest buffer size allowed is of 10kS, so my setting of 100S was useless.

 

Setting the "number of samples per channel" allowed me to remove the "wait" i had in the while loop.

 

Resuming: the problem arouse when trying to save measurements from NI-9236, which has a minimum data rate of 794S/s, with a lower frequency (this is particularly necessary for "structural static tests"). This was solved by setting a 1000S/s (I prefer round numbers) and a "number of samples  per channel" of 20, resulting in a 50Hz data logging. I'm not sure this is the best way to go but it clearly worked.

0 Kudos
Message 11 of 13
(734 Views)

Hi Jeff,

I followed your first advice. (Changed "Start task" with "Control task" + "commit", and "finite samples" for "sample mode").

This worked for a while until I got this error message:

This error showed sooner or later, depending on the "Buffer size" I set.

I have never used the producer-consumer structure, I will try it soon.

Regards.

 

FiniteSampleProblem.png

0 Kudos
Message 12 of 13
(733 Views)

Make sure you Read the Number of samples you set in the timing node.  The task stops after it acquires the number of sample set in the TIMING vi but the Read vi returns just as many samples as you ask for-  (leaving some old stuff in the buffer that will eventually get overwritten.

 

I put up a example PC stae for DAQ a bit ago I'll check my images and post a link

 

Here is a link to a similar thread with an example of a P-C DAQ system


"Should be" isn't "Is" -Jay
0 Kudos
Message 13 of 13
(729 Views)