What do we have to know about LabVIEW?
As a LabVIEW product manager, I am asked this question many times.
Honestly, it's not the right question. It becomes a valid question by adding a little nuance and application context (for example, "What is best for this task that has these limitations?"). Without this detail, it is like asking why bread is better than flour.
If you want to create a measurement or control system, then NI LabVIEW system design software is a tool that can save you the risk, expense, and inconvenience of creating a system using low-level languages like C.
I'm not suggesting that LabVIEW is a “better” programming language than C – especially considering that large portions of LabVIEW are written not only in G but also in C and C++. Rather, I mean that they have different strengths that programmers need to understand in order to be successful.
The relationship between LabVIEW and C is similar to bread and flour. If you want to make a sandwich, you should use the bread directly. If you want to bake a cake, you should use the flour to cook it. Baking flour for bread from scratch can be expensive and time consuming (especially if you want a quick meal), but when it comes to a cake, flour is essential.
Similarly, it can be difficult to decide which programming language is best for a task. It all comes down to using the right tool for the right job.
C provides control at low level
C is often better for applications with tight resources that need to be carefully managed. Since C is a relatively low-level language, it forces you to consider and specify even the smallest details, such as memory allocations and threads.
A good programmer can use this low-level check to eliminate overhead in most higher-level implementations. At this level, you can also take advantage of the architecture of the target of execution or the characteristics of the host operating system to achieve higher performance.
For this reason, NI programmers wrote most of the LabVIEW libraries in C or C++. Operations such as I/O and file parsing are just as fast in LabVIEW as in C, since they are written in low-level languages and optimized for each of the platforms and operating systems that LabVIEW supports.
Efficiency versus control
At certain times, the developer's efficiency is better than hand-optimized code. Giving up some control and trusting developers who have solved similar problems can benefit many projects in terms of productivity. Programming languages are constantly progressing towards higher levels of abstraction. This helps to focus on the problem at hand rather than the small details.
LabVIEW: For parallel execution and real world I/O
No matter what the implementation language, the division between high-level system design and low-level implementation is inevitable.
In measurement and control applications, programming is only a task for a system designer. Engineers often don't have time to keep up or rewrite old software to support advances in computing, measurement hardware, operating systems, etc. An engineer's value-add is finding the best way to acquire, manipulate, and present real-world data—not inventing new ways to manage memory allocations and thread pools. With LabVIEW, the final application can be built using low-level libraries from NI that are already tested, supported, and maintained.
Choosing C means that you will need to implement, support, and maintain your own lower-level libraries or purchase them from a vendor (NI offers NI LabWindows ™/CVI software and NI Measurement Studio for this use case).
A syntax tip, C is optimized for sequential execution of instructions as fast as the CPU can handle. This is perfect for pure calculation, when only one task is executed and the instructions are more basic. By contrast, LabVIEW's graphical syntax is optimized for parallel execution of timed tasks.
LabVIEW allows you to skip building the fundamentals and go straight to customizing.
LabVIEW is more than just a programming language and associated libraries. When you use the LabVIEW integrated development environment (IDE) with NI or third-party hardware, you get a development experience that is greater than the sum of its parts. The software is aware of the available hardware resources and can present the available I/O channels and execution hardware as dropdown menus and project items. Incorrect configurations can be prevented or detected during editing, avoiding costly and difficult-to-debug errors during runtime – The next generation of measurement hardware (such as the NI PXI-5644R vector signal transceiver) even allows LabVIEW to redefine the firmware hardware to achieve performance levels that the various programming languages and traditional tools cannot.
Too many projects are completed late or over budget because people underestimate the efforts required to bring parts from disparate sources together. Using LabVIEW, hardware drivers return data in the same format that the analysis libraries consume, user interface widgets display technical data in the same format that the analysis libraries produce it, eliminating the need to assemble the data. different components.
So which is better: LabVIEW or C?
The answer could well be “it depends.” It will depend on the problem you are trying to solve. LabVIEW and C are useful tools that, in the hands of trained users, can solve almost any problem: LabVIEW tends to be better for high-level test, measurement, and control applications, and C is better suited for low-level implementations. of computationally intensive tasks. The next time someone asks you if LabVIEW trumps C, don't hesitate to answer “it depends”. It may be the only answer that will get the debate moving in the right direction.
