What is LabVIEW used for?

LabVIEW is used for 4 main purposes:

  1. Automated Manufacturing test of a component/sub-system/system.
  2. Automated Product design validation of a component/sub-system/system.
  3. Control and/or monitoring of a machine/piece of industrial equipment/process.
  4. Condition monitoring of a machine/piece of industrial equipment.

(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.

Poll – Vote to see how your peers voted!

As a test engineer, what do you wish your manager better understood about test systems? (Multiple choice)
This field is for validation purposes and should be left unchanged.

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

Manufacturing test systems are used to verify your product is within spec before it leaves the plant. The main drivers for manufacturing test are usually (1) test consistency, (2) error reduction (3) throughput improvements and (4) increased reliability/uptime.

Here’s some good examples of manufacturing test systems:

LabVIEW use case – Automated Product Validation

Product validation systems are used during the design process to validate that the design works as intended, before production begins.  The main driver for automating product validation is that the number of dimensions that need to be swept across (e.g. temperature, power supply voltages, pressure) can be large and take a lot of time (sometimes repeating over many cycles) to both collect and analyze the data.

Here’s some good examples of product validation systems:

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

The main drivers for using LabVIEW (with NI hardware) for industrial embedded applications are: (1) rapid prototyping and development using off-the-shelf hardware (2) tight tolerance timing or (3) acquisition of high-speed signals.

Here’s some good examples of industrial embedded systems:

LabVIEW use case – condition monitoring

The main drivers for condition monitoring are generally either (1) improving machine up-time/reliability or (2) reducing maintenance costs.

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:

I work in manufacturing. I need a custom test system. »
I need my LabVIEW code updated so I can get back to work. »
I work in R&D. I need a tester to characterize my product. »
I’ve got an old test system that needs to be updated. »