In your original post, you wrote:
"I am Having the NI PXIe 1082 DC Chassis with PXI 8880 Windows based controller with the following cards NI 4480 Sound and Vibration cards and PXI 6238 Multifunction I/O card. All my hardware will be enclosed in a closed chamber and deployed under the water at 18Km distance with 30M depth. I am having Hydrophones and pressure sensors that will acquire the sound and Pressure under the water and it will acquire data using DAQmx APIs and it will transmit the data in the form of ethernet packets using TCP/IP. And I will Read the Data in the Host side and I will process the data as per my requirement. "
When I see a description of an isolated Processor (the PXI system) collecting Real-Time data and sending it to a "Host" system using Ethernet, I think of something like the LabVIEW Real-Time environment, which is where I got my start with LabVIEW. You have two semi-independent programs running -- one on a PC running Windows that is the Host, responsible for sending commands and queries to a remote Target that "does most of the work running the Data Acquisition and Control stuff", communicating with the Host using TCP/IP.
While the Target can run Windows, a multi-tasking Operating System designed for "doing many things all at once" and not particularly concerned with response time or priorities, NI provides an alternative "Real-Time" environment designed to optimize throughput (I'm saying this wrong -- you can find a better description on the Web).
If you intend to run your PXI system with Windows and have a LabVIEW routine that can run your program locally on the PXI, with all you need to do is "run it remotely" from an on-shore PC that has a TCP/IP connection to this remote Windows system, I would say you might want to consider setting up the PXI so that you can connect to it using Window's Remote Desktop, which lets you "log into a remote PC running Windows" and act as though you were running on that remote system. All of the acquisition, control, and storage would take place on the PXI (remotely), and at the conclusion of the Data Acquisition, you could upload the data files using a TCP/IP transfer utility.
Or you could install a Real-Time Operating System on the PXI (possibly even a dual-boot system) and set up a true Host/Target Real-Time data acquisition. In this model, all of the User Interaction (Front Panel indicators, displays, file I/O, etc.) would take place on the PC, and all of the Real-Time Data Acquisition and Control would take place on the PXI Target. You would communicate between the Host and the Target with TCP/IP, using TCP, UDP, or NI's Network Streams (which is what I've used). This technology is well-developed by NI and LabVIEW (I got my start with LabVIEW 7, and switched to Network Streams somewhere around LabVIEW 8). I used an older version of the PXI (I've forgotten the number), with 4 Network Streams -- one for Messages ("commands") from Host to Target, one for Target-to-Host Messages, one for Target-to-Host A/D data (streamed as fast as the data were acquired, as all the display had to be on the Host), and one for Target-to-Host Digital Data (which were "occasional" things, such as button presses or limit switches).
Bob Schor
