Remote Messaging between VIs

[ChrisClark]

What's the latest for messaging between VIs on different machines? Can I use message ques across machines, or would I have to use TCP or something else, for example drop a message on a que on machine1, that que is serviced by a TCP loop and transmitted to machine 2, where it is received and then dropped on a que there. I'd probably have a qued producer consumer setup on both ends. I know I've read something about this but can't find it now.

related question:

I've been following the form of D. Elizalde's "Simple TCP/IP Messaging Protocol" for LVRT messaging, how has Shared Variable change this approach for anyone?

cc

[Rolf Kalbermatter]

What's the latest for messaging between VIs on different machines? Can I use message ques across machines, or would I have to use TCP or something else, for example drop a message on a que on machine1, that que is serviced by a TCP loop and transmitted to machine 2, where it is received and then dropped on a que there. I'd probably have a qued producer consumer setup on both ends. I know I've read something about this but can't find it now.

related question:

I've been following the form of D. Elizalde's "Simple TCP/IP Messaging Protocol" for LVRT messaging, how has Shared Variable change this approach for anyone?

cc

Traditional objects based on refnums do not have any meaning outside of the process that created them.So queues or notifiers or such won't work as they couldn't connect each to each other.

Your options are as follows"

1) Use LabVIEW 8 shared variables

2) Use DataSocket in earlier LabVIEW versions

3) Use VI server

4) Use TCP/IP to write your own client/server communication

5) Use external files

I'm not sure about 1), but 2) is something I wouldn't recommend for a number of reasons. It's performance is quite limited, it can be hard to get configured right, and it uses an undocumented protocol.

1) and 3) have the same issue about being undocumented but at least 3) does work very well and all the low level stuff is done for you.

4) is the hardest to implement and requires quite some experience to get a good working system that will also be able to deal with extensions in the future. But it is the most flexible and also most performant solution.

5) is really only a last ressort. I wouldn't recommend it at all as you get all sorts of problems with synchronizing access to the files between the two or more applications.

Rolf Kalbermatter

[Guillaume Lessard]

Two weeks ago I tried slapping together something quick using shared variables; I would previously have done that program using the "Simple TCP/IP Messaging" bag of tricks.

The result was not good. Crashes aplenty on the RT machine after a few minutes of run time. Meanwhile I have fundamentally the same functionality implemented the old way and that runs for hours without any problem.

I've thus decided that I'm not trying shared variables again on 8.0...

Guillaume Lessard

[Mike Ashe]

For my money either VIServer or TCP/IP is the way to go and I usually use TCP/IP. Fast, flexible and you can hook or be hooked into external text based programs pretty easily.