5 DAQ Debugging Techniques

Is LabVIEW not doing the DAQ things you were expecting? Maybe you have PEBCAK (Problem Exists Between Chair And Keyboard), meaning you’ve made a mistake (quite easy), or maybe there’s another problem with the software or the hardware that’s not your fault. We have already reviewed LabVIEW’s basic debugging tools in Chapter 1, Section 1.11. Let’s now look at some additional techniques for tracking down LabVIEW/DAQ problems in general.

5.1 LABVIEW’s DEBUGGING TOOLS

LabVIEW’s probe and toolbar buttons were created specifically for debugging. They are described in Chapter 1, Section 1.11, as they’re rather fundamental to LabVIEW. Please review those few paragraphs quickly, then we’ll mention some other techniques.

5.2 TRACKING DOWN BAD DATA

If you can isolate your bug to a certain condition in terms of LabVIEW’s data, then this section contains some ideas you should try first. For example, suppose you have some LabVIEW data on a block diagram that should never be negative, yet it’s occasionally negative. If this is the case, you can use the Case Structure to catch that negative data only when it occurs, plus any other useful data from your block diagram that might be causing the problem.

Whether you’re using the Case Structure to catch your debugging data only during certain conditions, or you want to continuously watch the data, there are a number of ways you can see this data. Here are some useful techniques:

1.   The probe, as described in Chapter 1, Section 1.11, is the simplest way to view the data. Its obvious disadvantage is that you can only view one data point at a time.

2.   The state cluster, as described in the next chapter, is a single cluster that you should often create on your main White Loop that contains all important state information. For debugging purposes, it is easy to add an extra data element to this state cluster for display on the main panel, then remove it later.

3.   Global variables can be used like the state cluster, but should be used as a last resort, since it’s sometimes tough to know exactly when they’re updated.

4.   File I/O can be used when you need to analyze a large amount of data for debugging purposes at a later time. File I/O can slow down the normal operation of your program, as it takes some time to access the disk.

5.   Serial I/O (the RS-232 port) can be used to stream the data to another computer. Although tougher to implement than file I/O, serial I/O does not slow the program nearly as much. Actually, any such data transmission to another computer will work as well, but serial I/O is currently the easiest to implement.

If your computer should lock up, the first three techniques do not always guarantee that you’re seeing the most recent data, particularly if your screen goes blank. The last two techniques are rather crash-proof, particularly the serial port strategy, since file writes are often buffered in memory unless the file is flushed or closed. The second computer will have control of the data as soon as it leaves the serial port of the first computer.

5.3 SOLVING CRASHES

Is your computer crashing for no apparent reason? Maybe it has a virus. See www.pcmag.com for PC Magazine’s opinion of the best virus protection software—they’re usually right on target with their reviews. I’ve found that certain virus protection software substantially slows down your computer.

I’ve been counting. LabVIEW itself does not crash very often. As I’ve written this book, my many untested beta versions of LabVIEW 6i have crashed 37 times, including the times I’ve repeated certain tricky procedures to try to make them crash, and I’ve reported all of these bugs to the responsive NI LabVIEW beta team. By contrast, my “shipping” version of Microsoft Word, which I’m using to type this document, has crashed well over 100 times (I’ve given up counting!). With Word, I’m doing my utmost to avoid crashes, as they often require a reboot. Based on my knowledge of LabVIEW shipping criteria, I expect it will be relatively difficult to make the “shipping” version of LabVIEW 6i crash. My point? LabVIEW crashes are usually a result of something other than LabVIEW itself. A virus, or some other piece of software, hardware, or hardware driver is usually the culprit. The most common cause of LabVIEW crashes is a lack of graphical system resources white editing. If you have a number of other graphics-intensive programs running with LabVIEW, you are at risk.

The worst kind of bug you can have is a crash that happens infrequently, yet ruins your test. First, try running your software on a completely different computer and see if that solves your problem. If not, your crash may indeed be caused by LabVIEW.

5.3.1 Hardware Induced Crashes

If you really must use the computer that is crashing, try replacing various pieces of hardware. Try removing different cards inside your computer, starting with the easiest to install and uninstall, then progressing to the most difficult. Also, try using a mouse with a different bus (PS/2, serial, or USB); I’ve run into crashing mice more than once. In the unlikely event that more than one component is causing a crash, your crash hunting will be very difficult! If you track down the crash to a particular piece of hardware, you may be able to solve your problem by updating the hardware’s driver from the hardware’s vendor.

Figure 5.1
Here’s my best shot at a graphic illustration of tracking down a crashing bug when no other techniques are working.

5.3.2 Software Induced Crashes

Your crash may be a result of some other piece of software running on your computer. First, try removing programs that are running simultaneously with your LabVIEW program. Some of them may be easy to stop, others not. For Windows, many programs are automatically started in Window’s startup folder. To find other sneakier Windows programs, run msconfig via Microsoft Windows’ Start»Run menu. If extremely desperate, save your important data, wipe your hard drive(s) clean, then reinstall the operating system.

If you’ve tried running your LabVIEW program on two computers with completely different brands of hardware, the crash is likely coming from some component of LabVIEW or NI-DAQ. First, back up your LabVIEW program in a different folder! Next, try removing all DAQ calls completely from your program and simulating your data with random numbers. If the crash still happens, try stripping down your program in chunks roughly half the size of the entire program until you isolate the crash (see Figure 5–1). Then, rebuild smaller pieces of the program until the crash starts again, at which point you start stripping it down again in even smaller pieces. This technique is applicable to any programming environment, not just to LabVIEW. Figure 5–1 is a crude diagram (don’t know how to make an elegant one) of how your crash hunting should proceed.

5.4 LAST RESORT

If you still cannot track down your problem, try getting outside help through a newsgroup or by calling NI. See the preface for more details. NI has some very sharp people working technical support. Though some of them may be new, they will eventually answer most of your questions.

Before moving on to the next chapter, close any VIs you might have open with the File»Close All menu item.