DAQmx Read and Write vi problems in while-loop

[beam]

Dear DAQmx professionals,

This is a follow on discussion to the earlier post “generating analog voltage output in increments with simultaneous analog input voltage acquisition” found here:

http://forums.ni.com/t5/Multifunction-DAQ/generating-analog-voltage-output-in-increments-with-simult...

I am still having problems using an analog Write vi and Read vi inside an while loop to accomplish the following:

loop iteration (1): set a constant analog output voltage (e.g., -2.6 V) and then AFTER this acquire n-mumber (e.g., 256) of voltage samples.

loop iteration (2): increase the constant analog output voltage to e.g., -2.6 V + (1* voltage step) and then AFTER this acquire the next n-number (e.g., 256) of voltage samples.

loop iteration (3): increase the constant analog output voltage to e.g., -2.6 V +(2* voltage step) and then AFTER this acquire .............

Problems:

When setting the AI channel sample clock to finite acquisition (with samples per channel: 256) and wiring a value of -1 to the Read vi, I am getting error -200278.  The the NI article "Error -200278 at DAQmx Read" suggests to switch to continuous acquisition if the Read vi is inside a while loop.

After switching to continuous acquisition, I deleted the samples per channel control at the AI sample clock and instead wired a samples to read control (i.e., 256) to the Read vi inside the while loop (please see attached Output_Input_IncrementLoop_6a_Rev). This solved the error message. However, how do I know that I am reading the “right” 256 samples per loop iteration from the buffer?  I included a Read vi property node to overwrite unread samples but I am not sure if this is the way to go?

Is there a way to use finite sample acquisition with a Read vi inside a while or for loop?  I think this would also make the buffer use much more efficient so I can apply a higher sample rate in the future when acquiring and reading more than 256 samples per channel?

In addition, I need to include a delay after setting the analog output voltage so that the external instrument connected to it can settle down before acquiring the 256 voltage samples via the Read vi.  I have tried to achieve this by including a sequence structure with a wait vi (please see attached Output_Input_IncrementLoop6a_Rev_WithDelay). However, when executing this program I will get error -200279 at the 0.75 V increment of the loop.  I assume this is again a buffer issue?

I would really appreciate if somebody with real DAQmx knowledge could tell me how to do these things properly as I am trying to figure this out for the last 4 days and now reaching “desperation state” J.

Best regards,

Beam

p.s., Using NI PCIe6363, X Series DAQ card connected to BNC-2120 connector block with Labview 201- (32-bit) – Full development System.

[beam]

Hi,

Is someone out there who could help me with this?

I would very much appreciate some help as I am stuck with this problem .

Best regards,

beam

p.s., The only example I could find in the NI discussion forum which is somehow related uses a timed while loop and can be found here: http://forums.ni.com/t5/Multifunction-DAQ/AI-with-timed-loop/m-p/737967#M41354

[Daniel-H]

Beam,

You can ensure that you are getting the "correct 256" samples simply because of the way the hardware works.  The buffer is a FIFO buffer meaning that the first values written will be the first values read.

The reason you are most likely getting this error is because you have set a finite size on this buffer.  While your program is waiting, the buffer is filling up. By the time you do your read task, your buffer is probably already full.  Since you are not defining this buffer size, it is defaulting to 1000.

You can either increase this buffer size or decrease you wait time to help with these errors.

Daniel

[Mcdan]

Beam,

I think you are on the right track.  When using finite sampling mode, you'll have to Start and Stop the task inside your loop (Use DAQmx Start Task before DAQmx Read, and DAQmx Stop Task afterward).

Hope that helps,

Dan

[beam · Accepted solution]

Dear Daniel and Dan,

Thank you very much for your comments and suggestions.  I have solved the problems but with using continuous acquisition mode and addressing the buffer via property node.

Berst regards,

beam