Debug and Optimize Performance with the Real-Time Execution Trace Toolkit
Print
Figure 1. This block diagram shows the DAQ Task in a timed loop with optional debugging built into the code.
Real-time systems are commonly used in applications requiring determinism, maximum reliability, or dedicated processing.
Determinism and maximum reliability are well-known to real-time developers. Dedicated processing is becoming more prevalent as developers seek systems without the bloat of a Windows OS or any of the background tasks associated with it, such as virus protection and IT updates. Many times two or more of the above traits are required in a system. This means, from a programming perspective, that due to the more specialized nature of a real-time system, developers must take more care when debugging an application to ensure they meet all the required software specifications of a system.
The NI Real-Time Execution Trace Toolkit offers programmers low-level insight into what is happening within the OS because they can observe items such as thread activity and memory allocation. NI LabVIEW 8.5 graphical programming software introduces the second iteration of this toolkit, which is fully integrated into the NI LabWindows™/CVI and LabVIEW development environments for developing real-time applications. The primary improvements to Version 2.0 include a redesign of the tool to make it more responsive, the addition of LabWindows/CVI compatibility, more configuration options for customization, and new capabilities to debug multicore systems. Explore the examples in figures 2 and 3 to see how you can use the Real-Time Execution Trace Toolkit in debugging applications.
Example 1 – Memory Allocation That Induces Jitter into a System
Consider a LabVIEW application that is performing a control task with the requirement of closing a loop under 1 ms timing. It is important to note that you must use a real-time OS for your application to meet the 1 ms barrier because general-purpose OSs cannot perform such granular timing in software. A common problem that arises in this type of application is when nondeterministic tasks affect the performance of the control algorithm due to programming oversights. Network communication and logging to disk are two of the most common, nondeterministic tasks that exist in most real-time applications. From a software architecture perspective, real-time performance is ensured by breaking up the application into two primary components – a deterministic loop for the control and a nondeterministic loop for all the other tasks. In software, you can set the two loops to different priorities, ensuring that the most important operation (the control loop) always has first right of refusal of the CPU to meet the timing requirement.
Does this mean that the nondeterministic loop will never interfere? Most of the time the answer is yes, but if the two loops have any “shared resources,” there is a potential for interference. This is where you can use the Real-Time Execution Trace Toolkit to plan for debugging and include optional debugging code in your application from the outset. The diagram disable structure is a great way to add the instrumentation VIs for tracing into your code (see Figure 1).
In this particular example, the programmer is doing something that you should never do inside a loop – allocating memory. Aside from inefficiently managing your memory, this can lead to a particularly dire situation in a real-time application by inducing jitter. Also, because the memory manager is a shared resource, it can sometimes lead to multiple tasks requesting memory simultaneously, which can cause priority inheritance. Priority inheritance occurs when a lower priority task inherits a priority or gets bumped up to a higher priority. In other words, the nondeterministic tasks (network communication, logging to disk) can get bumped to the same level as the time-critical task.
Examining a trace of this VI, you can see that memory allocation does occur as denoted by the green flag (see Figure 2).
This small hiccup added a few microseconds of jitter to the application, and the total time of the operation (12.9 μs) is viewed by the selection of trace indicated by the gray coloring. Luckily, no priority inheritance occurred in this example. The solution is an easy one – preallocate memory instead of dynamically allocating memory in the loop. Without the Real-Time Execution Trace Toolkit, it would be more difficult to realize the root cause and go back to correct the programming oversight.
Figure 2. By examining a trace of a VI, you can see that memory allocation has occurred, as shown by the green flag.
Figure 3. This image shows the trace of an application running on a real-time SMP system.
Example 2 – Multithreaded Code Running on Multiple CPUs
As a second example, consider a real-time application that requires high-end performance. A dual-core real-time target is chosen with the goal that both CPUs max out the performance capabilities of the system. The LabVIEW 8.5 Real-Time Module adds support for symmetric multiprocessing (SMP), so the OS can load-balance tasks across available CPUs in a system. An example application where this is useful is hardware-in-the-loop (HIL) testing, in which one CPU can run a control model at a fast rate and the other CPU can handle all the other tasks in the system.
With the Real-Time Execution Trace Toolkit, you can visualize which thread is running on which CPU. In this example, there are two timed loops, one running on each CPU (see Figure 3).
In “Highlight CPU Mode,” you can look at one CPU or the other, and this feature supports the viewing of up to 32 CPUs simultaneously. Note that there are spaces between the blocks of time each thread is running in this screenshot. This is an indicator of available CPU cycles, so additional headroom is available to add more processing to the application at the current loop rate, or alternatively, the loop rate can run even faster and still hit timing constraints.
The Real-Time Execution Trace Toolkit is an important tool for debugging your application and finding jitter issues and code hotspots you can further optimize. The Real-Time Execution Trace Toolkit 2.0 is compatible with LabVIEW 7.1.1 and later as well as LabWindows/CVI 8.5, and it is part of the real-time deployment option in NI Developer Suite. The toolkit is included as a 30-day free evaluation with both LabVIEW and LabWindows/CVI Real-Time.
Jeff Meisel is the product manager for LabVIEW Real-Time. He holds a bachelor’s degree in computer engineering from Kansas State University.
View a tutorial on debugging multicore applications with the Real-Time Execution Trace Toolkit.
New Quad-Core Controllers for High-Performance Applications
The new NI 8353 and NI 8353 RT 1U rack-mount controllers, based on the 2.4 GHz Intel Core 2 Quad processor, offer up to 4 GB DDR2 RAM. You can bundle them with appropriate MXI-Express or MXI-4 remote controllers to control a PXI or PXI Express chassis to create a flexible yet powerful system for your test, measurement, and industrial control applications. The NI 8353 and NI 8353 RT controllers have Windows XP and LabVIEW Real-Time OS preinstalled, respectively.
The mark LabWindows is used under a license from Microsoft Corporation.
This article first appeared in the Q1 2008 issue of Instrumentation Newsletter.
Reader Comments | Submit a comment »
Legal
This material is protected under the copyright laws of the U.S. and other countries and any uses not in conformity with the copyright laws are prohibited, including but not limited to reproduction, DOWNLOADING, duplication, adaptation and transmission or broadcast by any media, devices or processes.