Talking to Other Computers: Network VIs

If you want to use LabVIEW to communicate over the network using low-level protocols, you can generally do so, but be aware that low-level networking takes a good deal of design and often more coding. You can use TCP/IP functions, for example, to communicate with any other computer, device, or program that also supports TCP/IP.

LabVIEW supports both the TCP and UDP, low-level Internet communication protocols, both of which are accessible from the Data Communication>>Protocols palette.

TCP/IP

TCP/IP is the underlying protocol for the Internet and most internal networks.

Incidentally, TCP stands for Transmission Control Protocol and IP stands for Internet Protocol. IP divides your data into manageable packets called datagrams and figures out how to get them from A to B. Problem is, IP isn't polite and won't do any handshaking with the remote computer, which can cause problems. And, like bulk mail with the U.S. postal service, IP won't guarantee delivery of the datagrams. So they then came up with TCP which, added on to IP, provides handshaking and guarantees delivery of the datagrams in the right order (more like Federal Express, to follow the analogy).

TCP is a connection-based protocol, which means you must establish a connection using a strict protocol before transferring data. When you connect to a site, you have to specify its IP address and a port at that address. The IP address is a 32-bit number that is often represented as a string of four numbers separated by dots, like 128.39.0.119. The port is a number between 0 and 65535. You can open more than one connection simultaneously. If you're familiar with Unix or have used Internet applications, then this should all be old hat to you.

LabVIEW has a set of VIs, found under the Data Communication>>Protocols>> TCP palette, that let you perform TCP-related commands, such as opening a connection at a specified IP address, listening for a TCP connection, reading and writing data, etc. They are all fairly easy to use if your network is configured properly (see Figure 16.48).

Figure 16.48. TCP palette

Good examples for getting started with building your networked VIs are Simple Data Client.vi and Simple Data Server.vi, found in the Full version of LabVIEW. Both of their diagrams are shown in Figures 16.49 and 16.50.

Figure 16.49. Simple Data Client.vi block diagram

Figure 16.50. Simple Data Server.vi block diagram

You can learn quite a bit about writing client/server VIs by examining these diagrams. The basic process for the client is as follows:

1.	Request a TCP connection (see Figure 16.51). You can set a timeout to avoid hanging your VI if the server doesn't respond. Figure 16.51. TCP Open Connection
2.	Read (or write, in other cases) data. Data is always passed as a string type (see Figure 16.52). Figure 16.52. TCP Read
3.	Close the TCP connection (see Figure 16.53). Figure 16.53. TCP Close Connection

The basic process for a server is as follows:

1.	Wait for a connection (see Figure 16.54). Figure 16.54. TCP Listen.vi
2.	Write (or read, in other cases) data. Data is always passed as a string type (see Figure 16.55). Figure 16.55. TCP Write
3.	Close the connection.

Because all data over a TCP/IP network has to be passed as a string, you will need to convert your data to the LabVIEW string type. The easiest way to do this, as in the previous examples, is to use the Type Cast function (or the Flatten To String function). Just ensure that both the server and client know exactly what kind of data they're passing. If the server, for example, typecasts extended-precision floats to a string and the client tries to typecast the string into a double-precision number, the result will be garbage!

If you are looking for a generic way to pass data, consider passing the data as a variant that has been flattened to a string. Then you will always know what type the flattened data is (a variant). Then, after you unflatten the variant, you can use variant inspection tools to determine its typejust as we discussed in Chapter 14.

Networked applications are ideal when you need to write a program to control a large distributed system, such as in process control applications

UDP

UDP, which stands for User Datagram Protocol, is a lot like TCP, relying on IP addresses, except it is a "connection-less" protocol. What this means is that a server can broadcast data to a large number of clients without actually having to manage or be aware of connections between each one. That is why for UDP, there is no concept of a "listener" like there is in TCP.

LabVIEW provides support for UDP through the Data Communication>> Protocols>>UDP palette, shown in Figure 16.56.

Figure 16.56. UDP palette

UDP is a good choice for less network bandwidth and no handshaking when you need to broadcast non-critical data from LabVIEW.

To see an example of UDP, run UDP Sender.vi and UDP Receiver.vi from the LabVIEW examples (at examples\comm\UDP.llb).