CHAPTER 3 ‐‐ LabVIEW REAL‐TIME APPLICATION DEVELOPMENTREFERENCES: [1] NI, Real‐Time LabVIEW.[2] R. Bishop, LabVIEW 2009.

LabVIEWLabVIEW is a major player in the area of testing and measurements, industrial automation, and data analysis

•

Engineers and scientists in research, development, production, test, and service industries as diverse as automotive, semiconductor, aerospace, electronics, chemical, telecommunications, and pharmaceutical have used and continue to use LabVIEW to support their work. 

•

LabVIEW programs are called Virtual Instruments, or VIs for short.

•

LabVIEW uses a graphical programming language, known as the G programming language.

•

LabVIEW uses a terminology familiar to scientists and engineers.

•

ENGG4420 ‐‐ CHAPTER 3 ‐‐ LECTURE 1October‐31‐105:12 PM

CHAPTER 3 By Radu Muresan University of Guelph Page 1

WHAT ARE VIRTUAL INSTRUMENTS?A VI and its components are analogous to main programs and subroutines from text programming languages such as C and Fortran.

•

An interactive user interface know as the front panel○Source code – represented in graphical form on the block diagram. The block diagram consists of executable icons (called nodes) connected (or wired) together

○

VIs have:•

The art of successful programming in G is an exercise in modular programming – divide a task into a series of simpler subtasks (subVIs)

•

The subVIs are similar to subroutines. The subVIs are then assembled on a top‐level block diagram to form the complete program. Modularity means that you can execute each subVI independently, thus making debugging and verification easier. Furthermore, if your subVIs are general purpose programs, you can use them in other programs.

•

The front panel is the interactive user interface of a VI. The front panel contains knobs, push buttons, graphs, and many other controls (the term control is interchangeable with inputs) and indicators ( or outputs).

○

The block diagram is the source code for the VI. The icons of a block diagram represent lower‐level VIs, built‐in functions, and program control structures. These icons are wired together to allow the data flow.

○

The icons and connectors specify the pathways for data to flow into and out of VIs. All VIs have an icon and a connector.

○

VIs (and subVIs) have three main parts: 1) the front panel, 2) the block diagram, and 3) the icon/connector. 

•

CHAPTER 3 By Radu Muresan University of Guelph Page 2

DATA FLOW PROGRAMMINGThe principle that governs VI execution is know as data flow ‐‐ Data flow programming is characteristic to execution of G programs and is not to be confused with a linear execution of lines of code.

•

The executable elements of a VI execute only when they have received all required input data.

•

In a situation where one code segment must execute before another, and there is no type dependency between functions, you must use a Sequence structure to force the order of execution.

•

LEARN LabVIEW PROGRAMMIN BY:Use Getting Started with LabVIEW document•Use the book: LabView 2009 by Robert H. Bishop.•

CHAPTER 3 By Radu Muresan University of Guelph Page 3

NEED OF A WELL TESTED AND DEBUGGED RTOS

Simplify the coding process for complex applications;

○

Help in building a product fast;○Aid in building robust and bug free software by testing and simulation before locating the codes into hardware.

○

Readily available RTOS:•

Common options available for selecting an RTOS: 1) Own RTOS for small scale embedded system; 2)Linux based RTOS functions: Red Hat, eCOS or RT Linux; 3) uC/OS‐II: freeware for noncommercial use; 4) VxWorks; 5) PSoS; 6) Nucleus; 7) QNX, Window CE, Palm OS, Pocket PC; 8) VRTX; 9) OS‐9.

•

BASIC FUNCTIONS EXPECTED FROM KERNEL OF AN RTOSKernel (Scheduler).•Error handling functions.•Service and system clock functions.•Device driver, network stack send and receiver functions.•Time and delay functions.•Initiate and start functions.•Task state switching functions.•ISR functions.•Memory functions ‐‐ Create; query; get; put•IPC(Inter‐Process Communication) functions ‐‐ Signal exception handling functions; semaphore; queue; mailbox; pipes; sockets.

•

CHAPTER 3 By Radu Muresan University of Guelph Page 4

LabVIEW RUNNING IN WINDOWS OPERATING SYSTEMSLabVIEW applications running in Windows are not guaranteed to run in real‐time, because Windows is not a real‐time OS. Windows cannot ensure that code always finishes within specific time limits. 

•

Many programs run in the background – screen savers, disk utilities, virus software, and so on

○

It must service interrupts – keyboard, mouse, Ethernet, etc.○

Processor time is shared between programs and the operating system can preempt high priority Vis. The time your code takes to execute in Windows depends on many factors, such as:

•

You can increase the probability of programs running deterministically in Windows by disabling all other programs such as screen savers, disk utilities, and virus software. 

○

You can further increase determinism by disabling drivers for devices with interrupts such as the keyboard, mouse, and Ethernet card. 

○

Finally, for better determinism, you can write a device driver in Windows to get the most direct access to hardware possible. 

○

How can you increase determinism in LabVIEW Windows??•

Nevertheless, increasing determinism does not ensure that code always executes with real‐time behaviour. This is because Windows can preempt your LabVIEW programs, even if you use time‐critical priority. 

•

With the LabVIEW Real‐Time Module, your program runs in a separate real‐time OS. You do not need to disable programs or write device drivers in order to achieve real‐time performance. A real‐time OS enables users to prioritize tasks so that the most critical task can always take control of the processor when needed.

•

CHAPTER 3 By Radu Muresan University of Guelph Page 5

REAL‐TIME OPERATING SYSTEMSEnsure that high‐priority tasks execute first•Do not require user input from peripherals (keyboard, etc.)

•

National Instruments designed the LabVIEW Real‐Time Module to execute VIs on two different real‐time OS. 

•

Venturcom Phar Lap Embedded Tool Suit (ETS) ‐‐provides a real‐time OS that runs on NI Real‐Time Series hardware to meet the requirements of embedded applications that need to behave deterministically or have extended reliability requirements. 

1)

Venturcom RTX adds a real‐time subsystem (RTSS) to Windows, Venturcom RTX enables you to run Windows and the RTSS at the same time on the same computer. The RTSS has a priority‐based real‐time execution system independent of the Windows scheduler. RTSS scheduling supersedes Windows scheduling to ensure deterministic real‐time performance of applications running in the RTSS.

○

The LabVIEW Real‐Time Module can execute VIs on hardware targets running the real‐time OS for Venturcom Real‐Time Extension (RTX).

2)

For more information about Phar Lap ETS or RTX, refer to the Venturcom Web site at www.vci.com.

•

In this Section of the course we will focus on the ETS real‐time platform. 

•

CHAPTER 3 By Radu Muresan University of Guelph Page 6

CHAPTER 3 By Radu Muresan University of Guelph Page 7

SELECTING AN OPERATING SYSTEM

If you only must acquire real‐time data, then you might not need a real‐time OS. NI has many data acquisition (DAQ) devices that can acquire data in real‐time even though they are controlled by programs running in Windows. The DAQ device has an onboard hardware clock that makes sure that data is acquired at constant rates. With technologies such as bus mastering, direct memory access (DMA) transfer, and data buffering, the I/O device can collect and transfer data automatically to RAM without involving the CPU.

○

General Purpose OS ‐‐ used for data acquisition; offline analysis; data presentation.

•

Consider an application where every data point needs to be acquired and analyzed by software before we can determine if an event has occurred that requires a response. Similarly, consider an application where every acquired point must be handled by software in order to determine the output of a control loop. In both these cases, the software and the operating system must behave deterministically. You must predict their timing characteristics – and those characteristics must be the same for any data set, at any time. In these applications, the software must be involved in the loop; therefore, you need a real‐time OS to guarantee response within a fixed amount of time.

○

Real‐Time OS used for: closed loop control; time‐critical decisions; extended run time; stand alone operation; increased reliability.

•

In addition, applications requiring extended run times or stand alone operations are often implemented with real‐time OS.

•

CHAPTER 3 By Radu Muresan University of Guelph Page 8

REAL‐TIME DEVELOPMENT TOOLS

LabVIEWReal-Time

Module

Execution Trace Tool

LabViewReal-Time

Target

RTOS

Microprocessor

I/O Device

CompilerLinker

Debugger

System AnalysisTools

Sof

twar

eH

ardw

are

The tools provided for real‐time development consist of code development tools including the compiler, the linker, and the debugger. In addition, system analysis tools provide advanced insight into optimizing real‐time applications.

•

The LabVIEW Real‐Time Module is the application environment that serves as the complete development and debugging tool. For more advanced diagnostics, the LabVIEW Execution Trace Toolkit offers complete real‐time application analysis.

•

All LabVIEW Real‐Time Module deployment platforms are based on a common hardware and software architecture. Each hardware target uses computing components such as a microprocessor, RAM, non‐volatile memory, and an I/O bus interface. The embedded software consists of a real‐time operating system (RTOS), driver software, and a specialized version of the LabVIEW Run‐Time Engine.

•

CHAPTER 3 By Radu Muresan University of Guelph Page 9

LabVIEW REAL‐TIME SYSTEM USING ETS

The first system is Window based. On this machine, called host, you develop an application. When you are ready, you can download the application to the target processor. 

○

The RT Engine has the job of: 1) executing code, 2)controlling any connected I/O, and 3) communicating back to the host machine.

The second processor runs a real‐time operating system of the Venturcom Phar Lap ETS. The software that runs on the target platforms is referred to as the LabVIEW Real‐Time Engine (RT Engine). 

○

This figure illustrates the basic hardware architecture of a LabVIEW Real‐Time system. First, in order to ensure determinism, you must offload any time‐critical task from Windows and delegate it to a real‐time engine or target. Therefore, you have two systems –

•

Several kinds of National Instruments real‐time hardware platforms exist upon which real‐time applications can run.

•

You can maintain a user interface for the ongoing embedded application. If not, you can deploy the application and gather back information as required. Various hardware architectures allow different communication protocols such as TCP/IP or VI server.

CHAPTER 3 By Radu Muresan University of Guelph Page 10

REAL‐TIME HOST

A real‐time system consists of software and hardware components. 

•

LabVIEW, the RT Enging, and VIs you build using LabVIEW. 

○The software components include: •

a host computer and an RT target.○The hardware components of a real‐time system include:•

STEPS OF DESIGN:Develop the VIs for the real‐time system on the host ‐‐ the host computer is a computer with LabVIEW and the LabVIEW Real‐Time Module installed. 

1.

Download and run the real‐time VIs on the RT target. 2.The host computer can run VIs that communicate with the VIs running on the RT target.

3.

CHAPTER 3 By Radu Muresan University of Guelph Page 11

REAL‐TIME HARDWARE

An RT target refers to Real‐Time Series hardware or the real‐time subsystem (RTSS) that runs the Real‐Time Engine and VIs you create using LabVIEW.

•

Real‐Time Series Plug‐in Devices, ○Desktop PCs, ○Real‐Time PXI embedded controllers, ○Real‐Time Compact FieldPoint controllers, and○Compact Vision Controllers.○

You can deploy the LabVIEW Real‐Time Module with a variety of real‐time targets –

•

CHAPTER 3 By Radu Muresan University of Guelph Page 12

REAL‐TIME HARDWARE CONFIGURATIONS

Single‐box configurations are those in which the real‐time component is integrated within hardware that also contains a general purpose operating system. Real‐Time Series PCI plug‐in devices or desktop PCs can serve in this type of configuration.

a.

Host‐target configurations are ones in which the real‐time application is downloaded to the target from a host system. The real‐time application executes in an embedded fashion on the hardware target. Real‐Time PXI embedded controllers, Real‐Time Compact FieldPoint controllers, and Compact Vision Controllers are examples of host‐target configurations. 

b.

There are two basic configurations for RT targets. •

Desktop PCs can run real‐time applications in either configuration, depending on implementation. If you use the desktop PC in a single‐box configuration, it must be running the RTX operating system. You can use a desktop PC as a target when running the ETS operating system.

•

CHAPTER 3 By Radu Muresan University of Guelph Page 13

HOST‐TARGET CONFIGURATION (ETS ONLY)

Standard desktop computer – Ideal for low cost implementation

•

NI Real‐Time Series PXI Controller –Ideal for high‐speed, high channel count acquisition.

•

NI Real‐Time Series FieldPoint Module – Ideal for distributed real‐time I/O applications.

•

NI 1450 Series Compact Vision System – Acquires, processes, and displays images for IEEE 1394 cameras

•

CompactRIO – Embedded system with real‐time controller, reconfigurable FPGA chassis, and industrial I/O modules.

•

A networked Real‐Time Series device is a networked hardware platform with an embedded processor with a real‐time operating system (ETS) that runs the RT Engine and LabVIEW VIs. You can use a separate host computer to communicate with and control VIs on a networked Real‐Time Series device through an Ethernet connection, but the device is an independent computer. Some examples of networked Real‐Time Series devices include:Standard desktop computer – a standard desktop PC used as a real‐time system running LabVIEW Real‐Time for ETS Targets.

•

NI Real‐Time Series PXI Controllers – A networked device that installs in an NI PXI chassis and communicates with NI PXI modules installed in the chassis. You can write VIs that use all the I/O capabilities of the PXI modules, SCXI modules, and other signal conditioning devices installed in a PXI chassis. The RT Engine also supports features of the Real‐Time Series PXI controller.

•

NI Real‐Time Series FieldPoint Network Modules – A networked device designed for distributed real‐time I/O applications.

•

NI 1450 Series Compact Vision System – A distributed, real‐time imaging system that acquires, processes, and displays images from IEEE 1394 cameras. 

•

CHAPTER 3 By Radu Muresan University of Guelph Page 14

PXI EMBEDDED CONTROLLER

PXI is based on the CompactPCI standard. A typical system consists of a chassis, a controller, and a choice of I/O modules. The controller performs the same function as a desktop CPU. It includes a processor, permanent storage, memory, etc. When used as a real‐time system, the LabVIEW application is downloaded to the embedded processor on the controller. As the application runs, it accesses data from the I/O modules in the system.

•

You can disconnect an application deployed on a PXI system from the host computer and run the application headless – no monitor, keyboard, or mouse. With PXI, you can create rugged real‐time applications and deploy them as headless stand‐alone systems. 

•

For example in the automotive industry, engineers use real‐time PXI system to test the algorithm for an adaptive cruise control system. The control algorithm is downloaded to the real‐time PXI controller. The PXI system is placed in a test vehicle and the plug‐in I/O modules are connected to the engine. As the vehicle is driven around the test track, the PXI system simulates the adaptive cruise control system. Engineers can monitor the performance of the control system and make adjustments as necessary. In this example, LabVIEW Real‐Time and PXI are used for rapid control prototyping of an adaptive cruise control system.

•

CHAPTER 3 By Radu Muresan University of Guelph Page 15

COMPACT FIELDPOINT [c]FP NETWORK MODULE

Compact FieldPoint (cFP). The cFP‐20xx has many features that enable it to act as a stand‐alone device. Because most stand‐alone devices reside in remote or inaccessible locations, these system must be reliable to eliminate the need for constant maintenance. The dedicated processor in the cFP‐20xx runs a real‐time operating system that executes the LabVIEW Real‐Time Module application deterministically. The reliability of the real‐time operating system also reduces the chances of system malfunction.

•

The cFP‐20xx includes a Watchdog timer that monitors the overall operation of the FieldPoint system. When the watchdog senses that the system has a malfunction, it can run a separate maintenance routine or even reboot the FieldPoint system. The operatoin of the watchdog is user‐defined by a protocol.

•

The cFP‐20xx also includes user‐defined dip switches and bi‐color and tri‐color LEDs that can provide user interaction in a stand‐alone system. For instance, the LEDs can signify certain states of operation, while you can configure DIP switches to specify the startup state of the compact FieldPoint system.

•

The onboard static memory consists of 32 MB memory of the cFP‐2000, and 64 MB for the cFP‐2010 and cFP‐2020. The cFP‐20202 also features a slot that accepts removable CompactFlash cartridges, ranging in capacity from 64 to 512 MB. CompactFlash cartridges contain solid‐state, nonvolatile memory for storing your downloaded application or for performing embedded data logging.

•

The serial port allows the cFT‐20xx to connect to existing systems or other serial devices. The Compact FieldPoint I/O modules can be used for industrial environments.

•

CHAPTER 3 By Radu Muresan University of Guelph Page 16

RT‐TARGET ‐ SINGLE BOX CONFIGURATION

A NI PCI‐7041 plug‐in device is a plug‐in device with and embedded processor device and DAQ daughterboard. The processor device contains a microprocessor with a real‐time operating system that runs the RT Engine in LabVIEW VIs. 

•

You can use the host computer to communicate with and control VIs running on the NI PCI‐7041 plug‐in device through an Ethernet connection or shared memory.

•

CHAPTER 3 By Radu Muresan University of Guelph Page 17

CHAPTER 3 By Radu Muresan University of Guelph Page 18

RT TARGET ‐‐ REAL‐TIME SUBSYSTEM (RTX ONLY)

When you use the LabVIEW Real‐Time Module for real‐time extension (RTX) targets, the RT Engine runs on the real‐time subsystem (RTSS) of the host computer. 

•

The RTSS creates the x:\RTXROOT directory, where x is the Windows root drive, to store all of the RT target files. Like Real‐Time Series hardware targets, the RTSS provides a real‐time platform where you can execute LabVIEW VIs deterministically. You can communicate with and control VIs running on the RTSS from LabVIEW in Windows.

•

VIs running on the RTSS can use an NI PCI‐7831 plug‐in device for data acquisition.

•

CHAPTER 3 By Radu Muresan University of Guelph Page 19

CHOOSING THE RIGHT TARGET PLATFORM

The various platforms of NI Real‐Time Series hardware encompass a wide spectrum of application needs. To find the best platform for your type of application, match the platform that best fits your system requirements. For example, if you are looking for a highly distributive system with a high channel count and your timing needs are less than 1 kHz, then FieldPoint may be the best choice.Real‐Time Series plug‐in boards suit applications requiring a small control component to be added to a Windows‐based computer.

•

PXI RT ideally suits high‐performance, real‐time applications requiring tight synchronization across a variety of I/O and precise input and output sampling rates.

•

Compact FieldPoint RT ideally suites industrial applications requiring a small footprint, high‐reliability, distributed, and industrially rated hardware.

•

The specification used to classify the ruggedness of each target is the mean time between failures (MTBF). MTBF values for PXI range from 169,000 hours to 280,000 hours. The MTBF values for FieldPoint is 559,188 hours (52 years).

CHAPTER 3 By Radu Muresan University of Guelph Page 20