As LabVIEW solidifies itself as the leading software tool for test and measurements, it continues to broaden its reach into new markets and industries. Professionals who are now becoming acquainted with the tool usually ask a very legit question about LabVIEW. Is LabVIEW a measurement and control application environment or a programming language? I posed this very question to the audience during my presentation in the Bay Area LabVIEW Users Group meeting held at National Instruments offices in Santa Clara this past week.
Well, the right answer is; Yes. LabVIEW is actually both a full application environment and a programming language. It is an application environment in a sense that it provides a same paradigm for the development and deployment of test, measurements and control applications in a variety of targets. It also includes an impressive hardware support not only for National Instruments made hardware, but also for third party instruments. Finally, it provides an ideal environment for rapid prototyping and incremental development through its LabVIEW FPGA module, which allows programmers to deploy software that run embedded in a FPGA target.
One of the main reasons LabVIEW became the standard for test and measurements applications is the fact that it maintains the same dataflow programming methodology across targets running different operating systems, whether they are non-deterministic operating systems such as Windows, Linux or Apple OS; deterministic real time operating systems or even FPGA targets.
The close second reason LabVIEW has grown to the current user base size it enjoys today and will most likely continue to grow, is its hardware support. It is reasonably straight forward for even a new user of LabVIEW to write a simple application that interface with hardware, through its native APIs. Integration with National Instruments hardware is almost transparent to the programmer, as well as third party instrumentation that have LabVIEW drivers already available.
Lastly, it provides the perfect setup for rapid prototyping and incremental development. The ones of you who are familiar with ASIC design for example, understand how lengthy and time consuming the process of designing a custom hardware application actually is. The ASIC gets programmed through low level embedded programming languages, the design is then sent to a manufacturing facility for the chip to be created, which is then returned to the Engineer for testing and debug.
With LabVIEW FPGA, the Engineer programs the FPGA using the same dataflow paradigm it uses to program other targets, compiles the code and in minutes she has the custom hardware design available for testing and debug.
I have mentioned LabVIEW is also a programming language. In fact, any construct that is available in any text based programming language has counterparts also available in what is called the G programming, or dataflow programming, or yet, LabVIEW. Anything that can be programmed in any text based programming language can be programmed in LabVIEW.
Furthermore, LabVIEW has inherent parallel execution. Implementing parallel execution and multi-CPU deployment requires effort in a text based programming language. In LabVIEW, no extra effort is required for code to be spread over multiple processors. LabVIEW natively does that spreading over multiple targets every time its compiler spots snippets of code that are programmed to run in parallel. This provides a level of abstraction to the programmer that simplifies and expedites the development of applications.
Lastly, LabVIEW being graphical, it provides a flowchart-like look and feel of its code that is easy to follow. Our human brains think in pictures and functionality blocks when creating software, LabVIEW aligns its actual code implementation with that way of thinking, which provides another productivity boost for programmers.
With all that said, it is important to mention that, much like in the case of any tool which allows much flexibility for its utilization, it is very easy for one to get in trouble programming in LabVIEW. As it was mentioned, with LabVIEW the bar is set very low for one to know details of the environment before being able to write a simple application that compiles and does something meaningful. With that, it is very common for one to see reasonably large and complex applications having what is known in the industry as spaghetti code under the hood.
As with the case of any other programming language, proficiency and experience with the tool add a tremendous value in creating large complex applications that can be more easily maintained, expanded and reused. Even if your company is looking at having internal resources creating applications in LabVIEW, I strongly encourage you to engage an experienced LabVIEW professional to create the initial framework that will serve as the foundation for the applications and to work closely with the internal staff to show them best practices that are specific to the application being developed. This practice will save your company thousands of dollars at the end.