Debugging Issues in LabVIEW Real-Time

Publish Date: Oct 11, 2011 | 3 Ratings | 3.00 out of 5 |  PDF

Overview

LabVIEW Real-Time applications generally serve a purpose that cannot be solved by a normal LabVIEW application. Thus, debugging a LabVIEW RT application might involve concepts and tools that LabVIEW users are not familiar with. Specifically, in LabVIEW RT applications, the most important thing to debug is the timing behavior of an application. In general LabVIEW applications, this is generally not a concern.

This means that in LabVIEW Real-Time applications, there are two levels of debugging we must worry about. The first is ensuring that the application behaves as expected. This requires the use of regular LabVIEW debugging tools to see whether errors occur, whether the flow of execution is as expected, and to locate error sources. Once the behavior of the application has been verified, we must also verify that the timing behavior is correct. This will require the use of various benchmarking tools.

This document introduces some key points and concepts that can be useful when trying to debug and improve the performance of a LabVIEW Real-Time application.

Table of Contents

  1. Verifying Application Behavior Using Standard LabVIEW Tools
  2. Verifying Real-Timeness Using Drivers
  3. Benchmarking Tools
  4. Benchmarking Tips
  5. Using LEDs

1. Verifying Application Behavior Using Standard LabVIEW Tools

The standard LabVIEW debugging tools (execution highlighting, single-stepping, probes, breakpoints, and so on) used to debug LabVIEW applications are available in the RT Development System while the host PC is targeted to the RT Engine. The only feature not supported is the Call Chain ring (also called the Call list), which appears in the toolbar of a subVI block diagram window while single-stepping. These tools are extremely useful for determining the source of an error in the application. These should not be used to debug execution timing, as all these tools will affect the timing behavior of the application.

The Profile window is a powerful tool for analyzing how your application uses execution time and memory. With this information, you can identify the specific VIs or parts of VIs you need to optimize. For example, if you notice that a particular subVI takes a long time to execute, you can focus your attention on improving the performance of that VI. The Profile window displays the performance information for all VIs in memory in an interactive tabular format. From the Profile window, you can select the type of information to gather and sort the information by category. You also can monitor subVI performance within different VIs. To display the Profile window, select Tools»Advanced»Profile VIs.

You must place a checkmark in the Profile Memory Usage checkbox before starting a profiling session. Collecting information about VI memory use adds a significant amount of overhead to VI execution, which affects the accuracy of any timing statistics you gather during the profiling session. Therefore, you should perform memory profiling separate from time profiling. Many of the options in the Profile window are available only after you begin a profiling session. During a profiling session, you can take a snapshot of the available data and save it to an ASCII spreadsheet file. The timing measurements accumulate each time you run a VI. Refer to LabVIEW Help: Profile Performance and Memory Window (linked below) for more information about using the Profile window.

See Also:
LabVIEW Help: Profile Performance and Memory Window

Back to Top

2. Verifying Real-Timeness Using Drivers


Once the basic behavior of the application has been verified, we can begin to test its timing characteristics. Many real-time applications involve control loops, which must be very accurately timed. One important test is to make sure that the application is capable of keeping up with the desired loop rate.

It is possible in some cases to use the software drivers to do this. For example, if you are using NI-DAQ in your application, it is possible to use NI-DAQ functions to time the loops as well as determine whether the loop rate is being maintained or if you are falling behind by using AI Single Scan in the loop. AI Single Scan has an output called "Data Remaining", which is 1 when data is still in the FIFO or buffer when the VI is about to return. The data remaining parameter is 0 when the FIFO is empty. If we monitor this value inside our loops, we can use it to determine whether we are keeping real-time or not. The example linked below shows how to use this VI to monitor real-timeness.

See Also:
Hardware Timed Loops Using AI SingleScan
Optimized Single Input, Single Output Control Loop

Back to Top

3. Benchmarking Tools


Several tools are available for benchmarking LabVIEW RT applications or sections of code. The first and most simple to use is "Tick Count." Tick Count uses a counter/timer on the DAQ device instead of a software timer, so the measurement is not affected by any bottlenecks in the operating environment. You can find an example of using Tick Count to benchmark your code under the ~LabVIEW/examples/real-time/RT Tutorial.llb/Benchmarking Shell.VI. This VI measures the time it takes to perform N iterations of a specified operation and calculates the average time in seconds per operation as well as average operations per second.

In certain instances you will want to use even more accurate timing tools than that. On Pentium based PXI controllers, it is possible to obtain a time stamp from the Pentium chip itself. The example linked below demonstrated this solution.

All the tools we have discussed so far will allow us to examine the relative timing of sections of code and to measure the software jitter of our application. In some cases it may be necessary to go one step further and to measure the jitter of the whole system. This becomes of particular concern when hardware timing is used, and the software jitter is masked out at the system level. In these cases, it may be necessary to use external tools such as an oscilloscope, to study the relationship between input and output signals, and to measure loop rates and jitter levels.

See Also:
Measuring the Determinism of Real-Time Applications
Timing deterministic control loops

Back to Top

4. Benchmarking Tips


To benchmark a LabVIEW Real-Time VI correctly, you must measure execution time for the worst-case scenario. Consider the following example, which illustrates a Case structure in a While Loop. The VIs execution time varies depending on the value of the Initial State input. In case 0, nothing happens, so the VI executes quickly. In case 1, the VI creates an array of a thousand elements, one element at a time. Each time this case executes, LabVIEW Real-Time must make one thousand memory allocations, which takes longer than case 0.




Although elementary, this example demonstrates that you should benchmark LabVIEW Real-Time VIs using the slowest possible scenario. Doing so establishes an upper bound on execution time that your VI should never exceed.

In order to obtain accurate and reliable benchmarks, it is also important that all functions inside the code being measured are bounded.

Back to Top

5. Using LEDs


The RT Series processor board has two LEDs. You can use these LEDs to indicate the state of your running application. On the PXI-7030, the LEDs are visible on the front panel. On the PCI-7030, the LEDs are located along the top edge of the board, and you must remove the cover from the case of your computer to view them. The red LED lights during a portion of the reset of the RT Series DAQ device. Also, the red LED lights and remains lighted if the RT Engine detects an internal error. You can control both the red LED and a second green LED from LabVIEW Real-Time applications to provide status information. You can use the RT Board LEDs VI in your application to control each LED independently. You can turn each LED on, off, or toggle its state. Refer to the LabVIEW Help for more information about the RT Board LEDs VI.

The 8140 RT series controllers also have LEDs you can use for debugging. Refer to the Controlling the LEDs on the 8140RT Series Hardware example (linked below) for more information.

See Also:
Controlling the LEDs on the 8140RT series hardware


Back to Top

Bookmark & Share


Ratings

Rate this document

Answered Your Question?
Yes No

Submit