DAQmx continuous (buffered) triggered acquisition

[s]

I am trying to use the DAQmx vi's to program a PCI-6251 board for triggered data-acquisition. The task channels (which includes the trigger channel) are set on "continuous" mode. Also set in the front panel of my app are the acquisition rate (DAQmx-Timing.vi), the number of samples per channel (DAQmx-Read.vi), timeout (DAQmx-Read.vi )and the buffer size (DAQmx-Configure-Input-Buffer.vi).

Given the timeout value, I know that the acquisiton is triggering. However, the data that I am reading from the buffer is not correct. I suspect the data is being overwritten: the waveform that is acquired is not in phase. Using the TestPanel from the MeasurementAndAutomationExplorer and configuring the task channels to use the "finite" sample mode, the waveforms are indeed in phase. However, this "finite" sampling mode is not adequate for my app since it really slows down the acquisition loop (<10Hz).

Is there a way to use the "continuous" sampling mode while keeping track of the buffer so that I am reading the waveform properly?

[s]

okay. some more notes and clarification.

Goal:
-----
-to trigger start data-acquisition of waveforms with the fastest rate
possible (1MHz for the PCI-6251 DAQ board). The phase of the waveform
(relative to the trigger) should be preserved. (i.e. each consecutive
waveform sample should be in phase). The samples would be read from
DAQ buffer into program process memory and then finally appended to a
file.


Configuration and programmatic sequence:
----------------------------------------
Task includes an analog input trigger line and a waveform input signal.

DAQmx-Timing.vi
-continuous sampling mode
-sample rate

DAQmx-Trigger.vi
-triggered on a rising edge for an analog input line (I convinced
myself that the trigger works by having the DAQmx-Read.vi timeout be
excessively long. When the trigger is connected, data-acquisition
occurs (but its finer details are another matter).)

DAQmx-Set-Input-Buffer.vi
-set buffer size

DAQmx-Start.vi

DAQmx-Read.vi called within while loop.
-set "Number of Samples"


Observations:
-------------
(1) The basic form of the program as detailed above would result in
the waveform (acquired for each iteration of the while loop) being out
of phase compared to the waveforms returned from previous or following
calls to DAQmx-Read.vi. Or, in other words, if a waveform graph
continually displays the waveform output of DAQmx-Read.vi, one would
not see an expected steady signal, but rather a signal that shifts.

(2) This steady signal could be properly acquired using the above
program in "finite" sampling mode (DAQmx-Timing.vi). However, this
change would slow the program down considerably. Perhaps this is due
to some automatic internal resetting after the acquisition is
finished??

(3) How does this compare to the behavior of TestPanel from the
MeasurementAndAutomationExplorer? I saw the same behavior. That is,
the TestPanel for the same task in "finite" sampling mode gives me
samples of the waveform starting from the time of trigger; each
waveform, as shown on the graph, conicides with other waveforms that
are redrawn successively over each other. However, like my program
above, the TestPanel in "continuous" sampling mode always redraws the
waveform samples out of phase.

(4) Could the buffer be overwritten so that I am reading subsequent
acquisitions at arbitrary positions?

(4a) I wired the Property node before starting the task so that
ReadAllAvailSamples is true. I am assuming that this would allow me
to clear the buffer by reading all available samples. The
ReadPosition would then be advanced to the buffer location that would
store the first sample after the next trigger. Unfortunately this did
not work: the acquired waveforms are
still out of phase. What is also puzzling is that the AvailSamples
(from Status) is never zero immediately after a DAQmx-Read.vi call.
So, this would lead me to believe that something didn't quite work.
Following the documentation provided, I set DAQmx-Read's parameter,
"Number of Samples" = -1 to effectively ReadAllAvailSamples, but this only resulted in
DAQmx-Read returning NaN error values.

(4b) I wired the Property node before starting the task so that
Overwrite = DoNotWriteOverSamples. This also choked up the
software with DAQmx-Read.vi returning "NaN". So I left Overwrite = WriteOverSamples.


--- continued below ---

[s]

--- continued from above ---


(5) Hmm.. so I now decide to figure out what this buffering business
is really about. I wire up Property Nodes inside the while-loop to
display Status before and after the DAQmx-Read.vi call. The status
includes CurrReadPos, AvailSamples, and SampReadPerChannel(?). Some
observations are listed below:

(5a) I suppose CurrReadPos is a pointer to buffer memory. However,
this pointer is somewhat abstracted given that it is not circular; it
is also a running counter of the number of samples read per channel;
it may exceed the size of the buffer. Or, in other words, could it
be that CurrReadPos mod the "Number of Samples" parameter for
DAQmx-Read.vi is the actual buffer index?

(5b) Running the program for approx the same time, setting a
timed-while-loop with a greater period would result in a larger ratio
of AvailSamples-vs-CurrReadPos. This is reasonable since the buffer
is continually being filled by a triggered acquisition that runs
independently of my program which merely reads "Number of Samples"
from the buffer on each iteration of the while-loop. If the
while-loop is too slow, the buffer will be overwritten. But..

(5bi) Does the AvailSample simply "run away" and increase indefinitely
compared to a modest buffer size? If this is so, then AvailSample
confounds the problem of keeping track of buffer pointers (if it is at
all possible!!).

(5bii) A little experiment: Set the buffer size to be a large number to
avoid buffer overwrite. While the ReadCurrPos and AvailSamples were
still much less than the buffer size, the waveforms acquired were
still out of phase. Hmmm... Is the buffer size limited to the
AnalogInput FIFO buffer size (4095 for the PCI-6251)?

(5biii) Okay. So set the buffer size to be 4095. Also set the "Number
of Samples" to be 4095. Assuming (if valid?) that the triggered
acquisition is much much faster than the looped DAQmx-Read.vi calls,
then each trigger will completely fill up the buffer AND each
DAQmx-Read will completely read (and clear) the buffer that now
contains the properly timed waveform... However, this is not the
case. The waveforms are still out of phase. Could it be that the
buffer is being overwritten while it is being read?? I also tried
such numbers as 128, 256, 512, and 1024. No luck.

(5biv) Perhaps I can change the RelativeTo and Offset Properties so that
I am reading from a better postion in the buffer. (i.e. setting
Offset to be the AvailSampl which effectively clears the buffer).
However, any such change, I soon discovered, would slow down the
program to a rate comparable to a "finite" sampling mode version. I
suspect that there is also some under-the-hood resetting which occurs
in this instance.

(5c) SampReadPerChannel is not an integer! What does this mean?




So from all of the confusion above, with all the tinkering of buffer, sample size, etc, I still wonder if it is possible to have a triggered continuous acquisition using DAQmx vi's that would preserve the waveform phase.

Finally,.. is there a way to get the traditional NI-DAQ VI's to work with the PCI-6251 (which is a DAQmx device)?

Thanks..

[AnujD]

A few thoughts --

Here's a great KB that explains how the timing information is stored on a DAQmx Waveform:
http://digital.ni.com/public.nsf/websearch/5D42CCB17A70A06686256DBA007C5EEA?OpenDocument

The program you start with -- are you using an example program? Open LabVIEW and look for Help >> Find Examples. I am assuming you already found this, but I have never seen any phase shift problems when acquiring continously using these examples.

If the buffer is overwritten you would get an error.

You should not have to worry about the the buffer positioning, but I beleive there are property nodes that let you do this.

You cannot use a M Series DAQ board with Traditional DAQ.

Here's a great resource to answer FAQ on DAQmx:

http://zone.ni.com/devzone/conceptd.nsf/webmain/EE47B125BB9E053686256FBC0014C384?OpenDocument&node=10181_US#2

Regards,
Anuj D.

[s]

Thanks for the info!

Actually here's what I discovered from studying the examples.

Continuous sampling mode is not used for triggered applications that try to preserve phase information (waveform relative to trigger signal).
Finite sampling mode IS the ideal mode for such applications.

Analog Trigger with Finite sampling mode is A LOT slower than Digital Trigger with Finite sampling mode for the PCI-6251.
I suspect that depending on the type of trigger, the DAQ boards re-arms itself differently.

In the end, I found that using a digital trigger is adequate.

Scott