This essay has been submitted by a student. This is not an example of the work written by our professional essay writers.
For large applications it is often necessary to pass data among different pieces of codes. Passing data between different routines of a same piece of code or between different codes of separate applications is often a difficult task. It generally involves measures to determine whether the data is continuous or bursty in nature. This paper discusses techniques of passing data between different nodes in LabVIEW. Four key methods are discussed, each with its advantages, disadvantages and memory considerations. Implementation in a typical LabVIEW environment is also demonstrated. The paper also discusses when to use which method and its effectiveness. Finally benchmark results of number of operations per iteration for Read and Write of two common methods are explained.
Keywords: Data transfer methods, LabVIEW, Global Variable, Queue, Notifier, Shared Variable
Large applications are developed by combining different subroutines that work independently but, however, interlinked due to the same data that is being processed by all of them.
For example: consider a system where data is acquired from some source like oscilloscope on one computer and then passed to another computer to be processed and converted in a waveform on the LabVIEW interface. To make this system efficient and compatible, we need to develop several small routines that initialize the oscilloscope interface, trigger data acquisition, handle the errors and convert to array. All these routines will basically work on the same data that we take from the oscilloscope. To make them work together smoothly, the user is faced with the problem of passing data among them.
Data Transfer Methods not only allow the exchange of data between different Virtual Instruments but also determine the sequence of operation of these Virtual Instruments.
This is because the predetermined sequence of data transfer makes the VIs dependent on
Once it is clear that data transfer is necessary, the user is faced with the problem of selecting the most effective method. This paper will discuss those methods turn by turn and present the pros and cons of each one to present a clear picture that which method should be adopted in which scenario.
MATERIALS AND MEHTODS
Global Variables are one of the options for inter VI data transmission. It can be inferred from the name, ââ‚¬Ëœglobalââ‚¬â„¢, that these variables can be accessed from any virtual instrument which currently resides in the memory space. Whenever a global variable is created, LabVIEW application generates a global VI. This global VI contains no block diagram, but a front panel. We call this VI as Global Variable Holder. User can put indicators and controls into this VI in order to set whether it would be read from or written to, from another VI. User also describes the type of data to be transferred using this global VI. Several objects can be placed simultaneously in a single Global Variable Holder or separate global VIs can be created for each object.
Figure : First in Last out methodAnother possibility for transferring data between two VIs in a LabVIEW based program is the use of Notifiers. However, they can only be used for communication between VIs executing on the same computer. Notifiers do not themselves transfer data between VIs but they assist in making this transmission more reliable. Technically notifiers suspend the LabVIEW application till an instruction is received. Notifiers can be used in routines which have to send or accept data. The pending data is called a Notification. When the Notification is received and accepted, the program resumes, i.e. data starts flowing through the paused loop. Notifiers can be used as indicators for other data transferring techniques between VIs e.g. in a queue system, it can notify queue when to read for data.
Figure : First in First outQueue system
A Queue function forms another option for data communication in LabVIEW between two different VIs.
Two important types of queues used in LabVIEW environment are:
Last-In First-Out (LIFO)
First-In First-Out (FIFO)
Both forms of queues work by structuring lines of data. Whenever there is a queue involved in a system, a buffer must also be the part of the system. However the way in which data is queued determines whether it will be Last-In First-Out or First-In First-Out.
Last-In First-Out is actually stacking of data. It can be compared to a real world example of multiple saucers stacked together. The saucer to come out first would be the last saucer stacked. It actually works on a push and pop mechanism.
First-In First-Out depicts a queuing system, where data gets in a buffer from one end and retrieved from the other.
Shared Variable is a recent feature added in version 8.0 and later of LabVIEW package. It can solve problems related to data transfer between VIs. Majority of the features of a shared variable can be compared to that of a global variable except that it can only be implemented within a single program. However, as opposed to global variable, a shared variable can be accessed over a network.
RESULTS AND DISCUSSION
For data transfer between two VIs, it is the easiest method.
From continuity point of view, it is better to be used for variables which contain non-continuous data.
Global Variables collect and store only one value at a time, so they cannot be used for variables which carry continuously changing data.
User needs to create a system for inspection (preferably by using loops) whether the values are changing or not.
Special attention is needed while using global variables, especially with large arrays. Whenever receiving node accepts data from a global variable, copy of that data is produced by LabVIEW. For small data operations global variables will suffice, but when dealing bigger arrays the load on memory increases terribly. Even if a single element of an array of N elements is accessed, whole array is copied into the memory. Eventually it results in slow and inefficient performance.
Figure : How to release Notifiers
Notifiers enable a programmer to transfer data between VIs without any polling. There is no need for a loop that continuously checks the value of a variable. So part of the code which needs data to be received stops working so computer power is saved.
No buffers are needed.
Synchronization is necessary between rate of transmission and reception of notifications to prevent data loss.
As no buffers are included with notifiers, so to prevent data loss a feedback system can be put in place.
Notifiers can be used for continuous data transfer as well, however it is not recommended.
Notifiers do not work across a network. Consequently notifiers cannot be used with applications running a VI server.
While using notifiers inside a loop, a new reference is created by LabVIEW at the start of each loop iteration. This gradually increases memory usage as each reference needs four additional bytes. However when VI is stopped, these memory bytes are released. But if your program needs to run for longer times (e.g. a continuous monitoring system) then memory requirements keeps increasing. A remedy to this problem can be use of Release Notifier object inside the loop, so that after every iteration, the used memory space is released.
One important advantage in a queued system is that it does not require synchronization. For instance if the receiving node does not de-queue the buffer and becomes full. In this case transmitting node automatically waits for de-queuing process.
This insures lossless reception of data.
Most suitable system for continuous data transmission.
Data elements in a queue cannot be retrieved randomly. Only option is to de-queue data elements on sample by sample basis.
It needs a buffer to be implemented.
It requires a loop to continuously poll and check whether data has arrived.
Whenever a queue is implemented, the memory reserved for the queue is never dislocated till the queue is finished or called off (mostly when the VI is stopped). If data comes in discontinuous bursts, then for a small period of time, the queue will go unused and so the memory. Performance can be increased by dynamically allocating the queue memory at run time rather than pre-allocating memory.
Shared Variables are enabled to be published over a network and thus create Published Shared Variables. These variables can then be accessed over a network and VI server.
No buffer created so lesser memory space required.
This feature only available in version 8 and above.
As there is no buffer, so it can only stock a single value at a given time. So loss of data might occur for continuous transmissions.
Shared Variables can put additional load on the memory. One reason for this load is SVE (Shared Variable Engine) which has to be loaded for using Shared Variables. Also using SV for network publishing creates additional references and thus puts load on memory.
To conclude, the LabVIEW package provides the user with many different methods to transfer data not only among VIs on the same computer but also among VIs running on different computers. The choice of which method to use depends on many factors e.g. continuity of data, availability of buffer, number of variables to be passed, type of data to be shared etc. However, eventually it all comes down to the type of application being developed. Table.1 shows the comparison of different methods that the researchers inferred after implementation.
For comparing the performance of shared and global variables, a benchmarking VI was used as described by . For a global variable, the write performance is marginally higher then shared variable. However there is significant increase in performance for Read in global variable. While Read/Write combined test showed almost the same results.
Figure : Shared Vs Global Variable
Only V 8.0 & above