Labview Real-Time Architecture and Good Programming Practices

LabVIEW Real-Time Architecture and Good Programming Practices

Table of Contents:

 LabVIEW RT Architecture  Front Panel Communication Protocol  Network Communication Protocol

LabVIEW RT Architecture

The LabVIEW RT architecture consists of the following three components: LabVIEW, the RT Development System, and the RT Engine. LabVIEW and the RT Development System are different ways to run the same executable, labview.exe, on the host machine. LabVIEW RT provides the LabVIEW executable with the ability to target different processors for execution. The RT Development System downloads the LabVIEW RT VIs to RT Engine on the target platform, which runs the VIs. The RT Engine provides deterministic real-time performance because it is designed to run optimally on RT Series hardware. Figure 1 shows the components of the LabVIEW RT architecture.

Figure 1. Components of LabVIEW RT Architecture

When labview.exe is targeted to the host machine, it behaves like normal LabVIEW. When you target any RT Series hardware, labview.exe uses the RT Development System to communicate with the RT Engine. Normal LabVIEW and the RT Development System cannot run on the same machine simultaneously because they are different ways of executing labview.exe. Conversely, the RT Engine uses a different executable, emblview.exe, which runs only on specific RT Series hardware with a real-time operating system.

Front Panel Communication Protocol

Both the RT Development System and LabVIEW can communicate with the RT Engine. When using the RT Development System, all VIs are targeted to the RT Series hardware and executed by the RT Engine. In other words, the RT Development System and the RT Engine execute different parts of the same VI, as shown in Figure 2. The RT Development System displays the front panel of the VI while the RT Engine executes the block diagram code. The RT Development System front panel communicates with the RT Engine block diagram through a user interface thread.

- 1 - Figure 2. Front Panel Communication Protocol

During development, using this user interface connection between the RT Engine and the host machine is very helpful. After downloading and running the VIs, you can keep the RT Development System open to show and operate the front panel of the embedded VI. When VIs run on the target platform, the RT Development System exchanges messages with the RT Engine to update the controls and indicators on the front panel. These communications occur automatically because they are built-in features of the RT Development System and embedded software.

Another helpful feature of the RT Development System is that you can debug embedded LabVIEW RT VIs while they run on the targeted platform. You can use LabVIEW debugging tools, such as probes, execution highlighting, breakpoints, and single stepping to locate errors in the block diagram code when the VI does not run correctly.

Network Communication Protocol

In some cases, a more efficient communication protocol is necessary. The following are examples in which you can write your own communication code to send information between the host machine and RT Series hardware.

 You want to run another application on the host machine, but if you keep the RT Development System open and targeted to the RT Engine, you cannot use LabVIEW on the host machine for any other task.  You want to have more control over the information sent back and forth.  You want to have control over the timing and sequencing of the data transfer.  You want to control what components are visible on the front panel because some controls and indicators may be more important for communication than others.  You want to do additional processing or logging with the data.

You can use the Network Communication Protocol to increase the efficiency of a communication system. In this architecture, the embedded VI continues to run on the RT Engine but the RT Development System is closed on the host machine, as shown in Figure 3. The host machine runs LabVIEW to communicate with the RT Engine and perform other required functions. LabVIEW communicates with the RT Engine using specific network communication programmatic controls such as TCP/IP, VI Server, and in the case of RT Series DAQ devices, shared memory reads and writes. When communicating in this way, LabVIEW is executing a different VI than that being executed by the RT Engine. A host VI runs on the host machine, while two VIs run their block diagram code on the RT Series hardware. In Figure 3, the time- critical loop VI is the same as the VI that runs on the RT Engine in the Front Panel Protocol. The difference is that this VI uses RT FIFOs to communicate with the normal priority communication

- 2 - loop VI. The normal priority communication loop VI uses network communication, specifically TCP/IP, to facilitate communication between the host machine and the RT Engine.

Figure 3. Network Communication Protocol

Be careful about separating network tasks from the time-critical thread because any network operation is inherently non-deterministic. Calling these functions from within a time-critical VI can harm the determinism of the application. A preferred solution is to have a separate normal priority thread handle the network communication. By using a more deterministic communication method, you can pass data between the following two threads: the time-critical loop and the normal priority communication loop. One such communication method is the RT FIFOs. Refer to the links below for more information on inter-thread communication and Real-Time FIFOs.