Time delay while flushing the buffer of a DAQmx task

[atwright]

I am currently using a NI DAQPad-6015 and SC-2345 Signal Conditioning Box with SCC-A103 conditioning units. It is configured with a laptop with Windows XP and Labview 7.1. To read in analog ins, I set up a DAQmx task for the 16 NRSE voltage channels sampling in a continuous sampling mode at 5000 fps per channel. The program collects and displays data live, then, when prompted, triggers outside devices through digital outs (a different DAQmx task) and begins writing the analog in data to a file while still displaying a live data feed. I have been looking for an efficient way to clear the buffer of the AI task before writing to the file such that the delay is minimized between the digital signal change and data collection. The best solution I have found still results in a 8ms delay (which is still a little long for our purposes). Here is my current method:
- Data is read in one final time for the live feed along with a couple of other commands (digital changes)
Then in a sequence structure:
- The task is stopped
- The data remaining in the buffer is read by setting number of samples per channel to -1
- The task is stopped
- The task is started
- The digital signals are sent out
Finally:
- Recording of the AIs begins
Note: All of the commands (read, stop, start) are the DAQmx subVIs in LabView. If there is going to be a delay, it is important that the AI task is started before the digital signals are sent such that we can record the DO change and measure the delay for correction.

I realize that the method above seems ackward and inefficient, but it's been the best that I've found through much trial and error. Is there possibly a DAQmx subVI that would clear the buffer quicker/easier? Or some way to improve the rate at which the digital signals are sent to decrease this delay? Or is this just the intrinsic delay for changing DO with Labview in our setup? Any help would be greatly appreciated.

[gcs]

One suggestion I have is to start the task that generates the digital signals at the beginning of your application. Then, when it is time to write the digital signals, simply write to this task that has already been started. This assumes that the digital generation is on-demand. This approach removes the time that is required to create, verify, reserve, commit, and start the digital generation task from the time critical section of your application.

Regarding "clearing the buffer," while I haven't tried it, I would explore the RelativeTo property in the DAQmx Read property node. Perhaps by setting the RealtiveTo property to "Most Recent Sample" and then back to "Current Read Position" would have the effect of moving the read position to the end of the buffer. I'm not sure if that will work, you may need to actually perform a small read in between the two modifications of the RealativeTo property.

geoff

[Kevin_Price]

RE: the "RelativeTo" property in the DAQmx Read property node.

I'm running an app where I regularly use the "RelativeTo" property set to the value 'Most Recent Sample' and I think geoff's suggestion might very well work for you.

In my app, I first call the DAQmx Read property node to set "RelativeTo" to 'Most Recent Sample' and set "Offset" = -50. My subsequent call to DAQmx Read.vi (with '# to read' set to 50) gives me the 50 most recent samples acquired without any delay waiting for new data. Then I evaluate the data, and depending on what I find, I may then ask for the next 50 future samples by setting "RelativeTo" to 'Most Recent Sample' and "Offset" = 0 (or maybe 1?), and calling DAQmx Read.vi (with '# to read' set to 50 again). In my app, the buffer sometimes overwrites unread data between Reads, but by using the DAQmx Read property node I don't get stuck with buffer overwrite errors.

Note that once you start overriding the default read mark, your buffer is more likely to overwrite itself. This will not generate an error for subsequent reads with "RelativeTo" = 'Most Recent Sample', but it may prevent you from reading relative to the 'Read Mark' (or 'Most Recently Read' -- I forget the exact name and my LV PC is a long walk from here). Also note that by skipping some data, you'll be glitching your live display a bit, though you're already doing some of that by stopping and restarting the task.

-Kevin P.