Labview Parallel While Loop

 

Parallel execution

An interesting effect of the LabVIEW data flow model is that of parallel execution. In most text-based languages, the structure of a program's source code completely defines the sequence of instruction execution. For instance, if a call to function A is placed directly above a call to function B, then function A is guaranteed to be called by that code segment before function B. This programming model of "sequence from code structure" is common in programming languages and is usually taken to be a rule-of-thumb by programmers.

LabVIEW, among a few other languages, does not explicitly fit this model. The sequence of instruction execution in LabVIEW cannot be entirely defined by the structure of the iconic code placed on the block diagram for two simple reasons--elements can be placed anywhere on the block diagram and can remain disconnected from each other. As an example, consider the placement of two while-loops next to one another with indicators showing their current iteration values as the program runs. It is indeterminate how these values will change as the program executes because the order of program execution cannot be determined by the structure of the block diagram. The second while-loop could run a thousand times before the first while-loop even runs once.

Figure 1:Indeterminate parallel execution. The order in which the two while-loops are executed cannot be determined from the block diagram. For instance, it is unclear if the loops will alternate from one to the other evenly, if they will alternate unevenly, or even if one loop always executes while the other waits indefinitely.

The property of parallel execution can be beneficial in many instances. If, for example, a program must control some external hardware such as a motor while logging data from a sensor such as a load cell, parallel execution assists by allowing the program to be structured in a way that separates the motor control from the data collection process. Such a separation not only keeps the code clean, but also allows for the parallel execution of the two tasks.

In other cases, parallel execution is undesired. Sometimes it is necessary to determine the execution sequence by the code structure. Consider a trivial LabVIEW program that needs to write its data to a file before reading it back in again. If these two VIs are independently placed on the block diagram, their order of execution is indeterminate meaning that the program could try to read the file before actually writing it. While one would probably never write a program that performs these operations, it demonstrates an instance in which parallel execution causes problems.

Figure 2: Parallel execution with unintended results. The value from the file path control flows down the wires to the save spreadsheet VI and the load spreadsheet VI. Which VI executes first, the load or the save, cannot be determined. In this case, parallel execution proves to be problematic if the program is trying to write the data to a file first and then read it in again.

Although LabVIEW inherently executes instructions in parallel, this behavior is not often seen because the structure of the program is more often than not defined by the connections between data sources and sinks. Block diagram elements only execute in parallel when they are disconnected from each other. When elements are wired together in some manner, then their order of execution becomes defined. For example, consider a LabVIEW program with a number of arithmetic operations in its block diagram. Since the data in the program always flows from source to sink, the order of operations can be defined by how the VIs are wired together.

Figure 3: Large scale sequential execution with small scale parallelism. The order of operation here is (addend1 + addend2) / divisor. The program cannot execute the divide operation until the add operation has completed because one of the inputs of the divide VI depends on the result of the add operation. Therefore, the addition is guaranteed to occur before the division. However, the order in which the values are read from the addend and divisor controls is still indeterminate--the divisor value could be read and passed to the divide VI before the addends are read and passed to the add VI.

The understanding of parallel execution, namely when to use it, when to avoid it, and how to control it, is essential in LabVIEW programming. Without a doubt, this concept is the most important of any of the others in these tutorials.