Introduction to Real-time Control · introduction to the basic principles underlying real-time...

Introduction to Real-time Controlusing LabVIEWTM with an Applicationto Distance Learning*

Ch. SALZMANN, D. GILLET, and P. HUGUENINSwiss 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 andfacilities to implement real-time control solutions. This goal is achieved first by way of anintroduction to the basic principles underlying real-time control. Then, by motivating the use ofpersonal computers as a versatile alternative to more traditional implementation equipment.Finally, by combining LabVIEW and DAQ boards to form an integrated framework for fastprototyping of real-time control solutions. Control algorithms written in G (the graphicalprogramming language of LabVIEW), in C or as S-functions (MATLAB scripts describingSIMULINK 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 remotelyvia the Internet, is a key feature from an educational point of view. In fact, the chosen paradigmtruly enable the `learning by doing' approach. Moreover, this practical activity can be carried out atany time from anywhere to efficiently support automatic control study.

INTRODUCTION

FEEDBACK CONTROL LOOPS are imple-mented to increase dynamical performance orprecision of scientific and industrial equipment.The basic principle of such loops is to take intoaccount actual measurements in order to computeappropriate actuations that adjust the operationalconditions to meet given requirements. Motioncontrol and process control are two major appli-cation areas of this paradigm. Due to thisbroad application field and its interdisciplinarynature, Automatic Control is a fundamentalsubject usually taught in many engineeringdisciplines, such as electrical, mechanical andchemical engineering.

Practical experimentations are made duringlaboratory sessions where students can try out onreal processes the material they learn during theclass [1]. As a matter of fact, implementing acomplete control solution from scratch requiresknowledge not only of the matter studied butalso of the different technologies needed to inter-face the real process, such as sensors and actuators,to the computer used to conduct the experiment.Computer knowledge such as hardware interfacingand real-time programming are also needed tocarry out the experiment. Fundamentals of allthese aspects should be taught to students inautomatic control.

Acquisition of measurements and modificationof actuations are the usual tasks carried out by

LabVIEWTM and DAQ boards. This implementa-tion paradigm based on personal computer andstandard operating systems constitutes a new trendin automation. It allows the user to avoid suchaged, specialised or expensive solutions as analogPID loops, programmable logic controllers (PLC)or dedicated hardware based on digital signalprocessors (DSP).

To stress the advantage of the above-mentionedopen paradigm, the students are provided with anintegrated framework versatile enough to bequickly adapted to their different needs and back-grounds. This solution reduces the additionalknowledge required to proceed with the imple-mentation and helps students focus on essentialconcepts. To be attractive to the students, theframework needs to be highly interactive andoffer a well-designed graphical user interface.

The recent increase in availability of personalcomputers at home and on campus has allowedstudents to exploit computer-aided instruction(CAI) tools to learn in their own way and attheir own pace. Unfortunately, such independentwork is not possible on laboratory-scale processessince these cannot be moved easily or duplicated insufficient numbers. Therefore, experimental workis done in the laboratory according to a predefinedschedule.

Both the recent developments in the Internetand the introduction of the World-Wide-Web(WWW) are opening the ways to interactivepresentations, even remote access opportunitiesto real-world equipment. The availability and thecapabilities of these new communication facilities,combined with the generalisation of computer use* Accepted 9 September 1999.

1

Int. J. Engng Ed. Vol. 16, No. 2, pp. 000±000, 2000 0949-149X/91 $3.00+0.00Printed in Great Britain. # 2000 TEMPUS Publications.

for data acquisition and control of real processes,enable the students to move from a presence atthe equipment location to a more versatile tele-presence, thereby allowing remote experimentation.

This paper discusses the necessary competenciesand facilities to implement real-time control solu-tions, either in traditional education or in distancelearning. An example of ditributed applicationsusing LabVIEW is given, where an electricaldrive is introduced as convenient setup to studylocally or remotely applications in motion control.This example serves as illustration throughoutthe paper. The advantages and the potential oflocal and remote experimentation supported byLabVIEW are expressed as conclusions.

FUNDAMENTALS OF REAL-TIMECONTROL

The notion of real-time implies that computeroperations rely on absolute and irreversibletime. These operations are generally performed

accordingly with the evolution of a physicalsystem. If necessary, the system-state is madeavailable to the computer through appropriateinterfacing devices, such as sensors and converters.The notion of real-time control reinforces theoriginal definition by specifically emphasisingactions carried out in addition to observations.

These notions can be illustrated by comparingdata acquisition and processing (Fig. 1) with real-time control (Fig. 2). There are two main dif-ferences. In the former case, a finite number ofacquisition cycles are performed to provide astream of data for post processing operations. Inthe latter case, continuous operation cycles areperformed. During these cycles only one datasample is acquired and immediately processed.

Moreover, in contrast to data acquisition,control operations require actuation values to becomputed and written to output ports at everycycle. This removes the possibility of performingbatch processing based on the data stored in anacquisition buffer (if there is any).

Appropriate actuators and amplifiers interfacedwith the output ports enable the computer to drive

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

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 thereference 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.

Ch. Salzmann et al.2

the physical system with the necessary amount ofenergy.

Implementation constraintsFigure 3 presents the standard structure for a

feedback loop. The output of the controller drivesthe input of a physical system, whereas the outputof the physical system is reintroduced as the inputfor the controller, thus closing the loop. Toguarantee an efficient and reliable control, someimplementation constraints must be taken care of.

The operations performed by the controller haveto comply with a standard sequence. The firstoperation performed is the measurement and theanalog-to-digital conversion of the input signal (1).Once converted into a digital number (2), thisvalue is compared to a reference value (3) resultingin an error signal which is used by the controlalgorithm to compute the command or outputvalue (4). Other quantities may also be computeddepending on the application (such as parametersor state estimates). The output value is thenconverted to an analog signal (5) and applied tothe controlled system. This sequence of operationsforms a real-time task (RTT), which is repeatedat a fixed interval, called the sampling period orthe cycle time. In advanced applications, theimplementation of different real-time tasks withdifferent sampling periods and priorities may berequired. The sampling period must be adapted tothe dynamics of the physical system. If the samplingperiod is too large, the control of the system will belost and if it is too short, quantisation problemsmay occur.

To allow the use of the traditional controlanalysis and design techniques, the samplingperiods are assumed to be constant. In otherwords, the cadence at which the real-time tasksare called must be as regular as possible. This isgenerally guaranteed by interruptions. Interrup-tions are generated either by an on-board timer(host computer) or by an external source locatedon the acquisition device (Fig. 4). These inter-ruptions tell the operating system (OS) to switchfrom the current task to the real-time tasksaccording to their respective priority. Once thereal-time tasks are completed, the OS resumesthe original task.

The cadence is mainly limited by the under-lying OS. Most of today's OSs only partiallysupport real-time operations and thereforeaccurate cadence cannot always be guaranteed.The use of specialized OSs, dedicated processorsor embedded systems are required for mission-critical implementations where, for example,people or equipment safety must be guaranteed.

The accumulated duration of the real-timeoperations should be smaller than the samplingperiod for obvious roll-back reasons.

The time between the occurrence of the inter-ruption and the launch of the real-time tasks iscalled the latency. This time is variable and OSdependent but should be much smaller than thesampling period.

Under tight time constraints, the real-time tasks(RTT) are generally monitored by a supervisiontask (ST). The supervision task has a lower prioritythan RTT and runs asynchronously. The ST

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

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

Introduction to Real-time Control using LabVIEW with an Application to Distance Learning 3

performs all the functions that are not time depen-dent such as managing the user interface. TheST exchanges data with RTTs through a circularbuffer (Fig. 5). The RTTs update one position ofthe buffer at each interruption, on the other handthe ST uploads the all buffer in one operation. Thecycle time of the supervision task is generally muchlonger than the cycle time of RTT.

When the user wants to modify a RTT para-meter, the RTK must reflect this modification inreal-time (interactivity). The user parameters aretransmitted asynchronously by the ST to the RTTthrough a buffer. This asynchronous buffer is notupdated at each interruption, but only when aparameter is modified.

Requirement for real-time control in educationThe real-time control capabilities required in

education are generally reduced compared toindustrial applications, mainly because laboratoryexperiments only show one aspect of the theory ata time. Usually, only one physical system iscontrolled and only one real-time task is sufficient,such as open-loop measurement, identification orclosed-loop control.

To minimize the time spent by the students inthe laboratory, the application should be welldesigned and well integrated within the environ-ment. The user interface should be of high quality.This might be different from industrial productswhere the GUI is less important in the exploitationphase. As a consequence, enough processor timeshould be reserved for the supervision task which

allows interaction between the user and therunning controller.

The classical trial and error learning approachimplies that successive changes should be made inthe control algorithm before getting the requiredor desired dynamical performance. This can bedeveloped using a fast prototyping environmentwhere the design-implementation-test cycle shouldbe as short and as integrated as possible.

The use of a software-only solution guarantees alow price and a great expendability. Moreover,remote experimentation, presented later, relies ona software-only solution for the distant users.

FUNDAMENTALS OF PID CONTROLLER

Typical controllers are implemented as numeri-cal algorithms that are designed to compute, atevery sampling time tk � kh (where h is thesampling period and k is the sample index), acorrection factor u�k� which is added to thenominal excitation of the controlled process. Thenominal excitation is a predefined signal based ona priori knowledge and issues to bring the processto desired operation conditions or to track giventrajectories. The correction is necessary to bothhandle unexpected disturbances which affect thedynamic behaviour of the controlled process andto cope with the unavoidable imprecision of thenominal excitation.

The most commonly used controller is calledthe PID. The corresponding algorithm issues a

Fig. 5. Data sharing principle. The RT task loop reads the input, executes the control algorithm (PID), writes the output and saves oneposition 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.


correction according with the time evolution ofthe actual error e�k� existing between the desiredand the measured output of the controlledprocess, respectively denoted yc�k� and y�k�.The acronym PID is due to the way the correc-tion is computed. The first term uP�k� of thecorrection is proportional (P) with the currenterror:

uP�k� � KP e�k� �1�The second term uI �k� takes into account theerror history in order to cancel out an eventualbias. To avoid the storage of all previoussamples, the past behaviour is summarised usingthe integral (I) of the error signal. In the discretecase, the integral can be evaluated in various ways.The method chosen is the sum of the trapezoidalareas obtained by linking the successive errorvalues (Fig. 6).

uP�k� � uI �k ÿ 1� � KP1

TI

e�k� � e�k ÿ 1�2

� �h

�2�In addition, the correction has to take into

account the speed of the error evolution. If theerror varies quickly, the correction has to be

stronger to avoid overshoots. Such an action isobtained by introducing a last term UD�k� which isproportional to the derivative (D) of the errorsignal computed using the last two availablesamples.

uD�k� � KP TDe�k� ÿ e�k ÿ 1�

h�3�

Finally,

u�k� � uP�k� � uI �k� � uD�k� �4�In equations 1, 2 and 3, the factors KP, TI and TD

are the tuning parameters defining the behaviourof the closed-loop system.

It is essential to underline that the PID describedin this chapter is purely discrete, which is the rightform for a computer implementation. Rigoroustechniques based for example on the Z-transformcan be applied for analysis and design purposes [2].However, it is often sufficient to carry out a singleopen-loop experiment on the physical system to becontrolled to get a convenient set of parameters.The idea is to apply a step of level U as anexcitation signal of the system (Fig. 7). The corre-sponding variation of the output provides theslope a at the inflection point (or at infinity if theresponse reaches no stationary value) and the time

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

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


interval L between the step and the crossing of thetangent at the inflection point with the time axis.

The convenient parameters are listed in Table 1,with respect to the results of the experiment andthe desired controller type.

The resulting sequence of operations which haveto be implemented to complete the PID correctionat time k is:

. acquire the measurement y�k�;

. get from the user the current PID parametersKP, TI and TD, as well as the reference signalyc�k�;

. compute the error e�k� � yc�k� ÿ y�k� (somefiltering can also be considered here);

. compute uP�k�, uI �k�, and uD�k� if applicable(the states of the controller uI �k ÿ 1� ande�k ÿ 1� have to be available);

. compute the sum u�k� and limit its value in arange compatible with the physical devices(power amplifier, motor);

. output the previously computed control signalu�k� (orwait for thenextsamplingperiodtodoso).

PID CONTROLLER IMPLEMENTATIONSWITHIN LabVIEW

This section presents the different alternatives forthe real-time implementation of a PID controller

using LabVIEW (National Instruments propose aPID toolkit with autotuning). The first solution isa plain LabVIEW implementation written in G.The next two solutions combine LabVIEW with areal-time kernel allowing the code of the controltask to be written in C or as a MATLAB/Simulink S-Function. The possibility to call a Croutine or an S-Function enables the use of legacycode. The last implementation relies on the newLabVIEW RT. The professional system Concur-rent PowerMAX as well as other embedded solu-tions are not evaluated in our review.

Plain LabVIEWIn LabVIEW, the execution of the program,

called the Virtual Instrument (VI), is paced bythe data flow. This flow can be slowed down orinterrupted by some external events such asnetwork accesses, mouse movements, disk opera-tions or other OS events. The cycle time for acontrol loop written in LabVIEW is therefore non-deterministic and dependent on the time used bythe other VIs running and to the computer's otheractivities. This implies that control of the physicalprocess might be lost when these events occur(Fig. 8).

To guarantee the correct behaviour of thesystem, the user must ensure that the duration ofthese events is much smaller than the chosensampling period. This can be partially alleviatedby using the multi-threaded functionality ofLabVIEW and by setting appropriate prioritiesto the different VIs. The main application is splitinto Sub-VIs, each representing a different thread(Fig. 9).

Higher priority is given to the PID code, whichcan be written using the regular LabVIEW func-tions or by using a formula node. The lowestpriority is given to the user interface updatewhich corresponds to the supervision task.

The appropriate use of the DAQ board can alsocompensate for the varying latency since many of

Table 1. Parameters of the P, PI or PID controller.

Controller KP TI TD

PU

a LÐ Ð

PI 0:9U

aL3.3 L Ð

PID 1:2U

aL2 L 0.5 L

Fig. 8. Unpredictable event occurrence. The LabVIEW execution flow can be interrupted by some external events such as networkaccesses, mouse movements, disk operations or other OS events. The cycle time for a control loop written in LabVIEW is therefore

non-deterministic.


today's universal acquisition boards have therequired timers and circuits to generate interrupts.The advantage of using the DAQ board interruptsis that such signals can also trigger, very accu-rately, the acquisition and the buffering of thedata, this independently of other computer activi-ties (Fig. 9). In such a way, the delay separating theinterrupt issuing and the sampling is inexistent.This is essential to achieve a predictable behaviour(invariant sampling period) and to conform withthe applicability conditions of the stability criteria.In this configuration, the latency corresponds tothe delay between the interrupt occurrence and theeffective buffer retrieval by the Read AD sub-VI.Fortunately, this delay is not critical to the controlloop reliability as long as it does not exceed thesampling period. If this happens, one or moresamples are not taken into account, which can bedisastrous. To detect such an event, the Read ADsub-VI must ensure that there is one and onlyone sample in the acquisition board buffer. Thismeans that the next interrupt has not occurred andthat the LabVIEW loop cycle is smaller than thesampling period (as expected). In this case, themain loop is running as fast as possible and waitsfor a measurement to arrive in the board buffer.

Alternatively, without the use of the DAQ boardtimers, the LabVIEW main loop should cadencethe execution of the controller using the WaitUntil Next ms Multiple VI (Fig. 10). In thiscase, the AD conversion is triggered at eachexecution of the main loop and the controller hasto wait for the data to become available. SinceLabVIEW execution can be interrupted ordelayed, it is not guaranteed that the given cadencecan be followed. Moreover, undesirable jitter inthe sampling time is impossible to avoid.

This jitter of the sampling period is particularlycritical for the computation of the derivative termin which h appears explicitly. If the desired value ofh is used instead of the real one, huge errors mayoccur. To compensate for the sampling period

variations, a timestamp needs to be stored witheach measurement sample. This timestamp will beused to determine the real sampling period to beuse in the numerical derivation, as well as for thedisplay and the storage of the data.

LabVIEW with the real-time kernelTo improve the performance of controllers

running within LabVIEW and to reuse the legacycode (C and S-Function) which may have beendeveloped and tuned for other applications, areal-time kernel (RTK) which handles all thereal-time operations has been designed, thusremoving the need for LabVIEW to do this [3].The RTK is able to execute the user's real-timetask (RTT) repetitively at a fast and accuratepace. To achieve these requirements, the RTKrelies on interrupts.

The real-time kernel is implemented in C as acode interface node (CIN, LabVIEW externalcode). This kernel allows one or more userroutines, typically a controller routine, to becalled by the OS at interrupt time.

Fig. 9. Multi-threaded implementation. The display loop and the real-time (RT) loop run in different threads. The Display loop has alower 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.

Fig. 10. `Wait Until Next ms Multiple' loop cadencing. TheAD VI adds a Timestamp to the measurement to compensate

the sampling period variation.


The RTK should be seen as a standalone back-ground application, which communicates throughshared memory with the foreground application(LabVIEW) holding the user interface. The RTKhas two main functions: the first is the communi-cation with the physical process via acquisitionboards. The second is the management of theuser-defined RTT, which can be any type of real-time operations such as real-time control, real-timesimulation or for example on-line identification.

The user-defined real-time tasks are called by theRTK at each sampling period or at a multiple ofthe sampling period (sub-sampling). If there ismore than one RTT defined for the same board,the RTK calls them in a pseudo-parallel fashion.This simplifies the implementation of parallel orcomplex operations. In the example of a singleRTT performing a cascade control with two PIDs,the RTT can be split into two single PID control-lers. In the same manner, sub-sampling allows twodifferent tasks such as filtering and control to becalled at different paces. Instead of having thecontroller called at a faster than needed samplingrate in order to filter the input signal(s), these twooperations are implemented in separate routines:the filtering operation which is performed at eachsampling period, and the control operation whichis called, for example, every twenty interrupts. Thefiltered signal is shared between the filter andthe controller using the buffer. This methodlowers the processor's load and makes the RTTeasier to write.

The input and output data defined by theuser are stored in an internal buffer. This bufferis updated synchronously with each interrupt.When called by an interrupt, the RTK puts thenewly acquired values into the buffer and thenretrieves the value for the next outputs from thesame buffer. For display purposes, this buffer canbe partly or completely retrieved asynchronouslyby LabVIEW. Besides input and output data,

other information such as timestamps, executionerrors, and virtual channels holding internal statesof a controller (for example the previous integralvalues) are stored in the buffer.

A set of VIs allows to control all the requiredoperations related with the RTK such as con-figuring the hardware, configuring the RTTs andstarting and stopping controller routine (Fig. 11).Another VI performs the data exchange from andto the controller routine. Those VIs are verysimilar to the current DAQ VIs.

The RTK allows the user to install one or morereal-time tasks. These tasks are Dynamic LinkedLibraries (DLLs written in C) or S-Function(written in MATLAB format). To avoid havingto worry about complex compiler environmentissues, the compiler can be controlled directly bya Real-Time Framework [3]. Currently, only theMacOS platform is supported. A freeware subsetof this environment is available on-line (http://iawww.epfl.ch).

MATLAB and Simulink (http://www.math-works.com) are widely used in the engineeringworld. The simulation and the design of controllerscan be conducted using the MATLAB/Simulinklanguage. Instead of rewriting the code developedin C or in G, the RTK can reuse the legacy code bycalling, at interrupt time, an interpreter, whichimplements a large subset of the MATLABsyntax. The built-in interpreter has been writtenwith the primary purpose to be run in real-time.Due to the extensive computer load resulting fromthe interpretation which is carried out at everysampling period, the achievable cycle time islarger (by a factor of 10) in that case than in theone when calling C code.

LabVIEW RTNational Instruments proposes an intelligent

DAQ board containing all of the necessary compo-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 initialisedand 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.


consists of two components: a processor boardand a DAQ daughter card. The processor boardincludes many of the PC components, but does notcontain hard-drive or other standard I/O devices.The daughter card is similar to other NI DAQproducts.

A multi-threaded real-time engine (RTE) runson the processor board using a real-time operatingsystem (RTOS). The RTOS ensures that thescheduler and other operating system servicescomply with the real-time requirements.

The RTE executes LabVIEW RT programswhich are exactly the same as the standardLabVIEW programs but with some limitations.For example, there are no disk access and noEthernet communication capabilities due to thelack of peripherals on the RT board and due tothe potential RTE performance degradation theywould imply. Attempting to use these unsupportedfunctions in an embedded LabVIEW RT applica-tion produces standard LabVIEW error codes.

The development system runs on Windows(NT/9�). Before being executed, the VIs aredownloaded on the RT board. Once on theRTE, the VIs run without any outside inter-ference thus allowing deterministic cycle times.The VIs running on the RTE will still be runningeven if the host computer reboots. For displayand other purposes, the VIs on the RTEexchange data with the RT development systemvia messages or shared memory. The display ofthe user interface is performed automaticallywithout any user programming.

There are no programming differences betweenLabVIEW RT and the standard version ofLabVIEW. Having the critical part running onthe dedicated RTE ensures that the embeddedcode will not be interrupted by any other outsideevent. The PID controller can be cadenced with themetronome (Wait Until Next ms Multiple) func-tion (Fig. 12). This function puts the currentthread into sleep and allows other threads to run.By giving the time critical priority to the embeddedPID VI, it is ensured that the loop execution time isguaranteed, this provided that the loop time issmaller than the sampling period. If the timecritical thread consumes most of the processortime, the others threads, such as the communi-cation thread, which exchange data with the RTdevelopment system will not have time to executeresulting in a sluggish user interface update. Theuser interface may even look frozen if the timecritical thread consumes all of the processor time.In that case, the embedded VI is still running, buthas no time to transfer the data to the developmentsystem. This might be suitable for industrialsystems not requiring a user interface, but foreducation it is important to interact in real-timewith the controller. Thus, the sampling periodshould allow enough time for the user interfacemanagement.

Concurrent PowerMAX real-time LabVIEWNational Instruments has ported LabVIEW to

the Concurrent PowerMax real-time architec-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-RTboard. It exchanges data (parameters and circular buffer) with the local VI containing the user interface by using the RTE_PEEK and

RTE_POKE VIs.


multitasking UNIX-based operating systemwhich can guarantee a given latency and adeterministic real-time response. This is a scalable,professional (read expensive for education) systemand therefore outside the scope of this paper.

DiscussionDifferent solutions have been presented for

implementing a PID controller within LabVIEW.Depending upon the financial and technicalrequirements, different solutions can be selected.Table 2 summarises the different possibilities.

In education, it is important to consider thecoding simplicity according to the students back-ground which may vary among engineeringmajors. The acquisition and maintenance cost ofthe real-time environment are also important. Thepart of the budget dedicated to hardware should bekept as small as possible, limiting the possibility touse professional hardware solutions. A software-only solution should be chosen. Moreover, due tothe strong interaction between the hardwaredrivers, the OS and the control software, real-time environment upgrades have to be carefullyplanned.

As it will be shown in the next chapter, asolution without additional hardware is preferredsince distant users do not want to duplicate theDAQ board or the embedded real-time environ-ment needed to locally control the remote system.

EXTENSION TO DISTANCE LEARNING

Motivation for remote experimentationCurrently, traditional and virtual universities

propose on-line courses based on electronicdocuments and multimedia presentations enrichedwith video and audio broadcasting [4]. While thestudents can take these classes from a remotelocation they still have to come onto the campusfor the laboratory practice. This restriction can beovercome by allowing students to access thelaboratory facilities from a distant location tocarry out hands-on sessions [5].

The development of remote-experimentationfacilities is also motivated by the fact that thedemand for access to laboratory facilities is

growing rapidly in all engineering colleges. At thesame time, the number of students is increasingwhile the allocated laboratory resources do notkeep pace with this change. Being able to makethe laboratory infrastructure accessible as virtuallaboratories, available 24 hours a day and 7 days aweek, goes a long way towards addressing thesedifficulties, and would also contribute to loweringthe costs of operating the laboratory in the longterm. Moreover, students are able to carry outexperimentation at the precise stage in their learn-ing process when they need to compare theirknowledge to reality. This is an additional benefitof such a new paradigm introduced in distancelearning. The increased availability is obtained byallowing students to reach the laboratory facilitiesvia the Internet using a modem, or from otherpoints of network access, such as computers avail-able at different campus locations. The Internetoffers many advantages over other technologies,which makes it the medium of choice. The firstadvantage is its price and availability. Nowadays,almost every household has a telephone line whichmakes a potential Internet connection. Currenttechnologies such as ISDN or 56K modems giveenough capacity to transmit voice and video withan acceptable quality. In a remote experimenta-tion, not only the users may be distributed all overthe world, the experiments can also be distributedamong the potential users (such as universities)thus giving an opportunity to reduce the costsassociated with laboratory facilities by sharingunique or expensive equipment.

The learning environment is based on a client/server architecture (Fig. 13). Given its fully com-puter-based implementation, the laboratoryenvironment can easily be expanded for remotemanipulation. The main concept in turning thelocally-controlled setup into a remotely-controlledone consists in moving the user interface awayfrom the experiment. Two distinctive parts result:the remote client and the local server.

. The remote client is a computer equipped withthe functionality necessary to observe and to acton the remote experiment. The client applicationis a VI compiled for the target platforms. ThisVI provides the user with a complete interface to

Table 2. PID implementation solutions.

Solution Coding Cycle time Platform Interrupt Hardware

Plain LV G 10 ms2 All soft DAQMulti-threaded LV G 5 ms2 All3 soft DAQRT Kernel calling C G1 & C 0.2 ms2 Mac4 soft/hard DAQRT Kernel calling S-Function G1 & Matlab 5 ms2 Mac4 soft/hard DAQLabVIEW RT G 1 ms Embedded on PCI, PXI hard RT5 & DAQPowerMax 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.


the real process. It is used to generate excitationsignals and observe corresponding responses.The main concept of such an interface is toprovide a general view of the physical processevolutions, and to allow full control of theoperations.

. The local server is the computer located nearthe real process and equipped with the hard-ware interface to the sensors and actuators. Thevideo camera and microphone can be assimi-lated to sensors. The server application receivesthe client commands and transmits them to thereal process. It also returns the states of thephysical process to the client including an image.

Three modules are necessary to build the client andthe server applications: the GUI module, the RTmodule and the COM module (Fig. 14). Theapplication used locally can be split in twomodules: the real-time controller (RT) and theuser interface (GUI). The client and the serverapplication can be designed by adding a commun-ication module to the two existing modules. Theclient application is made up of the GUI and thecommunication modules. The server application ismade up of the controller and the communicationmodule. The server may require a basic user inter-face for supervision of the ongoing operations. Thecommunication module allows the client andserver applications to exchange information withother computers distributed in different geographi-cal locations. This module also takes care ofsecurity issues regarding network management.For example, it prevents unauthorised access andschedules logins to avoid conflict.

By isolating carefully these modules in thedevelopment process, it is easy to port a local

solution to a remote one, or port the remotesolution to different physical systems.

RequirementsDistancing the user from the local experiment

while keeping the same amount of benefits as localexperimentation is challenging. Not only the samedegree of interactivity must be maintained, but theremote solution must also allow the user to `feel'the real experiment. During local experimentationstudents can use their senses of vision and hearingto perceive the effect of their acts on the controlsystem. In a remote experimentation mode, thisspecification is addressed by providing audio andvideo feedback information in addition to theinformation given to the remote computer throughthe graphical user interface (GUI). Obviously,such feedback needs to be given in a reasonableamount of time, minimising the misleading (andmost likely also disturbing) effects of signal-transport delays. For example, a remote userwill not find acceptable feedback that arrives 30seconds after an action has been accomplished,while the local response is achieved in fractions ofa second. Consequently, fast system responsivenessis a key goal in all developments for remoteexperimentation. As might be expected, idealinstantaneous responses are not possible, butresponse times should still be minimised.

In addition to the need to remotely `feel' thephysical system, it is also necessary to remotely`touch' it. For example, perturbing the system byhand to observe the reaction of the controllershould be possible. This is achieved by introducingan additional actuator or by artificially altering

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


some control or measurement signals to mimic thedesired effect.

The interactivity must be adequate, otherwisethe gain induced by remote experimentation will beminor and the facility will probably not be used.The objectives for a fast application such asmotion control, where the user should be able tocatch the dynamics of the process, are differentfrom the objectives of a slow chemical plant wherethe user needs mostly to deal with the complexityof the system. The solution presented here focuseson fast dynamic systems such as electromechanicalprocesses. Since they have mobile parts, they canbe monitored remotely by cameras. In the case ofvisually static systems such as thermal systems,remote observation can be enabled by the use ofsensors that modify their appearance according tothe measured state.

Streams and adaptationAdaptation to the network (i.e. Internet) load is

necessary for using wisely the available bandwidth.In the future, unfriendly applications, which donot adapt might be banned from networks if theydo not behave adequately.

Different kinds of information are exchangedbetween the server and the clients according tofour different classes:

. the data stream representing the measurementsmade on the physical system;

. the audio/video stream acquired by the camera;

. the parameter stream reflects the user actions onthe client side;

. the administrative stream which deals with thelogin/logout issues [6].

The adaptation is made by assigning a differentpriority to each stream. An algorithm, taken thenetwork load seen at the client side into account,determines the server bandwidth usage. Based onstream priorities and the information coming fromthe client, the server optimises the packet size andpacket rate. The server application can adapt theamount of information transmitted by increasingthe image compression factor and/or by deci-mating the measurements. This scheme canadapted in real-time to a wide range of bandwidthfrom modem line to LAN connection. A specifictechnique is used to recover packets, which are lostduring the transmission.

DISTRIBUTED APPLICATIONS USINGLabVIEW

Different solutions exist for controlling acomputer remotely. Maybe the simplest one isthe sharing of the remote screen and the redirec-tion of the different local input devices such as themouse and the keyboard. The informationexchanged by the screen sharing application, suchas Timbuktu (http://www.netopia.com), is mainlypixels representing the remote screen. The dataused by the remote experimentation have a morecompact representation and they can be updated/transmitted more efficiently since conventions existbetween the client and the server. For examplewhen a new point is added to the measurementdisplay (1 in Fig. 18), the screen sharing appli-cation will update and transmit the all display tothe remote computer. A better alternative is to

Fig. 14. The three modules for building the client and server application. The RT module handles the real time operations (videoacquisition 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.


only transmit the new point, resulting in a muchmore efficient use of the bandwidth.

National Instruments provides a fully featuredweb server written in LabVIEW. When runningthis server, the front panel (FP) of running VIs canbe transmitted to a Web browser and updated atregular intervals using the server-push/client-poptechnique. The server also support CGIs (commongate interface) written in LabVIEW such as imagemap. The combination of different VIs (FP image,CGI, and Form) can provide the client with a viewof the remote setup. The user will be able tointeract with the server within the limitation ofcurrent Web technology, i.e. the slow image update(a few frames per minute), the limited use of theform format to transmit information to the serverand the rather cumbersome LabVIEW CGIprogramming required on the server side.

Nacimiento (http://www.Nacimiento.com) soft-ware proposes AppletVIEW, a toolkit whichprovides users with a complete development en-vironment for creating Java pallets as front-endinstrumentation panels that communicate with aLabVIEW server. Web pages may contain knobs,sliders, switches, and charts that are actualcontrols that communicate with the AppletVIEWVI. This is done without any Java programming.

LabVIEW 5 introduced a new mechanism,called VI Server, to programmaticaly accessLabVIEW objects and functionalities. The serverrelies on TCP to exchange data between VIs (localand remote). This is done transparently and nospecific knowledge is required. The security isdefined on the server side. Different methods canbe invoked, for example a VI can remotely set acontrol value, open a given VI or print the frontpanel. Another possibility is to call a remote sub-VI by invoking a call by reference node. Theprinciple is similar to a remote procedure call(RPC) under UNIX. The only difference betweena local or a remote call is the need to define the IPaddress and IP port of the remote machine. Priorto calling the sub-VI, the user needs to establish aconnection with the server. On termination, theconnection needs to be closed. A simple example of

a remote machine transmitting its local time usingthe call by reference node is shown in Fig. 15.

Four `call by reference VIs' were used toremotely control the physical setup. The first VItransmits the controller parameters from the clientto the server, the second VI sends the measuredvalues from the server to the client, and the thirdand fourth VIs implement watchdogs to detect ifthe client or the server are still available. Thismethod has the advantage of being easy to imple-ment and the performances are good on a lightlyloaded local area networks (LANs). On the otherhand, this method suffers from the TCP limitation(TCP slow start) when the network load increasesor when the connection is not reliable implyingpacket losses.

LabVIEW UDP tools are used to overcome theTCP limitation, they allow full control of thebandwidth usage. This method is well suited fortransmission over the Internet. UDP does notsuffer from the slow start limitation, but this hasa price: the packet delivery is not guaranteed. Inother words UDP is connectionless, which meansthat the server has no knowledge of the packetarrival at the client side. The client application hasthe responsibility to inform, if required, that apacket has been lost and ask for its retransmission(this is done automatically under TCP).

For some applications, the packets can belost without affecting the client application. Forexample, when transmitting a movie, a frame canbe lost and the movie is still understandable.Remote experimentation belongs to this categoryand implements an advanced control scheme ontop of UDP.

Figure 16 presents a local time server usingUDP. It has the same functionalities as theprevious example presented. The client applicationlistens to a given port and waits for a UDP packetto arrive. The UDP Open and UDP Close VIs areonly used to specify the UDP port to listen to andto free the port once the program quits. There isno connection establishment under UDP. It is theapplication developer's responsibility to define theconnection 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 withthe 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.


task that requires a good knowledge of commun-ication technology.

EXAMPLE

The electrical driveMany mechatronic systemsÐi.e., those that

integrate electrical and mechanical partsÐused ina control engineering laboratory are attractive to

students because they often yield responses thatare easy to identify visually. Furthermore, experi-mentation can typically be conducted in a reason-able amount of time. For example, a completelaboratory experiment could take between oneand two hours of work, during this period thestudent carries out modeling and design studies,including shorter periods (5 to 15 minutes) ofinteraction in real-time mode with the experimentfor measurement and control purposes.

Fig. 16. A simple time client-server application using UDP. The Sender VI continuously sends its local time to the specified IP Addressand 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.

Fig. 17. Electrical drive. (1) motor, (2) load, (3) magnetic brake, (4) position potentiometer, (5) reference potentiometer.


The electrical drive is a typical mechatronicsystem (Fig. 17), which is used in many textbooksto illustrate an automatic control system. Theexample considered here is simple and exhibits analmost linear behaviour. It consists of a 14 W DCmotor (1) equipped with a built-in tachometer. Themotor drives a loadÐin this case a steel disk (2).An adjustable magnetic brake (3) introduces aviscous friction effect, allowing thereby a modifi-cation of the time constant during operations.Either axle angular position or speed can becontrolled by adjusting the motor voltage.

The angular position is measured by a poten-tiometer (4) connected to the motor axle througha reduction device. The reference value can begenerated manually by a similar potentiometer(5). Both potentiometers are equipped withenlarged disks, which permit easy visualisation ofthe motion, either locally or remotely.

Visual feedbackThe visual feedback is provided by the graphical

user interface (GUI). A cockpit-like metaphor [5]is used to present the different information to theuser (Fig. 18). The GUI is split into four areas. Thescope area (1) enables the user to follow the timeevolution of all signals relevant to the experiment(for example the internal states of the controller).The visual area (2) provides the video feedback ofthe real process enhanced with the virtual repre-sentation of the process. The user is allowed to

modify the parameters (3) of the controller as wellas other adjustable characteristics of the experi-ment, such as the sampling period. The pushbutton is meant for remotely perturbing thephysical system. The administrative area (4)manages the different connection stages such asuser login and quitting.

Augmented reality and video grabber VIsVideo feedback is especially well suited for

mechatronic processes. Special attention has beenmade to providing the user with not only the videoimage of the process but also by superimposingother information such as the virtual realityrepresentation of the physical system, resulting acomposite image called augmented reality (Fig. 19).The virtual image is derived from the measure-ments made on the real system, whereas the videoimage comes from the video camera. Special care isneeded to synchronise these two representations.This is largely compensated for by the benefitsresulting from their combination.

The virtual image is also useful when the avail-able bandwidth is small. Instead of using a largeportion of the available bandwidth with the videoimage, only a few video images per second (1 orless) are sent. The missing dynamic of the video iscompensated for by the animation of the virtualimage. When using the highest compression factor,the smallest size for the video image is about 2Kilobytes whereas for the `same' information

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

Fig 19. Video and virtual reality image. (a) Generally speaking the video image and the virtual view are synchronized. (b) The virtualview 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.


(angle), only 2 Bytes are needed to update thevirtual image. This wide range of possible packetsize gives considerable room for adaptation.

Observe that the video image carried far moreinformation than the virtual image. Through thereal image, the user can get a feeling for the realsetup. This is essential in remote experimentation.The video image also gives environmental informa-tion which is undetectable using the virtual image,as for example a wire running across the movingparts of the electrical drive.

A set of VIs was developed to grab imagescoming from a video camera. These VIs arebased on QuickTime (QT). They can use anyinput source supported by QT provided that thecorresponding vdig (driver) exists. The image isdisplayed in a LabVIEW picture indicator.These images can be compressed in JPEGformat (other formats are possible) beforebeing sent across the Internet. On the receiverside the images are first decompressed and thendisplayed. If needed, the virtual imageis superimposed to the video image beforebeing displayed.

Figure 20 presents a simple video grabber withan augmented view of the real system. The image isupdated 5 times per second.

CONCLUSIONS

One of the major requirements in engineeringeducation is to provide students with convenientenvironments to practice what they have beentaught or what they have learned conceptually.This is true in traditional education as well as indistance learning. It should be stressed that local orremote experimentation on physical systems is anessential complement to simulation and written

exercises. Compared with experimentation invirtual reality, real experimentation is easier toimplement and more versatile. In fact, adding orselecting another physical setup does not involvethe elaboration of complex mathematical modelsand graphical representations. In addition, engi-neering students gain confidence in their ability todeal with real applications, which is going to betheir career challenge.

When planning to set up an environment forexperimentation in academia, the criteria forselecting a commercial solution are different fromin the industry. Usually, the need for interactivityis higher and the overall capabilities are lower. Thescalability and the ease in designing a userinterface provided with LabVIEW, as well asits multi-platform implementation, make thispackage well suited to develop didactic tools.Moreover, the possibility to compile standalonevirtual instruments, which can be distributed freelyto the students, is a big advantage.

Various ways exist of exploiting LabVIEW forimplementing automatic control solutions accord-ing with the user requirements in terms of qualityof services and the constraints inherent in thecontrolled physical system. The most critical partis the handling of the real-time operations. Thesurvey of different solutions given in this paperenables the selection of the solution most suit-able for a particular application. Depending onthe curricula into which the practice is inte-grated, coding the control algorithm in G, Cor MATLAB may be chosen. The required cycletime is also an important element when selectingan implementation solution. Finally, when securityis a major concern, embedded solutions have to beconsidered.

Programming is usually not the main topic ofautomatic control laboratory sessions. Practicaltraining of the material learned is the main

Fig. 20. Simple QT frame grabber. The video source is selected by using the SETUP_QT VI. The acquired image (QT_GRAB VI) isconverted 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.


point. Thus, three different implementationapproaches have been chosen at the Swiss FederalInstitute of Technology. The first one is appliedto engineering students spending only a few hoursin the laboratory concurrently with the basiccontrol course. They are provided with standaloneVIs which enable them to experiment locally orremotely the behaviours of the controllers theyhave studied in class, such as the PID controller.In such a case, they use high level VIs, which letthem observe the effect of changing importanttuning parameters. But, they do not changethe underlying control algorithms, so requiringno programming. These VIs are developed by theeducators using LabVIEW enhanced with theReal-Time Kernel. The second approach concernsstudents involved in advanced automatic controlcourses who may want to validate the variouscontrol algorithms they have studied. Sincethey usually carried out the design and thesimulation with MATLAB, they are providedwith LabVIEW enhanced with the Real-TimeKernel and the MATLAB interpreter for imple-mentation purposes. The last approach is followedby the students, which conducts a semester or adiploma project on a didactic or industrial setup.Here, as the constraints may vary, they under-took a short introductory course in real-timeimplementation and LabVIEW programming

before choosing the most suitable solution totheir application.

For distance learning purposes, the VIs aredeveloped by a team of educators and computerscientists. From the server side, a real-time controlloop is implemented with one of the availableimplementation solutions. To guarantee the bestpossible quality of service and to provide aversatile client management, the communicationlayer is developed using the LabVIEW UDP tools.To broadcast the view of the real experimentrunning remotely, a set of QT video acquisitionVIs have been developed. They provide LabVIEWwith a video image displayed in a picture indicatorproperly synchronised with the data display.

Finally, the proposed solutions demonstrate thefeasibility of using LabVIEW for real-time control,allowing students to carry out experimental studieseither on campus or remotely, as well as tutors topresent live in-class demonstrations. Moreover,the proposed paradigm for real-time controlimplementation is not only limited to education.In research and industry, its ease of use alsorepresents an interesting opportunity to meetthe growing needs of scientists for fast proto-typing. This paradigm enables teachers to imple-ment real-time control solutions in a reallyefficient manner, both from a time and resourcesperspective.

REFERENCES

1. D. Gillet, G. F. Franklin, R. Longchamp and D. Bonvin, Introduction to automatic control via anintegrated 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 applicationsin 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 andsynchronous 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 developpractical 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-timeexperimentation over the Internet, Int. Conf. Engineering Education, ICEE 98, paper 222, Rio deJaneiro, Brazil (1998).

Christophe Salzmann received his MS degree in Computer and Information Sciences in 1999from the University of Florida, Gainesville. He is currently a Ph. D. student at theAutomatic 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 theEPFL and for the development of the Real-Time Kernel. His research interests includereal-time computing, telepresence, distance learning, multimedia technologies andcommunication networks with an emphasis on bandwidth adaptation.

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


Associate Professor (MER) at the EPFL. His research interests include on-line optimizationand control, multimedia technologies, distance learning, telepresence, fast prototyping andreal-time implementation.

Pierre Huguenin received his Diploma in Mechanical Engineering in 1988 from the SwissFederal Institute of TechnologyÐLausanne (EPFL). He is currently a Ph. D. student at theAutomatic Control Institute (EPFL). His current research interests include real-timecomputing, modelling, non-linear control and intelligent transportation system.


Introduction to Real-time Control · introduction to the basic principles underlying real-time...

Documents

Transcript of Introduction to Real-time Control · introduction to the basic principles underlying real-time...