Using Network Streams for Data Transfer in Real-time Applications

[Alisha_P]

Overview
This example VI project demonstrates how to deal with the data collected from the real-time target.

Description
Network Streams were added to LabVIEW with LabVIEW 2010. They "were designed and optimized for lossless, high throughput data communications. Network streams use a one-way, point-to-point buffered communication model to transmit data between applications". (See this http://www.ni.com/white-paper/12267/en/ for more information on Network Streams) This works well as a mean to transfer the data being collected on a real-time target back to the host computer (or another target) for either manipulation or saving to disk. However, the network stream itself is not deterministic so the data must be transferred to a lower priority loop before writing it to the network stream.

This example VI using a single process shared variable to transfer the data to a lower priority loop, writing that data to a network stream and reading the data from the network stream on the host computer, also writing the data to file on the host computer

Requirements

• LabVIEW 2012 (or compatible)

Steps to Implement or Execute Code

1. Download and unzip the attached folder to your computer
2. Right-click New»Targets and Devices to add your real-time target to the project.
3. Drag the "RT App Network Stream Target.vi" and the "Variable Library" down below your target
4. Open the "RT App Network Stream Target.vi" and add your data collection code where indicated.
5. Open the "RT App Network Stream Host.vi" front panel and browse for the TDMS File Path where you want your data saved
6. Run the program of RT and Host

Additional Information or References
VI Block Diagram of "RT App Network Stream Host.vi"

 

 **This document has been updated to meet the current required format for the NI Code Exchange.**

[GriffinRU]

Network streams are not so great...

If you would like to have real-time performance -> define you specs first

You can be within ms on windows running machines over VI server (TCP-IP protocol)

If you would like to be better thean 1ms -> good luck on any PC system over 24h time window...

-Artur

P.S. VI server can be painful to program, but works great(4+ years of 24/7 run on managed network)

[Nancy_Hollenback]

What was the specific issue you had with Network Steams?

[GriffinRU]

1. Not event-driven (alot more programming to implement)
2. Not robust (problems with conection were observed on regular basis on systems running 24/7)

Less layers in programing = better efficiency, closer to TCP/IP protocol you get - better you are, network streams are extra layer and fancy color box. It might make some tasks easy to do, but not all and not when top-notch real-time performance with data consistency required.

-Artur