>> I've been experimenting with the AI Read VI and digitally triggered, buffered acquisition. I modified an example VI called, I think, "Acquire N Scans Digital Trig.vi" to call AI Read two times with several seconds of delay between calls. The first call, which returns the entire acquisition as waveform data, is made before acquisition is complete, so it blocks until it can return the data. The second call, after the imposed delay, returns 1 scan worth of waveform data with a read/search location of -(NSCANS-1) relative to "end of data". It turns out that the timestamps of both sets of waveform data are the same to within a millisecond, in spite of the delay.
Your point is valid. If you call AI Read with a read/search location of -(NSCANS-1) relative to "end of data" then it will not generate a second timestamp because the read/search location relative to "end of data� is telling the VI that the data has already been acquired and that it should use the timestamp already associated with it
>> Clearly, AI Read doesn't generate a new timestamp every time it is called.
As can be inferred from above, AI Read will generate a new timestamp when called depending on the read/search mode used.
>> Does the first call to AI Read cause the storage of a system time which is then used for subsequent calls to AI Read that occur before AI Clear?
The short answer is yes. Let me clarify under which circumstances the timestamp remains associated with the data:
If using a reference trigger
AND calling AI Read before the hardware has finished the input operation
AND specifying the read search location relative to the trigger point
AND reading the total amount of points in the buffer (read = buffer size)
Then:
A correct timestamp (precise to the ms range) will be associated to the data. The timestamp will be obtained from the system time by the AI Read VI as soon as the data is available. Calculations will be performed in order to subtract the total acquisition time ((pre-trigger + post-trigger samples) / Scan rate)) from the time the data was available to AI Read (the time the hardware operation completed) therefore obtaining the t0 (initial time of the returned waveform).
Additionally:
Successive calls to AI Read with a read/search position relative to the end of data will not yield in a new timestamp and will use the original system time (from when the data became available and perform the same calculations again in order to return t0.
>> or does the PCI6110E board store a system time when it acquires the data, independent of when AI Read is called, that the AI Read VI refers to to generate timestamps?
No, the hardware does not access the system time. AI Read obtains the timestamp. You can verify it by delaying the initial AI Read long enough so that the operation is complete way before you issue the Read call.
>> If the AI Read VI has already been called at least once to read the entire set of acquired data (= entire buffer?), will this method work?
Assuming you are referring to finding out what the current backlog is:
It will work if you use the read search position relative to the end of data, with an offset of �NSCANS. And the number of scans to read equals zero.
I must warn you that the timestamp will be bogus because the calculations will not work correctly unless you read all the data available in the buffer (make the number of scans to read equals to the buffer size). This takes us to the next point:
>> I was under the impression that "backlog" only refers to data which has never been returned by the AI Read Buffer VI, or AI Read VI. This is significant to me because I was hoping to create, for my own future use, a subVI that would return the timestamp of the first acquired data point given as input only a task id.
If you are willing to make the timestamp calculation yourself then I believe it would possible to do it by:
- Reading from the same task ID before you clear the operation.
- Setting the read search position relative to the end of data, with an offset of �NSCANS
- Reading 0 scans and subtracting the total acquisition time ((pre-trigger + post-trigger samples) / Scan rate)) from the timestamp you obtain from the waveform returned by the read call.
I know one of your concerns has been the amount of data you pass into your sub-VIS. I understand this concern and I wanted to point out that there is more than one way to pass data in LabVIEW. Things that might be useful:
- Using clusters
- Using local Variables
- Using clusters and local variables
- Using Global Variables
- Using VI Server to read, write and programmatically control VIs (even if they are not sub-VIs of your application)
I have also noticed that you are concerned with the fact that AI-Read blocks the program execution. AI Read is a synchronous call and it will wait for the requested amount of data or time-out. Some things you might want to experiment with:
- Using parallel architecture within your Vis, there are all kinds of synchronization objects available in LabVIEW, you can use local variables to pass data.
- Using a timeout of 0 in your AI-Read and polling every so often to see if the data is there (your timestamp will be affected by how often you poll)
- Using DAQ Events (occurrences in LabVIEW). Unfortunately the DAQ Occurrences do not apply to pre-triggered (this case) acquisitions because the occurrences are fired by the continuous acquisition (which is waiting for the reference trigger).
- Using VI Server to execute a separate VI which could perform the acquisition and hold the data for you, without obstructing the dataflow of your main VI.
- Dynamically calling a sub-vi and using VI Server to read the results from it (similar to the previous option)
For more information on the topics I have mentioned above please consult the LabVIEW User Manual and the LabVIEW Measurements manual. There are also shipping examples available for some of these concepts.
I hope this helps,
Alejandro
