VTI Instruments EX1629, Руководство пользователя

Страница: 85 / 346

www.vtiinstruments.com
EX1629 Programming 85
R
ETRIEVING
D
ATA
(R
EAD
FIFO
AND
S
TREAMING
D
ATA
)
The EX1629 stores acquisition data in a large, on-board FIFO in the instruments RAM memory.
48 MB of RAM are reserved for the on-board FIFO. There are two primary mechanisms for
retrieving acquisition data from the EX1629 FIFO:
Read FIFO
Asynchronous Streaming Data
The Read FIFO mechanism is similar to the way data is returned from traditional data acquisition
instruments, with the user application making periodic (polling) queries of the instrument to
retrieve data from the instrument’s on-board FIFO, while asynchronous data streaming is a more
modern, efficient technique, made possible by the instrument’s LXI interface, in which the
instrument automatically transmits acquisition data to the user application as data becomes
available.
The streaming data interface is slightly more complicated to use than the Read FIFO interface, but
makes very efficient use of the host computer’s processor and the test system’s network. As such,
the streaming data interface scales well for high channel count and/or high sample rate systems.
The two data retrieval mechanisms are mutually exclusive – if the streaming data interface is
enabled, Read FIFO requests will return an error.
Read FIFO
Use of the Read FIFO mechanism is straight-forward. After properly configuring the system and
initializing acquisition (vtex1629_trig_init), a user-application queries the instrument’s FIFO for
data using the vtex1629_read_fifo function (or the vtex1629_read_fifoEx function – see below).
This function takes the number of data scans to retrieve as an argument, along with a timeout
value in seconds. The instrument driver attempts to retrieve the requested number of samples from
the instrument, returning to the user-application when either the request has been fulfilled, or the
timeout elapses. To fulfill the request, the instrument driver may need to make many, repeated
queries of the instrument, each query being a network transaction with the instrument. The
instrument driver continues “polling” the instrument for data. During the instrument driver call,
the user-application “blocks”, meaning that the user-application does not continue to the next
instructions until the vtex1629_read_fifo function returns.
Figure 6-1 illustrates the general sequence of events when using Read FIFO. In this diagram, time
flows from top to bottom. The two vertical lines represent the two network nodes: the host
computer, running the user application, and the EX1629 instrument. The diagonal arrows
connecting them represent network messages sent between them (the diagonal arrow, instead of a
horizontal arrow, indicates that the message is not received instantaneously). As illustrated in this
diagram, each instrument driver function call results in two network messages: one to the EX1629
(a request) and one from the EX1629 (a response). The instrument driver function does not return
control to the user application until the response message is received.
As can be seen by the vertical distances, each of the instrument driver function calls takes some
finite amount of time, allowing for host computer processing, network transmission and reception,
and instrument processing. For instrument setup (e.g., configuring acquisition channels or trigger
parameters), this time is typically negligible. For retrieving acquisition data, however, these delays
can become significant. This is especially true in high sample count and/or high channel count
systems. In such systems, the host computer can waste a significant amount of CPU time in these
polling loops, also consuming network bandwidth. The streaming data mechanism offers a more
efficient alternative.