LabVIEW Communication Techniques for Distributed Applications

Agenda

• Intro: What is a Distributed Application?• Part I: LabVIEW Communication Techniques• Part II: Implementing Communication Tasks

• For this presentation, distributed applications = two or more [LabVIEW] programs connected via Ethernet

• Nodes may be Windows/Mac/Linux/Real-Time

10011

10011

Distributed Applications Defined

10011

10011

110

Part I: Communication Techniques

LabVIEW Communication Methods

• Data Transfer– Non-Deterministic

• LabVIEW Shared Variable• Low Level Protocols (TCP/UDP)• DataSocket

– Deterministic Data Transfer• NI Time-Triggered Variables• Reflective Memory

• Remote Application Automation– VI Server

The LabVIEW Shared Variable

• Three Shared Variable types– Single-Process: share data within a local

system– Network-Published: share data with

networked systems– Time-Triggered: share data deterministically

through Ethernet between real-time systems

• Feature for sharing data in LabVIEW Applications

Network-Published Shared Variable• LV structure that abstracts communication from diagram• Supports most LabVIEW Datatypes

– Custom controls included• Any LabVIEW application on network can be a client

– CVI and Measurement Studio applications can also be clients

Module Specific Variable Features• LabVIEW Real-Time

– RTFIFO– Modbus TCP and Serial Support– Time-Triggered Variables– Multiple Variable Editor

• LabVIEW Datalogging and Supervisory Control (DSC)– Scaling– Alarming– Historical Logging– Security– Binding to OPC Tags– Modbus TCP and Serial Support– Multiple Variable Editor

Demo: LabVIEW Shared Variable

How Network-Published Variables Work• Data transferred by NI Publish and Subscribe Protocol

(NI-PSP)– Next generation of Logos protocol– Built on UDP– Additional layer of software for guaranteed delivery

• Designed for efficient data transfer– Delta filtering reduces network bandwidth– Updates are packaged into one packet– Value change updates

The Shared Variable Engine (SVE)• Service that publishes network-published variables

– Tagsrv.exe is Windows startup service– Network Variable Engine component on real-time targets– Requires 32 MB of total system memory (64 MB recommended)

LabVIEW Real-Time TargetsWindows Systems

Variables and Libraries• All variables are part of project libraries• Libraries deployed as SVE processes• Libraries persist for robust server behavior

– Don’t forget: Tools»Shared Variable»Variable Manager

SVE

Shared Variables Under the Hood

SVE

Two of Clubs variable is deployed to target, SVE running on target hosts

the variable

Value is written to “Two of Clubs” by Variable Client

Value Change is sent to SVE using NI-PSP

Value Change is sent to subscribers using NI-PSP

SVE records the value change and publishes the

value to all subscribers

New value read in next iteration

Network Buffering

• Configured in shared variable properties dialog• Several buffers created• Performance impact

– Increases memory usage– Delta-filtering disabled to ensure all data is transferred

• Does not report overflow/underflow– If reader is slower than writer data will be lost– Use timestamp for manual check (precision = 1 ms)

Performance: Network-Published Shared Variables versus Real-Time FIFOs and TCP/IP

1

10

100

1000

10000

100000

1 10 100 1000 10000

Payload (Doubles)

Thro

ughp

ut (K

B/s

)

Network-Published: SVE on TargetNetwork-Published: SVE on HostReal-Time FIFO + TCP (10 ms)Real-Time FIFO + TCP (1 ms)

Network-Published Variables PerformanceShared Variables versus RTFIFO + TCP (PXI)

Network-Published Variables versus RT FIFO VIs and TCP/IPPXI-8196 (100 Megabit Network)

0

2000

4000

6000

8000

10000

12000

1 4 16 64 256 1024 1536 2048 2560 3072 3584 4096

Array size (double data type)

Thro

ughp

ut (K

B/s

)

SVE on Host

SVE on Target

TCP 11.5 MB/s

9.8 MB/s

7.2 MB/s

Network-Published Variable: What You Gain

Shared Variable Summary• Advantages

Abstracts communication codeScalable (point/tag based)Multiple client supportFront panel bindingOPC Server functionalityIntegrates LabVIEW Real-Time and DSC features

• DisadvantagesProprietary transfer protocolNot optimized for streamingSlightly more overhead than TCP/UDP

• Ideal Applications– LabVIEW to LabVIEW communication– Monitoring (SCADA)

Low-Level Communication ProtocolsTCP (Transmission Control Protocol)

• AdvantagesReliableStandard networking protocolFast performance

• DisadvantagesRequires a non-trivial amount of codingData must be flattened to strings before sendingAdditional code needed for multiple clientsDifficult to scale for many data points

• Ideal applications– Streaming data– LabVIEW to C/VB/C++ communication

Using TCP in LabVIEW

Listen for connection Send header info

Typecast data into string

Send data

Low-Level Communication ProtocolsUDP (User Datagram Protocol)

• AdvantagesAsynchronousConnectionlessVery fast performanceBroadcasting support

• DisadvantagesDelivery not guaranteedRequires non-trivial amount of codingDifficult to scale for many data pointsData must be flattened to string

• Ideal Applications– Broadcast applications– Fast transfers– Custom network protocols

Using UDP

Open UDP Port Close UDP Port

Typecast data into string

Send header and data

DataSocketLegacy NI Communication Protocol

• AdvantagesAbstracts communication codeMultiple client supportFront panel binding

• DisadvantagesNot designed for large data setsNot designed for streamingCannot host items on real-time targets

• Ideal Applications– LabVIEW to LabVIEW communication

Advanced Communication: Time-Triggered NetworksDeterministic communication• Data transfer occurs in guaranteed time• Up to 10 kHz network loop rates• ±5 µs clock synchronization between nodes

Time-Triggered Networks

Reserved Network Time Slots

Time-Triggered NetworksDeterministic Ethernet

• AdvantagesDeterministic data transferExtremely fastCost-effective alternative to reflective memory

• DisadvantagesRT to RT onlyPXI/PC onlyProprietary protocolRequires two network interfaces per node

• Ideal Applications– Distributed control and simulation

Beyond Ethernet: Reflective MemoryPCI/PXI mapped memory between nodes

• AdvantagesExtremely fast deterministic data transferDeterministic data transfer to any OS that supports PC/PXI

• DisadvantagesVery expensiveNot available for industrial targets (cRIO, cFP, etc.)

• Ideal Applications– Distributed control and simulation– Very fast data streaming

Fiber/Copper Cable

Automating LabVIEW Remotely: VI Server• Advantages

Complete automation of LabVIEW is possibleObject oriented

• DisadvantagesData transfer is slow

• Ideal Applications– Automating VI execution– Performing remote VI calls

Part II: Implementing Communication Tasks

Communication Tasks

• Data Streaming• Remote User Interface• Automating Execution of Remote System• Closed-loop Control over Ethernet

Data Streaming

• Data produced needs to be streamed to consumer node• Applications: datalogging or post processing• Buffers decouple producer, network, and consumer jitter• Communication Techniques: UDP, TCP, Shared Variables

Producer Consumer

Network AsynchronousActivity

Optimizing Data Streaming

Read FIFO or queue until empty

Flatten data

Send data sizeSend data

Optimizing Data StreamingTCP Throughput Rates on PXI-8196 RT - LabVIEW 8.0 (Gigabit)

0

10000

20000

30000

40000

50000

60000

70000

0 1000 2000 3000 4000 5000 6000 7000 8000 9000

Payload (bytes)

Thro

ughp

ut (K

B/s

ec)

Larger payloads are most efficient

Implementing Redundancy

Acquire Send data via primary

Send backup heart beat

Error

Error

Send “Disconnected Backup”message via primary

Send data via secondary Error Shutdown

Switch primary and secondary

Yes

No

No

Yes Yes

No

Redundant Streaming Example

Redundancy is not trivial, but it can be done

Demo: Streaming

Web UI Remote ApplicationNetworkCommunication Control

Remote User Interface: Web Interface

• Live update of Web-based user interface• Only front panel is transferred; data transfer must be

implemented separately• LabVIEW Web Server and Remote Panels

Remote User Interface: SCADA Monitoring

• Asynchronously updates values to multiple listeners• Suitable for high channel count supervisory control systems• Subscriptions can be dynamically created and destroyed• LabVIEW Shared Variables and LabVIEW DSC

Subscriber

PublisherNetworkSubscriber

Typical SCADA Requirements

• Display data from hundreds to thousands of channels/tags

• Retrieve data from multiple types of hardware (usually through OPC)

• Log data to enterprise/historical databases• LabVIEW DSC converts LabVIEW into SCADA

package

What is OPC?• OPC = OLE for Process Control• Standard for data communication

between industrial controllers• Hardware vendors usually

distribute OPC servers for their hardware

• SCADA systems are usually OPC clients

PLCPAC

OPC Server

OPC Server

SCADA

LabVIEW and OPC

• LabVIEW as OPC Server– Shared Variable Engine on Windows is OPC Server

• All shared variables can be read by OPC clients– FieldPoint and DAQmx also provide OPC Servers

• LabVIEW as OPC Client– With LabVIEW DSC the Shared Variable Engine becomes an

OPC client• You can bind shared variables to OPC tags

– DataSocket VIs read/write OPC 2.0 items

Demo: Using LabVIEW for SCADA System

Automating Applications: Command-Based Architecture• Provides a framework for building robust

applications that can be expanded in the future• Minimizes the network overhead and CPU

overload• Provides a way of creating “event-driven”

distributed applications

MediumPriorityTasks

Command-Based ArchitectureEmbedded Target

CommandParser

Host Computer

Command/Parameter

Sender

DataReceiver

HighPriorityTasks

• XML header stores data scheme• Target responds to commands from host

Commands

Data

NI Command-Based Example Architecture

• XML header is sent once for host to know data scheme• Host sender loop sends commands to Target command

parser• Target sender loop sends data to host receiver loop• Application note and example VIs at ni.com/devzone• Shipping example with LabVIEW Real-Time

Demo: Command-Based Achitecture

Distributed Closed-Loop Control (Time-Triggered)

1. Node A acquires a point 2. Point is sent to Node B 3. Node B processes point4. Output is sent back to Node A, loop is closed

Node A Node BNetwork

314

2

• The network is part of the control loop– Network jitter → Loop jitter

• Control loop rate depends on network throughput

Time-Triggered Distributed Simulation Example

Ethernet

Engine Model

Ethernet

ECU Model

RPM, Throttle

Timing, Fueling

Private Ethernet Network

• Create Time-Triggered shared variables

• Reserve time slots for variables in network configuration utility

Time-Triggered Distributed Simulation Example (Real-Time Only)

Time-Triggered Distributed Simulation Example

Summary

• Array of LabVIEW technologies for network communication

• Choose communication method depending on application requirements

• Consult the NI Developer Zone for advanced examples

Additional Resources

• Customer Education– LabVIEW Intermediate II: Performance and Connectivity– LabVIEW Real-Time Application Development

• NI Developer Zone– Using the LabVIEW Shared Variable– Deterministic Data Streaming in Distributed Data Acquisition

Systems– Command-based Architecture for LabVIEW Real-Time – Using Time-Triggered Networks to Communicate

Deterministically Over Ethernet