LabWindows/CVI

cancel
Showing results for 
Search instead for 
Did you mean: 

Send data to various PC using TCP/IP

Hi,
    My PXI embedded system is required to acquire data (such as CAN messages and voltage values) to various PC(about 5) over the network which I intend to use Labwindows TCP/IP feature to do this. However, the data to be sent to these 5 PCs are specific to each of them. For example, I only need to send dataA to PC A, dataB to PC B, etc at real-time constraint. What I had in mind is to open 5 ports(which means to register 5 TCP servers) and handle the transmission of data to these 5 PC individually.
 
My question: is such an idea workable as well as efficient? Since my PXI is running other programs as well, multi-threading is a must. Hence, if I register 5 TCP servers, would I need to create an additional 5 threads from the common thread pool to handle the sending of data via TCP/IP or just one thread is sufficient? Advice please!! Thanks!!
 
YB
0 Kudos
Message 1 of 3
(3,440 Views)
Hi evangel55,

In general, you should create one "listener" thread (on a single port) that accepts connections and then spawns off slave threads to handle each connection. The first data passed across the connection should identify which PC is connecting. In your case, this could be in the form of one "identification" byte that corresponds to PCs 1-5. In your code, you can switch on this byte and handle the rest of the messages accordingly.

While it is possible to setup 5 separate listener threads, each on a different port, this approach will require more overhead and it is really unnecessary.

For an in depth discussion on creating network applications in CVI, please refer to the following article on our website:
Building Networked Applications with the LabWindows/CVI TCP Support Library

Also, as a starting point, you can refer to the following multi-threaded network example:
<CVI>\samples\tcp\MultiThreading.cws

This example actively refuses more than one connection (as seen on line 117 of MultiThreadingServer.c), so this is where you would instead spawn a new slave thread.

Regards,
0 Kudos
Message 2 of 3
(3,403 Views)
Hi,
    Your suggestion seems more efficient than what I originally intended. I will try to work on this idea over the next week. Thanks!!
 
YB
0 Kudos
Message 3 of 3
(3,387 Views)