Data Communication

Data Communication deals with the sharing of data between parallel processes.  It ranges in platform from local (within a VI), global (across an application), and to multi-platform (multiple targets: PCs, PXI, cRIO, FPGA, etc.).  It also ranges from single element (lossy), steamed, and buffered (FIFO, Queue, etc.). Some Frameworks abstract the data communication but are ultimately built on one or more of these methods (see Actor Framework, DQMH, DCAF, AMC).

Single VI

Wires

The Wire is the simplest form of data communication in G. In dataflow programming the data literally flows from sources to sinks. A source can be a Control Terminal, Constant, or the output from another Node. The wire connects from a source to a sink which can be an input terminal of another node or the terminal of an Indicator. The wire has a defined data type determined by the source and appears as a "broken wire" if connected to an incompatible data type at the sink. The value on the wire is the data being communicated and can be a value or a reference to an object or memory space depending on the source.

Local Variables

Create Local Variables for front panel objects in a single VI when you do not have access to a front panel object or you need to pass data between block diagram nodes. For example, use a local variable when transmitting a stop button read to multiple loops running in the same VI.

With a local variable, you can write to or read from a control or indicator on the front panel. Writing to a local variable is like passing data to any other terminal. However, with a local variable you can write to it even if it is a control or read from it even if it is an indicator. In effect, with a local variable, you can access a front panel object as both an input and an output.

Single Application

Global Variables

Use Global Variables to access and pass data among several VIs that run simultaneously. Global variables are built-in LabVIEW objects. When you create a global variable, LabVIEW automatically creates a special global VI, which has a front panel but no block diagram. Add controls and indicators to the front panel of the global VI to define the data types of the global variables it contains. In effect, this front panel is a container from which several VIs can access data.

Shared Variables (Single-Process)

Use Single-Process Shared Variables to transfer data between two different locations on the same VI that cannot be connected by wires, such as parallel loops on the same VI, or two different VIs within the same application instance. The underlying implementation of the single-process shared variable is similar to that of the LabVIEW global variable. The main advantage of single-process shared variables over traditional global variables is the ability to convert a single-process shared variable into a network-published shared variable that any node on a network can access.

Functional Global Variable (FGV)

Functional Global Variables (FGV) are VIs that use loops with uninitialized shift registers to hold global data. FGVs are functionally equivalent to LabVIEW Global Variable and are sometime referred to as LV2 Global Variables (because LabVIEW 2 did not have Global Variables, but it did support uninitialized shift registers).  A FGV usually has an action input parameter that specifies which task the VI performs (read/write data). See more on Functional Global Variables (FGV).

Data Value Reference (DVR)

A Data Value Reference (DVR) is shared memory location where the location to the data is passed on the wire as a reference rather than passing the data.  It keeps memory copies from being created by using In Place Element Structures to read and write to the data.  DVRs are automatically locked from other writers while a process is writing to it and has the option for multiple parallel reads.   This is functionally equivalent to a Global Variables except that the reference must be passed around to be used.

Notifier

Notifiers are like mailboxes for data: one process sends data to the mailbox and another process receives data from the mailbox. In this way they are like local or global variables. When using a variable, however, the process that is waiting for information must cycle continuously to check the value of the variable. One benefit of notifiers is that the process that receives information completely stops execution while waiting and starts again only when new data becomes available. This cuts down on computer time wasted on endless polling. 

One use for Notifiers is to set the data type as Boolean to stop multiple looks. In this case all of the loops are polling by using the Get Notifier Status node. In this use it acts much like a local variable, when the Notifier is set to TRUE all loops polling receive the TRUE and can be stopped with it. This has the benefit over local variables that the loops can be in SubVIs. 

Queue

A Queue maintains a first in/first out (FIFO) order of data items. It is useful in producer/consumer situations, where one portion of code is creating data to be used by another portion. The advantage of using a queue is that the producer and consumer rates do not have to be identical. If consumption is slower than production, the queue will eventually become full and the producer code will be forced to wait until the consumer has dequeued an element before a new element can be queued up. 

User Events

You can create and name custom events, called User Events, to carry data that you define.   When a User Event is created the User Event wire can be forked to multiple Register For Event nodes.  Two or more loops can register for the same event if the each use their own Register For Event node.  The Register For Event node is responsible for establishing the event queue.  If the Register For Event wire is forked, and used for two or more loops, this has the same affect as if they were using the same queue.  The first one to dequeue it would receive the data and it would be lost to the other loops.

The User Event wire can also be forked to be used inside of other loops to Generate the User Event.  This has the affect of enqueuing the event data in all the event queues that have been registered and established to receive it.

Channel Wires

The Channel Wire, a new, feature in LabVIEW 2016, simplifies the programming involved in data transfer between parallel loops, such as the common producer/consumer pattern. All wires provide a graphical representation of data flow through your program. Most wires depict synchronous flow from a source node that, when it finishes, passes its result to its sink terminal(s). Channel wires depict asynchronous data flow: data flows from a source loop while that loop is still executing to allow sink loops to start execution immediately. Channel wires abstract complex data transfer patterns to help you develop applications that run correctly with fewer mouse clicks and fewer corner cases to debug. Channels can efficiently carry any type of LabVIEW data, from simple scalar values to complex arrays, clusters, or objects.

Multiple Platform

Shared Variables (Network-Published)

Using the Network-Published Shared Variable, you can write to and read from shared variables across an Ethernet network. The networking implementation is handled entirely by the network-published variable. The network-published shared variable adds many features not available with the single-process shared variable.

Shared Variables (Time-Triggered)

Time-triggered Shared Variables transfer data across a closed private network to ensure that network traffic never delays data transmission. Thus, time-triggered network communication is deterministic, which means you can guarantee that each value written to the time-triggered shared variable will be available to other VIs across the network within a deterministic amount of time. For control and automation tasks involving multiple devices, deterministic network communication can be crucial.

You can only use time-triggered networks with RT PXI and RT desktop targets, and each target must be configured with two Ethernet devices.

DataSocket

DataSocket is an easy-to-use, high-performance programming tool designed specifically for sharing and publishing live data in measurement and automation applications between different applications and between machines across the Internet. DataSocket for LabVIEW simplifies live data exchange between different applications on one computer or between computers connected through a network.

Although a variety of different technologies exist today to share data between applications, including TCP/IP, most of these tools are not targeted for live data transfer to multiple clients. With TCP/IP, you have to convert your data into an unstructured stream of bytes in the broadcasting application and then parse the stream of bytes back into its original format in subscribing applications. DataSocket, however, simplifies live data transfer.

User Datagram Protocol (UDP)

User Datagram Protocol (UDP) provides a means for communicating short packets of data to one or more recipients. Unlike TCP, UDP does not guarantee the safe arrival of data to the destination. Furthermore, data sent in multiple packets may not arrive at the destination in the order they were sent. Therefore UDP should be used to send short, non-critical messages to one or more destinations. The size limit of each packet is approximately 65K.

Because UDP does not have much in the way of communication control, no explicit connection to the other side of communcation is necessary in order to send or receive data. A client must simply listen on a specified UDP port, and any data broadcast to that port of that client is received.

Transmission Control Protocol (TCP)

Transmission Control Protocol (TCP), Internet Protocol (IP), and User Datagram Protocol (UDP) are the basic tools for network communication. The name TCP/IP comes from two of the best-known protocols of the internet protocol suite, the Transmission Control Protocol and the Internet Protocol. With TCP/IP you can communicate over single networks or interconnected networks (Internet). TCP/IP communication provides a simple user interface that conceals the complexities of ensuring reliable network communications.

The main difference between UDP and TCP is that UDP broadcasts data with no concern for whether the listener receives the data (or that there is even a listener) whereas TCP provides handshaking between writer and listener to ensure data is not lost.

Network Streams

Network Streams are an easy-to-configure, tightly integrated, and dynamic communication method for transferring data from one application to another with throughput and latency characteristics that are comparable with TCP.  However, unlike TCP, network streams directly support transmission of arbitrary data types without the need to first flatten and unflatten the data into an intermediate data type.  Network Streams flatten the data in a backwards compatible manner, which enables applications using different versions of the LabVIEW runtime engine to safely and successfully communicate with each other.  Network Streams also have enhanced connection management that automatically restores network connectivity if a disconnection occurs due to a network outage or other system failure.  Streams use a buffered, lossless communication strategy that ensures data written to the stream is never lost, even in environments that have intermittent network connectivity.

Other Protocols

More to Come.