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

Transcription

1 CHAPTER 3 By Radu Muresan University of Guelph Page 1 ENGG4420 CHAPTER 3 LECTURE 1 October :12 PM CHAPTER 3 LabVIEW REAL TIME APPLICATION DEVELOPMENT REFERENCES: [1] NI, Real Time LabVIEW. [2] R. Bishop, LabVIEW LabVIEW LabVIEW 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.

2 CHAPTER 3 By Radu Muresan University of Guelph Page 2 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. VIs have: 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 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. VIs (and subvis) have three main parts: 1) the front panel, 2) the block diagram, and 3) the icon/connector. 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.

3 CHAPTER 3 By Radu Muresan University of Guelph Page 3 DATA FLOW PROGRAMMING The 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.

4 CHAPTER 3 By Radu Muresan University of Guelph Page 4 NEED OF A WELL TESTED AND DEBUGGED RTOS Readily available 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. 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 RTOS Kernel (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.

5 CHAPTER 3 By Radu Muresan University of Guelph Page 5 LabVIEW RUNNING IN WINDOWS OPERATING SYSTEMS LabVIEW 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. 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: Many programs run in the background screen savers, disk utilities, virus software, and so on It must service interrupts keyboard, mouse, Ethernet, etc. How can you increase determinism in LabVIEW Windows?? 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. 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.

6 CHAPTER 3 By Radu Muresan University of Guelph Page 6 REAL TIME OPERATING SYSTEMS Ensure 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 realtime OS. 1) 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. 2) The LabVIEW Real Time Module can execute VIs on hardware targets running the real time OS for Venturcom Real Time Extension (RTX). 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. For more information about Phar Lap ETS or RTX, refer to the Venturcom Web site at In this Section of the course we will focus on the ETS real time platform.

7 CHAPTER 3 By Radu Muresan University of Guelph Page 7

8 CHAPTER 3 By Radu Muresan University of Guelph Page 8 SELECTING AN OPERATING SYSTEM General Purpose OS used for data acquisition; offline analysis; data presentation. 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. Real Time OS used for: closed loop control; time critical decisions; extended run time; stand alone operation; increased reliability. 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. In addition, applications requiring extended run times or stand alone operations are often implemented with realtime OS.

9 CHAPTER 3 By Radu Muresan University of Guelph Page 9 REAL TIME DEVELOPMENT TOOLS Software Hardware Compiler Linker Debugger System Analysis Tools RTOS Microprocessor I/O Device LabVIEW Real-Time Module Execution Trace Tool LabView Real-Time Target 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.

10 CHAPTER 3 By Radu Muresan University of Guelph Page 10 LabVIEW REAL TIME SYSTEM USING ETS 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 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 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). The RT Engine has the job of: 1) executing code, 2) controlling any connected I/O, and 3) communicating back to the host machine. 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.

11 CHAPTER 3 By Radu Muresan University of Guelph Page 11 REAL TIME HOST A real time system consists of software and hardware components. The software components include: LabVIEW, the RT Enging, and VIs you build using LabVIEW. The hardware components of a real time system include: a host computer and an RT target. STEPS OF DESIGN: 1. 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. 2. Download and run the real time VIs on the RT target. 3. The host computer can run VIs that communicate with the VIs running on the RT target.

12 CHAPTER 3 By Radu Muresan University of Guelph Page 12 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. You can deploy the LabVIEW Real Time Module with a variety of real time targets Real Time Series Plug in Devices, Desktop PCs, Real Time PXI embedded controllers, Real Time Compact FieldPoint controllers, and Compact Vision Controllers.

13 CHAPTER 3 By Radu Muresan University of Guelph Page 13 REAL TIME HARDWARE CONFIGURATIONS There are two basic configurations for RT targets. a. 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. b. 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. 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.

14 CHAPTER 3 By Radu Muresan University of Guelph Page 14 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 realtime 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.

15 CHAPTER 3 By Radu Muresan University of Guelph Page 15 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 realtime 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.

16 CHAPTER 3 By Radu Muresan University of Guelph Page 16 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 The cfp 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.

17 CHAPTER 3 By Radu Muresan University of Guelph Page 17 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.

18 CHAPTER 3 By Radu Muresan University of Guelph Page 18

19 CHAPTER 3 By Radu Muresan University of Guelph Page 19 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.

20 CHAPTER 3 By Radu Muresan University of Guelph Page 20 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).