Hello DAD,
Besides the PXIe-8133 embedded controller in slot 1, my PXIe-1082 chassis also includes (5) 16-analog-input-channel PXIe-4496's in slots 2 through 6, a total of 80 accelerometer measurements. I read in 2 seconds of data for each accelerometer measurement sampled at 4096 Hz.
The LabVIEW VI running on the Windows-7-Professional PXIe-8133 has (2) WHILE LOOP's, one for relatively fast DAQ {producer loop} and the other {consumer loop} for slow computing Fast Fourier Transform (FFT) on all 80 measurements, performing limit checking and TDMS-formatted data logging, as well as displaying FFT results graphically in the frequency domain.
To prevent memory leaks, I use
(a) "queue" for data transferring from {producer loop} to {consumer loop}, as well as
(b) "semaphore" to make sure all FFT computations are finished before DAQ starts again {the sample mode of "DAQmx Timing.vi" is FINITE}, and
(c) only 6 FFT results are displayed graphically at a time
All TCP/IP examples so far suggest the implementation of (2) WHILE LOOP's, one for sending and the other for receving. My LabVIEW VI on a remote Windows-7-Professional PC
(1) sends a 1-byte (1 or 0) to the LabVIEW VI running on the Windows-7-Professional PXIe-8133 to turn (on or off) TDMS-formatted data logging if a threshold limit among 80 accelerometer measurements is violated
(2) receives a 1-byte (1 or 0) from the LabVIEW VI running on the Windows-7-Professional PXIe-8133 indicating whether or not an accelerometer measurement exceeds its threshold limit
Since I do not want to create more WHILE LOOP's, I implement "TCP Read.vi" in the DAQ {producer loop}, and "TCP Write.vi" in the FFT {consumer loop}. For inputs to "TCP Read.vi", I use 1 for "bytes to read" and 100 for "timeout ms" {the same for "TCP Write.vi"}. However, I notice the graphical display of FFT results slow down quite a bit.
From your experience, are "TCP Write.vi" and "TCP Read.vi" the culprits here? Should I implement (2) additional WHILE LOOP's for TCP/IP?
Regards,
Chi
