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:
Here are some good resources if you’re interested in more detail on 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):
- A GUI – either with a standard monitor or touch panel.
- 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.
- 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.
- 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:
- A Windows-based PC
- A Windows-based PXI
- An NI CompactRIO
- 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):
- 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.
- Production volumes – at some quantity, it’ll likely make more sense from a financial standpoint to use the sbRIO.
- 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?.
If you work for a US-based manufacturer or R&D lab, does one of these scenarios align with your needs?