LabVIEW
From Wikipedia, the free encyclopedia
LabVIEW (short for Laboratory Virtual Instrumentation Engineering Workbench) is a platform and development environment for a visual programming language from National Instruments. The graphical language is named "G". Originally released for the Apple Macintosh in 1986, LabVIEW is commonly used for data acquisition, instrument control, and industrial automation on a variety of platforms including Microsoft Windows, various flavors of UNIX, Linux, and Mac OS. The latest version of LabVIEW is version 8.20, released in honor of LabVIEW's 20th anniversary.
Contents |
[edit] Dataflow programming
The programming language used in LabVIEW, called "G", is a dataflow language. Execution is determined by the structure of a graphical block diagram (the LV-source code) on which the programmer connects different function-nodes by drawing wires. These wires propagate variables and any node can execute as soon as all its input data become available. Since this might be the case for multiple nodes simultaneously, G is inherently capable of parallel execution. Multi-processing and multi-threading hardware is automatically exploited by the built-in scheduler, which multiplexes multiple OS threads over the nodes ready for execution.
Programmers with a background in conventional programming often show a certain reluctance to adopt the LabVIEW dataflow scheme, claiming that LabVIEW is prone to race conditions. In reality, this stems from a misunderstanding of the data-flow paradigm. The aforementioned data-flow (which can be "forced", typically by linking inputs and outputs of nodes) completely defines the execution sequence, and that can be fully controlled by the programmer. Thus, the execution sequence of the LabVIEW graphical syntax is as well-defined as with any textually coded language such as C, Visual BASIC, Python etc. Furthermore, LabVIEW does not require type definition of the variables; the wire type is defined by the data-supplying node. LabVIEW supports polymorphism in that wires automatically adjust to various types of data.
[edit] Graphical programming
LabVIEW ties the creation of user interfaces (called front panels) into the development cycle. LabVIEW programs/subroutines are called virtual instruments (VIs). Each VI has three components: a block diagram, a front panel and a connector pane. The latter may represent the VI as a subVI in block diagrams of calling VIs. Controls and indicators on the front panel allow an operator to input data into or extract data from a running virtual instrument. However, the front panel can also serve as a programmatic interface. Thus a virtual instrument can either be run as a program, with the front panel serving as a user interface, or, when dropped as a node onto the block diagram, the front panel defines the inputs and outputs for the given node through the connector pane. This implies each VI can be easily tested before being embedded as a subroutine into a larger program.
The graphical approach also allows non-programmers to build programs by simply dragging and dropping virtual representations of the lab equipment with which they are already familiar. The LabVIEW programming environment, with the included examples and the documentation, makes it simpler to create small applications. This is a benefit on one side but there is also a certain danger of underestimating the expertise needed for good quality "G" programming. For complex algorithms or large-scale code it is important that the programmer possess an extensive knowledge of the special LabVIEW syntax and the topology of its memory management. The most advanced LabVIEW development systems offer the possibility of building stand-alone applications. Furthermore, it is possible to create distributed applications which communicate by a client/server scheme, and thus is easier to implement due to the the inherently parallel nature of G-code.
[edit] Benefits
One benefit of LabVIEW over other development environments is the extensive support for accessing instrumentation hardware. Drivers and abstraction layers for many different types of instruments and buses are included or are available for inclusion. These present themselves as graphical nodes. The abstraction layers offer standard software interfaces to communicate with hardware devices. The provided driver interfaces save program development time. The sales pitch of National Instruments is, therefore, that even people with limited coding experience can write programs and deploy test solutions in a reduced time frame when compared to more conventional or competing systems. A new hardware driver topology (DAQmxBase), which consists mainly of G-coded components with only a few register calls through NI Measurement Hardware DDK (Driver Development Kit) functions, provides platform independent hardware access to numerous data acquisition and instrumentation devices. The DAQmxBase driver is available for LabVIEW on Windows, MacOSX and Linux platforms.
In terms of performance, LabVIEW includes a compiler that produces native code for the CPU platform. The graphical code is translated into executable machine code by interpreting the syntax and by compilation. The LabVIEW syntax is strictly enforced during the editing process and compiled into the executable machine code when requested to run or upon saving. In the latter case, the executable and the source code are merged into a single file. The executable runs with the help of the LabVIEW run-time engine, which contains some precompiled code to perform common tasks that are defined by the G language. The run-time engine reduces compile time and also provides a consistent interface to various operating systems, graphic systems, hardware components, etc. The run-time environment makes the code portable across platforms. Generally, LV code can be slower than equivalent compiled C code, although the differences often lie more with program optimization than inherent execution speed.
Many libraries with a large number of functions for data acquisition, signal generation, mathematics, statistics, signal conditioning, analysis, etc., along with numerous graphical interface elements are provided in several LabVIEW package options.
The LabVIEW Professional Development System allows creating stand-alone executables and the resultant executable can be distributed an unlimited number of times. The run-time engine and its libraries can be provided freely along with the executable.
A benefit of the LabVIEW environment is the platform independent nature of the G-code, which is (with the exception of a few platform-specific functions) portable between the different LabVIEW systems for different operating systems (Windows, MacOSX and Linux). National Instruments is increasingly focusing on the capability of deploying LabVIEW code onto an increasing number of targets including devices like Phar Lap OS based LabVIEW real-time controllers, PocketPCs, PDAs, FieldPoint modules and into FPGAs on special boards.
There is a low cost LabVIEW Student Edition aimed at educational institutions for learning purposes. There is also an active community of LabVIEW users who communicate through several e-mail groups and Internet forums.
[edit] Criticism
LabVIEW is a proprietary product of National Instruments. Unlike common programming languages such as C or FORTRAN, LabVIEW is not managed or specified by a third party standards committee such as ANSI. Obtaining a fully compatible and up to date LabVIEW platform requires purchasing the product. There is a movement to create user-defined extensions for the development environment at OpenG.org but an initial purchase of LabVIEW is still required. Currently there is no open source, free software or alternative commercial program that can implement any portion of G-code.
In addition, as of version 8, all LabVIEW installs require customers to contact National Instruments by Internet or phone to "activate" the product.[1] The increasing dependence on the vendor suggests possible privacy and data security concerns. For example, although National Instruments claims the process is "secure and anonymous" the immediate implication is that a legal but privately installed instance of LabVIEW seems no longer possible. However, if National Instruments were to go out of business, the LabVIEW code is escrowed and would be released to the public, and so there would be no concerns over activation. This would mean that, with the current system, the user would no longer be able to access their code base as well as certain formats of archived data.
Building a stand-alone application with LabVIEW requires the Application Builder component which is included with the Professional Development System but requires a separate purchase if using the Base Package or Full Development System.[2] Compiled executables produced by the Application Builder are not truly standalone in that they also require that the LabVIEW run-time engine be installed on any target computer on which users run the application.[3] Although this run-time engine can be freely downloaded from National Instruments' website, this added requirement is in contrast to other compiled languages, such as C, where a stand-alone executable file can be created, run and distributed without the need for additional files or installation procedures. These requirements can cause problems if an application is distributed to a user who may be prepared to run the application but does not have the inclination or permission to install additional files on the host system prior to running the executable. The need for a separately-installed LabVIEW run-time engine makes the development and distribution of truly portable applications using LabVIEW difficult.
There is some debate as to whether LabVIEW is really a general purpose programming language (or in some cases whether it is really a programming language at all) as opposed to an application-specific development environment for measurement and automation.[4] Critics point to a lack of features, common in most other programming languages, such as native recursion and, until version 8.20, object oriented features. While it is possible to write complex applications in LabVIEW that involve no measurement or automation, it is not best suited to the task.
[edit] Articles on LabVIEW
[edit] Articles about specific applications of LabVIEW
- Desnica V, Schreiner M (Oct 2006). "A LabVIEW-controlled portable x-ray fluorescence spectrometer for the analysis of art objects". X-Ray Spectrometry 35 (5): 280-286. DOI:10.1002/xrs.906.
- Keleshis C, Ionita C, Rudin S (Jun 2006). "Labview graphical user interface for micro angio-fluoroscopic high resolution detector". Medical Physics 33 (6): 2007. DOI:10.1118/1.2240285.
- Fedak W, Bord D, Smith C, Gawrych D, Lindeman K (May 2003). "Automation of the Franck-Hertz experiment and the Tel-X-Ometer x-ray machine using LABVIEW". American Journal of Physics 71 (5): 501-506. DOI:10.1119/1.1527949.
[edit] Articles about using LabVIEW in education
- Belletti A, Borromei R, Ingletto G (Sep 2006). "Teaching physical chemistry experiments with a computer simulation by LabVIEW". Journal of Chemical Education 83 (9): 1353-1355.
- Moriarty PJ, Gallagher BL, Mellor CJ, Baines RR (Oct 2003). "Graphical computing in the undergraduate laboratory: Teaching and interfacing with LabVIEW". American Journal of Physics 71 (10): 1062-1074. DOI:10.1119/1.1582189.
- Lauterburg, Urs (June 2001). "LabVIEW in Physics Education". A white paper about using LabVIEW in physics demonstration and laboratory experiments and simulations..
- Drew SM (Dec 1996). "Integration of national instruments' LabVIEW software into the chemistry curriculum". Journal of Chemical Education 73 (12): 1107-1111.
- Muyskens MA, Glass SV, Wietsma TW, Gray TM (Dec 1996). "Data acquisition in the chemistry laboratory using LabVIEW software". Journal of Chemical Education 73 (12): 1112-1114.
- Ogren PJ, Jones TP (Dec 1996). "Laboratory interfacing using the LabVIEW software package". Journal of Chemical Education 73 (12): 1115-1116.
[edit] Alternatives
National Instruments also offers a product called Measurement Studio, which offers many of the test, measurement and control capabilities of LabVIEW, as a set of classes for use with Microsoft Visual Studio. This allows developers to harness some of LabVIEW's strengths within the text-based .NET framework.
National Instruments also offers LabWindows/CVI as an alternative for ANSI C programmers.
Agilent Technologies positions their VEE product as a similar alternative to LabVIEW.
[edit] See also
[edit] External links
- Official Home Page - The National Instruments web site for the LabVIEW product line.
- LabVIEW Help - NI's entire set of online help documentation for LabVIEW 8.2.
- Official LabVIEW Community Home Page - NI's "LabVIEW Zone" web site.
- LabVIEW Advanced Virtual Architects (LAVA) - Independent community with discussion forums and a code repository.
- Info-LabVIEW - User-community LabVIEW electronic mailing list and digest (since 1991).
- The LabVIEW FAQ - Hosted at lavag.org.
- The LabVIEW Wiki - A user editable LabVIEW knowledge base powered by MediaWiki.
- Free online LabVIEW course - Authored by NI engineers, based on LabVIEW 7.x, hosted by Connexions
- LabVIEW Web Ring - Dozens of LabVIEW user resource based web sites linked by a Web ring.
- OpenG - An open source LabVIEW community (downloads and discussion forums).
- LVdiff - An open source tool to compare virtual instrument (binary VI) files written in LabVIEW.
[edit] References
- ^ "Product Activation FAQ", National Instruments.
- ^ "Building a Stand-Alone Application", National Instruments.
- ^ "Using the LabVIEW Run-Time Engine", National Instruments.
- ^ Is LabVIEW a general purpose programming language?
[edit] Partner Companies & Products
- Measurement Computing - Alternative hardware compatible with LabVIEW
- ExpressPlus - Hardware and Software Add-on resources for LabVIEW and TestStand
- VI Package Manager (VIPM) - Application for Installing and distributing LabVIEW tools and add-ons into your LabVIEW development environment.