Int. J. Engng Ed. Vol. 16, No. 2, pp. 000±000, 2000 0949-149X/91 $3.00+0.

00
Printed in Great Britain. # 2000 TEMPUS Publications.

Introduction to Real-time Control

using LabVIEWTM with an Application
to Distance Learning*
Ch. SALZMANN, D. GILLET, and P. HUGUENIN
Swiss Federal Institute of Technology Lausanne, Switzerland. E-mail: christophe.salzmann:epfi.ch
This paper presents the approach taken to give engineering students the necessary competencies and
facilities to implement real-time control solutions. This goal is achieved first by way of an
introduction to the basic principles underlying real-time control. Then, by motivating the use of
personal computers as a versatile alternative to more traditional implementation equipment.
Finally, by combining LabVIEW and DAQ boards to form an integrated framework for fast
prototyping of real-time control solutions. Control algorithms written in G (the graphical
programming language of LabVIEW), in C or as S-functions (MATLAB scripts describing
SIMULINK dynamical models) can be validated on laboratory-scale processes. The possible real-
time control and monitoring of ongoing operations, either locally on the host computer or remotely
via the Internet, is a key feature from an educational point of view. In fact, the chosen paradigm
truly enable the `learning by doing' approach. Moreover, this practical activity can be carried out at
any time from anywhere to efficiently support automatic control study.

INTRODUCTION LabVIEWTM and DAQ boards. This implementa-

tion paradigm based on personal computer and
FEEDBACK CONTROL LOOPS are imple- standard operating systems constitutes a new trend
mented to increase dynamical performance or in automation. It allows the user to avoid such
precision of scientific and industrial equipment. aged, specialised or expensive solutions as analog
The basic principle of such loops is to take into PID loops, programmable logic controllers (PLC)
account actual measurements in order to compute or dedicated hardware based on digital signal
appropriate actuations that adjust the operational processors (DSP).
conditions to meet given requirements. Motion To stress the advantage of the above-mentioned
control and process control are two major appli- open paradigm, the students are provided with an
cation areas of this paradigm. Due to this integrated framework versatile enough to be
broad application field and its interdisciplinary quickly adapted to their different needs and back-
nature, Automatic Control is a fundamental grounds. This solution reduces the additional
subject usually taught in many engineering knowledge required to proceed with the imple-
disciplines, such as electrical, mechanical and mentation and helps students focus on essential
chemical engineering. concepts. To be attractive to the students, the
Practical experimentations are made during framework needs to be highly interactive and
laboratory sessions where students can try out on offer a well-designed graphical user interface.
real processes the material they learn during the The recent increase in availability of personal
class [1]. As a matter of fact, implementing a computers at home and on campus has allowed
complete control solution from scratch requires students to exploit computer-aided instruction
knowledge not only of the matter studied but (CAI) tools to learn in their own way and at
also of the different technologies needed to inter- their own pace. Unfortunately, such independent
face the real process, such as sensors and actuators, work is not possible on laboratory-scale processes
to the computer used to conduct the experiment. since these cannot be moved easily or duplicated in
Computer knowledge such as hardware interfacing sufficient numbers. Therefore, experimental work
and real-time programming are also needed to is done in the laboratory according to a predefined
carry out the experiment. Fundamentals of all schedule.
these aspects should be taught to students in Both the recent developments in the Internet
automatic control. and the introduction of the World-Wide-Web
Acquisition of measurements and modification (WWW) are opening the ways to interactive
of actuations are the usual tasks carried out by presentations, even remote access opportunities
to real-world equipment. The availability and the
capabilities of these new communication facilities,
* Accepted 9 September 1999. combined with the generalisation of computer use

1
2 Ch. Salzmann et al.

Fig. 1. Data acquisition and processing sequence. The AI_MULT_PT VI acquires a stream of data coming from the radar, these data are
then processed (FFT) in one pass and displayed.

for data acquisition and control of real processes, accordingly with the evolution of a physical
enable the students to move from a presence at system. If necessary, the system-state is made
the equipment location to a more versatile tele- available to the computer through appropriate
presence, thereby allowing remote experimentation. interfacing devices, such as sensors and converters.
This paper discusses the necessary competencies The notion of real-time control reinforces the
and facilities to implement real-time control solu- original definition by specifically emphasising
tions, either in traditional education or in distance actions carried out in addition to observations.
learning. An example of ditributed applications These notions can be illustrated by comparing
using LabVIEW is given, where an electrical data acquisition and processing (Fig. 1) with real-
drive is introduced as convenient setup to study time control (Fig. 2). There are two main dif-
locally or remotely applications in motion control. ferences. In the former case, a finite number of
This example serves as illustration throughout acquisition cycles are performed to provide a
the paper. The advantages and the potential of stream of data for post processing operations. In
local and remote experimentation supported by the latter case, continuous operation cycles are
LabVIEW are expressed as conclusions. performed. During these cycles only one data
sample is acquired and immediately processed.
Moreover, in contrast to data acquisition,
control operations require actuation values to be
FUNDAMENTALS OF REAL-TIME computed and written to output ports at every
CONTROL cycle. This removes the possibility of performing
batch processing based on the data stored in an
The notion of real-time implies that computer acquisition buffer (if there is any).
operations rely on absolute and irreversible Appropriate actuators and amplifiers interfaced
time. These operations are generally performed with the output ports enable the computer to drive

Fig. 2. Control cycle. The position of the robot arm read by the AI_ONE_PT VI is compared, within the controller (PID VI), to the
reference value. The AO_ONE_PT VI writes the controller command in the output, thus closing the loop. This operation is performed at
each loop iteration.
 Introduction to Real-time Control using LabVIEW with an Application to Distance Learning 3

Fig. 3. Feedback structure. (1) The measurement is converted into a number (2) and compared to a reference value (3) within the
controller. The resulting command (4) is converted to an analog signal (5) applied to the physical system.

the physical system with the necessary amount of To allow the use of the traditional control
energy. analysis and design techniques, the sampling
periods are assumed to be constant. In other
Implementation constraints words, the cadence at which the real-time tasks
Figure 3 presents the standard structure for a are called must be as regular as possible. This is
feedback loop. The output of the controller drives generally guaranteed by interruptions. Interrup-
the input of a physical system, whereas the output tions are generated either by an on-board timer
of the physical system is reintroduced as the input (host computer) or by an external source located
for the controller, thus closing the loop. To on the acquisition device (Fig. 4). These inter-
guarantee an efficient and reliable control, some ruptions tell the operating system (OS) to switch
implementation constraints must be taken care of. from the current task to the real-time tasks
The operations performed by the controller have according to their respective priority. Once the
to comply with a standard sequence. The first real-time tasks are completed, the OS resumes
operation performed is the measurement and the the original task.
analog-to-digital conversion of the input signal (1). The cadence is mainly limited by the under-
Once converted into a digital number (2), this lying OS. Most of today's OSs only partially
value is compared to a reference value (3) resulting support real-time operations and therefore
in an error signal which is used by the control accurate cadence cannot always be guaranteed.
algorithm to compute the command or output The use of specialized OSs, dedicated processors
value (4). Other quantities may also be computed or embedded systems are required for mission-
depending on the application (such as parameters critical implementations where, for example,
or state estimates). The output value is then people or equipment safety must be guaranteed.
converted to an analog signal (5) and applied to The accumulated duration of the real-time
the controlled system. This sequence of operations operations should be smaller than the sampling
forms a real-time task (RTT), which is repeated period for obvious roll-back reasons.
at a fixed interval, called the sampling period or The time between the occurrence of the inter-
the cycle time. In advanced applications, the ruption and the launch of the real-time tasks is
implementation of different real-time tasks with called the latency. This time is variable and OS
different sampling periods and priorities may be dependent but should be much smaller than the
required. The sampling period must be adapted to sampling period.
the dynamics of the physical system. If the sampling Under tight time constraints, the real-time tasks
period is too large, the control of the system will be (RTT) are generally monitored by a supervision
lost and if it is too short, quantisation problems task (ST). The supervision task has a lower priority
may occur. than RTT and runs asynchronously. The ST

Fig. 4. Interruption cycle. The Interruption triggers the signal acquisition and tells the OS to switch from the current task to the RT
task. The time between the interruption and the execution of the RT tasks is called the latency.
4 Ch. Salzmann et al.

Fig. 5. Data sharing principle. The RT task loop reads the input, executes the control algorithm (PID), writes the output and saves one
position in the circular buffer at each sampling period. The supervision task uploads the whole buffer in one operation and displays its
content. It also updates the RT task parameters.

performs all the functions that are not time depen- allows interaction between the user and the
dent such as managing the user interface. The running controller.
ST exchanges data with RTTs through a circular The classical trial and error learning approach
buffer (Fig. 5). The RTTs update one position of implies that successive changes should be made in
the buffer at each interruption, on the other hand the control algorithm before getting the required
the ST uploads the all buffer in one operation. The or desired dynamical performance. This can be
cycle time of the supervision task is generally much developed using a fast prototyping environment
longer than the cycle time of RTT. where the design-implementation-test cycle should
When the user wants to modify a RTT para- be as short and as integrated as possible.
meter, the RTK must reflect this modification in The use of a software-only solution guarantees a
real-time (interactivity). The user parameters are low price and a great expendability. Moreover,
transmitted asynchronously by the ST to the RTT remote experimentation, presented later, relies on
through a buffer. This asynchronous buffer is not a software-only solution for the distant users.
updated at each interruption, but only when a
parameter is modified.
FUNDAMENTALS OF PID CONTROLLER
Requirement for real-time control in education
The real-time control capabilities required in Typical controllers are implemented as numeri-
education are generally reduced compared to cal algorithms that are designed to compute, at
industrial applications, mainly because laboratory every sampling time tk ˆ kh (where h is the
experiments only show one aspect of the theory at sampling period and k is the sample index), a
a time. Usually, only one physical system is correction factor u…k† which is added to the
controlled and only one real-time task is sufficient, nominal excitation of the controlled process. The
such as open-loop measurement, identification or nominal excitation is a predefined signal based on
closed-loop control. a priori knowledge and issues to bring the process
To minimize the time spent by the students in to desired operation conditions or to track given
the laboratory, the application should be well trajectories. The correction is necessary to both
designed and well integrated within the environ- handle unexpected disturbances which affect the
ment. The user interface should be of high quality. dynamic behaviour of the controlled process and
This might be different from industrial products to cope with the unavoidable imprecision of the
where the GUI is less important in the exploitation nominal excitation.
phase. As a consequence, enough processor time The most commonly used controller is called
should be reserved for the supervision task which the PID. The corresponding algorithm issues a
 Introduction to Real-time Control using LabVIEW with an Application to Distance Learning 5

Fig. 6. Time evolution of the error used by the PID controller.

correction according with the time evolution of stronger to avoid overshoots. Such an action is
the actual error e…k† existing between the desired obtained by introducing a last term UD …k† which is
and the measured output of the controlled proportional to the derivative (D) of the error
process, respectively denoted yc …k† and y…k†. signal computed using the last two available
The acronym PID is due to the way the correc- samples.
tion is computed. The first term uP …k† of the
correction is proportional (P) with the current e…k† ÿ e…k ÿ 1†
uD …k† ˆ KP TD …3†
error: h

uP …k† ˆ KP e…k† …1† Finally,

u…k† ˆ uP …k† ‡ uI …k† ‡ uD …k† …4†
The second term uI …k† takes into account the
error history in order to cancel out an eventual In equations 1, 2 and 3, the factors KP , TI and TD
bias. To avoid the storage of all previous are the tuning parameters defining the behaviour
samples, the past behaviour is summarised using of the closed-loop system.
the integral (I) of the error signal. In the discrete It is essential to underline that the PID described
case, the integral can be evaluated in various ways. in this chapter is purely discrete, which is the right
The method chosen is the sum of the trapezoidal form for a computer implementation. Rigorous
areas obtained by linking the successive error techniques based for example on the Z-transform
values (Fig. 6). can be applied for analysis and design purposes [2].
  However, it is often sufficient to carry out a single
1 e…k† ‡ e…k ÿ 1† open-loop experiment on the physical system to be
uP …k† ˆ uI …k ÿ 1† ‡ KP h
TI 2 controlled to get a convenient set of parameters.
…2† The idea is to apply a step of level U as an
excitation signal of the system (Fig. 7). The corre-
In addition, the correction has to take into sponding variation of the output provides the
account the speed of the error evolution. If the slope a at the inflection point (or at infinity if the
error varies quickly, the correction has to be response reaches no stationary value) and the time

Fig. 7. Step response of the system to be controlled.

6 Ch. Salzmann et al.

Table 1. Parameters of the P, PI or PID controller. using LabVIEW (National Instruments propose a
PID toolkit with autotuning). The first solution is
Controller KP TI TD
a plain LabVIEW implementation written in G.
The next two solutions combine LabVIEW with a
U
P Ð Ð real-time kernel allowing the code of the control
aL
task to be written in C or as a MATLAB/
PI 0:9
U
3.3 L Ð
Simulink S-Function. The possibility to call a C
aL routine or an S-Function enables the use of legacy
U
code. The last implementation relies on the new
PID 1:2
aL
2L 0.5 L LabVIEW RT. The professional system Concur-
rent PowerMAX as well as other embedded solu-
tions are not evaluated in our review.
interval L between the step and the crossing of the Plain LabVIEW
tangent at the inflection point with the time axis. In LabVIEW, the execution of the program,
The convenient parameters are listed in Table 1, called the Virtual Instrument (VI), is paced by
with respect to the results of the experiment and the data flow. This flow can be slowed down or
the desired controller type. interrupted by some external events such as
The resulting sequence of operations which have network accesses, mouse movements, disk opera-
to be implemented to complete the PID correction tions or other OS events. The cycle time for a
at time k is: control loop written in LabVIEW is therefore non-
. acquire the measurement y…k†; deterministic and dependent on the time used by
. get from the user the current PID parameters the other VIs running and to the computer's other
KP, TI and TD , as well as the reference signal activities. This implies that control of the physical
yc …k†; process might be lost when these events occur
. compute the error e…k† ˆ yc …k† ÿ y…k† (some (Fig. 8).
filtering can also be considered here); To guarantee the correct behaviour of the
. compute uP …k†, uI …k†, and uD …k† if applicable system, the user must ensure that the duration of
(the states of the controller uI …k ÿ 1† and these events is much smaller than the chosen
e…k ÿ 1† have to be available); sampling period. This can be partially alleviated
. compute the sum u…k† and limit its value in a by using the multi-threaded functionality of
range compatible with the physical devices LabVIEW and by setting appropriate priorities
(power amplifier, motor); to the different VIs. The main application is split
. output the previously computed control signal into Sub-VIs, each representing a different thread
u…k† (or wait for the next sampling period to do so). (Fig. 9).
Higher priority is given to the PID code, which
can be written using the regular LabVIEW func-
PID CONTROLLER IMPLEMENTATIONS tions or by using a formula node. The lowest
WITHIN LabVIEW priority is given to the user interface update
which corresponds to the supervision task.
This section presents the different alternatives for The appropriate use of the DAQ board can also
the real-time implementation of a PID controller compensate for the varying latency since many of

Fig. 8. Unpredictable event occurrence. The LabVIEW execution flow can be interrupted by some external events such as network
accesses, mouse movements, disk operations or other OS events. The cycle time for a control loop written in LabVIEW is therefore
non-deterministic.
 Introduction to Real-time Control using LabVIEW with an Application to Distance Learning 7

Fig. 9. Multi-threaded implementation. The display loop and the real-time (RT) loop run in different threads. The Display loop has a
lower priority than the RT loop. The CONFIG_BOARD VI sets up the DAQ board for continuous acquisition without buffer. The on-
board timer insures the accurate sampling period. The user is informed of a faulty operation (i.e. more than one sample in the buffer
meaning that the loop was slowed down or interrupted) by the Keeping_RT_? button.

today's universal acquisition boards have the variations, a timestamp needs to be stored with
required timers and circuits to generate interrupts. each measurement sample. This timestamp will be
The advantage of using the DAQ board interrupts used to determine the real sampling period to be
is that such signals can also trigger, very accu- use in the numerical derivation, as well as for the
rately, the acquisition and the buffering of the display and the storage of the data.
data, this independently of other computer activi-
ties (Fig. 9). In such a way, the delay separating the LabVIEW with the real-time kernel
interrupt issuing and the sampling is inexistent. To improve the performance of controllers
This is essential to achieve a predictable behaviour running within LabVIEW and to reuse the legacy
(invariant sampling period) and to conform with code (C and S-Function) which may have been
the applicability conditions of the stability criteria. developed and tuned for other applications, a
In this configuration, the latency corresponds to real-time kernel (RTK) which handles all the
the delay between the interrupt occurrence and the real-time operations has been designed, thus
effective buffer retrieval by the Read AD sub-VI. removing the need for LabVIEW to do this [3].
Fortunately, this delay is not critical to the control The RTK is able to execute the user's real-time
loop reliability as long as it does not exceed the task (RTT) repetitively at a fast and accurate
sampling period. If this happens, one or more pace. To achieve these requirements, the RTK
samples are not taken into account, which can be relies on interrupts.
disastrous. To detect such an event, the Read AD The real-time kernel is implemented in C as a
sub-VI must ensure that there is one and only code interface node (CIN, LabVIEW external
one sample in the acquisition board buffer. This code). This kernel allows one or more user
means that the next interrupt has not occurred and routines, typically a controller routine, to be
that the LabVIEW loop cycle is smaller than the called by the OS at interrupt time.
sampling period (as expected). In this case, the
main loop is running as fast as possible and waits
for a measurement to arrive in the board buffer.
Alternatively, without the use of the DAQ board
timers, the LabVIEW main loop should cadence
the execution of the controller using the Wait
Until Next ms Multiple VI (Fig. 10). In this
case, the AD conversion is triggered at each
execution of the main loop and the controller has
to wait for the data to become available. Since
LabVIEW execution can be interrupted or
delayed, it is not guaranteed that the given cadence
can be followed. Moreover, undesirable jitter in
the sampling time is impossible to avoid.
This jitter of the sampling period is particularly
critical for the computation of the derivative term
in which h appears explicitly. If the desired value of Fig. 10. `Wait Until Next ms Multiple' loop cadencing. The
h is used instead of the real one, huge errors may AD VI adds a Timestamp to the measurement to compensate
occur. To compensate for the sampling period the sampling period variation.
8 Ch. Salzmann et al.

The RTK should be seen as a standalone back- other information such as timestamps, execution
ground application, which communicates through errors, and virtual channels holding internal states
shared memory with the foreground application of a controller (for example the previous integral
(LabVIEW) holding the user interface. The RTK values) are stored in the buffer.
has two main functions: the first is the communi- A set of VIs allows to control all the required
cation with the physical process via acquisition operations related with the RTK such as con-
boards. The second is the management of the figuring the hardware, configuring the RTTs and
user-defined RTT, which can be any type of real- starting and stopping controller routine (Fig. 11).
time operations such as real-time control, real-time Another VI performs the data exchange from and
simulation or for example on-line identification. to the controller routine. Those VIs are very
The user-defined real-time tasks are called by the similar to the current DAQ VIs.
RTK at each sampling period or at a multiple of The RTK allows the user to install one or more
the sampling period (sub-sampling). If there is real-time tasks. These tasks are Dynamic Linked
more than one RTT defined for the same board, Libraries (DLLs written in C) or S-Function
the RTK calls them in a pseudo-parallel fashion. (written in MATLAB format). To avoid having
This simplifies the implementation of parallel or to worry about complex compiler environment
complex operations. In the example of a single issues, the compiler can be controlled directly by
RTT performing a cascade control with two PIDs, a Real-Time Framework [3]. Currently, only the
the RTT can be split into two single PID control- MacOS platform is supported. A freeware subset
lers. In the same manner, sub-sampling allows two of this environment is available on-line (http://
different tasks such as filtering and control to be iawww.epfl.ch).
called at different paces. Instead of having the MATLAB and Simulink (http://www.math-
controller called at a faster than needed sampling works.com) are widely used in the engineering
rate in order to filter the input signal(s), these two world. The simulation and the design of controllers
operations are implemented in separate routines: can be conducted using the MATLAB/Simulink
the filtering operation which is performed at each language. Instead of rewriting the code developed
sampling period, and the control operation which in C or in G, the RTK can reuse the legacy code by
is called, for example, every twenty interrupts. The calling, at interrupt time, an interpreter, which
filtered signal is shared between the filter and implements a large subset of the MATLAB
the controller using the buffer. This method syntax. The built-in interpreter has been written
lowers the processor's load and makes the RTT with the primary purpose to be run in real-time.
easier to write. Due to the extensive computer load resulting from
The input and output data defined by the the interpretation which is carried out at every
user are stored in an internal buffer. This buffer sampling period, the achievable cycle time is
is updated synchronously with each interrupt. larger (by a factor of 10) in that case than in the
When called by an interrupt, the RTK puts the one when calling C code.
newly acquired values into the buffer and then
retrieves the value for the next outputs from the LabVIEW RT
same buffer. For display purposes, this buffer can National Instruments proposes an intelligent
be partly or completely retrieved asynchronously DAQ board containing all of the necessary compo-
by LabVIEW. Besides input and output data, nents to develop real-time systems. The board

Fig. 11. The RT-kernel calling a RT-task (written in C or as an S-function). At first the board is configured, then the RTT is initialised
and started. During the loop execution data (parameters and buffer) are exchanged with the RTK via the RT_READ VI. Upon
termination, the RTT is stopped and removed from the memory.
 Introduction to Real-time Control using LabVIEW with an Application to Distance Learning 9

consists of two components: a processor board There are no programming differences between
and a DAQ daughter card. The processor board LabVIEW RT and the standard version of
includes many of the PC components, but does not LabVIEW. Having the critical part running on
contain hard-drive or other standard I/O devices. the dedicated RTE ensures that the embedded
The daughter card is similar to other NI DAQ code will not be interrupted by any other outside
products. event. The PID controller can be cadenced with the
A multi-threaded real-time engine (RTE) runs metronome (Wait Until Next ms Multiple) func-
on the processor board using a real-time operating tion (Fig. 12). This function puts the current
system (RTOS). The RTOS ensures that the thread into sleep and allows other threads to run.
scheduler and other operating system services By giving the time critical priority to the embedded
comply with the real-time requirements. PID VI, it is ensured that the loop execution time is
The RTE executes LabVIEW RT programs guaranteed, this provided that the loop time is
which are exactly the same as the standard smaller than the sampling period. If the time
LabVIEW programs but with some limitations. critical thread consumes most of the processor
For example, there are no disk access and no time, the others threads, such as the communi-
Ethernet communication capabilities due to the cation thread, which exchange data with the RT
lack of peripherals on the RT board and due to development system will not have time to execute
the potential RTE performance degradation they resulting in a sluggish user interface update. The
would imply. Attempting to use these unsupported user interface may even look frozen if the time
functions in an embedded LabVIEW RT applica- critical thread consumes all of the processor time.
tion produces standard LabVIEW error codes. In that case, the embedded VI is still running, but
The development system runs on Windows has no time to transfer the data to the development
(NT/9). Before being executed, the VIs are system. This might be suitable for industrial
downloaded on the RT board. Once on the systems not requiring a user interface, but for
RTE, the VIs run without any outside inter- education it is important to interact in real-time
ference thus allowing deterministic cycle times. with the controller. Thus, the sampling period
The VIs running on the RTE will still be running should allow enough time for the user interface
even if the host computer reboots. For display management.
and other purposes, the VIs on the RTE
exchange data with the RT development system Concurrent PowerMAX real-time LabVIEW
via messages or shared memory. The display of National Instruments has ported LabVIEW to
the user interface is performed automatically the Concurrent PowerMax real-time architec-
without any user programming. ture. Concurrent computers develop a real-time

Fig. 12. The local and the embedded VI. The emdedded VI containing the controller code (PID) is downloaded to the LV-RT
board. It exchanges data (parameters and circular buffer) with the local VI containing the user interface by using the RTE_PEEK and
RTE_POKE VIs.
10 Ch. Salzmann et al.

Table 2. PID implementation solutions.

Solution Coding Cycle time Platform Interrupt Hardware

2
Plain LV G 10 ms All soft DAQ
Multi-threaded LV G 5 ms2 All3 soft DAQ
RT Kernel calling C G1 & C 0.2 ms2 Mac4 soft/hard DAQ
RT Kernel calling S-Function G1 & Matlab 5 ms2 Mac4 soft/hard DAQ
LabVIEW RT G 1 ms Embedded on PCI, PXI hard RT5 & DAQ
PowerMax G not tested PowerMax hard PM6 & DAQ
1
LabVIEW is used for the supervision task (user interface).
2
Depends on processor performances.
3
Mac version is currently not multi-threaded.
4
Porting the RTK to the PC platform is under evaluation.
5
Require the embedded LV board.
6
Require a PowerMax computer.

multitasking UNIX-based operating system growing rapidly in all engineering colleges. At the
which can guarantee a given latency and a same time, the number of students is increasing
deterministic real-time response. This is a scalable, while the allocated laboratory resources do not
professional (read expensive for education) system keep pace with this change. Being able to make
and therefore outside the scope of this paper. the laboratory infrastructure accessible as virtual
laboratories, available 24 hours a day and 7 days a
Discussion week, goes a long way towards addressing these
Different solutions have been presented for difficulties, and would also contribute to lowering
implementing a PID controller within LabVIEW. the costs of operating the laboratory in the long
Depending upon the financial and technical term. Moreover, students are able to carry out
requirements, different solutions can be selected. experimentation at the precise stage in their learn-
Table 2 summarises the different possibilities. ing process when they need to compare their
In education, it is important to consider the knowledge to reality. This is an additional benefit
coding simplicity according to the students back- of such a new paradigm introduced in distance
ground which may vary among engineering learning. The increased availability is obtained by
majors. The acquisition and maintenance cost of allowing students to reach the laboratory facilities
the real-time environment are also important. The via the Internet using a modem, or from other
part of the budget dedicated to hardware should be points of network access, such as computers avail-
kept as small as possible, limiting the possibility to able at different campus locations. The Internet
use professional hardware solutions. A software- offers many advantages over other technologies,
only solution should be chosen. Moreover, due to which makes it the medium of choice. The first
the strong interaction between the hardware advantage is its price and availability. Nowadays,
drivers, the OS and the control software, real- almost every household has a telephone line which
time environment upgrades have to be carefully makes a potential Internet connection. Current
planned. technologies such as ISDN or 56K modems give
As it will be shown in the next chapter, a enough capacity to transmit voice and video with
solution without additional hardware is preferred an acceptable quality. In a remote experimenta-
since distant users do not want to duplicate the tion, not only the users may be distributed all over
DAQ board or the embedded real-time environ- the world, the experiments can also be distributed
ment needed to locally control the remote system. among the potential users (such as universities)
thus giving an opportunity to reduce the costs
associated with laboratory facilities by sharing
EXTENSION TO DISTANCE LEARNING unique or expensive equipment.
The learning environment is based on a client/
Motivation for remote experimentation server architecture (Fig. 13). Given its fully com-
Currently, traditional and virtual universities puter-based implementation, the laboratory
propose on-line courses based on electronic environment can easily be expanded for remote
documents and multimedia presentations enriched manipulation. The main concept in turning the
with video and audio broadcasting [4]. While the locally-controlled setup into a remotely-controlled
students can take these classes from a remote one consists in moving the user interface away
location they still have to come onto the campus from the experiment. Two distinctive parts result:
for the laboratory practice. This restriction can be the remote client and the local server.
overcome by allowing students to access the
laboratory facilities from a distant location to . The remote client is a computer equipped with
carry out hands-on sessions [5]. the functionality necessary to observe and to act
The development of remote-experimentation on the remote experiment. The client application
facilities is also motivated by the fact that the is a VI compiled for the target platforms. This
demand for access to laboratory facilities is VI provides the user with a complete interface to
 Introduction to Real-time Control using LabVIEW with an Application to Distance Learning 11

Fig. 13. Architecture for carrying out real experiments in distance learning.

the real process. It is used to generate excitation solution to a remote one, or port the remote
signals and observe corresponding responses. solution to different physical systems.
The main concept of such an interface is to
provide a general view of the physical process
evolutions, and to allow full control of the Requirements
operations. Distancing the user from the local experiment
. The local server is the computer located near
while keeping the same amount of benefits as local
the real process and equipped with the hard- experimentation is challenging. Not only the same
ware interface to the sensors and actuators. The degree of interactivity must be maintained, but the
video camera and microphone can be assimi- remote solution must also allow the user to `feel'
lated to sensors. The server application receives the real experiment. During local experimentation
the client commands and transmits them to the students can use their senses of vision and hearing
real process. It also returns the states of the to perceive the effect of their acts on the control
physical process to the client including an image. system. In a remote experimentation mode, this
Three modules are necessary to build the client and specification is addressed by providing audio and
the server applications: the GUI module, the RT video feedback information in addition to the
module and the COM module (Fig. 14). The information given to the remote computer through
application used locally can be split in two the graphical user interface (GUI). Obviously,
modules: the real-time controller (RT) and the such feedback needs to be given in a reasonable
user interface (GUI). The client and the server amount of time, minimising the misleading (and
application can be designed by adding a commun- most likely also disturbing) effects of signal-
ication module to the two existing modules. The transport delays. For example, a remote user
client application is made up of the GUI and the will not find acceptable feedback that arrives 30
communication modules. The server application is seconds after an action has been accomplished,
made up of the controller and the communication while the local response is achieved in fractions of
module. The server may require a basic user inter- a second. Consequently, fast system responsiveness
face for supervision of the ongoing operations. The is a key goal in all developments for remote
communication module allows the client and experimentation. As might be expected, ideal
server applications to exchange information with instantaneous responses are not possible, but
other computers distributed in different geographi- response times should still be minimised.
cal locations. This module also takes care of In addition to the need to remotely `feel' the
security issues regarding network management. physical system, it is also necessary to remotely
For example, it prevents unauthorised access and `touch' it. For example, perturbing the system by
schedules logins to avoid conflict. hand to observe the reaction of the controller
By isolating carefully these modules in the should be possible. This is achieved by introducing
development process, it is easy to port a local an additional actuator or by artificially altering
12 Ch. Salzmann et al.

Fig. 14. The three modules for building the client and server application. The RT module handles the real time operations (video
acquisition and physical setup control). The COM. module located on both ends transfers the data intelligently between the client and
the server. The GUI module displays the incoming data and sends the parameter changes to the server.

some control or measurement signals to mimic the The adaptation is made by assigning a different
desired effect. priority to each stream. An algorithm, taken the
The interactivity must be adequate, otherwise network load seen at the client side into account,
the gain induced by remote experimentation will be determines the server bandwidth usage. Based on
minor and the facility will probably not be used. stream priorities and the information coming from
The objectives for a fast application such as the client, the server optimises the packet size and
motion control, where the user should be able to packet rate. The server application can adapt the
catch the dynamics of the process, are different amount of information transmitted by increasing
from the objectives of a slow chemical plant where the image compression factor and/or by deci-
the user needs mostly to deal with the complexity mating the measurements. This scheme can
of the system. The solution presented here focuses adapted in real-time to a wide range of bandwidth
on fast dynamic systems such as electromechanical from modem line to LAN connection. A specific
processes. Since they have mobile parts, they can technique is used to recover packets, which are lost
be monitored remotely by cameras. In the case of during the transmission.
visually static systems such as thermal systems,
remote observation can be enabled by the use of
sensors that modify their appearance according to
the measured state. DISTRIBUTED APPLICATIONS USING
LabVIEW
Streams and adaptation
Adaptation to the network (i.e. Internet) load is Different solutions exist for controlling a
necessary for using wisely the available bandwidth. computer remotely. Maybe the simplest one is
In the future, unfriendly applications, which do the sharing of the remote screen and the redirec-
not adapt might be banned from networks if they tion of the different local input devices such as the
do not behave adequately. mouse and the keyboard. The information
Different kinds of information are exchanged exchanged by the screen sharing application, such
between the server and the clients according to as Timbuktu (http://www.netopia.com), is mainly
four different classes: pixels representing the remote screen. The data
used by the remote experimentation have a more
. the data stream representing the measurements compact representation and they can be updated/
made on the physical system; transmitted more efficiently since conventions exist
. the audio/video stream acquired by the camera; between the client and the server. For example
. the parameter stream reflects the user actions on when a new point is added to the measurement
the client side; display (1 in Fig. 18), the screen sharing appli-
. the administrative stream which deals with the cation will update and transmit the all display to
login/logout issues [6]. the remote computer. A better alternative is to
 Introduction to Real-time Control using LabVIEW with an Application to Distance Learning 13

only transmit the new point, resulting in a much a remote machine transmitting its local time using
more efficient use of the bandwidth. the call by reference node is shown in Fig. 15.
National Instruments provides a fully featured Four `call by reference VIs' were used to
web server written in LabVIEW. When running remotely control the physical setup. The first VI
this server, the front panel (FP) of running VIs can transmits the controller parameters from the client
be transmitted to a Web browser and updated at to the server, the second VI sends the measured
regular intervals using the server-push/client-pop values from the server to the client, and the third
technique. The server also support CGIs (common and fourth VIs implement watchdogs to detect if
gate interface) written in LabVIEW such as image the client or the server are still available. This
map. The combination of different VIs (FP image, method has the advantage of being easy to imple-
CGI, and Form) can provide the client with a view ment and the performances are good on a lightly
of the remote setup. The user will be able to loaded local area networks (LANs). On the other
interact with the server within the limitation of hand, this method suffers from the TCP limitation
current Web technology, i.e. the slow image update (TCP slow start) when the network load increases
(a few frames per minute), the limited use of the or when the connection is not reliable implying
form format to transmit information to the server packet losses.
and the rather cumbersome LabVIEW CGI LabVIEW UDP tools are used to overcome the
programming required on the server side. TCP limitation, they allow full control of the
Nacimiento (http://www.Nacimiento.com) soft- bandwidth usage. This method is well suited for
ware proposes AppletVIEW, a toolkit which transmission over the Internet. UDP does not
provides users with a complete development en- suffer from the slow start limitation, but this has
vironment for creating Java pallets as front-end a price: the packet delivery is not guaranteed. In
instrumentation panels that communicate with a other words UDP is connectionless, which means
LabVIEW server. Web pages may contain knobs, that the server has no knowledge of the packet
sliders, switches, and charts that are actual arrival at the client side. The client application has
controls that communicate with the AppletVIEW the responsibility to inform, if required, that a
VI. This is done without any Java programming. packet has been lost and ask for its retransmission
LabVIEW 5 introduced a new mechanism, (this is done automatically under TCP).
called VI Server, to programmaticaly access For some applications, the packets can be
LabVIEW objects and functionalities. The server lost without affecting the client application. For
relies on TCP to exchange data between VIs (local example, when transmitting a movie, a frame can
and remote). This is done transparently and no be lost and the movie is still understandable.
specific knowledge is required. The security is Remote experimentation belongs to this category
defined on the server side. Different methods can and implements an advanced control scheme on
be invoked, for example a VI can remotely set a top of UDP.
control value, open a given VI or print the front Figure 16 presents a local time server using
panel. Another possibility is to call a remote sub- UDP. It has the same functionalities as the
VI by invoking a call by reference node. The previous example presented. The client application
principle is similar to a remote procedure call listens to a given port and waits for a UDP packet
(RPC) under UNIX. The only difference between to arrive. The UDP Open and UDP Close VIs are
a local or a remote call is the need to define the IP only used to specify the UDP port to listen to and
address and IP port of the remote machine. Prior to free the port once the program quits. There is
to calling the sub-VI, the user needs to establish a no connection establishment under UDP. It is the
connection with the server. On termination, the application developer's responsibility to define the
connection needs to be closed. A simple example of connection protocol. This can be a time consuming

Figure 15. A simple time client-server using CALL_BY_REFERENCE VI. The OPEN_APPLICATION and OPEN_VI VIs open a connection with
the remote LabVIEW running the specified VI (LOCAL_TIME). At each loop iteration, the CALL_BY_REFERENCE VI retrieves the remote
data and displays it. Upon termination the connection is closed.
14 Ch. Salzmann et al.

Fig. 16. A simple time client-server application using UDP. The Sender VI continuously sends its local time to the specified IP Address
and IP Port. The Receiver VI listens to a given port for a given time. If a valid packet arrives, the data (remote time) are displayed. If
not, it waits again for a fixed time until the user stops the VI. Upon completion the UDP ports are released.

task that requires a good knowledge of commun- students because they often yield responses that
ication technology. are easy to identify visually. Furthermore, experi-
mentation can typically be conducted in a reason-
able amount of time. For example, a complete
EXAMPLE laboratory experiment could take between one
and two hours of work, during this period the
The electrical drive student carries out modeling and design studies,
Many mechatronic systemsÐi.e., those that including shorter periods (5 to 15 minutes) of
integrate electrical and mechanical partsÐused in interaction in real-time mode with the experiment
a control engineering laboratory are attractive to for measurement and control purposes.

Fig. 17. Electrical drive. (1) motor, (2) load, (3) magnetic brake, (4) position potentiometer, (5) reference potentiometer.
 Introduction to Real-time Control using LabVIEW with an Application to Distance Learning 15

Fig. 18. Client GUI. (1) Scope area, (2) visual area with enhanced video feedback, (3) Parameters, (4) Administrative area.

The electrical drive is a typical mechatronic modify the parameters (3) of the controller as well
system (Fig. 17), which is used in many textbooks as other adjustable characteristics of the experi-
to illustrate an automatic control system. The ment, such as the sampling period. The push
example considered here is simple and exhibits an button is meant for remotely perturbing the
almost linear behaviour. It consists of a 14 W DC physical system. The administrative area (4)
motor (1) equipped with a built-in tachometer. The manages the different connection stages such as
motor drives a loadÐin this case a steel disk (2). user login and quitting.
An adjustable magnetic brake (3) introduces a
viscous friction effect, allowing thereby a modifi- Augmented reality and video grabber VIs
cation of the time constant during operations. Video feedback is especially well suited for
Either axle angular position or speed can be mechatronic processes. Special attention has been
controlled by adjusting the motor voltage. made to providing the user with not only the video
The angular position is measured by a poten- image of the process but also by superimposing
tiometer (4) connected to the motor axle through other information such as the virtual reality
a reduction device. The reference value can be representation of the physical system, resulting a
generated manually by a similar potentiometer composite image called augmented reality (Fig. 19).
(5). Both potentiometers are equipped with The virtual image is derived from the measure-
enlarged disks, which permit easy visualisation of ments made on the real system, whereas the video
the motion, either locally or remotely. image comes from the video camera. Special care is
needed to synchronise these two representations.
Visual feedback This is largely compensated for by the benefits
The visual feedback is provided by the graphical resulting from their combination.
user interface (GUI). A cockpit-like metaphor [5] The virtual image is also useful when the avail-
is used to present the different information to the able bandwidth is small. Instead of using a large
user (Fig. 18). The GUI is split into four areas. The portion of the available bandwidth with the video
scope area (1) enables the user to follow the time image, only a few video images per second (1 or
evolution of all signals relevant to the experiment less) are sent. The missing dynamic of the video is
(for example the internal states of the controller). compensated for by the animation of the virtual
The visual area (2) provides the video feedback of image. When using the highest compression factor,
the real process enhanced with the virtual repre- the smallest size for the video image is about 2
sentation of the process. The user is allowed to Kilobytes whereas for the `same' information

Fig 19. Video and virtual reality image. (a) Generally speaking the video image and the virtual view are synchronized. (b) The virtual
view is updated more often than the video image when the transmission channel is loaded. (c) Only the virtual view is displayed when
the transmission channel is heavily loaded.
16 Ch. Salzmann et al.

Fig. 20. Simple QT frame grabber. The video source is selected by using the SETUP_QT VI. The acquired image (QT_GRAB VI) is
converted and displayed 5 times per second in a Picture indicator. The virtual view can be added to the real view of the setup. Upon
completion the video source is released.

(angle), only 2 Bytes are needed to update the exercises. Compared with experimentation in
virtual image. This wide range of possible packet virtual reality, real experimentation is easier to
size gives considerable room for adaptation. implement and more versatile. In fact, adding or
Observe that the video image carried far more selecting another physical setup does not involve
information than the virtual image. Through the the elaboration of complex mathematical models
real image, the user can get a feeling for the real and graphical representations. In addition, engi-
setup. This is essential in remote experimentation. neering students gain confidence in their ability to
The video image also gives environmental informa- deal with real applications, which is going to be
tion which is undetectable using the virtual image, their career challenge.
as for example a wire running across the moving When planning to set up an environment for
parts of the electrical drive. experimentation in academia, the criteria for
A set of VIs was developed to grab images selecting a commercial solution are different from
coming from a video camera. These VIs are in the industry. Usually, the need for interactivity
based on QuickTime (QT). They can use any is higher and the overall capabilities are lower. The
input source supported by QT provided that the scalability and the ease in designing a user
corresponding vdig (driver) exists. The image is interface provided with LabVIEW, as well as
displayed in a LabVIEW picture indicator. its multi-platform implementation, make this
These images can be compressed in JPEG package well suited to develop didactic tools.
format (other formats are possible) before Moreover, the possibility to compile standalone
being sent across the Internet. On the receiver virtual instruments, which can be distributed freely
side the images are first decompressed and then to the students, is a big advantage.
displayed. If needed, the virtual image Various ways exist of exploiting LabVIEW for
is superimposed to the video image before implementing automatic control solutions accord-
being displayed. ing with the user requirements in terms of quality
Figure 20 presents a simple video grabber with of services and the constraints inherent in the
an augmented view of the real system. The image is controlled physical system. The most critical part
updated 5 times per second. is the handling of the real-time operations. The
survey of different solutions given in this paper
enables the selection of the solution most suit-
able for a particular application. Depending on
CONCLUSIONS the curricula into which the practice is inte-
grated, coding the control algorithm in G, C
One of the major requirements in engineering or MATLAB may be chosen. The required cycle
education is to provide students with convenient time is also an important element when selecting
environments to practice what they have been an implementation solution. Finally, when security
taught or what they have learned conceptually. is a major concern, embedded solutions have to be
This is true in traditional education as well as in considered.
distance learning. It should be stressed that local or Programming is usually not the main topic of
remote experimentation on physical systems is an automatic control laboratory sessions. Practical
essential complement to simulation and written training of the material learned is the main
 Introduction to Real-time Control using LabVIEW with an Application to Distance Learning 17

point. Thus, three different implementation before choosing the most suitable solution to
approaches have been chosen at the Swiss Federal their application.
Institute of Technology. The first one is applied For distance learning purposes, the VIs are
to engineering students spending only a few hours developed by a team of educators and computer
in the laboratory concurrently with the basic scientists. From the server side, a real-time control
control course. They are provided with standalone loop is implemented with one of the available
VIs which enable them to experiment locally or implementation solutions. To guarantee the best
remotely the behaviours of the controllers they possible quality of service and to provide a
have studied in class, such as the PID controller. versatile client management, the communication
In such a case, they use high level VIs, which let layer is developed using the LabVIEW UDP tools.
them observe the effect of changing important To broadcast the view of the real experiment
tuning parameters. But, they do not change running remotely, a set of QT video acquisition
the underlying control algorithms, so requiring VIs have been developed. They provide LabVIEW
no programming. These VIs are developed by the with a video image displayed in a picture indicator
educators using LabVIEW enhanced with the properly synchronised with the data display.
Real-Time Kernel. The second approach concerns Finally, the proposed solutions demonstrate the
students involved in advanced automatic control feasibility of using LabVIEW for real-time control,
courses who may want to validate the various allowing students to carry out experimental studies
control algorithms they have studied. Since either on campus or remotely, as well as tutors to
they usually carried out the design and the present live in-class demonstrations. Moreover,
simulation with MATLAB, they are provided the proposed paradigm for real-time control
with LabVIEW enhanced with the Real-Time implementation is not only limited to education.
Kernel and the MATLAB interpreter for imple- In research and industry, its ease of use also
mentation purposes. The last approach is followed represents an interesting opportunity to meet
by the students, which conducts a semester or a the growing needs of scientists for fast proto-
diploma project on a didactic or industrial setup. typing. This paradigm enables teachers to imple-
Here, as the constraints may vary, they under- ment real-time control solutions in a really
took a short introductory course in real-time efficient manner, both from a time and resources
implementation and LabVIEW programming perspective.

REFERENCES

1. D. Gillet, G. F. Franklin, R. Longchamp and D. Bonvin, Introduction to automatic control via an

integrated instruction approach, 3rd IFAC Symp. Advances in Control Education, Tokyo, Japan,
(1994) pp. 83±86.
2. G. F. Franklin, J. D. Powel and M. L. Workman, Digital Control of Dynamic Systems, 3rd Edition,
Addison-Wesley (1997).
3. Ch. Salzmann, D. Gillet, R. Longchamp and D. Bonvin, Framework for fast real-time applications
in automatic control education, 4th IFAC Symp. Advances in Control Education, Istanbul, Turkey
(1997) pp. 345±350.
4. H. A. Latchman, Ch. Salzmann, S. Thottapilly and H. Bouzekri, Hybrid asynchronous and
synchronous learning networks in distance education, Int. Conf. Engineering Education, ICEE 98,
paper 351, Rio de Janeiro, Brazil, 1998.
5. D. Gillet, Ch. Salzmann, R. Longchamp and D. Bonvin, Telepresence: an opportunity to develop
practical experimentation in automatic control education, European Control Conference, ECC 97,
paper 439, Brussels, Belgium (1997).
6. Ch. Salzmann, H. A. Latchman, D. Gillet and O. D. Crisalle, Requirements for real-time
experimentation over the Internet, Int. Conf. Engineering Education, ICEE 98, paper 222, Rio de
Janeiro, Brazil (1998).

Christophe Salzmann received his MS degree in Computer and Information Sciences in 1999
from the University of Florida, Gainesville. He is currently a Ph. D. student at the
Automatic Control Institute at the Swiss Federal Institute of TechnologyÐLausanne
(EPFL). During 1995 he was an invited scientist at National Instruments, Austin, TX,
where he worked on LabVIEW. He is also responsible for the LabVIEW User Group at the
EPFL and for the development of the Real-Time Kernel. His research interests include
real-time computing, telepresence, distance learning, multimedia technologies and
communication networks with an emphasis on bandwidth adaptation.

Denis Gillet received his Diploma in Electrical Engineering in 1988 from the Swiss Federal
Institute of TechnologyÐLausanne (EPFL) and his Ph. D. degree in Control Systems in
1995 from the same university. During 92/93, he worked as a Research Fellow at the
Information Systems Laboratory, Stanford University. In 1996, he was an invited Professor
at the National Polytechnic Institute Grenoble for three months. Currently, he is an
18 Ch. Salzmann et al.

Associate Professor (MER) at the EPFL. His research interests include on-line optimization
and control, multimedia technologies, distance learning, telepresence, fast prototyping and
real-time implementation.
Pierre Huguenin received his Diploma in Mechanical Engineering in 1988 from the Swiss
Federal Institute of TechnologyÐLausanne (EPFL). He is currently a Ph. D. student at the
Automatic Control Institute (EPFL). His current research interests include real-time
computing, modelling, non-linear control and intelligent transportation system.