Top LabVIEW RT Programming Mistakes

[Owen_O'Brien]

This document describes the top LabVIEW RT programming mistakes and explains how to avoid them.

1. Reinventing the wheel. Learn more
2. Benchmarking poorly. Learn more
3. Including non-deterministic code in a time-critical VI or a timed structure. Learn more
4. Running loops faster than necessary. Learn more
5. Relying on front panel objects, properties, and events. Learn more
6. Combining timed structure priorities with VI priorities. Learn more
7. Overusing parallelism. Learn more
8. Over-publishing data. Learn more
9. Opening and closing references inside a loop. Learn more
10. Misunderstanding synchronous and asynchronous execution. Learn more
11. Hosting shared variables improperly. Learn more
12. Performing too many tasks on the RT target. Learn more
13. Turning off the RT target without switching to a safe shutdown state. Learn more

Reinventing the Wheel

Most real-time applications use a subset of common tasks. For the most common RT tasks, there are proven task architectures you can use as starting points in your applications. Reusing common, time-tested code reduces development and debugging time and generally increases the reliability of the application.

Benchmarking Poorly

Benchmarking is easy to get wrong, but it can be difficult to know when your benchmarks are misleading. National Instruments strongly recommends using the RT Benchmark example project as a starting point when benchmarking code that will be included in a time-critical VI or a timed structure. You also can use the RT Benchmark example project to benchmark non-time-critical code. However, before doing so you should change the priority of the benchmarking VI to match the priority at which the code will run in your application. The code in the RT Benchmark example has been carefully designed to provide accurate average-case and worst-case (jitter) execution time over thousands of iterations. However, even when you are using the RT Benchmark example, it is important to keep the following considerations in mind:

• Benchmark with the settings you plan to use during deployment, rather than the settings you use during development. For example:
  • Disable legacy USB support (in BIOS). Legacy USB support causes severe jitter.
  • Ensure that Hyper-threading is disabled (in BIOS). Hyperthreading is disabled by default on all NI RT targets. However, if you are using a desktop PC as an RT target, National Instruments recommends that you disable Hyper-threading because Hyper-threading can cause severe, unbounded jitter.
  • Switch to polling mode for Ethernet (in MAX)
  • Install only the minimum software set (in MAX)
  • Disable RT feedback (CPU and memory publishing, periodic connection checking)
  • Avoid subVI overhead within a tight time-critical loop
  • Disable debugging, log/print, and auto handling of menus
  • Disable legacy USB support in the BIOS
  • Minimize the size of the VI to optimize caching effects
  • Mass compile your application
  • Disable event logging in the ni-rt.ini file
  • Benchmark the entire contents of a loop rather than a specific subsection of the loop

When benchmarking timed structures, use the built-in timing nodes of the structure rather than the Get Timestamp function or the RT Get Timestamp VI.

Including Non-Deterministic Code in a Time-Critical VI or a Timed Structure

Common foes of determinism include:

• Memory Allocation–Always preallocate arrays before using them in your loops. Use the Show Memory Allocations tool to identify places in your code where memory is allocated. Ideally, you should eliminate all sources of memory allocation from a time-critical loop.

Add text here.

Running Loops Faster Than Necessary

Add text here.

Relying on Front Panel Objects, Methods, and Events

Add text here.

Combining Timed Structure Priorities with VI Priorities

Add text here.

Overusing Parallelism

Add text here.

Over-Publishing Data

Add text here.

Opening and Closing References Inside a Loop

Add text here.

Misunderstanding Synchronous and Asynchronous Execution

Add text here.

Hosting Network-Published Shared Variables Improperly

Generally, you should host network-published shared variables on the host PC rather than on the RT target itself. Hosting network-published shared variables consumes CPU resources, and in most cases there is no advantage to hosting on the RT target. Because RT CPU cycles are generally more valuable than CPU cycles on a desktop PC, it usually makes more sense to host network-published shared variables on a desktop PC to minimize CPU overhead on the RT target.

Performing Too Many Tasks on the RT Target

If your application consumes over 95% of the CPU resources available on the RT target, consider offloading certain tasks either to a desktop PC or to an FPGA target, if available. Use the following guidelines to determine the most appropriate device for offloading specific types of tasks.

Task	Appropriate Devices
Data acquisition	RT, FPGA
Control loop	RT, FPGA
Data analysis for logging or monitoring purposes (offline analysis)	Desktop PC
Data logging	RT

Turning Off the RT Target Without Switching to a Safe Shutdown State

National Instruments never recommends turning off an RT target without stopping the application or switching the application to a safe shutdown state. Even if your RT target uses the Reliance file system, you can still cause data corruption by turning off the target while a file is open. Reliance protects the integrity of the file system itself in such cases, but does not guarantee the integrity of individual files that might be open when you turn off the RT target.

For example, the following block diagram shows the shutdown state of the top-level state machine for an RT application.

The code in the shutdown state ensures that all files are closed before notifying the operator that it is safe to turn off the RT target.