LabVIEW Data Acquisition

Gotchas, tips & tricks, and how to get help

What is it and how’s it used?

LabVIEW-based data acquisition involves writing software on top of appropriate hardware to acquire data from various sensors (e.g., temperature, pressure, current, …).  Those data are then usually manipulated and/or filtered before being displayed and/or recorded for further analysis.

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”).

If you’re curious what sorts of acquisition LabVIEW is used for, check out this resource, which covers the 4 main uses for LabVIEW.

Gotchas:

Assuming that just because it’s easy to get started it’s also easy to finish.  LabVIEW is a very complex programming environment.  The good news is that there’s not much you can’t do with it.  The bad news is that you have the freedom to get yourself into a lot of trouble (e.g., having sluggish user interfaces, dropped communication packets, acquisition buffer overruns, files that grow too large, creating control loops that won’t make timing, or have too much cycle-to-cycle variation).

Not organizing your LabVIEW code.  Trust me, you won’t want a gigantic rats nest to try to debug, make updates to, or pass off to someone else in the future. With all those wires, LabVIEW brings graphical meaning to spaghetti code!

Hooking up a strain gauge or low voltage source (such as a thermocouple) sensor without signal conditioning.  There are others.  Signal conditioning is hugely important to be able to recover your signal(s) of interest.

Coding without requirements.  It’s obviously more fun to just start banging out some code, but you’ll probably regret not taking a step back to at least jot down a bulleted list in a doc.  Why?  Because:

  1. You’ll want to know what you’re going to test in order to prove to yourself the thing works.
  2. It makes it more apparent if you’ve got conflicting requirements.
  3. It’ll help you think of other features you wanted but forgot about at one point or another.

If you’d like to start considering your requirements but aren’t sure where to start, feel free to check out our requirements templates (these might be more involved than is appropriate for your needs, but it gives you a starting point):

  1. industrial embedded requirements and specification template.
  2. test system requirements and specification template.

Assuming all downloadable instrument drivers will just work out of the box.  Some instrument drivers are of great quality, while others are horrible.  You’ll want to know where your driver falls on the spectrum, but for sure don’t assume it’ll just work.  Get a sense of driver quality from feedback on various forums.

Assuming your application will just work the first time out of the box.  It likely won’t.  Make your life less stressful and allocate debugging time up front.  As a very loose data point, consider allocating anywhere from 50%-150% of the time you spent coding on debug, depending on the overall complexity of course.

Not understanding what an FPGA is and how it works.  You won’t always need an FPGA-based acquisition system, but if you do, you should understand that you’re coding a very different piece of hardware.  If you’re looking to understand some of the very basics, see here: FPGA Basics – A Look Under the Hood.

Fundamentals – How to do it:

NI covers the basics well.  See http://www.ni.com/white-paper/3536/en/.  Also, check out this quick video from University of Minnesota: https://www.youtube.com/watch?v=GBhJk5Tnshc.

Tips & Tricks:

There are lots of ways to move data between loops in LabVIEW and to send commands along with the data to tell the receiver what to do with those data. Here are two methods, one tried-and-true and one which I bet you didn’t know: Communicating between Parallel Loops.

Another popular method leverages TCP/IP for communicating between sections of a single application or between multiple applications, either on the same PC or between PCs. Check out: Are You Using Network Streams?

Don’t find yourself knee-deep in a project only to find that you’ve got a sea of intermingled code, making it hard to differentiate what goes where and how to find files. Learn how to avoid this: Why Poor LabVIEW Project Organization Makes Your Code Stink.

If you want to do synchronous data acquisition across multiple channels, even if across boards, and perhaps even synchronized with output channels, you should check out: http://www.ni.com/product-documentation/4322/en/

LabVIEW uses data flow to sequence code execution. This approach offers inherent multitasking capabilities, including parallel tasks managed in multiple while loops. However, a desire arises to communicate between parallel tasks.  Learn about several types of LabVIEW synchronization tools: Synchronization in LabVIEW.

How to get help:

If you’re looking for LabVIEW data acquisition help for your application, see here for how we can help solve your data acquisition problems.

Yes, I need a LabVIEW-based data acquisition system »