LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Passing data between two computers on a local network

Solved!
Go to solution

I have a requirement control a machine located in a closed room ( for safety reasons ) from a PC located at a distance from the room. 

 

The PC inside the closed room runs LabVIEW code and the required inputs for controlling it should come from another PC located outside the room. 

 

In all about 6 slider analog data + 4 digital data will have to be sent to the PC inside the room which in turn will send back both analog and digital status updates. 

 

I think this is a fit case for network shared variables. But we also have the following possibilities  and would like to know which would be an ideal solution. (The rate of data transfer is not high - one update on both sides every 50ms is good enough. )

 

1. Serial 

2. TCP or UDP 

3. Bluetooth

 

Thanks

Raghunathan
LabVIEW to Automate Hydraulic Test rigs.
0 Kudos
Message 1 of 6
(2,517 Views)
Solution
Accepted by topic author MogaRaghu

@MogaRaghu wrote:

I think this is a fit case for network shared variables. But we also have the following possibilities  and would like to know which would be an ideal solution. (The rate of data transfer is not high - one update on both sides every 50ms is good enough. )


I disagree.  It is not uncommon for NPSVs to not update in the system for 100ms after you wrote to it.  I am very much against NPSVs for many reasons.

 

Serial communications are pretty secure with low latency.  I would go with RS-422 if you go this route so you can have better signal integrity and longer cable lengths.  For your update rate, you will want a decently high baud rate such as 115200 bits/sec.

 

TCP is pretty simple to implement especially with fixed IP addresses, it is secure on a closed network, and you can get some high data rates.  This would be my first choice.

 

I would avoid Bluetooth mostly from a reliability standpoint.

 

Regardless of connection, spend some time to come up with a solid message protocol whether it is simple ASCII commands or a defined binary/hex/raw message format.


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
Message 2 of 6
(2,489 Views)

I completely agree with @crossrulz.  I'm working on a LabVIEW Project where the machine doing the control and data acquisition must be electrically isolated from the PC "running the show".  Fortunately, we have a low-power LabVIEW Rio device that includes WiFi, so have configured a LabVIEW Real-Time Host/Target system using TCP/IP as the communication pathway, and using a pair of Network Streams to send "Messages" (as in the Queued Message Handler, a Cluster with a "Message", telling the receiver which Case of the Message Handler to run, and a variant "Data" component for instances where we need to send or receive a parameter, or data).  This has high reliability, pretty low latency (in the msec range, if not better -- haven't run rigorous tests on this yet), and fairly easy to program.

 

Bob Schor

Message 3 of 6
(2,463 Views)

@crossrulz

 

The information about NPSV latency is an eye opener. So far have not used them but looks like I have not been missing much. 

 

Guess I will go the TCP way. 

 

Thanks !!

Raghunathan
LabVIEW to Automate Hydraulic Test rigs.
0 Kudos
Message 4 of 6
(2,418 Views)

Been trying the Simple TCP-Client.VI.

 

The setup is shown below. PC1 is the Client and PC2 is the Server.  They are on the same local Wireless network. 

 

In the example I just entered the IP address of PC2 in the Client code and that of PC1 in the Server code ... the sketch makes it clear. 

 

When I try to run both, after a long time ( based on time out ) communication just starts and then stops with a time out error. 

 

Am I doing anything wrong ? 

IMG_3148.jpg

Raghunathan
LabVIEW to Automate Hydraulic Test rigs.
0 Kudos
Message 5 of 6
(2,390 Views)

Either you are "doing something wrong" or one of your PC's Networking isn't configured the way you think it is.

 

I don't use the Simple TCP Server-Client setup, myself, but I just tried it out from the LabVIEW 2019 examples.  I first ran it on one PC, noting that the Client (by default) "points to" the Server running on "Local Host", namely the same PC as is running the Client.  So I started the Server, saw nothing exciting, started the Client, and the Server started showing me a noisy waveform (because the Server was generating Random Numbers).  When I stopped the Client, the Server stopped.

 

OK, so I fortunately had a second PC available running LabVIEW.  I opened the same example on PC-2 and opened the Client.  I noticed that the Server didn't need to know the Client's IP, but the Client needed to know the Server's, so I found it (192.168.1.xxx) and copied it (as a string) into the box that formerly said "localhost".  Ran Server, started Client on second PC, and saw a noisy graph on both.

 

So the Example (in my hands) works as advertised.  The only change I made was to put the IP address of the Server into the "address" string of Simple TCP - Client.vi running on the Client, start the Server, and within 30 seconds, start the Client.

 

Bob Schor

Message 6 of 6
(2,378 Views)