LabVIEW Communication Techniques for Distributed Applications

LabVIEW Communication Techniques for Distributed Applications

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

Distributed Applications Defined For this presentation, distributed applications = two or more [LabVIEW] programs connected via Ethernet Nodes may be Windows/Mac/Linux/Real-Time 110 10011 10011 10011 10011

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 Feature for sharing data in LabVIEW Applications 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

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) Windows Systems LabVIEW Real-Time Targets

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 records the value change and publishes the value to all subscribers SVE New value read in next iteration Value Change is sent to subscribers using NI-PSP Two of Clubs variable is deployed to target, SVE running on target hosts the variable Value Change is sent to SVE using NI-PSP Value is written to Two of Clubs by Variable Client

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

Network-Published Variables Performance Shared Variables versus RTFIFO + TCP (PXI) 100000 10000 Throughput (KB/s) 1000 100 10 Network-Published: SVE on Target Network-Published: SVE on Host Real-Time FIFO + TCP (10 ms) Real-Time FIFO + TCP (1 ms) 1 1 10 100 1000 10000 Payload (Doubles)

Network-Published Variables versus RT FIFO VIs and TCP/IP PXI-8196 (100 Megabit Network) 12000 10000 TCP Throughput (KB/s) 8000 6000 4000 2000 SVE on Target SVE on Host 0 1 4 16 64 256 1024 1536 2048 2560 3072 3584 4096 11.5 MB/s 9.8 MB/s 7.2 MB/s Array size (double data type)

Network-Published Variable: What You Gain

Shared Variable Summary Advantages Abstracts communication code Scalable (point/tag based) Multiple client support Front panel binding OPC Server functionality Integrates LabVIEW Real-Time and DSC features Disadvantages Proprietary transfer protocol Not optimized for streaming Slightly more overhead than TCP/UDP Ideal Applications LabVIEW to LabVIEW communication Monitoring (SCADA)

Low-Level Communication Protocols TCP (Transmission Control Protocol) Advantages Reliable Standard networking protocol Fast performance Disadvantages Requires a non-trivial amount of coding Data must be flattened to strings before sending Additional code needed for multiple clients Difficult 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 Send data Typecast data into string

Low-Level Communication Protocols UDP (User Datagram Protocol) Advantages Asynchronous Connectionless Very fast performance Broadcasting support Disadvantages Delivery not guaranteed Requires non-trivial amount of coding Difficult to scale for many data points Data must be flattened to string Ideal Applications Broadcast applications Fast transfers Custom network protocols

Using UDP Send header and data Open UDP Port Close UDP Port Typecast data into string

DataSocket Legacy NI Communication Protocol Advantages Abstracts communication code Multiple client support Front panel binding Disadvantages Not designed for large data sets Not designed for streaming Cannot host items on real-time targets Ideal Applications LabVIEW to LabVIEW communication

Advanced Communication: Time-Triggered Networks Deterministic 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 Networks Deterministic Ethernet Advantages Deterministic data transfer Extremely fast Cost-effective alternative to reflective memory Disadvantages RT to RT only PXI/PC only Proprietary protocol Requires two network interfaces per node Ideal Applications Distributed control and simulation

Beyond Ethernet: Reflective Memory PCI/PXI mapped memory between nodes Advantages Extremely fast deterministic data transfer Deterministic data transfer to any OS that supports PC/PXI Disadvantages Very expensive Not 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 possible Object oriented Disadvantages Data 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 Producer Consumer Network Asynchronous Activity 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

Optimizing Data Streaming Read FIFO or queue until empty Flatten data Send data size Send data

Optimizing Data Streaming TCP Throughput Rates on PXI-8196 RT - LabVIEW 8.0 (Gigabit) 70000 60000 Throughput (KB/sec) 50000 40000 30000 20000 Larger payloads are most efficient 10000 0 0 1000 2000 3000 4000 5000 6000 7000 8000 9000 Payload (bytes)

Implementing Redundancy Acquire Send data via primary Error Yes Send data via secondary Error Yes Shutdown No No Send backup heart beat Error No Switch primary and secondary Yes Send Disconnected Backup message via primary

Redundant Streaming Example Redundancy is not trivial, but it can be done

Demo: Streaming

Remote User Interface: Web Interface Web UI Network Remote Application Communication Control 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 Subscriber Network Publisher Subscriber 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

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 SCADA OPC Server OPC Server PAC PLC

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

Command-Based Architecture Host Computer Embedded Target Command/ Parameter Sender Data Receiver Commands Data Command Parser Medium Priority Tasks High Priority Tasks XML header stores data scheme Target responds to commands from host

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) The network is part of the control loop Network jitter Loop jitter Control loop rate depends on network throughput Network Node A 1. Node A acquires a point 4 2. Point is sent to Node B 1 3. Node B processes point 2 4. Output is sent back to Node A, loop is closed Node B 3

Time-Triggered Distributed Simulation Example RPM, Throttle Engine Model Ethernet Private Ethernet Network Timing, Fueling Ethernet ECU Model

Time-Triggered Distributed Simulation Example (Real-Time Only) Create Time-Triggered shared variables Reserve time slots for variables in network configuration utility

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