Creating a Generic Virtual Research Environment · PDF fileCreating a Generic Virtual Research Environment ... The goal of the thesis is to create a generic virtual research environment

Creating a Generic VirtualResearch Environment

Morten Sørensen

Supervised by Alfred Heller

Kongens Lyngby 2013

BYG-M.Sc.-12-095

Technical University of Denmark

Department of Civil Engineering

Building 118, DK-2800 Kongens Lyngby, Denmark

Phone +45 45251700, Fax +45 45883282

[email protected]

www.byg.dtu.dk BYG-M.Sc.-12-095

Summary (English)

The goal of the thesis is to create a generic virtual research environment forthe Department of Civil Engineering using the program LabVIEW. The pointis to investigate whether LabVIEW will be a tool to invest more time and e�ortin, or �nd some other tool that will be better suited to the situation in thedepartment.

Another goal for the thesis is to investigate the old weather station at thedepartment, and the system monitoring it. The system is poorly documented,and hence no one has been able to �nd a new solution for the old system.

A prototype of a virtual research environment was developed, capable of doingdata acquisition, manipulation and preservation/logging. The program is mod-ule based, to allow professors and students to create new modules to ful�ll theirneeds.

LabVIEW certainly is a useful program for the department, as it is easy to learnand the graphical approach makes it more tangible for people working withphysical components. National Instruments has many devices able to measurefrom all sorts of physical components. That combined with a good amount ofaddons available to LabVIEW to use them and an active community, meansthat LabVIEW has potential.

Tests on the old weather station could not be performed, however the old codehas been analysed to �gure out the structure of the program, datatypes andoperation. In the same time, the old setup has been documented by this project.With that, the old system would be able to be replaced with the virtual research

ii

environment developed. This was not possible due to the fact that faculty wasnot ready to take this step.

Summary (Danish)

Målet for denne afhandling er at skabe et generisk virtuelt forskningsmiljø tilInstitut for Byggeri og Anlæg ved hjælp af programmet LabVIEW. Meningener at undersøge om LabVIEW er et værktøj som instituttet skal satse på, ellerom der er værktøjer som vil være bedre egnet givet det arbejde som foregår påinstituttet.

Et andet mål med afhandlingen er at undersøge den gamle vejrstation på insti-tuttet og hele systemet der overvåger den. Systemet er dårligt dokumenteret ogingen har været i stand til at �nde på en løsning på et nyt system til den gamlestation.

En prototype af et virtuelt forskningsmiljø der var i stand til at opsamle, ma-nipulere og gemme data blev udviklet. Programmet er modulbaseret, hvilkettillader professorer og elever at lave nye moduler til at opfylde deres behov.

LabVIEW er et nyttigt program for instituttet da det er let at lære, og dengra�ske tilgang til programmering kan være mere håndgribeligt for folk der tildagligt arbejder med fysiske komponenter. National Instruments tilbyder enlang række enheder der er i stand til at måle på fysiske komponenter. Detkombineret med en stor mængde ekstra moduler til LabVIEW og et aktivtudvikler fællesskab gør, at LabVIEW har et potentiale.

Tests på den gamle vejrstation kunne ikke udføres, men til gengæld er den gamlekode blevet analyseret for at få et overblik over programmets struktur, datatyperog operation. Det gamle setup er blevet dokumenteret i dette projekt. Med detvil man kunne erstatte det gamle program med det nye virtuelle foskningsmiljø,

iv

og foretage alle målinger på stationen derfra. Dette var dog ikke muligt, dafakultetet ikke var klar til at udføre dette skridt.

Preface

This thesis was prepared at the department of Civil Engineering at the TechnicalUniversity of Denmark in ful�llment of the requirements for acquiring an M.Sc.in Computer Science and Engineering.

The thesis deals with creating a prototype of a new software platform, whichcan be used for both research and education, as well as to update outdatedsystems for the new platform. The tool to be used is LabVIEW, and the thesiswill focus on documenting the old weather station system, as well as developingthe new software platform.

The thesis consists of a short analysis of LabVIEW to see if it is able to tasksbasic for a virtual research environment, followed by a thorough investigationof the old weather station system. Finally, the new platform will be discussed.

Lyngby, 31-January-2013

Morten Sørensen

vi

Acknowledgements

I would like to thank my supervisor, Alfred Heller, for constant support andguidance throughout this thesis. He has helped me greatly with focusing on theassignment.

I would also like to thank Hans Lund and Jørgen Schjær-Jacobsen, for shar-ing their knowledge and the code for the old weather station system and foranswering questions when there were any.

A big thank goes to friends (both online and o�ine), family and co-workers, forsupport and for listening to my rants when problems arose. They have helpedme greatly to move past problems and �nd a solution.

viii

Glossary

API Application Programming Interface, a technical description on how twosoftware components can communicate, by listing available functions, theirarguments, and what can be expected in return.

Big Endian See Endian.

Cluster LabVIEW describes a cluster as a bunch of (electrical) wires, bundledtogether into a larger wire. This is comparable to structures in C/C++.

DOS Disk Operating System.

DLL Dynamic Link Library, Windows' implementation of shared libraries. Usedto group together functions which are related (like being the driver forgraphics card) and allow for execution dynamically during the executionof a program.

Endian How data are written in memory. When storing a value of for exam-ple two bytes (0xAB 0xCD), little endian stores the least signi�cant byte(0xCD) �rst (lowest address) and then the most signi�cant byte (resultwould be 0xCD 0xAB in memory), while big endian stores the most sig-ni�cant byte (0xAB) �rst and then the least signi�cant (result would be0xAB 0xCD in memory). Di�erent hardware behaves di�erently and it isimportant to remember which endian is used when reading and writingdata (standard 32- and 64-bit systems all uses the same endian, little).Mixed types of endian also exists but is not that common.

FAT File Allocation Table, simple �le system, used primarily when DOS wasa dominating operation system. FAT32 is still commonly used on thumbdrives.

x

GPIB General Purpose Interface Bus.

HP The electronics company Hewlett-Packard, but the abbreviation HP is morecommonly used.

HPIB HP Interface Bus, a communications bus created by HP, later to bestandardised and renamed GPIB.

Little Endian See Endian.

MS-DOS Microsoft DOS, predecessor to Windows and is the �rst operationsystem Microsoft developed.

SMS SolMåleStation (Sun Measurement Station), the name of the weatherstation.

SunSPOT Sun Small Programmable Object Technology, a small wireless sen-sor node developed by Sun Microsystems (now Oracle). Contains, amongothers, light and temperature sensors.

VI Virtual Instrument, LabVIEW's name for code modules in order to stickwith the electric component terminology LabVIEW uses.

VRE Virtual Research Environment

Wires A visual representation of where output from one VI in LabVIEW isused as input for another VI. This also tells in which order VIs should beexecuted, as all input to a VI has to be ready before it can be executed.

xi

xii Contents

Contents

Summary (English) i

Summary (Danish) iii

Preface v

Acknowledgements vii

Glossary ix

1 Introduction 1

2 Problem 3

3 Experimenting with LabVIEW 53.1 VRE requirements . . . . . . . . . . . . . . . . . . . . . . . . . . 6

3.1.1 Read data from �le . . . . . . . . . . . . . . . . . . . . . . 63.1.2 Read data from a webservice . . . . . . . . . . . . . . . . 83.1.3 Get live data . . . . . . . . . . . . . . . . . . . . . . . . . 133.1.4 Calculate and control . . . . . . . . . . . . . . . . . . . . 14

4 Advanced application case 174.1 The hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

4.1.1 Weather station . . . . . . . . . . . . . . . . . . . . . . . 184.1.2 HP data acquisition unit . . . . . . . . . . . . . . . . . . . 184.1.3 PC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

4.2 Source code and �ow . . . . . . . . . . . . . . . . . . . . . . . . . 194.3 Structure of �les . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

4.3.1 FIL �le . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

xiv CONTENTS

4.3.2 HPO �le . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244.3.3 KOMMENTS �le . . . . . . . . . . . . . . . . . . . . . . . 244.3.4 RIE �le . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254.3.5 HPx �les . . . . . . . . . . . . . . . . . . . . . . . . . . . 254.3.6 Borland Real48 . . . . . . . . . . . . . . . . . . . . . . . . 26

4.4 What is still needed . . . . . . . . . . . . . . . . . . . . . . . . . 28

5 Our VRE implementation in LabVIEW 315.1 The user interface . . . . . . . . . . . . . . . . . . . . . . . . . . 325.2 Program structure . . . . . . . . . . . . . . . . . . . . . . . . . . 33

5.2.1 User interaction . . . . . . . . . . . . . . . . . . . . . . . 335.2.2 The execution loop . . . . . . . . . . . . . . . . . . . . . . 365.2.3 Calling modules . . . . . . . . . . . . . . . . . . . . . . . 38

5.3 Module interface . . . . . . . . . . . . . . . . . . . . . . . . . . . 395.4 Creating a new module . . . . . . . . . . . . . . . . . . . . . . . . 42

5.4.1 Example of creating a module . . . . . . . . . . . . . . . . 44

6 Discussion 496.1 Numerical e�ciency . . . . . . . . . . . . . . . . . . . . . . . . . 496.2 Parallel execution . . . . . . . . . . . . . . . . . . . . . . . . . . . 506.3 Design �aws in LabVIEW . . . . . . . . . . . . . . . . . . . . . . 50

6.3.1 Limitations on plots visualized . . . . . . . . . . . . . . . 506.3.2 All �les must have unique names . . . . . . . . . . . . . . 516.3.3 Updating data structures . . . . . . . . . . . . . . . . . . 51

6.4 Output data limitation . . . . . . . . . . . . . . . . . . . . . . . . 516.5 Usability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 516.6 Replacing the SMS system . . . . . . . . . . . . . . . . . . . . . . 52

7 Conclusion 55

8 The perspective 57

A Java code 59A.1 Host Java code . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59A.2 SunSPOT Java code . . . . . . . . . . . . . . . . . . . . . . . . . 60

B VRE VIs 63

C Graph theory 91

D VIs to read SMS con�g �les 93

Bibliography 99

Chapter 1

Introduction

During research, test and experiments, many di�erent kinds of tools are oftenused to acquire data, manipulate it, and display it in some meaningful way.Very often all of these tools are not able to communicate with each other, whichrequires researchers and students to create all kinds of small programs to trans-form data such that the next program in the chain can understand it. Thisgluing programs together is often very project dependent, meaning that it onlyworks for the project it was created for, while a general bridge between theprograms would be useful for more than just a single project.

One way to create such a bridge, is to create a generic virtual research environ-ment, VRE. In the big picture, it looks like the simple gluing programs togetherwith scripts as described earlier, but a VRE creates a standardized way of han-dling input and output which a custom script does not ensure. This VRE canbe useful in both research and during education, and work�ows can easily beshared with colleagues or students.

According to Dr. Michael Fraser, Head of the Infrastructure Systems and Ser-vices Group at Oxford University, the de�nition of a VRE is a follows (citedfrom [Fra04]):

�A set of online tools, systems and processes interoperating to facilitate or en-

hance the research process within or without institutional boundaries.�

2 Introduction

Furthermore, a VRE is capable of:

• Research administration

• Resource discovery and access management

• Data creation, use and analysis

• Collaboration and communication

• Research publication, curation and preservation

Such a system requires a lot of work, and not all of the capabilities will besupported in the planned VRE; it will simply be a prototype. The VRE willbe running o�ine (it can post or get data from online resources though), andemphasis will be on data creation and use. Preservation of data can be done aswell, but will be in form of data �les written to disk or databases like the FedoraRepository (http://fedora-commons.org) or MySQL (http://www.mysql.com).

Many physical components are used during research as well, and many of themcan be controlled by external systems. The VRE should be able to control thesecomponents as well.

The Department of Civil Engineering at DTU has many di�erent experimentsrunning, both long and short term, to conduct test on anything from new meth-ods and materials to new potential useful sensors that could be used duringconstructions. Many of these experiments can be monitored by a computer,which leads to many small programs that only can monitor exactly that exper-iment and is not able to cooperate with any other. A common VRE would bevery useful in these situations.

Chapter 2

Problem

During the 80's, a Sun Measurement System (shortened SMS by the originaldevelopers) was constructed at the Department of Civil Engineering with so-larimeters to measure direct, indirect and global solar radiation, anemometersto measure wind speed, and so on. This should make a good base for a VRE,as it already possesses some of the qualities of a VRE:

• Any device can be monitored in real-time.

• Data from multiple devices can be obtained and displayed at the sametime.

• Data can be written to disk for further analysis later.

However, the system got has some drawbacks as well. Many of the originaldevelopers have either gone on pension or are otherwise no longer associatedwith the SMS system; that together with the very poor documentation on theinner workings of the system have made it very hard for new developers toupgrade the system. Some attempts have been made over the past ten yearsto upgrade or replace the system, but all have failed because of the missingdocumentation.

4 Problem

Another downside to the system is, that it is only capable of measurementson devices that output its value as a voltage over a wire. This works �ne forlight sensors and such, but is not very useful for devices where the developershave made the e�ort and added normal USB output to easier interface with acomputer.

To demonstrate the functions of the VRE, this project will base itself on theSMS system, because it already bears a close resemblance to a generic VRE.In the same time the current project produces the long missing documentationof the SMS in the current stage, and gives suggestions on how to replace theelderly system. As a third result a more generic VRE will be developed withthe capabilities to work with a wider range of devices.

Chapter 3

Experimenting withLabVIEW

LabVIEW by National Instrument is the tool picked to create a new VRE toreplace the old SMS system. LabVIEW was been picked for several reasons:

• LabVIEW was created with non-programmers in mind, and was madeeasy for researchers to quickly pick up and create programs to obtain andmanipulate data.

• Good debugging.

• It o�ers easy access to low level components. If an operation is not possiblein LabVIEW, bridging with C is possible.

• LabVIEW and all of National Instrument's components were designedwith sensors and measurement systems in mind.

• The Department of Civil Engineering has demanded that LabVIEW shouldbe used for this project as a strategic measure.

In addition to the above reasons, all programming elements are graphical build-ing blocks which can be stuck together in various ways to produce di�erentresults. These building blocks are called VIs, short for Virtual Instruments, and

6 Experimenting with LabVIEW

Figure 3.1: A simple example of programming in LabVIEW. Calculates thesum of (2 + 3) ∗ 5 and prints the result.

the coupling between VIs are called wires. LabVIEW uses a terminology whichresembles the use of electronic devices. The wiring gives a clear view of wherevalues are used, however, this can quickly become a downside as well. A largeVI will quickly become cluttered, and and getting a clear overview of the VI willbe nearly impossible with the amount of wiring needed. A simple example ofhow programming is done in LabVIEW can be seen in Figure 3.1. It calculatesthe sum of (2 + 3) ∗ 5 and prints the result.

3.1 VRE requirements

For creating the VRE, LabVIEW must be able to solve some requirements:

• Read data from a �le and present it.

• Read data o� a web service and present it.

• Get live data and present it.

• Do calculations on data and use it to control physical components, suchas motors, switches etc.

The following subsections go through these requirements one by one.

3.1.1 Read data from �le

The easiest, but certainly not least important, of the test cases must be thereading of data from a �le. For any VRE to be useful, old data have to be ableto be read again to further studies and manipulation. A snippet of the �le tobe read can be seen in Listing 3.1, and a visualization of the program in formof a graph in Figure 3.3.

3.1 VRE requirements 7

0 :00 9 ,23 2 ,1 3 ,1 −0,5 2 ,2 3 ,82 1 ,60 :02 9 ,2 2 ,6 4 −0,5 2 ,6 2 ,69 2 ,50 :04 9 ,18 3 4 ,1 −0,6 2 ,8 5 ,54 30 :06 9 ,19 3 ,1 4 ,1 −0,5 2 ,7 4 ,28 3 ,20 :08 9 ,2 3 4 −0,4 2 ,5 6 ,05 30 :10 9 ,2 3 4 ,1 −0,4 2 ,7 0 ,92 30 :12 9 ,21 3 ,1 4 −0,3 2 ,8 2 ,14 3 ,10 :14 9 ,21 3 ,1 4 −0,3 2 ,7 3 ,32 2 ,9

Listing 3.1: Snippet of the data �le to be read.

The �le contains solar radiation and, for this purpose, uninteresting data. Thetask will be to extract only the solar data. The interesting columns will be three(di�use radiation), �ve (direct radiation), and eight (global radiation). The �rstcolumn is a timestamp, which will also be extracted. The LabVIEW code toextract and present the data can be seen in Figure 3.2.

Figure 3.2: LabVIEW code for only reading the solar radiation data


The code continues in a loop until either stop is pressed, or end of the �le isreached. It starts by reading a single line into an array of strings. Afterwards,it picks only the columns that were interesting (LabVIEW uses zero as the �rstindex, so it becomes zero, two, four and seven) for further processing. Thesolar radiation data is all converted from text to fractional numbers, and thendisplayed on the front panel in numerical displays and a graph. The timestampis �rst split up into hours and minutes, then to be put together as a timestampand displayed on the front panel. To slow the parsing down (so humans canfollow it), an adjustable timer has been inserted.

Figure 3.3: LabVIEW user interface for the reading of solar radiation datafrom a �le

3.1.2 Read data from a webservice

With an increased desire and need for accessing data no matter where you are,webservices become more and more important, which also makes it importantthat LabVIEW can retrieve data over the web and work with it.


This example uses a webservice created by Christian Orthmann (student, DTU)for a project of his, and provides measurement data from several SunSPOTdevices1 used in the project. The webservice provides the data in a simple XMLformat. The LabVIEW code can be seen in Figure 3.4. The webservice is stillin development, so it is only able to deliver all data at a time and not only partsof it. For the current purpose, this is su�cient.

1A wireless sensor node, see the Glossary for longer description


Figure

3.4:LabVIEW

codeforreadingdata

o�awebservice,andparsetheXMLoutputto

displayit.The�gureshow

sboth

modesof

operation,acquireavailableSunSPOTs(theTRUEcase),andacquiredata

fortheselected

SunSPOT(theFALSEcase).


At the time of writing, only a few functions have been implemented in thewebservice:

• List, add or remove tracked SunSPOTs

• List all measurements for all SunSPOTs

• Extract all measurements for a single SunSPOT in XML format, not lim-iting for speci�c time period or type of data available

In the �rst mode of operation, acquiring a list of available SunSPOTs, the codefetches the webpage with a list of all the available SunSPOTs from the server,parses the HTML to get their numbers, and inserts them into a dropdown menu.For the next run, operation mode should be switched to acquire data from thatparticular SunSPOT selected in the dropdown. This time, the code fetches anXML document with all of the recordings from that SunSPOT and parses it.The data contains a value for the light measured, temperature in degree Celsius,temperature in degree Fahrenheit, and a timestamp in milliseconds.

The user interface of the example can be seen in Figure 3.5.


Figure

3.5:LabVIEW

userinterface

ofthewebserviceexample


3.1.3 Get live data

Based on the philosophy LabVIEW is created on, the utilization of live datafrom experiments must be one of the most important examples. This is also thecase that resembles the SMS system the most.

For demonstrating such an example, a microphone has been used as the sourceof the live data. The code can be seen in Figure 3.6. The code runs in acontinuous loop where it collects a second worth of data and presents it in agraph.

Figure 3.6: LabVIEW code for collecting live data from a microphone

The user interface to this example can be seen in Figure 3.7.

Figure 3.7: LabVIEW user interface of the live data example


3.1.4 Calculate and control

The example for doing calculations and using them for controlling some device,is based on the tracker from the weather station. The current position of thesun and how much the tracker should move to block it, is calculated. Thecalculations are sent to the control unit for the tracker which actually makes itmove. It is not possible to use the actual tracker for this example, so a pair ofSunSPOTs were used instead.

The calculates are based on a teaching note ([Joh]) about sun radiation, anddepends on the exact location of the tracker to calculate the position of thesun. This example only uses the sun azimuth for controlling the SunSPOT.Had it been a real tracker, the sun's height on the sky should also be takeninto consideration when moving the tracker, whether the surface is horizontalor not (i.e. angled in relation to the planet's surface or not). In this example,the surface is assumed �at and not angled in any direction. The user interfacefor this example can be seen in Figure 3.8.

Figure 3.8: LabVIEW user interface of the calculate and control example

The LEDs on the SunSPOT are used to simulate the direction that the tracker


Figure 3.9: A SunSPOT with �ve LEDs light, and the basestation.

is facing. The azimuth of the sun can take a value of ±180◦, and to normalizeit 180◦ is added to the value. Each LED represents 1

8 of 360◦, or 45◦. If theformula results in 0, the normalized azimuth is equal or less than 44◦, 1 is equalor above 45◦ and equal or below 89◦, and so on.

The formula for calculating the number of LEDs to light is as follows:

leds =

⌊azimuth+ 180◦

45◦

⌋

This number is then sent to a small Java program that transmits it to theSunSPOT which then lights the selected number of LEDs (example in Figure3.9). The source code for the Java programs can be seen in Appendix A. TheLabVIEW code can be seen in Figure 3.10.


Figure

3.10:LabVIEW

codeforcalculatingthepositionofthesun,andcontrollingaSunSPOT.

Chapter 4

Advanced application case

This chapter is both a manual and a description of the current SMS system, aswell as the setting required to construct the new VRE. The current SMS systemwas put live in 1989 as part of a research program by the Ministry of Energyand has run ever since ([Lun94]).

4.1 The hardware

The hardware of the current SMS system consists of primarily older parts, be-cause of various restrictions and limitations from when the system was �rstconstructed. It consists of three major components: the weather station withall of its sensors, a Hewlett-Packard 3852A Data Acquisition Unit to collectmeasurements from the weather station, and a PC to get the measurementsfrom the HP unit to present the data to the user and write them to disk. Anoverview of the system can be seen in Figure 4.1.

18 Advanced application case

Figure 4.1: Illustration of the current SMS system

4.1.1 Weather station

The weather station consists of a range of di�erent sensors, many of them over-lapping in functionality. Some sensors are commercial products, where othersare own creations or commercial sensors modi�ed to �t a speci�c case.

During the almost 25 years the system has been online, many of the sensors havebroken down, replaced and/or recalibrated to ensure that they work correctly.Some have been left broken as the interest in them was not high enough tojustify the hassle and expenses of replacing or repairing them. Some have beenproperly maintained and replaced/recalibrated when needed. Some of these arethe sensors that measure direct sun radiation, indirect (one with static ring toblock direct sun light, and one with a tracker1) sun radiation, and global (directand indirect) sun radiation.

4.1.2 HP data acquisition unit

The HP data acquisition unit solves the task of reading the voltage output thesensors produces and make them available for a computer to acquire and workwith them. The unit was expanded to handle 45 data channels up from theoriginal 20. Not all of them are in use, so there is room for expansion of thesystem without major problems.

1The tracker has a small disk which is used to block the sun. The position of this smalldisk is adjusted by using a small electrical motor. In the shade created by this small disk is asensor which measures di�use sun radiation.

4.2 Source code and �ow 19

4.1.3 PC

The PC is where all of the manipulation, display and storage of data happens.The PC has been replaced some times during the time the system has been inservice, but a few things have remained the same: a 3.5" �oppy disk drive, aHP 82990 HPIB extension card, MS-DOS and DESQview.

The HPIB extension card is needed to communicate with the HP unit alongwith a communication program provided by HP. Since the system is from atime before the Internet was common, and in general before sharing was madeeasy, the only way to transport data in and out of the system was though theuse of a �oppy disk.

Another weakness in the MS-DOS system is that it was not able to run multipleprograms at the same time, which was required in order to execute the HPcommunication program and the code Hans Lund et al. had developed. This iswhat DESQview handles, as it provided multitasking and windowing capabilitiesto MS-DOS.

4.2 Source code and �ow

The source code for the SMS system is written in Turbo Pascal and has beendeveloped by Hans Lund (associate professor, emeritus, at DTU) et al., and thelatest corrections and updates (2012) have been done by Jørgen Schjær-Jacobsen(electrical engineer, emeritus, at DTU). The code will only be available on theattached CD.

In the �rst versions of the system, the program had three di�erent modes ofoperation:

• Reading data from the sensors and storing them

• Reading stored data and write it in a plain text format

• Sending data over a serial connection

The mode for transmitting over a serial connection has not been used for manyyears and was scrapped in 2008.


Figure 4.2: Program �ow as seen from the log �le snippet. All the involvedterms will be discussed in the following.

One very handy method for the task investigating the �ow of the program isto look at the log �le that it produces. A snippet can be seen in Listing 4.1.It does not reveal the entire �ow, but it reveals some of the most importantparts of the initialisation process. By going through the initialisation code ofthe units2 listed in the log �le, it creates the �ow that can be seen in Figure4.2.

2012 -10 -19 12:54:20.04 Unit OpVars; starting unit init code

2012 -10 -19 12:54:21.91 Unit OpVars , proc Indl\aesMaal; EOF

encountered reading file MaalFil

2012 -10 -19 12:54:22.02 Unit OpVars; finished unit init code

2012 -10 -19 12:54:22.07 Unit Trak; end of unit init code

2012 -10 -19 12:54:22.13 Unit Data_Op; starting unit init code

2012 -10 -19 12:54:22.18 Unit Data_Op; starting proc Initialiser

2012 -10 -19 12:54:22.24 Unit Data_Op; proc Initialiser; valid

Pointerfil found

2012 -10 -19 12:54:22.68 Unit Data_Op; finished proc Initialiser

2012 -10 -19 12:54:22.73 Unit MaalInit; starting unit init code

2012 -10 -19 12:54:22.84 Unit Udlaes; starting unit init code

2012 -10 -19 12:54:22.90 Prog Get; starting main loop

Listing 4.1: Snippet of the initialisation process of the program

As hinted earlier, the log �le does not give the full initialisation path fromstart of execution to when the program reaches the main loop. To get that,

2A module, a logical collection of code. A unit in Pascal can be compared to classes inJava, and like Java, all of the units that a unit depends on are listed in the beginning of theunit using the keyword "uses".

4.3 Structure of �les 21

understanding how a unit2 is initialised is necessary. When a unit initialises,it will �rst go through the "uses" in the beginning of the unit, and start byinitialising them before it executes the initialisation code. When executing theprogram, the main unit is Get.

Get uses the units (we only look at the case where we want to collect data fromthe sensors, since that is the main case)OpVars, ReadStr, Udlaes, Crt, Dos,Data_Op and SystemPr.

OpVars is the �rst to be mentioned, so that is executed �rst. Excluding stan-dard units (Crt and Dos), OpVars does not use any other units so its initiali-sation code is executed immediately. Going through all of the �les likewise, theinitialisation �ow that follows is:

Figure 4.3: Program �ow when analysing "uses"

When comparing the two �ows, Figure 4.2 and Figure 4.3, it can be seen thatthey match.

When the system is initialised, it will stay in the main loop forever. The �owcan be seen in Algorithm 1. Before the looping really begins, it draws a gridon the screen in which values will be displayed. During the looping, it startsby printing values to the screen, then move the tracker to next position. Everytwo minute it will collect measurements from the 1-series, and every 30 minutesfrom the 2- and 3-series, and then moves all of the measurements from the ramdrive to the hard drive.

4.3 Structure of �les

The SMS system uses several custom �le formats to store data and con�gura-tions, none of which have any documentation. This is the reason why it hasbeen so hard to understand and work with the system. These results are basedon empirical tests compared with former known values of the di�erent datastructures and by studying the source code for the SMS system (also known asreverse engineering).

Another thing that has made the system di�cult to work with, is that some ofits datatypes are not fully compatible with modern datatypes (Table 4.1). Thesize of Turbo Pascal's Integer back in the 80s was two bytes ([Sto10]) where it


Algorithm 1 Main loop �ow

while True dowhile KeyPressed 6= 13 do . Enter = 13

Get.Udskriv() . Prints measured values to screenData_op.Opsamling() . Start a measurementTrak.Tracker() . Moves the trackerData_op.Tidsinterval2() . Collect 2 minute values and write them to

ram disk

if (Minut div 2) = 14) or ((Minut div 2) = 29 thenData_op.Tidsinterval30() . Collects 30 minute values and write

them to ram diskData_op.Copytohard() . Move data from ram drive to hard drive

end ifKeyPressed← ReadKey()

end whileGet.Hovedmenu()

end while

Name Length in bytes Modern counterpart

Byte 1 Char or unsigned byteChar 1 CharInteger 2 Signed shortSingle 4 FloatReal 6 None

Table 4.1: List of datatypes used and their modern counterpart. Only typeswhich are used in the SMS system are listed.

is four bytes today. However, that is a problem that easily can be solved as wecan just interpret it as a modern short (which is two bytes) type. Much moredi�cult to convert was the real type which is not a type used anymore andthat has no modern datatype that it resembles enough to be replaced with ( seeSection 4.3.6 for the solution). All data is written in Little Endian.

4.3.1 FIL �le

The FIL �le is the storage for all of the inserted types of measurements, but notall of them are necessarily in use. The structure can be seen in Table 4.2.


Name Data type Use

Middel Byte Tells how the system should interpretthe result from the HP unit. Zero is totake the last value and multiply it with afactor and round it up or down to nearestinteger. One is to take the sum, divideit with the number of measurements andthen multiply it with a factor. Anythingelse results in an invalid value.

Factor Single Conversion factor, converts from value ofthe output from the sensors to somthingcompatible with the unit type.

Maaling Integer Measurement index, used as index in theother con�guration �les and for the posi-tion in the measurement �les (HP1, HP2and HP3). The value 255 indicates thatthe measurement is not in use.

Byte The actual size of the name string.Navn String Name of the measurement, 8 bytes are

reserved.Dec Byte Number of decimals to display.Back Real Conversion factor, used for reading and

writing �les to the measurement �les(HP1, HP2 and HP3) without losing toomuch precision but still minimising thesize of the entry.

Byte The actual size of the unit string.Enhed String The unit (like Celcius or lux) of the mea-

surement, 8 bytes are reserved.Place Byte The location of the measurement in the

UI.

Total bytes per entry 29

Table 4.2: The structure of the FIL �le.


Name Data type Use

wr String The command to be sent to the HP unit,end of line is indicated with \r \n (car-riage return and new line, 0x0D 0x0Ain hexadecimal). 255 bytes are reserved,and all unused bytes hold the value ofspace (0x20 in hexadecimal).

kor Integer Index into an array that indicates thetype of correction according to the sen-sor type. Zero is none, one is 'ret', two is'CM5', three is CM11, four is 'lic1', �veis 'p1000', and six is 'therm'.

k1 Single Calibration value.k2 Single Calibration value.


Table 4.3: The structure of the HPO �le.

4.3.2 HPO �le

The HPO �le (also goes by the name HPORDRER) contains all of the commandsthat should be sent to the HP unit in order to make it take a measurement ofthe desired type on the desired channel, and return it to the computer. Thestructure can be seen in Table 4.3. The �le only contains the number of entriesas the number of valid entries in FIL.

4.3.3 KOMMENTS �le

The KOMMENTS �le is the last of the con�guration �les that describe mea-surements, and is more focused towards documenting the system for developersthan being useful for a simple user. Its most common use is to tell the channelof a measurement on the HP unit and which wires it is using. The structurecan be seen in Table 4.4. The �le only contains the number of entries as thenumber of valid entries in FIL.


Name Data type Use

Byte The size of the comment string.komment String The comment associated with the mea-

surement. 255 bytes are reserved, un-used bytes hold garbage.


Table 4.4: The structure of the KOMMENTS �le.

Name Data type Use

Byte Size of the name string.FilNavn String Name of the measurement series, also

used as the extension on measurementdata �les.

MaxInterval2 Byte Number of measurements in the seriesthat are on a 2 minutes interval.

MaxInterval30 Byte Number of measurements in the seriesthat are on a 30 minutes interval.


Table 4.5: The structure of the RIE �le

4.3.4 RIE �le

The RIE �le describes the di�erent measurement series, along with the numberof entries in the series and how often they are updated. Only 2 minute and 30minute update intervals are possible. The structure of the �le can be seen inTable 4.5.

4.3.5 HPx �les

Measurement data are stored according to their measurement series, HP1, HP2and HP3, and there is one for each series each day. For example, measurementsfrom the 20th of August 1998 would be located in the relative path from theprogram "\M8\98-8-20.HPx ", where x is 1, 2 or 3. The directory M8 indicatesthat it is the eighth month; there is one for each month in the year, startingfrom 1. The structure of the �les can be seen in Table 4.6.


Name Data type Use

Value Integer The value of a measurement times a fac-tor.


Table 4.6: The structure of the HPx �les

The size of each �le depends on which series it is, and can be calculated by usingthe following formula:

size =

(24 ∗ 60

2∗MaxInterval2 +

24 ∗ 6030

∗MaxInterval30

)∗ 2 + 13 + 9

For HP1, MaxInterval2 is 25 and MaxInterval30 is 0, while for HP2 and HP3,MaxInterval2 is 0 and MaxInterval30 is 10 (all of these values depends on whatis read from the RIE �le, but it have been like this since close to the start of theSMS system). The next 13 bytes designate the relative path to the FIL, RIE,HPO and KOMMENTS �les used for the measurements. The path could forexample be "M11\9-11-30.", the path to each �le would then be:

M11\9-11-30.RIEM11\9-11-30.FILM11\9-11-30.HPOM11\KOMMENTS

Notice that KOMMENTS is di�erent, because the FAT �lesystem can not han-dle �le extensions longer than three characters.

The last nine bytes are unused and hold the value \0 (0x00 in hexadecimal).

4.3.6 Borland Real48

Borland Real48 is the full name of the real type used in Turbo Pascal 5, andis di�cult to convert because it is not used anymore and has a di�erent com-position compared to �oat or double. See Figure 4.4 for an example. Thedocumentation on Borland Real48 could not be found, so understanding andconverting the value had to rely on alternative sources ([Sto10, iMa05]). InListing 4.2 is a C code snippet to convert a char array containing the real48


double real48ToDouble ( const char ∗ r ea lVa lue ) {double exponent = double ( ( unsigned char ) rea lVa lue [ 0 ] ) − 129 . 0 ;double mantissa = 1 . 0 ;double power = 1 . 0 ;

f o r ( i n t i = 46 ; i >= 8 ; i−−) {power ∗= 0 . 5 ;i f ( ( r ea lVa lue [ i >> 3 ] >> ( i & 7) ) & 0x01 )mantissa += power ;

}

i f ( mantissa == 1.0 && rea lVa lue [ 0 ] == 0)re turn 0 . 0 ;

i f ( r ea lVa lue [ 5 ] & 0x80 )mantissa = −mantissa ;

r e turn mantissa ∗ pow (2 . 0 , exponent ) ;}

Listing 4.2: Code to convert from Borland Real48 to IEEE Double

Figure 4.4: Comparison of the structure of Borland Real and IEEE Double

value to double. In summary, it goes through the mantissa part of the real48value to construct its pendant as a double, and calculates the resulting doubleas follows:

resultvalue = (k ∗mantissa) ∗ 2exponent

The value of k depends on the value of the sign, the most signi�cant bit. If it is1, it indicates that the value is negative, and k will be -1.0. If it is 0, the valueis positive, and k is 1.0.


4.4 What is still needed

If the system were to be upgraded or recreated, what part of the old systemstill would need to be retained highly depends on how much the Department ofCivil Engineering wants to replace.

The least demanding upgrade, illustrated in Figure 4.5, would reuse the HPunit and the HP-IB card needed for communicating with it, but the computerwould be replaced with a new one running a more modern operating system thanMS-DOS and using new (and better documented) code for the SMS program.This could be the VRE that is going to be developed. All con�guration valuesfor the old system (commands for the HP unit, calibration values etc.) can bereused in the new system.

Figure 4.5: Illustration of the SMS system with only the computer replaced

A more demanding upgrade, illustrated in Figure 4.6, will replace the entiresystem with new components. Besides the new computer with the new VRE de-scribed before, the HP unit will be replaced as well. This replacement could forexample be an Agilent 34980A Switch/Measure Unit (which resembles the cur-rent system the most) or the modular DAQ system from National Instruments(looks less like the current system).

4.4 What is still needed 29

Figure 4.6: Illustration of the SMS system with both the computer and HPunit replaced

All of the sensors on the weather station have always been replaceable and shouldcontinue to be. In the old system, all that it required was some rewiring to theHP unit, and some editing of the con�g �les on the computer. The controllerfor the tracker will be di�cult to replace as it controls the motor with electricalimpulses. Maybe a new acquisition unit is able to take over this functionality,but it is not an important feature.


Chapter 5

Our VRE implementation inLabVIEW

A simple prototype of a full VRE has been developed and ful�lls some of therequirements for a VRE listed in Section 1:

• Data acquisition

• Visualization

• Data manipulation

The VRE has been developed with the experiments in Section 3 and the ad-vanced case in Section 4 in mind, which resolved in a module-based program,allowing users to develop custom modules to do acquisition, manipulation orlogging. With clever use of the module interface, additional requirements for aVRE can be made available. All of the code can be seen in Appendix B.

Using modules has a couple of advantages:

• Only a module needs to be written instead of a whole program.

• Creates a streamlined way of handling data.

32 Our VRE implementation in LabVIEW

• Everything can be collected and handled by a single program.

• Modules can be easily shared and used in other projects.

5.1 The user interface

The user interface (seen in Figure 5.1) consists of three major parts; a tree viewover all modules and their output, a graph visualizing data, and a multicolumnlistbox used for listing which output is currently being displayed in the graph.

Figure 5.1: User interface of the VRE implementation. To the left is the treeview used for displaying modules and their outputs, to the topright is the graph used for visualizing data, and to the bottomright is the multicolumn listbox used for listing data about theplots in the graph. In this example, the Random module outputsa random value between 0 and 10, and the Add module adds 10to that value.

In Figure 5.2 the �ve main buttons to control the program are shown. Itis possible to add a module, remove a module, recon�gure a module (like if amodule after initialization requires other parameters to function optimally), addan output to the graph, and remove an output from the graph.

Above the main components is a control for exiting the program (Figure 5.3). It

5.2 Program structure 33

Figure 5.2: Buttons used to control the VRE

Figure 5.3: Exit button of the VRE

is important that the implemented exit button is used and not LabVIEWs ownstop button, as it ensures that all modules is terminated properly and all datais written to �les and closed. The checkbox lets the user decide if the currentlyloaded modules and their con�guration should be written to the con�guration�le so that it will continue with that setup the next time the program starts.This functionality is unimplemented however because of time constrains.

5.2 Program structure

The program starts in the VI named UI, and it contains the main loop, partof the initialization code, and the exit code. The initialization code clears thegraph, the listbox and the tree view, and the rest is handled by the VI InitCon-�guration. Its responsibility is to load the con�guration �le and initialize allshared variables used in the program.

The main section of the program consists of two loops; one responsible forreacting to the user interacting with the UI, and one responsible for executingmodules and gathering data. More on that later.

The exit code, also handled by the VI UI, makes sure that every module isclosed correctly. This is especially needed if a module opens ports or �les onthe computer as they need to be closed and freed, else the module might blockother programs from using that port or �le. The graph and the two lists arenot cleared as leaving them does not cause problems for others, and they arecleared anyway when the program starts next time.

5.2.1 User interaction

The user interaction is handled by a loop. As seen in Figure 5.4 it is eventbased and is triggered when the user presses the di�erent buttons. The buttons


Figure 5.4: The while loop containing the event structure which reacts on theuser pressing the di�erent buttons in the UI

are the �ve below the tree view and the exit button.

Besides the buttons for add module and exit, the buttons require that eithera module or an output is selected in the tree view. Below are the individualactions as presented.

5.2.1.1 Add module

The add module button is probably the most important of them all as itinitializes and adds a module to the execution loop.

It starts by checking the API version of the module so that it can call the rightfunctions correctly later on. Full speci�cation of the module interface can befound in Section 5.3. Afterwards it executes InitializeModule which containsthe module-speci�c initialization code. After that the module is executed onceand then inserted into the execution loop and into the tree view along with alist of the module's output (if any). The module is given a unique ID whencreated. Any output that the module may have is given a unique ID as well.

5.2.1.2 Remove module

The remove module button, as the name implies, remove the module from theprogram and deletes any data associated with it. In case an output is selectedand the remove module is pressed, it will �rst �nd the correct module and then


proceed to remove that module. A con�rmation box will appear before themodule is actually removed.

To remove a module, the RemoveModule function is executed. After beingremoved from the execution loop, both metadata and output data associatedwith the module are removed. In case any data from the module to be removedis visualized in the graph, these will be removed from there as well.

5.2.1.3 Recon�gure module

The recon�gure module button allows a user to recon�gure a module (if themodule allows that). This is useful if some parameters for the module requireto be changed during the lifetime of the module, or if the user mistakenly typedin the wrong parameters at start.

Like with the remove module button, if an output is selected when pressing therecon�gure module button, the correct module will be found before proceedingto call Recon�gureModule function for that module.

5.2.1.4 Add to graph

The add to graph button adds the selected output to the graph and does notwork for modules.

It �rst searches through the list of output already being displayed in the graphand also checks if there are any free spaces left in the graph. Due to a limitationin the program and LabVIEW there can be at most ten output displayed at thesame time (displaying more is not advised either as already with ten it can bevery di�cult to see anything useful). If the output is not already in the list, andthere is a free slot, it is inserted into the list and an entry in the multicolumnlistbox is created with some useful information about the output (like name,unit, ID and color in the graph (colors not implemented)).

The new output to be displayed in the graph will be inserted the next time thegraph updates (at the end of the execution loop).


Figure 5.5: The while loop responsible for executing all modules and updatingthe graph. This �gure is a mashup from the code in UI and inExecutionLoop.

5.2.1.5 Remove from graph

The remove from graph button removes an output from the graph. Theoutput to be removed has to be selected in the tree view. It can not be selectedin the multicolumn box where all currently displayed outputs are listed.

The button removes the entry from the multicolumn listbox and frees up aslot in the graph. The content of the graph will be updated the next time theexecution loop �nishes.

5.2.2 The execution loop

The execution loop, seen in Figure 5.5, is responsible for two tasks; executingall modules and storing their output, and updating the content of the graph.

The execution loops over a list of module IDs held in the shared variable calledSortedKeys. This variable is a serialized version of the graph build by themodules' dependency on each other. When a module is picked for execution, allinput it requires from other modules will be ready for it. It can not depend onoutput that comes from a module that will execute afterwards.

After an ID has been selected, the loop fetches all of the data the module needsin order to execute like the list of sources the module depends on (and thedata associated with them), the list of IDs on the module's output, and thecon�guration data for the module.

The module is executed and any output will be appended to what is alreadystored in memory for that module and then reduced to a number of data entries.This is set at initialization. If this limit is set to zero, everything will be kept in


memory. It will then be up to the user to ensure that the computer has enoughmemory to store everything, or not use modules that can create an in�niteamount of data (like a live system with continuous sampling).

When all of the modules listed in SortedKeys have been executed, the loopupdates the content of the graph and the loop starts all over.

5.2.2.1 Internal dependency graph

The dependency graph is constructed as a directed acyclic graph (see AppendixC for an explanation). The acyclic property is ensured because, when �rst ini-tialized a module can not select other input sources in a possible recon�gurationand it can only select sources that already exists.

When constructing the array SortedKeys, it uses a topological ordering of thegraph developed by Arthur Kahn in 1962, seen in Algorithm 2 ([Kah62]). Alledges and all vertices (nodes) are only visited once during the algorithm, whichresults in a O (|V |+ |E|) run time.

Algorithm 2 Topological Sort

L← Empty listS ← Set of all nodes with no incoming edgeswhile S is not empty do

Remove node n from SInsert node n into Lfor all node m with an edge e from n to m do

Remove edge e from the graphif m has no incoming edges then

Insert m into Send if

end forend whilereturn S

The implementation of the graph and algorithm used in this program relies ona base node to pick up all those nodes that do not depend on any sources. It isonly there to create a single place to start the search and to create an edge tonodes that otherwise would not have any incoming edges.


5.2.2.2 Updating graph control content

The solution to updating the graph comes with the cost of performance, howeverit solves some other problems. Normally if one were to update the graph andadd data for the next iteration, the data would be collected in a single clusterand wired to the graph. The graph would append it to the existing data that itcontains and update the graph. However, when an output is set to be visualizedin the graph, it is desired that it does not only add new data generated at thenext tick, but that also the data already in memory is visualized right away.This will also solve the problem if modules do not generate output at every tick,but in bursts. The most naive way to do that is to construct the full set of datathat the graph can display every time. Given that one tick in the graph is acluster with a single value from all of of the plots that it is visualizing, and thefull set of data is an array of these clusters, the best way to �ll them out is totake one source at a time and loop over the array of clusters. With the numberof ticks the graph can hold, T, and the number of plots that it can show, N, itresults in a running time of O (|N | × |T |). In this implementation T is 100 andN is 10 which results in 1000 iterations over this array of clusters.

5.2.3 Calling modules

Calling modules use a feature of LabVIEW called Call By Reference, and iscomparable to the use of re�ection in Java. LabVIEW opens up a reference tothe VI it wants to call and using prede�ned input and output to know what toexpect from the VI.

Figure 5.6: Example of the open reference node. In this case, the Initialize-Module is used to specify the VI input and output.

In Figure 5.6 a reference to a VI is opened. It requires a path to the VI andhow input and output is for that VI. Di�erent �ags for the VI can be set as wellfor example if it should allow for asynchronous calls and if reentrant is allowed.

5.3 Module interface 39

Figure 5.7: Example of Call By Reference. The node has changed to matchthe input reference (again the InitializeModule is used).

The next step is to use Call By Reference seen in Figure 5.7. The VI changesto match the input and output pattern de�ned when opening the reference andcan then be used like a normal VI.

This method of implementing modules have certain bene�ts compared to im-plementing modules as DLL �les which normally is used for libraries (Windowsuses DLL �les, for example Linux uses .so). First of LabVIEW sees and usesthem as if they were regular VIs. Simple things like array length is taken caredof for you by LabVIEW. It is also a lot easier to use custom data structures.With a DLL �le, being native code, the call is di�cult to set up right, and anycustom data type has to be transformed when sending to and receiving from themodule. Array sizes also have to be given in a separate argument. No systemexists to help you to get the size of an array. In short, keeping everything inLabVIEW makes it easier for novices to create new modules and reduces thepotential for errors.

One downside to this might be a loss in performance compared to calling nativecode like a DLL �le, because LabVIEW does many things in the backgroundto use a VI (like automatic memory management and automatic typecasting).Comparison of performance of a call to a DLL �le and to a VI has not beenconducted. Another downside to not using DLL �les is that modules can only bedeveloped in LabVIEW. Compilers to other programming languages can usuallygenerate DLL �les, and if they followed the interface de�ned for a module, theprogram would have been able to use them if the DLL approach was used.

With all this being said, there is nothing that hinders a module from using DLL�les in its execution.

5.3 Module interface

This section contains a more technical documentation of input and output ofthe di�erent functions in a module.


Name Direction Comment

Input sources Input Array of clusters containing theID, name and unit of available in-put sources.

Con�gStrings Input Cluster containing two arrays, keysand values. These correspond tothose written with GenerateCon-�gStrings and contain the savedcon�guration of the module.

Con�g cluster refnum Output Reference to the con�g cluster.Input sources dependency Output Array containing those input

sources the module depends on.Have length zero is it does notdepend on any.

Output names Output Name of the outputs the modulehas. Length zero if the moduledoes not output anything.

Units Output The unit of the outputs. Musthave the same length as outputnames.

Error out Output Error cluster used for error han-dling and content is written to log.

Run once Output Used to check if the module onlyshould run once.


Version cluster Output Cluster containing the major, minor and buildversion of the API that the module uses.

5.3 Module interface 41


Con�guration cluster Input Reference to the con�gurationcluster for the module.

Recon�gured cluster Output Reference to the recon�gured clus-ter.

Error out Output Error cluster used for error han-dling and logging.


Con�g cluster refnum in Input Reference to the con�gurationcluster for the module.

Con�g cluster refnum out Output Reference to the con�gurationcluster for the module.

Con�gStrings Output Cluster containing two arrays, keysand values. These two arrays haveto be of equal length and containthe keys and values used in thecon�guration �le.

Error out Output Error cluster, used for error han-dling and logging.



Con�g cluster in Input Reference to the con�guration cluster forthis module.

First run Input Boolean value telling the module whether itis executed for the �rst time or not.

Input list Input Array of clusters containing an array of dou-bles with all of the data for that data sourceand an integer with the number of new en-tries since the last time the module whichthe source belongs to was executed.

Con�g cluster out Output Reference to the con�guration cluster.New data list Output Array of clusters containing an array of dou-

bles with the new values for one output dur-ing this execution. The order of this list cor-responds to the order of which the Namesarray was de�ned in InitializeModule.

Error out Output Error cluster, used for error handling andlogging.


Con�g cluster Input Reference to the con�guration cluster.Error out Output Error cluster, used for error handling and log-

ging.

5.4 Creating a new module

The above description of the module architecture aims at giving a relativelysimple template for the development of modules for own purposes. The devel-opment of a module by a user is described here.

A template (ModuleTemplate) is provided for creating new modules. It should

5.4 Creating a new module 43

be copied and renamed to whatever the name of the module should be. After-wards, all VIs in the directory to <function name>_<module name>.vi. Fora module called Add, InitializeModule.vi should be renamed to InitializeMod-ule_ Add.vi, and so on. The reason for this requirement can be seen in Section6.3.2. The included control �les (.ctl) can be ignored, they are some of thecustom input and output data structures used.

Next step is to create the initialization code in InitializeModule. What needsto be initialized depends entirely on how much control the developer wants theuser to have and what the module actually does. A few issues might arise while�lling out this VI.

Unless the module is going to be completely hardcoded, a dialog box is required.If all that is required from the user is a text string, a boolean response ora number, it can be handled by standard VIs. For more complex input like�le paths or dropdown boxes a custom dialog box is required. For that, it isadvised to read the document published by National Instruments ( [Ins09a]). Ifthe dialog does not show up when executing InitializeModule, use Invoke Nodeswith the methods Front Panel: Open and Front Panel: Close.

The next issue that might arise, is how to get the reference for the con�gurationcluster. When all of the values required to make the module work are collectedinto a cluster, create an indicator for it. Afterwards right click on the indicatorand create a local reference to it and wire it to the output for the con�gurationcluster reference. The content of this cluster is module dependant, no assump-tions about the content is made by the program. The order in which values wereinserted into the con�guration cluster is important and need to be rememberedfor later.

The next step is to �ll out the Recon�gureModule VI. Techniques for creatinguser dialogs can be reused. The real challenge in this is to get and set valuesin the con�guration cluster. Wire the con�guration cluster to a Property Nodewhich outputs an array of controls in the cluster. The array of controls is in thesame order as when being inserted into the cluster. Select the desired controlusing Index Array and wire it to another Property Node which gives the valueof the control. The value, being a variant, needs to be wired to a Variant ToData node as well as the data type that the variant should be converted to. Thevalue is now ready to use. All this can be seen in Figure 5.8


Figure 5.8: Get the value of a control in a cluster using Property Nodes. Hereit is a double value being acquired from the control.

When changing the value of a control, the same procedure as getting the valuecan be used, except that the value Property Node should be set to write insteadof read. The value is changed by wiring the new data into a To Variant nodeand then to the Property Node. This case can be seen in Figure 5.9.

Figure 5.9: Changing the value of a control in a cluster using Property Nodes.Here it is a double value being inserted.

The next step is to �ll out the ExecuteModule VI. Fill it out according to whatthe module should do, like adding a constant to the input, or reading datafrom a �le. Use the technique of getting values from the con�guration clusterdescribed earlier. The input list is ordered in the same way as the array of inputdependencies set when �lling out InitializeModule, and contains a cluster withall data and the number of new entries from the last time the module executed.This allows for the module to work with either all of the data of the inputsources or only work with the new entries. For the output array, it has to beordered in the same way as the output names array. Every entry in the arrayis a cluster containing an array with the new data to be added to the internaldata storage.

The last important VI is RemoveModule. This is used to let the module cleanup after itself. Any open �les or ports should be closed.

5.4.1 Example of creating a module

The �rst thing to do is to come up with what the module should do. This ex-ample will create a module that outputs a random value each round, so let's call


the module �Random�. The module template is copied and renamed accordingto the instructions, and all VIs are renamed as well, as seen in Figure 5.10.

Figure 5.10: The �le structure after all �les have been renamed according tothe instruction.

Next is to �ll out InitializeModule VI. The module is not able to take any inputfrom other modules, so Input sources are ignored, and an empty constant iscreated for Input sources dependency.

The module needs to take some input from the user. The requirements for thismodule are minimal and only a name for the output and a multiplier is needed.The name is for easier identi�cation for a user and is purely cosmetic, while themultiplier extends which values the module can output during execution. Therandom in LabVIEW outputs a number between 0 and 1, which will then bemultiplied with the multiplier. A simple Prompt User for Input node can beused for that and con�gured as seen in Figure 5.11.


Figure 5.11: The con�guration of Prompt User for Input.

An event case is set up to register whether the user pressed ok or cancel inthe prompt. In case of cancel the module outputs an error cluster with theerror number 43 (default number for user cancelled operation) and a meaningfulmessage. In case of ok the name of the output is made into a one dimensionalarray and wired to Output names. Another one dimensional array with the �rst�eld in the array being an empty string is wired to Units. Both of this can beseen in Figure 5.12.

Figure 5.12: Output names and units for the module.

The last thing to do in InitializeModule is to output a reference to the con�gura-tion cluster. The cluster for this module is only going to contain the multiplierand follow the instructions for this, it is wired into a Bundle node and displayedin an indicator and the reference to that indicator is wired to Con�g clusterrefnum. This can be seen in Figure 5.13.


Figure 5.13: Example of how to create the con�guration cluster.

The next relevant �le to �ll out is Recon�gureModule. It is not terribly im-portant but it has its use. The only value in the con�guration cluster is themultiplier and this can again be handled by the Prompt User for Input, butthis time it should only take a number value instead of number and name. Themultiplier control is the �rst value in the cluster and using the method in theinstruction, the new multiplier value is inserted as seen in Figure 5.14.

Figure 5.14: The multiplier value is replace in the con�guration cluster.

And now for the VI that actually does the work, ExecuteModule. Using themethod described earlier the value of the multiplier is retrieved from the clusterand multiplied with the value from the Random node. This can be seen inFigure 5.15.

Figure 5.15: Multiplies the value from Random with the multiplier.

This module only has a single output, and that output only generates a single


new value each time it is executed. So the multiplied random value is �rst trans-formed to an array, bundled in a cluster, which afterwards is then transformedto an array, and �nally wired to the New data list. This can be seen in 5.16.

Figure 5.16: Transformation of the multiplied value, such that it matches thestructure of New data list.

The last important VI is RemoveModule, however for this module it is notinteresting at all. The module uses no �les or ports which require allocationfrom the operating system so it can just output a neutral error cluster andterminate. Had any of these �les or ports been allocated, these would have tobe freed here else they might prevent other programs or modules from functioncorrectly.

Chapter 6

Discussion

As the presented VRE implementation is only a prototype, several things areleft un�nished. Either because of time constraints or because no solution hasbeen found to some of the limitations met in LabVIEW.

6.1 Numerical e�ciency

One improvement that should be done is to improve on the graph data feedspeed. A run time of O (|N | × |T |) should only be absolutely worst case thatonly very rarely happens (like, allN visualized outputs bursts out T new values),but in the current implementation it is a regular thing. Run time for adding orremoving a plot in the graph should take O (|T |), and adding a new tick shouldtake O (|N |).

A to improve on this, is to restrict access to updating the graph with a semaphore.The execution loop will only handling adding one or more new frame on everyloop, the run time will then be O (|N | × |M |), where 0 ≤M ≤ T . If each outputonly produces one new value each tick (with will be the normal case), M will be1 and it results in the run time O (|N |).

When adding a new plot to the graph, only old values for that output have to

50 Discussion

be added to the graph. For that, N will be one and 0 ≤ M ≤ T , at worst caseit will be O (|T |).

It will hold the execution loop until it have �nished adding the new plot tothe graph, but this approach will on average be a lot faster than the currentimplementation.

6.2 Parallel execution

Another point where the program could be speeded up is when executing mod-ules. Right now only a single thread is used for going through the list Sorted-Keys, but this could be paralleled. As soon as all input for a module is readynothing hinders it from being executed right away, except for the ordering cre-ated by the topological sort. Taking advantage of the multiple CPUs in moderncomputers would speed it up. It requires a modi�cation of the sorting as wellas a new data structure to store when a module may be executed.

6.3 Design �aws in LabVIEW

When designing a large program such as LabVIEW many di�cult design deci-sions have to be made. Some will be sound and not cause anyone problems lateron, but some will prove to be a mistake.

6.3.1 Limitations on plots visualized

An often met problem is that LabVIEW needs to know the type of all inputand output when execution starts, which forces some limitations on the numberof plots that can be visualized on the graph. The graph is set to view tenplots at a time, it can not suddenly display nine or eleven. A way to trick thegraph is to display only the number of plots that the user desires (up to themaximum number ten), is to replace the value for the unused plots with NaN(not a number, which you will get from trying to calculate 1

0 ). It can not bedisplayed so that data point will be hidden. The user will not notice this unlessit tries to visualize more than ten plots.

6.4 Output data limitation 51

6.3.2 All �les must have unique names

With the creation of the modules a large �aw (or feature) on the design choiceof LabVIEW was found. When trying to open a reference to two di�erent �leswhich have same name but di�erent path, the second time a reference is createdit will point to the �rst �le that was opened. It appears as if it looks up thename of a VI in its internal table before opening it. If another �le has beenopened before with the same name, it gives the same reference regardless ofwhether the two are stored in di�erent locations on the hard drive. In otherwords, every VI used must have a unique name.

6.3.3 Updating data structures

Another design �aw is if a data structure has to be changed. This can notbe speci�ed in one place, with the program updating every place where thestructure is referenced. Instead, the structure has to be manually updatedeverywhere it is used.

6.4 Output data limitation

The only output available currently, is doubles. This is again because LabVIEWneeds to know all input and output from the beginning. A module can notoutput a cluster containing for example strings, booleans and timestamps whichmight have been useful for another module (like logging). This may becomeavailable through the use of references or typecasting but it will require moree�ort of the module developers and visualization of output will become harder.

6.5 Usability

Something that would improve the usability of the program is the ability tosave and load module con�guration. This will reduce time needed to con�gureeverything every time the VRE is started and makes it easier to share modulecon�guration with fellow students or colleagues.

Recursively deleting modules would also be useful to help with preventing mod-ule from depending on data sources that no longer exists. When removing a

52 Discussion

module the user could select recursive delete, and recursively delete all modulesdepending on it.

In the multicolumn listbox below the graph, one column represents a color.Displaying the plot color there has not been implemented either, but is desirableto improve usability. Until that happens, the user has to remember which coloron the plot is which output.

6.6 Replacing the SMS system

Actually replacing the SMS system was never a goal for multiple reasons, butthe primary reason was a lack of desire. A replacement has been on the wishlistfor many, many years, but due to the lack of knowledge of the old system, thepeople responsible fear that it all might break completely if anyone touches it.The old system does break down a couple of times every month, and is notrestarted until this is discovered, so there are already many holes in the datathat the system has generated. No tests could be made with the actual physicalcomponents, but it can be made plausible that the new VRE can replace theold SMS system.

The �rst thing to be handled is to actually read the old SMS con�g �les. Onlya few, if any, of the current con�guration of the system are written in plain textanywhere (on paper or in a document on a computer), so it is important thatthe old �les be made readable. Based on the documentation in Section 4.3,some VIs capable of reading the old �les can be seen in Appendix D.

The next step can be solved in multiple ways, depending on which solution inSection 4.4 is picked. If only the computer (and software) is to be replaced,it requires that LabVIEW to be able to use HPIB/GPIB ports. With thedriver pack to LabVIEW listed in [Ins09b], it is able to communicate withGPIB ports (and with small/no modi�cations, also HPIB ports). This enablescommunication with the old HP data acquisition unit, and the use of the unitcan be duplicated in LabVIEW.

If both the computer and HP unit are to be replaced, National Instrumentssells many di�erent kind of components. These can for example by digitalmultimeters, modules that can measure the voltage on a wire or read thermo-couple input. These have perfect integration with LabVIEW and can act asthe replacement for the old HP unit. It could also be replaced with the Agilent34980A Switch/Measure Unit as suggested in 4.4. The latter resembles the oldsetup more, and LabVIEW should not have any problems communicating with

6.6 Replacing the SMS system 53

it either.

The last component to be considered is the tracker. It is controlled throughan IO card in the computer and can either be migrated to the new computeror replaced with some other hardware, for example from National Instruments,able to do the communication. The actual board controlling the tracker is notto be replaced.

The original code controlling the tracker and the number of pulses to the elec-trical engine controlling the tracker each second have been calculated in before-hand. This reduced the number of calculations to be done during executiongreatly. In the simulation of the tracker in Section 3.1.4 it relies on the cur-rent time of day as well as the location and placement of the tracker to tell theposition of the sun. The di�erence between the new and the old position of thesun could then be translated to a number of pulses required to move the trackerto the correct position. This would give a more reliable tracker algorithm com-pared to the current, as the tracker can not be moved to a new position withoutdoing several new calculations, and it would eliminate any doubt the currentdevelopers may have whether the equation of time has been applied or not.

With the old con�g �les able to be read in LabVIEW, the ability to eithercommunicate with the HP unit (or replace it entirely) and using the tracker, itshould be very likely that the new VRE can take over operation from the oldSMS system.

54 Discussion

Chapter 7

Conclusion

A part of this thesis was to decide whether LabVIEW was worth investingtime and e�ord for a generic utilization at the department of Civil Engineering.Given the ease to get started with LabVIEW, the simplicity of accessing lowlevel components (if the VIs needed have already been developed by NationalInstrument), and how quick something graphical can be put together, it worksvery well with novice programmers in the environment the department operatesin. If drivers have not already been put together, a large database of user madedevice drivers are available online. A large community of users is also active onthe National Instruments forum to help programmers with problems. Shouldthe user be interested, an extension to the LabVIEW suite (LabWindows/CVI)can be installed to allow for regular C code to be created and compiled. Thisgives all the power of C and LabVIEW combined. All these strengths makes theLabVIEW suite a good tool to be used by the Department of Civil Engineeringfor many or all of their experiments.

A second goal of the paper was to develop a VRE. It has been developed andmeets several of the requirements listed for a VRE:

• Data acquisition

• Visualization

56 Conclusion

• Data manipulation

The module interface in Section 5.3 is what makes the VRE generic. Besidesthe assumptions and limitations discussed in Section 6, the VRE makes noassumption about what the modules do or which data is handled. Anythingthat follows (or can be adapted to follow) the module interface can be used bythe VRE.

Through the use of specialized modules the VRE can get data from, manipulateand write data to virtually anything that LabVIEW in itself can communicatewith.

The last goal was to see if the VRE could replace the old SMS system. Asconcluded in Section 6.6 it is very plausible that the old system could be eitherpartly or entirely (only counting the computer and the HP unit) replaced. Theprimary reason as to why this could not be tested is lack of support from thepeople responsible for the old system.

Now it is up the the department to adopt this approach, �nalizing it and get itinto work.

Chapter 8

The perspective

To make this VRE a more complete application all the things missing, listedin Section 6 should be implemented. It will improve speed, functionality andusability. What has to happen afterwards depends on several factors.

If it is concluded that the VRE solves all requirements for the Department ofCivil Engineering nothing more is really needed besides the occasional develop-ment of new modules to research and education.

If a VRE meeting more requirements listed in the introduction is needed, de-velopment might have to start all over again. The current code can be reused,as it does solves the task of periodically execute modules to do data acquisi-tion, manipulation or logging, but it will not be able to, for example, performcollaboration or access management. Content management systems like FedoraCommons (http://fedora-commons.org) or Drupal (http://drupal.org) can solvethis task however.

An important thing to �gure out is, how multiple types of data can be dis-tributed through the same channels. Right now the system can only handledoubles, but a full featured VRE should be able to handle any type of dataand be able to visualize it as well. For this, LabWindows/CVI might enhanceLabVIEW.

58 The perspective

In regard to replacing the old SMS system, it will be important that tests areconducted with the weather station. It can be a small scale replica of theweather station at �rst, and then slowly scaling up, but tests have to be donebefore actually switching. As described in Section 6.6, large parts of the oldsystem have been documented and LabVIEW VIs to read the old con�g �leshave been developed. Very little, besides the will of people in charge, preventsthe old system to be replaced. With some successful tests and some goodwill,it can be done already in a few months.

Never before the replacement of the old SMS system been so reachable as now,having the proposed replacement software and replacement strategy.

Furthermore the department has, after application tests on real experiments, aprototype that is able to scale up to a wider application and other experiments.

Appendix A

Java code

This appendix contains the Java code for Section 3.1.4, and is based on the tem-plates provided by the SunSPOT project on how to write host and SunSPOTapplications. The Java code is used in an example where LabVIEW has tocontrol an external device based on calculations, and the two programs com-municate using built-in radio transmitters and receivers. Very few sanitation ofinput and error handling is built in, as it was only used for an example, and itcould be guaranteed that no illegal input would be received. Should it be usedin less controlled environments, more error handlingjh have to be build in.

A.1 Host Java code

The host application (running on a computer) is designed to getting startedand stopped all the time. Experiments have shown, however, that this is nota good practice as this procedure takes a long time (a few seconds). The codeitself executes as fast as if it had been a normal Java program, but the modi�edJava engine used in the SunSPOT project is slow to start and stop. Having theprogramming running constantly and receiving orders over a Socket would bethe way to go if the program should be put in production.

The host program works by receiving an argument, a number from zero to

60 Java code

seven, open up a radio connection which broadcasts on channel 100 (a dedicatedconnection between the SunSPOT and the host is not required to be set upbeforehand, and it just sends out the transmission on channel 100 without anycon�rmation on that any have received it), and sends the number over thatconnection. Afterwards, the program exits.

package org . sunspotworld ;

import javax . m i c roed i t i on . i o . Connector ;import javax . m i c roed i t i on . i o . Datagram ;import javax . m i c roed i t i on . i o . DatagramConnection ;

/∗∗∗∗ @author Morten Soerensen∗/pub l i c c l a s s SunSpotHostAppl icat ion {

p r i va t e s t a t i c i n t tmp ;

pub l i c void run ( ) throws Exception {DatagramConnection conn = (DatagramConnection )

Connector . open ( " radiogram :// broadcast :100 " ) ;Datagram dg = conn . newDatagram( conn .

getMaximumLength ( ) ) ;dg . w r i t e In t (tmp) ;conn . send ( dg ) ;conn . c l o s e ( ) ;

}

pub l i c s t a t i c void main ( S t r ing [ ] a rgs ) throws Exception{tmp = In t eg e r . pa r s e In t ( args [ 0 ] ) ;SunSpotHostAppl icat ion app = new

SunSpotHostAppl icat ion ( ) ;app . run ( ) ;System . e x i t (0 ) ;

}}

Java/SunSpotHostApplication.java

A.2 SunSPOT Java code

The SunSPOT application (running on a SunSPOT) opens up a radio connec-tion and listens to channel 100 in server mode (it receives anything on channel100, whether it is broadcast transmission or transmissions speci�cally to thatSunSPOT). When a transmission is received, it reads the number included,

A.2 SunSPOT Java code 61

makes sure that it stays within the limits (zero to seven, done with a modulusoperation), and lights the number of LEDs speci�ed.

package org . sunspotworld ;

import com . sun . spot . r e s ou r c e s . Resources ;import com . sun . spot . r e s ou r c e s . t r ansduce r s . ITriColorLEDArray ;import com . sun . spot . r e s ou r c e s . t r ansduce r s . LEDColor ;import com . sun . spot . u t i l . U t i l s ;import java . i o . InputStream ;import javax . m i c roed i t i on . i o . Connector ;import javax . m i c roed i t i on . i o . Datagram ;import javax . m i c roed i t i on . i o . DatagramConnection ;import javax . m i c roed i t i on . mid let . MIDlet ;import javax . m i c roed i t i on . mid let . MIDletStateChangeException ;

pub l i c c l a s s S ta r tApp l i c a t i on extends MIDlet {

p r i va t e ITriColorLEDArray l ed s ;p r i va t e DatagramConnection conn ;

protec t ed void setup ( ) throws Exception {conn = (DatagramConnection ) Connector . open ( " radiogram

:// : 1 00 " ) ;l e d s = ( ITriColorLEDArray ) Resources . lookup (

ITriColorLEDArray . c l a s s ) ;l e d s . setOn ( ) ;

}

protec t ed void loop ( ) throws Exception {Datagram dg = conn . newDatagram( conn . getMaximumLength ( ) ) ;conn . r e c e i v e ( dg ) ;

i f ( dg . getLength ( ) > 0) {i n t n = dg . readInt ( ) ;n = n % l ed s . s i z e ( ) ;f o r ( i n t i = 0 ; i < n ; i++) {

l ed s . getLED( i ) . setRGB(0 , 0 , 255) ;}f o r ( i n t i = n ; i < l ed s . s i z e ( ) ; i++) {

l ed s . getLED( i ) . setRGB(0 , 0 , 0) ;}

} e l s e {U t i l s . s l e e p (1000) ;

}}

protec t ed void cleanup ( ) throws Exception {l ed s . s e tO f f ( ) ;

}

protec t ed void startApp ( ) throws MIDletStateChangeException {try {

setup ( ) ;whi l e ( t rue ) {

loop ( ) ;

62 Java code

}} catch ( Exception ex ) {

ex . pr intStackTrace ( ) ;}

}

protec t ed void pauseApp ( ) {}

protec t ed void destroyApp ( boolean bln ) throwsMIDletStateChangeException {

}}

Java/StartApplication.java

Appendix B

VRE VIs

64 VRE VIs

Figure

B.1:UIVI

65

Figure

B.2:InitCon�gurationVI

66 VRE VIs

Figure B.3: LoadCon�guration VI

67

Figure

B.4:OpenLogFileVI

68 VRE VIs

Figure B.5: CloseLogFile VI

Figure B.6: WriteToLog VI

69

Figure

B.7:AddNodeVI

70 VRE VIs

Figure

B.8:ConstructSortedKeyListVI

71

Figure B.9: GetNode VI

Figure B.10: GetNodeInternal VI

72 VRE VIs

Figure B.11: DeleteNode VI

73

Figure

B.12:DeleteN

odeInternalVI

74 VRE VIs

Figure

B.13:MoveN

odeVI

75

Figure B.14: AcquireExecutionVariant VI

76 VRE VIs

Figure B.15: ReleaseExecutionVariant VI

Figure B.16: AddOutputNode VI

77

Figure B.17: DeleteOutputNode VI

Figure B.18: GetOutputNode VI

78 VRE VIs

Figure B.19: DeleteOutputData VI

Figure B.20: GetOutputData VI

79

Figure

B.21:InsertOutputD

ata

VI

80 VRE VIs

Figure

B.22:AddOutputD

ata

VI

81

Figure

B.23:AddModuleVI

82 VRE VIs

Figure

B.24:AddplotToGraphVI

83

Figure

B.25:ExecuteModuleInternalVI

84 VRE VIs

Figure B.26: ExecutenLoop VI

85

Figure

B.27:Recon�gureModuleVI

86 VRE VIs

Figure

B.28:Rem

oveM

oduleVI

87

Figure

B.29:Rem

oveP

lotFromGraphVI

88 VRE VIs

Figure

B.30:GenerateGraphData

VI

89

Figure B.31: AddUpdateExecutionDataNode VI

Figure B.32: DeleteExecutionDataNode VI

90 VRE VIs

Figure B.33: GetExecutionDataNode VI

Appendix C

Graph theory

This section introduces a few simple graph theory concepts used.

The sample graph shown in Figure C.1has no directions on edges. All nodes ina graph do not necessarily have to be connected.

Figure C.1: A simple graph example. Not all nodes are connected, and thereare no direction on edges.

The example in Figure C.2 is a directed acyclic graph. All edges have set adirection, indicated by the arrows. If they did not have a direction, the graph

92 Graph theory

would have created a cycle. But because of the directions, it is not possible tostart o� in a node, and get back to it by following the edges.

Figure C.2: A directed, acyclic graph.

Appendix D

VIs to read SMS con�g �les

94 VIs to read SMS con�g �les

Figure

D.1:FILparser

VI

95

Figure D.2: HPOparser VI

Figure D.3: KOMMENTparser VI


Figure

D.4:RIEparser

VI

97

Figure

D.5:RealToDoubleVI


Bibliography

[Fra04] Michael A. Fraser. De�nition of a vre. http://users.ox.ac.uk/

~mikef/rts/vre/img2.html, 2004.

[iMa05] iMalc. Conversion of pascal real48 (48-bit �oat)to c++ double. http://www.gamedev.net/topic/

326742-conversion-of-pascal-real48-48-bit-float-to-c-double/

page__p__3112103#entry3112103, 2005. Last edited: June 19, 20053:12:46 AM.

[Ins09a] National Instruments. Creating quality dialog boxes in labview. http://www.ni.com/white-paper/8768/en, 2009.

[Ins09b] National Instruments. Ni-488.2 2.7.3 - real-tids os, windows 2000/764-bit/xp/vista 64-bit/vista 32-bit/7 32-bit. http://joule.ni.com/

nidu/cds/view/p/id/1529, 2009.

[Joh] Ann-Mari Lanty Johansen. Solstråling. Teaching note about sun radi-ation used by the Department of Civil Engineering at DTU. Createdin 2009 under guidance of Simon Furbo, last edited 6/9-11.

[Kah62] Arthur B. Kahn. Topological sorting of large networks. Communica-

tions of the ACM, 5(11), November 1962.

[Lun94] Hans Lund. Solmålestationen. LfV 94-18, Institute for Build-ings and Energy, Laboratory for Thermal Insulation, June 1994.Also available at: http://www.byg.dtu.dk/upload/institutter/

byg/publications/rapporter/lfv94-18.pdf.

[Sto10] Dr. J. R. Stockton. Pascal / delphi / + types. http://www.merlyn.

demon.co.uk/pas-type.htm, 2010.

http://users.ox.ac.uk/~mikef/rts/vre/img2.html

http://users.ox.ac.uk/~mikef/rts/vre/img2.html

http://www.gamedev.net/topic/326742-conversion-of-pascal-real48-48-bit-float-to-c-double/page__p__3112103#entry3112103



http://www.ni.com/white-paper/8768/en

http://www.ni.com/white-paper/8768/en

http://joule.ni.com/nidu/cds/view/p/id/1529

http://joule.ni.com/nidu/cds/view/p/id/1529

http://www.byg.dtu.dk/upload/institutter/byg/publications/rapporter/lfv94-18.pdf

http://www.byg.dtu.dk/upload/institutter/byg/publications/rapporter/lfv94-18.pdf

http://www.merlyn.demon.co.uk/pas-type.htm

http://www.merlyn.demon.co.uk/pas-type.htm

Documents

Creating a Generic Virtual Research Environment · PDF fileCreating a Generic Virtual Research Environment ... The goal of the thesis is to create a generic virtual research environment