Are You Using Network Streams?

I discovered Network Streams in LabVIEW a while ago; I think they were introduced in LabVIEW 2010. If you’ve not used them, you should be aware of this really cool tool.

Basic Properties

Network Streams use Ethernet to communicate between a single writer and a single associated reader. They provide lossless data transfer and are robust to connection interruptions. As such, they are essentially queues that operate across an Ethernet connection.

Such a point-to-point connection implies that data transfer is in one direction. To establish a stream, you create a writer with the ‘Create Network Stream Writer Endpoint’ VI and a reader with the ‘Create Network Stream Reader Endpoint’ VI.

Network Streams natively support many LabVIEW data types, similar to Network Shared Variables. It’s interesting to note that data are flattened to be compatible across different versions of the LabVIEW runtime engine.

A Network Stream is defined with an element of some data type and a buffer size to hold a specified number of those elements. If during writing the buffer becomes full, the writer will hold off pushing more data into the buffer until the reader removes one or more elements, just like a normal LabVIEW queue.

Typical Usages

Almost any application will use at least two Network Streams, since if you want to send data to machine B from A, you will also likely want to send responses to A from B. For example, A may be a host or master and B a client or slave. Machine A will be sending commands to B which will then reply with status or results.

Of course, if there are multiple processes or multiple machines, you may need multiple Network Streams.

Specifying the Endpoint

A nice feature of Network Streams is that only one side of the Network Stream needs to specify the IP address of the other side. This feature makes it useful for creating a system with a batch of cRIOs or sbRIOs all sending data to a host, say for embedded  control or embedded monitoring systems such as for large scale machine conditioning monitoring. The host needs to know the IP addresses of all the cRIOs or sbRIOs (and the names of the writers) so it can create a bunch of readers, but the cRIOs or sbRIOs don’t need to know the IP address of the host. You can also create Network Streams for multiple applications on the same machine.

The writer and reader creation VIs just sit still waiting for the other to engage so that it does not matter which is started first.

More info

Check out http://www.ni.com/white-paper/12267/en for more details. This white paper contains good tips for maximizing performance (speed and memory), some performance graphs comparing raw TCP with Network Streams, and some information about minimizing latency.  If you’re looking for additional test & measurement resources, check out our resources page.  If you’re looking for help with your LabVIEW-based system, check out our capabilities and reach out if you want to chat.