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

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

www.vtiinstruments.com
EX1629 Programming 87
acqdata,
&numdata,
TIMEOUT_SECS);
The actual number of scans and data returned by vtex1629_read_fifo may be equal to or less than
the values requested (NUM_SCANS and MAX_NUM_SAMPLES in the example) if the timeout
period (TIMEOUT_SECS in the example) expires before the EX1629 has acquired the requested
number of samples. The actual number of scans returned and data values returned are stored in
numscans and numdata, respectively, by vtex1629_read_fifo.
Additionally, there is a vtex1629_read_fifoEx function that provides access to acquisition data
from the confidence measurement system. Please refer to the function references for further
details.
Asynchronous Streaming Data
The asynchronous streaming data interface optimizes communication between the host computer
and the EX1629. The asynchronous streaming data interface allows the EX1629 to transmit
acquisition data to the host computer whenever data is available. It “streams” data to the host
computer – that is the EX1629 transmits data when available – and is “asynchronous” in that data
arrives outside the normal control flow of the user-application. This is in contrast to the Read
FIFO mechanism, where the client polls or queries the instrument for data, and the data is returned
to the user application when the vtex1629_read_fifo function returns (synchronous with the
normal program control flow).
Figure 6-2 illustrates the general sequence of events when using the streaming data mechanism.
This can be compared to Figure 6-1 for using the Read FIFO mechanism. Prior to initiating the
acquisition (vtex1629_trig_init), the streaming data interface must be enabled via the
vtex1629_enable_streaming_data function). This configures the streaming data communication on
both the instrument and the host computer. It is important that the streaming data interface be
enabled prior to initiating acquisition, as the EX1629 prevents streaming data from being enabled
after initiating acquisition. As Figure 6-2 shows, the EX1629 transmits acquisition data to the host
computer periodically, whenever data is available, without the host having to request it.
The streaming data interface uses a separate “socket”, or communications link, than the one used
for other instrument driver functions. Since TCP/IP can support thousands of concurrent sockets,
all multiplexed on the same network interface, this does not present a problem for the network.
NOTE The network communication diagrams provided are oversimplifications. Since TCP/IP is used as
the transport layer, there are potentially several Ethernet packets involved (send and receive) in
each high-level message. These packets provide, among other things, the reliable data transport
feature of TCP.
The asynchronous nature of the streaming data arrival at the host computer presents the issue of
how to deliver the data to the user application. For efficiency, particularly when the acquisition
system consists of many instruments, a multi-threaded model was chosen.
Multi-threaded programming is beyond the scope of this manual, but the general idea is that an
application can have multiple, concurrent “threads” of control. By default, all applications have
one thread, the one that begins executing at the main() function (or similar entry point, depending
on the programming language). Optionally, applications may have additional, programmer created
threads. These threads all execute in the same memory space, making it very efficient for them to
share data. This is different from multi-process programming, wherein each process – basically a
memory space with a single, default thread – executes independently.
Threads execute asynchronously to each other by default – that is, their execution relative to other
threads within the same application (process) is non-deterministic, and shared data must be