How to communicate between Labview application instances?

[labJunky]

Hello, I have a question about how to communicate data between two labview application instances on different computers connected over a network.

I'll explain what I am trying to do:

I have a data acquisition program that has been split into two independant parts. The backend is responisible for acquisition of data from several DAQ devices, and the frontend simply displays the data collected. The two parts are coupled by labview events. The backend sends out a new data event (to any one listening) when ever it gets some new data, and the frontend listens to those events and updates some graphs on its front panel when ever it receives that event. Other than that the two parts have no communication. 

Now there is a need to split the frontend and backend onto two different computers connected over a network. The backend will be connected to the DAQ devices as normal, but the frontend will execute on a different computer. 

So my questions are: Will the my current communication mechanism still work across labview application instances? And if not, what is the best way to connect the two in the least amount of new code, and without breaking the current program if I decided to port them back to the same computer?

 (I was thinking that some sort of middle-man would be the best that deals with the networking.)

Thanks, any advice will be useful!

Paul.

[nathand · Accepted solution]

I think the easiest way to do this is a TCP/IP link.  You can do this, as you suggested, with a pair of "middleman" VIs.  On one end, you catch the user events in a VI and send them over the network; on the other end you receive data and turn it back into an event, requiring minimal changes to the rest of your code.  The TCP/IP VIs are fairly easy to use and the LabVIEW examples are good.  NI provides the Simple Messaging Reference Library.  You may also want to look at Jack Hamilton's "Robust TCP" from LabUseful.com (disclaimer: I've never used nor even looked at these VIs and cannot verify that they're actually useful, I've only seen discussion and links to them).

[labJunky]

Thanks Nathand,

I had a look at the Simple Messaging Reference Library linked above, and that will do fine! The templates and examples are quite handy, and simple as the name suggests.

There are many other ways to do it, like using:

 VI Server, shared variables, data sockets, tcp connections, remote panels...

But when to use one over the other, is there a summary somewhere?

Thanks,

Paul.

[nathand]

Here's my quick attempt at summarizing the methods you listed, but there's no substitute for reading the documentation and experimenting.

Remote front panels are great when you have a working VI and you just need to display it on a remote machine (maybe that would be enough for your application), because they don't require any code.  However, they don't allow you to transfer data.  Datasocket and shared variables are good for streaming data, especially when it's more important to have current data than to receive all the data.  They can also bind to non-VI sources of data such as OPC servers.  VI server is neat for launching and controlling a remote VI but incurs some overhead and isn't as useful for communicating between VIs that run continuously.  TCP is lower-level, simple and flexible, and good for any sort of reliable communication, but you have to design the protocol and parse the messages yourself.

Which one to pick depends on your application and what you're comfortable using; there's overlap between these approaches and no one right choice for each application.

[Ben]

Excellent post nathand!

I'd like to add one note to the above list. If you have an application spread across mulitple machines and you have to implement very tight hand-shaiking between them, then invoking an Action Engine from one machine and served on another can simplify your work. I am mentioning this just to give everyone "another hammer" for their toolbox.

Thank you  natahnd!

Ben

[labJunky]

Hello,

I have implemented the Simple Messaging Reference tcp connection server, and client, to allow my app to work across a local area network. But I am having some problems with the connection. I can run the server and client fine when both are running on the same computer, the localhost. However, when I put the client on the other computer, I get a error 56 message immediately on trying to establish the tcp connection. This makes a error 62 occur on the server vi.

So I decided to try the example vi's that are packaged with the library. Called STM basic server, and basic client. The server sends random numbers to the client.

However, this also results in the same errors. The error on the client is immediate, which is strange because the default timeout is 60 seconds.

The ip address of the server is 169.254.102.17 and the client 169.254.194.202, and they are wired directly to each other. (I have tested the link, and the connection works for file sharing, for example.) 

I am not sure what the problem could be, I have disabled the vi server:configuration tcp connection, just in case it was that. 

Any idea's would be great!

Thanks, Paul. 

[labJunky]

the connection works in reverse. 

i.e. I put the server on the other computer IP 169.254.194.202, and the client on computer  IP ending in 102.17 and the example vi's work correctly. However with the server running on computer with IP ending 102.17 and client on IP ending 194.202, the connection end with the errors above.

I though it could be my antivirus program, so I switched it off, this didn't change anything.

?? 

[nathand]

Sounds like it's probably a firewall problem, not your antivirus software.  Try disabling the firewall temporarily (probably on the server machine, but check both ends) and see if that fixes the problem; if so, re-enable your firewall and add an exception for your application.

[labJunky]

I already tried that but only with the server machine's firewall off. Now I turned both of them off, but it doesn't solve the problem.

[nathand]

This seems like a less-likely source of that error, but have you tried using a different port?  Maybe you have some other piece of software running on one machine but not the other that's already using the port you're trying to use for your program, although I would expect a different error in that case.