Viewpoint News, Fall 2007

Main Article: How Have You Used LabVIEW RT Lately?

By now, most of you know that National Instruments offers a version of LabVIEW that runs on a realtime operating system. This LabVIEW Realtime (LV RT) operating system (OS) removes all those “invisible” applications that run in the background and that interfere with your LV application under a typical OS (e.g., Windows). Loop execution timing jitter is reduced just by removing these interfering applications. Nevertheless, loop jitter will still be present and can be large without proper understanding of some common sources of timing jitter.

This article describes some tips on minimizing jitter and summarizes some applications we have implemented with LV RT showing a range of what is possible with LV RT.

 

Background
Starting 2 or 3 years ago, Viewpoint Systems now increasingly uses LV RT for implementing a wide variety of solutions. However, we have learned (sometimes the hard way!) that you need to be aware about RT development: it is not exactly the same as regular LV.

What follows are a section on some tips to minimize loop jitter and then some sections illustrating a few applications under which we learned these tips.

 

Programming Challenges 
Perhaps the biggest challenge when writing code for RT is execution time management. Just because you are running your application under RT does not mean that the application will run without jitter. Attention to detail is critical to any RT application. Handling the Time Critical Loop (TCL) is especially important.

Below is a list of some stumbling blocks that need consideration when using LV RT. These items can significantly affect execution performance and jitter.

• Communication between the TCL and the rest of the program: The communication content can be data acquired or analyzed from within the TCL that needs to be moved to the main portions of the application, configuration parameters sent to the TCL that control execution behavior, status information from the TCL, and so on. Globals are bad due to overwriting. VI globals (also called a functional global or a LV2-style global) are bad due to execution holdoff (the same VI in two diagrams cannot execute in parallel). LV RTFIFOs are the best way to move data around.
• Execution of common VIs: This situation is similar to the use of VI globals: if the TCL calls a VI that can also be called by code outside the TCL, the TCL can be held off.
• Memory allocation: Allocation of arbitrary amounts of memory take varying amounts of time, causing timing jitter. For example, the time required to execute a build array is dependent on the number of elements in the array, thus leading to differing delays in the loop execution time. If the overall loop time greatly exceeds this delay, then the issue is not very important. We’ve seen situations in loops running at around 1 ms where this delay becomes an issue. The best method pre-allocates memory.
  

In general, LabVIEW applications written for RT require special attention to avoid introducing jitter due to software-induced holdoffs and latencies. Despite the high-priority of the TCL, it is still possible for LV RT to require execution of some code to complete before the TCL is given CPU time. In addition, latencies due to data-dependent processing time add jitter in the execution timing of downstream code.

 

Performance Decisions 
Some of our applications have been on the PXI platform while others have targeted the cRIO and FPGA platforms. First, the chart below shows some baseline performance criteria that drive platform choices.

The split between the “slow” and “fast” speeds are roughly around 1 to 10 ms range. And, on the complexity axis, “simple” and “complex” are divided by a number of factors that include handling acquired data, data processing and analysis, and algorithmic logic.

Generally, a “simple” app has no need to buffer acquired data (because aggregate rates are low enough), applies simple arithmetic to channels (some calculated channels and level checking for triggering or state changes), and uses a state machine with only a few states. All other applications are “complex”.

Of course, these descriptors are rules of thumb and results will vary.

 

Performance Experience 
We have delivered successful applications in each one of the quadrants in the above diagram. Note that the uniqueness of applications in the upper right quadrant implies that the majority of our applications exist in the other quadrants. Likewise, in our experience, applications that need FPGA usually combine the bottom row: the application needs the FPGA for some fast acquisition and/or control and the cRIO for slower analysis and data management.The following examples highlight some representative solutions were we have used LV RT.

 

Model-based Control and Acquisition
We have used LV RT to simulate a controller via a numerically-computed model when a real controller would otherwise be connected to the Unit Under Test (UUT). Other times, the UUT is subjected to conditions that are more easily created via the output(s) of a computational model than to create an actual electromechanical environment that would place the UUT in the desired conditions.

Of course, in these types of tests, we also use either normal LV or LV RT for test management and measurements.

We run the model(s) on PXI, FPGA, or both.

For example, we’ve run a model (essentially a rate-limited PID) for a SISO (Single Input, Single Output) analog hydraulic controller on the FPGA at a 20 µs loop period. This model used the fixed-point arithmetic under LV 8.5. The model was originally from Simulink and was recoded into the FPGA code. Another version of this same application used a 3 M gate FPGA to handle 8 channels of RMS measurements, 2 channels of demodulation from an LVDT, and 2 of the rate-limited PIDs all running at 125 µs loop period.

Some other more complex situations required a PXI controller. One system emulated the load for an aircraft flight surface and had about 30 channels of analog and digital I/O running at 1 ms loop period. This system used control algorithms to move both the flight surface and the simulated load. Another PXI-based system tested a Gatling gun controller by connecting it to a PXI box that simulated an actual Gatling gun’s mechanical and electrical properties, such as acceleration, fire control timing, and position feedback. This system had about 50 digital I/O channels and IEEE-1553 communications running under LV RT at 1 ms loop period.

 

Smart Data Monitor combined with Logging
We have used the cRIO platform many times as a smart Datalogger. These systems monitor one or more channels, watch for special conditions, and log the data into memory whenever such an event is detected.

The data logged is usually either a snapshot of values (waveforms of single samples) or a buffer of most recent history on all channels. This latter usage is nice because it allows some understanding of why the event occurred.

The small physical size of the cRIO makes it an ideal solution for these applications. We typically use the Ethernet port to extract the collected data via FTP for review elsewhere.

 

Machine Control
PLCs are commonly used for machine control. However, some machines are simply too fast for PLC control, and an ideal solution uses a PXI or cRIO or a combination of both.

A typical application concerns glass containers being manufactured at about 300 per minute along an assembly line. During the 200 ms per container, analog sensor waveforms collected at 10 kS/s indicate quality of each container, digital sensors collected at 10 kS/s indicate product position, and digital outputs must be synchronized to product position to within a few milliseconds.

The challenge in this application was not the sample rates, which were nominal for a PXI or cRIO. Instead, the challenge was the synchronization of the digital sensor timing information with the positioning of the analysis window on the analog waveforms and the digital control on the reject station. Thus, some rapid, on-the-fly data analysis adjustments were required, forcing the need for rapid, deterministic algorithm timing.

 

Custom Instrumentation
The cRIO and FPGA platforms simplify the development of custom instrumentation for applications needing only a few channels of signal conditioning or signal measurements.

We’ve used the FPGA to build “circuitry” that performs the same function as actual circuitry. Some examples are:

• Digital debouncer, to remove switch bounce for reliable event triggering.
• Quadrature detector, to measure the phase and amplitude of an LVDT output.
• RMS meter, to measure the amplitude of a signal.
• Low pass filter, to remove noise from a signal.

All these examples took an input signal, manipulated it, and created an output signal.  It is easy to imagine other applications in this arena that would utilize the cRIO processor too. For example, to construct a frequency-band power meter, the input analog signal could be processed with an FFT, and an analog output could be created from the amount of power in a specified frequency band (or bands, if you wanted to output multiple analog signals).