CHAPTER 3 By Radu Muresan University of Guelph 3 LECTURE 3.pdf · CHAPTER 3 By Radu Muresan University of Guelph Page 7 . SHARED RESOURCES ‐‐MEMORY MANAGEMENT The LabVIEW Real‐Time

IMPROVING THE DETERMINISM OF THE APPLICATIONChoose appropriate hardware•Avoid shared resources•Avoid contiguous memory confilicts•Avoid subVI overhead•Disable non‐essential options•Use only one time‐critical loop in an application•

The easiest way to improve the determinism is to choose a faster hardware platform. If you are unable to achieve a desired loop rate, first check your hardware to be sure it is capable of reaching the required rate.

•

If your hardware rates are acceptable, you can improve the determinism of your application in software by avoiding shared resources, contiguous memory conflicts, and subVI overhead. Because the LabVIEW Real‐Time Module Memory manager is a shared resource, using memory reduction techniques also helps to improve the determinism of an application.

•

We have seen that it is suggested to use only one time‐critical loop in one application because when a time‐critical loop goes to sleep, the entire thread goes to sleep. Next we explain programming methods for improving determinism.

•

ENGG4420 ‐‐ CHAPTER 3 ‐‐ LECTURE 3November‐01‐107:26 PM

CHAPTER 3 By Radu Muresan University of Guelph Page 1

SHARED RESOURCESA shared resource in the LabVIEW Real‐Time Module is anything that can only be used by one process at a time

•

Global variables; real‐time module memory manager; networking code (TCP/IP, UDP, VI server); shared variables; non‐reentrant subVIs; semaphores; file I/O.

○LabVIEW RT shared resources include the following:•

Certain data structures, driver libraries, and variables only can be accessed serially, one process at a time. A simple example of a shared resource common to all programming languages is the global variable. You cannot access global variables simultaneously from multiple processes. Therefore, compilers automatically protect the global variables as a shared resource while one process needs to access it. Meanwhile, if a second process tries to access the global variable while it is protected, the second process must wait until the first process has finished with the global variable.

•

Understanding shared resources and how to identify them it is an important skill when programming real‐time applications.

•

These operations are inherently non‐deterministic. Never use them inside a time‐critical priority loop if you are attempting to achieve real‐time performance.

•


SHARED RESOURCES

Running WaitingShared

Resource

Process 1 Process 2

Waiting RunningShared

Resource

Process 1 Process 2

Before a process can begin using a shared resource, it must obtaina mutual exclusion (mutex)

After Process 1 finishes, Process 2 proceeds

For our purposes a shared resource is defined as a software object that can run only one thread at a time. In this example, assume both processes constantly must access the shared resource. Process 1 runs at normal priority, while Process 2 runs at time‐critical priority.

•

Normally, when a time‐critical thread needs to execute, it preempts all other code running on the real‐time target; however, a normal priority thread can block the time‐critical thread if it has not released a mutex that the time‐critical thread needs. This is known as a priority inversion because the real‐time OS cannot allow the time‐critical thread to preempt the normal priority thread, merely because of the mutex around a shared resource.

•

A mutex is mutual exclusion object that allows multiple threads to synchronize access to a shared resource. A mutex has two states: locked and unlocked. After a thread locks a mutex, other threads attempting to lock it will block. When the locking thread unlocks (releases) the mutex, one of the blocked threads acquires (locks) it and proceeds.

•


SHARED RESOURCES ‐ PRIORITIES

Time-Critical Priority waitingPriority inversion: Normal priority VI blocks the higher priority VI with a mutex around the shared resource.

Normal Priority runningPriority ineritance: Normal priority VI inherits higher priority to release mutex.

In this example, the shared resource is a global variable, which is shared by two VIs – one set to normal priority and one set to time‐critical priority.

•

Allowing the lower priority thread to temporarily inherit the time‐critical priority setting long enough to finish using the shared resource and to remove the protection.

a.

After the protection is removed, the lower priority thread resumes its original lower priority setting and is taken off of the processor.

b.

Now the time‐critical priority thread is free to proceed and use the resource, that is, access the global variable.

c.

The real‐time OS uses a method called priority inheritance to resolve the priority inversion as quickly as possible, by doing the following:

A result of this priority inversion the task jitter in the time‐critical priority thread is increased. However, the jitter induced by a protected global variable is small compared to the jitter induced by protecting the LabVIEW Memory Manager. Unlike accessing global variables, performing memory allocations is unbounded in time and can introduce a broad range of software jitter while parallel operations try to allocate blocks of memory in a wide variety of sizes. The larger the block of memory to be allocated, the longer the priority inheritance takes to resolve the priority inversion.

•


SHARED RESOURCES ‐ SubVIs

Configure a subVI for reentrant execution if unrelated parallel processes call the subVI – allows several instances of a subVI to be called simultaneously.Reentrant subVIs do NOT act like global variables.

Sharing subVIs causes priority inversions the same way global variables do. When a subVI is set to subroutine priority, that subVI can be skipped within time‐critical code to avoid software jitter that would have occurred from a priority inversion. However, if you run unrelated parallel processes that call the same subVI, you can configure the subVI for reentrant execution.

•

A reentrant subVI establishes a separate data space in memory each time it is called. A reentrant subVI allows LabVIEW RT to call several instances of a particular subVI simultaneously. Because reentrant subVIs use their own data space, you cannot use them to share or communicate data between threads. You should only use reentrancy when you must simultaneously run two or more instances of a subVI within unrelated processes that do not need to share data within the reentrant subVI.

•

To configure a subVI for reentrancy, select VI Properties >> Execution, and then select the Reentrant Execution checkbox.

•


SHARED RESOURCES ‐MEMORY MANAGEMENT

The user does not explicitly have to allocate or de‐allocate memory

○

This means memory management is easy, but harder to control

○

The LabVIEW Real‐Time Module manages memory automatically

•

You must control memory allocations to avoid shared resource conflicts with the memory manager

○

You statically allocate memory before time‐critical process begins.

○

The LabVIEW Real‐Time Module has a memory manager that is a shared resource

•

The LabVIEW Real‐Time Module has memory manager that automatically allocates and deallocates memory at run time. Allocating memory can consume a significant amount of CPU time, depending on the amount of memory needed.

•

The memory manager may already be mutexed by, causing a shared resource conflict.

○

Even if the memory manager is immediately available, allocating memory is non‐deterministic because there is no upper bound on the execution time of the malloc( ).

○

If you allow the LabVIEW Real‐Time Module to dynamically allocate memory at run time, your application could suffer from software jitter for the following reasons:

•


PREALLOCATE ARRAYS

Avoid allocating arrays within a time-critical loop

Avoid allocating memory within a time‐critical VI control loop.

•

For example, instead of using Build Array within your loop to index new data into an array, use Replace Array Subset to insert new array values into preallocated arrays.

○

If you are using arrays in time‐critical VI control loops, you can reduce jitter by preallocating arrays before entering the loop.

•


SHARED RESOURCES ‐‐MEMORY MANAGEMENT

The LabVIEW Real‐Time Module memory manager is a shared resource,

○

All memory allocations must be removed from the time‐critical loop to guarantee robust, hard real‐time perf.,

○

Preallocate arrays outside of the time‐critical loop,○Cast all data to the proper data type,○Use inplaceness when possible to reuse memory buffers,○Reduce the use of global variables.○

Key points about memory management and real‐time•

In general, memory allocations within a time‐critical loop induce jitter and effect the deterministic properties of a LabVIEW Real‐Time Module program. All memory allocations must be removed to guarantee robust hard real‐time performance. You must preallocate your arrays outside of the loop if you want your application to run deterministically. Certain LabVIEW Real‐Time Module functions allocate memory, such as Build Array and Bundle.

•

Cast data to the proper data type in VIs running on the RT target. Each time LabVIEW performs a type conversion, LabVIEW makes a copy of the data buffer in memory to retain the new data type after the conversion. The LabVIEW Memory Manager must allocate memory for the copy, which might affect the determinism of time‐critical VIs. Also, creating copies of the data buffer takes up memory resources on an RT target. Refer to the LabVIEW Help for more information about casting data types. Use the smallest data type possible when casting the data type. If you must convert the data type of an array, do the conversion before you build the array.

•

Also, keep in mind that a function output reuses an input buffer only if the output and the input have the same data type – representation, size, and dimension. Arrays must have the same structure and number of elements for function outputs to reuse the input buffer. This ability for a function to reuse buffers is called inplaceness.

•

LabVIEW creates an extra copy in memory of every global variable you use in a VI. Reduce the number of global variables to improve the efficiency and performance of VIs.Creating copies of the global variable takes up memory resources on an RT target.We don’t discuss all types of shared resource. Avoid semaphores, TCP/IP, UDP, VI Server, and File I/O function within a time‐critical loop. These functions are inherently non‐deterministic and use shared resources. For example, semaphores are themselves shared resources, network functions use the Ethernet driver, and file I/O functions use the hard disk. These functions can introduce severe software jitter in time‐critical code on account of priority inversions. Also, be aware that all handshaking protocols are non‐deterministic. Do not run GIPB, RS‐232, TCP/IP at time‐critical priority. DAQ handshaking protocols are non‐deterministic and avoid using them in time‐critical loops, such as burst mode and 8255 emulation mode on the 653x devices.

•


AVOID CONTIGUOUS MEMORY CONFLICTS

RTOSRT Engine

RTOSRT Engine

RTOSRT Engine

RTOSRT Engine

ArrayMaker.vi ArrayMaker.vi ArrayMaker.vi

Array 1 Array 2

Array 3

1 2 3 4

Preallocate array space equal to the largest expected array size

Same memory space is used for new arrays smaller than Array 1

Because Array 3 is larger than Array 1, other contiguous memory space must be found

LabVIEW handles many of the memory details that you normally handle in a conventional, text‐based language. For example, functions that generate data must allocate storage for the data. When the data is no longer needed, LabVIEW deallocates the associated memory. When you add new information to an array or a string, LabVIEW allocates new memory to accommodate the new array or string. However, running out of memory is a concern with VIs running on an RT target.

•

You must design memory‐conscious VIs for RT targets. Always preallocate space for arrays equal to the largest array size that you might encounter. When you reboot or reset an RT target, the RTOS and the RT Engine load into memory as shown in fig. 1. The RT Engine uses available memory for running RT target VIs and storing data. In Fig. 2, ArrayMaker.vi creates Array 1. All elements in Array 1 must be contiguous in memory.

•

The RTOS reuses the same memory addresses if you stop a VI and then run it again with arrays of the same size or smaller. If Fig. 3, ArrayMaker.vi creates Array 2. The RTOS creates Array 2 in the reserved memory space that was allocated to Array 1. Array 2 is small enough to fit in the reserved memory space that was allocated to Array 1. The extra contiguous memory used for Array 1 remains in the reserved memory space, as shown in Fig 3.

•

When ArrayMaker.vi runs for a third time with a larger array or if another VI generates a larger array, the RT Engine must find a large enough contiguous space. In Fig. 4, ArrayMaker.vi must create Array 3, larger than the previous arrays, in the available memory.

•

Even when ArrayMaker.vi stops running, the RT Engine continues to run. Previously reserved memory is not available. If ArrayMaker.vi runs a fourth time and attempts to create an array larger than Array 3, the operation fails. There is no contiguous memory area large enough to create the array because of the memory fragmentation. You can preserve memory space by preallocating array space equal to the largest use case.

•


AVOID SubVI OVERHEADEach subVI involves a small amount of overhead,•subVI overhead can be significant if you place the subVI inside a looping structure,

•

Place the looping structure, if possible, inside the subVI instead.

•

Calling a subVI from a VI running on an RT target adds a small amount of overhead to the overall application. Although the overhead is small, calling a subVI multiple times in a loop can add a significant amount of overhead. You can embed the loop in the subVI to reduce the overhead.

•

The overhead involved in calling a subVI increases depending on the amount of memory that needs to be copied by the memory manager.

•

You also can convert subVIs into subroutines by changing the VI property. The LabVIEW execution system minimizes the overhead to call subroutines. Subroutines are short, frequently executed tasks that generally do not require user interaction. Subroutines cannot display front panel data and do not multitask with other VIs. Also, avoid using timing or dialog box functions in subroutines.

•


DISABLE NON‐ESSENTIAL OPTIONSTo reduce memory requirements and increase performance of VIs, disable nonessential options in the VI Properties dialog box available by selecting File >> VI Properties. Select Execution from the Category pull‐down menu and remove check marks from the Allow debugging and Auto handle menus at launch checkboxes. By disabling these options, VIs use less memory, compile more quickly, and perform better.

•

Note. The LabVIEW Real‐Time Module ignores the Enable automatic error handling option.

•

AVOID EXPRESS Vis TO REDUCE JITTERLabVIEW Express VIs increasde LabVIEW ease of use and improve productivity with interactive dialog boxes that minimize programming for measurement applications. Express VIs require additional performance overhead during execution.

•

Therefore, do not use Express VIs in time‐critical or processor‐intensive applications. Instead, develop real‐time applications with standard LabVIEW VIs. Refer to the Getting Started with LabVIEW manual for more information about LabVIEW Express VIs.

•


PASSING DATA BETWEEN THREADS

Inter-Thread Communication Methods Good: Global Variables

Better: Functional Global Variables

Best: Real-Time FIFO VIs, Shared-Variable FIFOs

Normal PriorityLoop

Time-CriticalLoop

Inter-ThreadCommunication

Target Program

After dividing tasks in an application into separate VIs of varying priorities, you might need to communicate between the different VIs on the RT target. You can use the following to send and receive data between VIs or loops in an application:Global variables•Functional global variables•Single‐process shared‐variables•LabVIEW Real‐Time Module FIFO VIs


GLOBAL VARIABLES ‐‐ GOOD

Can cause jitter, because they are a shared resource

Lossy – A global variable may be written to many times before being read.

Good for scalar data (<32 bits)

Normal PriorityLoop

Time-CriticalLoop

Global Variables

Target Program

A global variable is a location in the memory that multiple VIs can access. While global variables are easier to program, they are not the ideal method for transferring large amounts of data.

•

Using a global variable can be a good way to pass data smaller than 32‐bits, such as scalar data, between VIs. However, global variables are a lossy form of communication, meaning the global variable can be overwritten before the data is read. Tasks in a lower priority VI might not have enough processor time to read the data before other tasks in a different VI overwrite the data.

•

Using global variables in time‐critical priority VIs in LabVIEW Real‐Time can compromise determinism. A global variable is a shared resource. If one piece of code accesses a global variable, no other piece of code can access the global variable until the first piece releases the global variable. When you block the access of a time‐critical VI to a global variable, forcing the time‐critical VI to wait, you introduce jitter to the application and compromise the determinism of the application.

•


FUNCTIONAL GLOBAL VARIABLE (FGV) ‐ BETTER

Normal PriorityLoop

Time-CriticalLoop

FunctionalGlobal Variable

Target Program

CHARACTERISTICSCan have several inputs and outputs; can skip if busy; can be lossy.

•

You can avoid jitter due to resource contention by using a functional global variable, setting it to subroutine priority, and selecting the Skip Subroutine Call if Busy option for it. With a functional global variable (FGV), the time‐critical VI must not access the global if another section of code is already using the global variable. Skipping a subVI helps in time‐critical VIs, because the VI does not wait for the subVI.

•

If you skip the execution of a subVI, the subVI returns the default value for data type and not the default indicator value. For example, the default data type value for numerics is zero, strings and arrays default to an empty string, and Boolean values default to FALSE. If you want to detect the execution of a functional global variable, wire a TRUE constant to a Boolean output on the functional global variable block diagram. If the Boolean output returns the default value of FALSE, the functional global variable did not execute.

•

Skip functional global variables in time‐critical VIs but not in lower priority VIs. In lower priority VIs, you can wait to receive non‐default values.

•

Functional global variables can be a lossy form of communication, if a VI overwrites the shift register data before another VI reads the data.

•


FUNCTIONAL GLOBAL VARIABLES ‐‐ EXAMPLE

Demo: NI Example FinderToolkits and Modules >> Real-Time >> Multithreaded Communication>> Functional Global Communication

In a FGV, the subVI contains a While Loop with a nested Case structure for read and write access. The above figure shows the read (get data) case and one of the write (set data) cases of the Case structure for a FGV.

•

The While Loop contains uninitialized shift registers that store data. A FGV receives an action input parameter that specifies which task the VI performs as shown in this figure by the Operation input parameter. Any subsequent calls to the FGV can access the most recent data.

•

FGV expand functionality beyond a simple global variable. For example, you can maintain a history of values in a FGV or you can set a switch to latched until read.

•


REAL‐TIME FIFO Vis ‐ BEST

Normal PriorityLoop

Time-CriticalLoop

Real-Time FIFO VIs

Target Program

CHARACTERISTICSCan specify buffer size; are lossy if buffer fills up; warn of data loss; use deterministic data transfer.

•

Use the RT FIFO VIs to transfer data between VIs in an application. An RT FIFO acts like a fixed queue, where the first value you write to the FIFO is the first value that you can read from the FIFO. RT FIFOs and LabVIEW queues both transfer data from one VI to another. However, unlike a LabVIEW queue, an RT FIFO ensure deterministic behavior by imposing a size restriction on the data. You must define the number and size of the RT FIFO elements. Both a reader and writer can access the data in an RT FIFO at the same time, allowing RT FIFOs to work safely from within a time‐critical VI.

•

Because of the fixed‐size restriction, an RT FIFO can be a lossycommunication method. Writing data to an RT FIFO when the FIFO is full overwrites the oldest element. You must read data stored in an RT FIFO before the FIFO is full to ensure the transfer of every element without losing data. Check the overwrite output of the RTFIFOWrite VI to ensure that you did not overwrite data. If the RT FIFO overwrites data, the overwrite output returns a TRUE value.

•

A larger FIFO gives the normal priority loop more time to catch up if it falls behind, which can help avoid FIFO overwrites. However, setting a FIFO to be too large wastes memory.

•


REAL‐TIME FIFO VIs

Create RT FIFOs for sending and fetching data. Control Data FIFO sends the type of waveform we want to generate, the amplitude of the waveform, and the time-critical loop rate. Result Data FIFO receives points of the waveform.

Demo: NI Example FinderToolkits and Modules >> Real-Time >> Communication >> RT FIFO Comm.

Use the RTFIFOCreate VI to create a new FIFO or open a reference to a FIFO that you created in another VI. Use the RTFIFORead and RTFIFOWrite VIs to read and write data to the FIFO.

•

Refer to the LabVIEW Help, available by selecting Help >> VI, Function, & How‐To Help, for VI reference information about the Real‐Time FIFO VIs and the data types supported by the Real‐Time FIFO VIs.

•


SHARED VARIABLESShared variables are a multipurpose communication tool you can configure to perform many tasks

•

Transfer non‐deterministic data between VIs. In this capacity, a shared variable functions much like a global variable. This type of shared variable is called a single‐process, shared variable.

○

Transfer non‐deterministic data between a target and a host. This type of shared variable is a network‐published shared variable, usually with the Real‐Time FIFO option enabled.

○

Transfer non‐deterministic data between hosts or between a host and other computers. Shared variables implement a publisher/subscriber model that allows non‐real‐time computers to communicate across a network. This type of shared variable is called a network‐published shared variable.

○

Transfer deterministic data between Real‐Time VIs or loops (Real‐Time FIFO). Shared variables can implement a Real‐Time FIFO to transfer data between loops on an RT target. This variable is usually a single‐process shared variable with the Real‐Time FIFO option enabled.

○

For more information, refer to the Using Time‐Triggered Networks to Communicate Deterministically Over Ethernet with the LabVIEW 8 Real‐Time Module document in the NI Developer Zone. To view the document visit ni.com/info and enter rduttl.

Transfer deterministic data between targets. With a dedicated network connection, shared variables can deterministically transfer data between two or more real‐time targets over a network. This type of variable is called a Time‐Triggered shared variable.

○

Shared variable can transfer the following:•


CREATING AND USING SHARED VARIABLESRight‐click project or library to create a variable•Shared Variable Properties dialog box allows you to configure the type of the shared variable and any other options.

•

Used much like a local or global variable on the block diagram except: SV have error terminals; SV configured for read can return a timestamp

•

Items in the project tree represent shared variables. In order to create a shared variable, right click a target or library and select New >> Variable. All variables must exist inside of a library. If you create a new variable outside of a library, LabVIEW automatically creates a library. When you create a shared variable, LabVIEW displays a Shared Variable Properties dialog box that allows you to configure the type of shared variable and any other options such as buffering and Real‐Time FIFO.

•

To use a shared variable on the block diagram, drag the shared variable from the Project Explorer window to the block diagram. Shared variable references on the block diagram work much like local or global variables. You can right‐click a shared variable and select Change to Read or Change to Write to change the direction of the variable. Unlike local or global variables, shared variables contain additional terminals along with the data. Each shared variable has error in and error out terminals, and shared variables set to read can return the timestamp at which the data was written. To display the timestamp, right‐click the variable and select Show Timestamp.

•


SHARED VARIABLE REAL‐TIME FIFOs

By enabling the Real-Time FIFO option on a single-process shared variable, you can create a variable which uses Real-Time FIFOs to transfer data

When you enable the Real‐Time FIFO option, LabVIEW uses Real‐Time FIFOs to transfer the data that is written to and read from the shared variable.

•

You can configure the FIFO to be single or multi‐element and define the size of the FIFO. When you enable the Real‐Time FIFO option, a small icon appears on references to the variable to indicate that it uses Real‐Time FIFOs.

•


PROGRAMMING TECHNIQUES ‐‐ INITIALIZATION

The FIFO is created the first time a variable is read or written Create and

initialize the FIFO by writing a meaningful value to it before your main loop

Or allow for extra jitter in the first iteration of a loop using variables

Reading the FIFO before a value is written returns error -2222 and a default data value Use the error to check for un-initialized variables

Shared‐variable FIFOs are created the first time a variable is read or written. This results in a slight delay. Therefore, either initialize the variable by reading or writing it before your main loop or allow for a delay in the first iteration of your loop as the FIFO is created.

•

If you read the value of a shared variable before it has been written to in the program, LabVIEW returns error ‐2222 and the default value for the data type. You can use this error to determine whether the value read is a valid data point, or whether it is the default value.

•

Alternately, if you initialize the variable by writing a meaningful value before starting the loop, you can avoid the possibility of reading the variable before it is written.

•


PROGRAMMING TECHNIQUES ‐‐ IDENTIFYING OVERFLOW AND UNDERFLOW

Multi‐element RT FIFOs have a fixed memory size and a fixed number of elements, which can be configured in the variable properties dialog. Therefore, multi‐element shared variable RT FIFOs introduce the possibility for overflow and underflow errors.

•

An overflow error occurs when a shared variable reference attempts to write to an RT FIFO that is already full. When an overflow occurs, the shared variable returns error ‐2221 and overwrites the oldest value in the FIFO with the new value. The oldest value is permanently lost.

•

An underflow error occurs when a shared variable reference attempts to read an empty RT FIFO. When an underflow occurs, the shared variable returns error ‐2220 and returns a default value for the data item. Note that this is different from error ‐2222, which only applies if a variable has never been written to. Also, error ‐2220 applies only to multi‐element FIFOs, whereas error ‐2222 applies to all shared variables.

•


PROGRAMMING TECHNIQUES ‐‐MULTIPLE READERS AND WRITERS

Multiple readers and writers block other operations of the same type

Multiple readers of a multi-element FIFO will each remove elements, preventing either reader from getting all of the data

Only a single reader and a single writer can access a shared variable at the same time. If a single variable has multiple readers and writers, the readers and writers alternate in accessing the variable like any other resource. Variable references waiting on another reader or writer are blocked and do not continue block diagram execution.

•

Because variables can block with multiple readers or writers, you should use caution when using variables in a time‐critical loop. A variable read by a time‐critical loop must not be read by any other loop and a variable written by a time‐critical loop must not be written by any other loop. Failure to follow these rules can cause the time‐critical loop to block and become non‐deterministic.

•

Multi‐element FIFOs with multiple readers only return each value in the FIFO once. Therefore, if each reader needs to access all of the values written to the FIFO, use a separate variable for each reader.

•


LOW‐LEVEL FIFO Vis vs. SHARED VARIABLE FIFOs

Shared Variable FIFO Low-Level FIFO VIs

Configuration Static Dynmic

Performance Write operations must store timestamps

Faster write operations

Programming Easier configuration and general operations

Easier dynamic configuration changes

Features Timestamp available, can be easily changed to other variable types

Compatible with LV 7.x and earlier

Shared variables store the timestamp of each piece of data they receive, this makes write operations slightly slower than the low‐level FIFO VIs.

•

Shared variable FIFOs can be changed to other shared‐variable types. For example, without any significant changes to the block diagram code, a single‐process shared variable FIFO can be changed into a network‐published shared variable FIFO to communicate with the host.

•

Shared variables debuted in LabVIEW 8.0. Real‐Time FIFOs are backwards compatible with previous LabVIEW versions.

•


STATIC vs. DYNAMIC CONFIGURATION

Shared Variable FIFOs are configured statically using dialog boxes Simplify programming and

wiring Conserve block diagram space

Low-level FIFOs are configured dynamically using block diagram code Simplify visually inspecting

block diagram Simplify modifying

configuration while the program is running

Improves control over when the FIFO is created and dstroyed

Shared variables are configured statically. This means that the properties of a shared variable are defined through interactive dialog boxes as you write your program, rather defining them at run‐time as shared variables are defined for dynamically configured entities such as a Real‐Time FIFO.

•

Static configuration simplifies the programming and conserves space on your block diagram. You do not need to create controls and constants for each configuration option. Variables, also do not require reference wires that can keep your diagram cleaner. In general, you must know the value of all variable properties before running the program, this means that user input or acquired data cannot determine the value of properties. You can configure some shared variable properties dynamically through VI server calls, but this requires significant programming.Dynamic configuration allows you to specify configuration settings as the program is running. For example, you can set the size of the FIFO based upon user input or by calculating loop frequencies. You can also destroy and re‐create a FIFO with new properties as a program is running. For example, you could destroy the FIFO and create a new FIFO with a larger size if overflow errors happen consistently. The ability to create and destroy the FIFO is useful for managing memory in systems where memory is limited. Dynamic configuration also simplifies determining the properties of the FIFO by inspecting the block diagram.

•


Documents

CHAPTER 3 By Radu Muresan University of Guelph 3 LECTURE 3.pdf · CHAPTER 3 By Radu Muresan University of Guelph Page 7 . SHARED RESOURCES ‐‐MEMORY MANAGEMENT The LabVIEW Real‐Time