VTI Instruments EX1629 - Page 88

VTI Instruments Corp.
88 EX1629 Programming
protected by design or through suitable inter-thread communication mechanisms (e.g., mutexes) to
guarantee consistency. Again, multi-threaded programming is beyond the scope of this manual,
but it is important to understand the fundamentals before the streaming data mechanism can be
used properly. For more information on this topic, we recommend reviewing a textbook on
operating systems (e.g., Operating System Concepts, by Silberschatz, Galvin, and Gagne or
Modern Operating Systems, by Tanenbaum) as well as the Windows SDK information available
online.
`
Host Computer
EX1629
5 7
0 2
3
HD
LAN
SHUNT
CAL
RES
SHUNT
CAL
RES
SHUNT
CAL
RES
1
4 6
13 15
8 10
11 9
12 14
21 23
16 18
19 17
20 22
29 31
24 26
27 25
28 30
37 39
32 34
35 33
36 38
45 47
40 42
43 41
44 46
PWR
EX1629
time time
Receive streaming data
Receive streaming data
Receive streaming data
Receive streaming data
Receive
:
vtex
1629
_
trig
_
init
()
response
Send
:
vtex
1629
_
enable
_
streaming
_
data
()
request
Receive
:
vtex
1629
_
enable
_
streaming
_
data
()
response
Send
:
vtex
1629
_
trig
_
init
()
request
FIGURE 6-2: STREAMING DATA NETWORK EXAMPLE
Basic Streaming Data Usage
When using the streaming data interface, via the vtex1629_enable_streaming_data function, the
user application provides a callback function. Internally, the instrument driver creates a thread and
then opens a socket for streaming data between the host computer and the instrument. The newly
constructed thread does a “blocking” read on the socket, which causes it to “sleep” (become idle)
until data arrives. When acquisition data arrives, the thread begins executing, receives the
acquisition data from the instrument, executes the user-provided callback function, passing in the
newly arrived data, and then returns to the “sleep” state. The callback function can do whatever is
necessary for the application: write the acquisition values to a file on disk, perform limit checking
on the acquisition values, update an application-specific data structure (e.g., FIFO) post the
acquisition data to a database or spreadsheet, etc. This behavior is illustrated in Figure 6-3, with
the reception of streaming data causing the user-provided callback function to be executed.
NOTE Since the callback function executes asynchronously in the same process as the main application
thread, it is important that any data or data structures used by both threads are suitably protected to
guarantee consistency. As with any multi-thread application, care must be taken when using inter-
thread communication primitives (e.g., mutexes) to prevent deadlocks and livelocks. Similarly,
performing GUI operations (e.g., updating an on-screen graph) within the callback function needs
to be implemented carefully.