What is LabVIEW used for?

(If you need LabVIEW help and want to know what your options are, check out LabVIEW Help – What are my options?. If you’re looking for why you might consider using LabVIEW, see our article Why use LabVIEW. If you’re just looking for some basics about what LabVIEW is, see What is LabVIEW?)

There are likely some additional corner cases out there, but this covers the vast majority of applications we see at Viewpoint.  Historically, LabVIEW has been widely adopted in the automated test realm, essentially becoming the de facto standard in that application space, whereas more recently it’s been gaining traction within the realm of industrial embedded monitoring and control.

LabVIEW is a software development environment created by National Instruments.  Originally it was focused on taking measurements from various lab instruments, but it’s expanded drastically from its inception.  Strictly speaking, LabVIEW is not a coding language, it’s a development environment.  The language is actually called “G”, but most people refer to LabVIEW as if it’s a language (i.e., most people would say “it’s coded in LabVIEW”).

LabVIEW is graphically-based, meaning you drag around various building blocks and connect them in a data flow architecture.  It’s similar to drawing a block diagram, except you’re drawing your code, as opposed to text-based languages like C# & VHDL where you type out in text what you want the software to do.

What basic functions can LabVIEW perform?

LabVIEW can be used to perform a huge number of mathematical and logic functions, including, but certainly not limited to: basic arithmetic, if/then/elseif conditional statements, case statements, FFTs, filtering, PID control loops, etc. There are huge libraries of functions to pull from. You can also interface to code developed in other languages, through DLLs. .NET assemblies, and run-time interpreters (e.g., MATLAB), for example.

Another somewhat unique capability that LabVIEW offers is real-time compilation and the ability to execute function blocks without requiring development of a test case. Each LabVIEW function is designed with a user interface so you can interact with your code immediately after you write it.

LabVIEW use case – Automated Manufacturing Test

Here’s some good examples of manufacturing test systems:

Here are some good resources if you’re interested in more detail on manufacturing test systems:

1. Test Systems as Lean Manufacturing Enablers To Reduce Errors & Waste
2. 5 Keys to Upgrading Obsolete Manufacturing Test Systems
3. Enhancing Manufacturing Test Systems to Support Production Volume Demand Increases – Automation & N-Up

LabVIEW use case – Automated Product Validation

Here’s some good examples of product validation systems:

LabVIEW use case – control and/or monitoring of industrial equipment & processes

Here’s some good examples of industrial embedded systems:

LabVIEW use case – condition monitoring

Some examples of condition monitoring applications include:

How does LabVIEW interact with the real world?

There are 4 ways that software developed with LabVIEW interacts with the real world (all requiring hardware with an appropriate processor on board (either desktop PC-based or SoC (System-On-Chip) based):

1. A GUI – either with a standard monitor or touch panel.
2. Interfacing with lab equipment/instruments (e.g. through GPIB, Ethernet, USB, PCI, RS-422) – for example power supplies, power meters, multi-meters, spectrum analyzers, oscilloscopes, switch matrices, and signal generators.
3. Measuring a signal with NI hardware (analog or digital) – for example temperature, pressure, vibration, current, load, voltage, flow, light, acoustics, force, location/orientation, vision, humidity/moisture, RF emissions, and magnetic field.
4. Controlling a signal with NI hardware (analog or digital) – for example motor control, actuator control, or mass-flow controllers.

What hardware does LabVIEW run on?

LabVIEW can run on any of these platforms:

1. A Windows-based PC
2. A Windows-based PXI
3. An NI CompactRIO
4. An NI Single-Board RIO (including the NI SOM)

The specs of your application will drive your choice of hardware platform.  Of course, you’ll want to be mindful of version compatibility as well.

For embedded applications, you’ll generally want to default to using a cRIO (we love the cRIO and use it a LOT) and let your project requirements convince you that a different platform (e.g. an sbRIO or SOM) is warranted.  There’s more details than provided here, but the decision process will usually be based on 3 main criteria (feel free to reach out here if you want to discuss those details):

1. Size / envelope – if your application requires a small envelope, the cRIO form factor may just be too big and you’ll be forced to go the sbRIO route.
2. Production volumes – at some quantity, it’ll likely make more sense from a financial standpoint to use the sbRIO.
3. I/O availability – depending on how much of what you need from an I/O (including comm. interface) standpoint is available either as a module or part of the base unit, the custom board non-recurring engineering design costs may sway you one way or another.

For test system applications, check out our guide Which NI Platform is Right for Your Test Needs? cRIO, PXI, cDAQ, sbRIO?.

Next Steps

Other LabVIEW questions? Check out our LabVIEW FAQ page.

If you work for a US-based manufacturer or R&D lab, go here for next steps: