LV and LV-executable on 2 machines

[torekp]

Having just read this thread on communication between executables, and this communication NI guide and this shared variable guide, I have more questions. I need to have two executables on different computers, or preferably one Labview program on the DAQ computer and an executable on the user's computer. The user's computer won't do much. Currently, I am using VI server on the user's computer to open and start the DAQ program and to check periodically that the DAQ program is still running. In the future, I'd also like to get occasional updates to display on the user's computer. There is no urgency or determinism necessary in this, and it is OK if a few updates are missed. The user's computer has little CPU demand.

In contrast, the DAQ computer is running near maximum capacity. (It analyzes data on the fly as well as acquiring, though acquiring seems to be the biggest resource hog.) That bolded "periodically" in the paragraph above was originally every 1 ms, but that caused the DAQ computer to miss some of what it is supposed to see. I changed it to every second, and now it's OK.

Is shared variables a good approach, given my needs? Is it possible to host the shared variable engine on the user's computer, as the second NI guide would advise (based on having adequate processor and memory resources)? Bear in mind that the user's computer will have only an executable.

If TCP/IP or some other alternative would create less burden for the DAQ computer, please let me know. Another alternative I have thought of is to write some binary data to file on the DAQ computer, and read it from the user's computer. Whatever is easiest on the DAQ computer's processor and avoids interrupting the data acquisition and computations, that's what I want.

[Mark Yedinak]

You could also look at using network queues to pass data between the applications. One thing I like about the network queues is that they are event driven and you don't need to poll anything.

[Mark Smith]

I looked at using shared variables for communication between two machines (one w/LabVIEW and one with just the RTE - and the shared variable engine) and found it to be a little confusing to set up but ultimately it worked as advertised. The machine w/LabVIEW acts as the client and the exe/RTE machine is the server. I have attached a sample project that I swear I loaded from the NI site but now I can't find it (that's why I'm attaching the project and not the link!) that demonstrates a simple client/server using shared variables. This project is in 8.5.

MarkDownload File:post-1322-1239988028.zip

[Mark Yedinak]

QUOTE (mesmith @ Apr 17 2009, 12:08 PM)

I looked at using shared variables for communication between two machines (one w/LabVIEW and one with just the RTE - and the shared variable engine) and found it to be a little confusing to set up but ultimately it worked as advertised.

That was my experience as well to some extent. We were trying to get synchronized bi-directional communication between a UI written in LabVIEW with code running under TestStand. When we tried to use shared variables we ran into lots of issues getting it configured correctly. Due to schedule constraints we abandomed the shared variables and went with network queues. In principal shared variables should work fine (they are essentially a client server model over TCP) but they do seem to be challenging to get configured.

[ned]

QUOTE (torekp @ Apr 17 2009, 11:37 AM)

...In the future, I'd also like to get occasional updates to display on the user's computer. There is no urgency or determinism necessary in this, and it is OK if a few updates are missed. The user's computer has little CPU demand.

...

If TCP/IP or some other alternative would create less burden for the DAQ computer, please let me know. Another alternative I have thought of is to write some binary data to file on the DAQ computer, and read it from the user's computer. Whatever is easiest on the DAQ computer's processor and avoids interrupting the data acquisition and computations, that's what I want.

This sounds like an ideal use of UDP in place of TCP, since you don't need determinism or guaranteed transmission. It's simpler to set up a UDP listener because there's no connection - kind of like sending a fax instead of calling someone on the telephone. Your DAQ computer sends a UDP packet whenever it wants to display an update; your user computer listens for UDP packets and displays them upon reception.

[torekp]

Thanks guys, I will take your advice :worship: Now if only y'all could just agree ... Actually, if SVs are just a fancy version of TCP, and UDP is easier on the DAQ computer than TCP ... then I guess ned's advice wins.

[Mark Yedinak]

QUOTE (torekp @ Apr 17 2009, 01:14 PM)

Thanks guys, I will take your advice :worship: Now if only y'all could just agree ... Actually, if SVs are just a fancy version of TCP, and UDP is easier on the DAQ computer than TCP ... then I guess ned's advice wins.

Whichever way you go spend some time designing a good message format. If you do this early on it makes your life much easier in the future when you may need to add new message types or different data.

[2and4]

QUOTE (torekp @ Apr 17 2009, 01:14 PM)

Thanks guys, I will take your advice :worship: Now if only y'all could just agree ... Actually, if SVs are just a fancy version of TCP, and UDP is easier on the DAQ computer than TCP ... then I guess ned's advice wins.

If you were looking for a tiebreaker vote, I second the UDP recommendation. Your DAQ program will be the UDP Sender. Your external PC will be the UDP receiver. This will be more efficient than using TCP/IP functions in the DAQ program since UDP doesn't keep track of whether the receiver actually received a particular piece of sent data or not (you indicated that it doesn't matter if occasionally a piece of data is lost or not). Shared Variables introduce the most overhead.

There is a very easy to understand UDP example that ships with LabVIEW: Use Example Finder and go to Networking >> TCP & UDP >> UDP Sender.vi and UDP Receiver.vi. Try it out:

1. Open UDP Receiver.vi on one PC.

2. Open UDP Sender.vi on another networked PC.

3. Set the "Remote Host" control on the Sender to the IP address or alias of the Receiver.

4. Type in some message into the "Data String" control.

5. Set the #Repetitions to something around 100.

6. Run the receiver.

7. Run the sender. Note that the sender doesn't care if it was started first or not.

8. You'll see the message you typed into the "Data String" showing up at the receiver.

Simple as that. You'll have your communication up and running in no time.