Handleiding experimentontwikkeling e-Xperimenteren+
Leendert van Gastel, Jasper Bedaux, Jeroen Verschuur, Piet Blankert, Jan Mulder, Wopke Wijngaard 12-12-2005
Colofon Handleiding experimentontwikkeling e-Xperimenteren+ Stichting Digitale Universiteit Oudenoord 340, 3513 EX Utrecht Postbus 182, 3500 AD Utrecht Telefoon
030 - 238 8671
Fax
030 - 238 8673
e-mail
[email protected]
Auteur Leendert van Gastel, Jasper Bedaux, Jeroen Verschuur, Piet Blankert, Jan Mulder, Wopke Wijngaard Copyright Stichting Digitale Universiteit De Creative Commons Naamsvermelding-GeenAfgeleideWerken-NietCommercieel-licentie is van toepassing op dit werk. Ga naar http://creativecommons.org/licenses/by-nd-nc/2.0/nl/ om deze licentie te bekijken.
Datum 2005-12-12 Kenmerk DU-3321_ Handleiding_experimentontwikkeling
pagina 2 van 11
Inhoudsopgave 1
Geschiktheid van een experiment voor remote experimenteren
2
Gebruik van algemene LabVIEW VI’s
4
2.1
Koppeling met reserveringssysteem
4
2.2
Log en journaal van het experiment
5
2.3
Dataopslag op de centrale server
6
2.4
Gebruik van webcams
6
3
4
Tips en aanwijzingen bij het schrijven van experimentbesturingssoftware
6
3.1
Veiligheid
6
3.2
Robuustheid
7
3.3
Duidelijkheid interface
7
3.4
Gebruik webcams
7
3.5
Omgaan met vertragingen
7
3.6
Minimaliseren datatransport
7
3.7
Initialiseren experiment
8
3.8
Zelftests
8
3.9
Gebruik tabs
8
3.10
LabVIEW problemen
9
4
Opname van experimentgegevens in de centrale database
5
Configuratie van de experimentserver
9 10
pagina 3 van 11
Dit document is bedoeld voor personen die een nieuw remote experiment willen maken of een bestaand experiment geschikt willen maken voor besturing op afstand voor gebruik in de omgeving van e-Xperimenteren+.
1
Geschiktheid van een experiment voor remote experimenteren Allereerst adviseren wij om grondig na te gaan of een experiment geschikt is voor remote experimenteren. Hierbij zijn niet alleen fysieke eigenschappen van een experiment, maar zeker ook 1
de beoogde leerdoelen van belang.
Behalve geschiktheid is het van nog veel groter belang dat er goede redenen zijn om een experiment op afstand toegankelijk te maken. Het succes van een remote experiment zal sterk afhangen van een duidelijke motivatie waarom ervoor gekozen is het experiment op afstand toegankelijk te maken. Redenen voor het remote uitvoeren van een experiment kunnen onder andere zijn:
−
Mogelijk maken van experimenten die normaalgesproken te gevaarlijk zijn (zoals experimenten met radioactieve straling).
−
Mogelijk maken van experimenten die normaal te kwetsbaar zijn om door (nog onervaren) studenten bediend te worden.
−
Mogelijk maken van uitvoeren van langdurige experimenten waarbij het noodzakelijk is om controle over het experiment uit te voeren zonder continu aanwezig te hoeven zijn.
− −
Delen van kostbare apparatuur. Besparing in de practicumbegeleiding door het mogelijk te maken eerst in een gecontroleerde omgeving te oefenen met kostbare of ingewikkelde apparatuur.
−
Mogelijk maken dat studenten op zelf te kiezen plaats en tijd een experiment kunnen uitvoeren.
−
Mogelijk maken om experimenten (via een computer) in een collegezaal tijdens een (hoor)college te demonstreren.
2
Gebruik van algemene LabVIEW VI’s Er is een aantal LabVIEW VI’s (Virtual Instruments) beschikbaar dat gebruikt kan worden voor een remote experiment onder andere als interface tussen de experimentbesturing en het reserveringssysteem. In het pakket is een gedetailleerde handleiding beschikbaar waarin de installatie en het gebruik wordt beschreven. In dit document volgt een globaal overzicht van de beschikbare componenten. Voor details over installatie en implementatie kunt u het bestand Readme.doc bij het pakket raadplegen.
2.1
Koppeling met reserveringssysteem Verschillende componenten verzorgen de koppeling met het centrale systeem van eXperimenteren+. De VI’s LoginByServer.vi en Logout.vi verzorgen het daadwerkelijke inloggen en uitloggen. Deze VI’s hoeven alleen maar op de juiste locatie (toegankelijk voor de LabVIEW web server) te worden geplaatst en eenmalig moeten enkele locaties worden ingesteld. Deze VI’s worden door de G-web server gebruikt en hoeven niet gestart te worden. Voor de communicatie met de centrale server moet er één VI worden opgestart, dit is Webserver control.vi (te vinden in Webserver control.llb). Deze VI zorgt onder andere voor communicatie met
1
Zie ook het document Good Practices Onderwijsvormen van e-Xperimenteren+
pagina 4 van 11
het reserveringssyteem, monitoring van de status van de experimentserver, verzending van de experimentlogs en opgeslagen data en het starten en stoppen van de LabVIEW G-web server. Het regelen van de toegang van gebruikers tot het experiment aan de hand van het centrale reserveringssysteem gebeurt verder geheel automatisch. Hiervoor hoeft in de VI’s van de experimentbesturing verder niets gedaan te worden. Relevante gegevens van onder andere het reserveringssysteem zijn beschikbaar voor de programmeur van het remote experiment via de VI Globals.vi. Voor een overzicht van de globale variabelen zie de documentatie bij de software. Hieronder volgen enkele belangrijke variabelen:
−
power_on: Deze variable is 0 als het experiment niet gereserveerd is en wordt 1 wanneer een reservering begint. Indien er een warmup time is ingesteld wordt deze variabele al eerder 1, namelijk uiterlijk warmup time vóór de reservering begint (eventueel enkele minuten eerder omdat de updates periodiek gebeuren).
−
exp_time_left [min]: Geeft de resterende experimenteertijd in minuten weer. Eventueel kan
−
selftest_on: Deze variabele wordt 1 selftest interval vóór een reservering begint, zie verder de
seconds_left gebruikt worden voor een nauwkeurigere indicatie. uitleg in 1.4. −
2.2
user_id: Unieke ID van elke gebruiker. Is 0 wanneer er op het moment geen reservering is.
−
name: De naam van de student in het reserveringssysteem.
−
email: Het email adres van de student in het reserveringssysteem.
Log en journaal van het experiment Bij elk experiment wordt er automatisch een log van het experiment aangemaakt. Standaard staat hier alleen begin en eindtijd in. Als maker van het experiment is het eenvoudig om entries toe te voegen aan het log met de bedoeling om tijdens het experimenteren bepaalde veranderingen automatisch bij te houden. Opnemen van een log entry gebeurt door invoegen in het block diagram van de VI LogEventEntry.vi. Er moet gekozen worden voor een event type. Opties zijn:
−
Measurement started: in Text 1 kan een naam van de meting worden aangegeven, bijvoorbeeld “temperature measurement”, in Text 2 kunnen relevante instellingen worden aangegeven.
− −
Measurement ended: in Text 1 kan de naam van de meting worden aangegeven. Parameter changed: in Text 1 kan de naam van de parameter worden aangegeven, in Text 2 de nieuwe waarde van deze parameter.
−
Other event: kan worden gebruikt voor andere events.
Door gebruik van deze VI wordt er automatisch een regel aan het experimentlog toegevoegd. Voor de gebruiker is het normaalgesproken mogelijk om ook zelf opmerkingen aan het experiment log toe te voegen, zodat op deze manier een elektronisch labjournaal ontstaat. Opmerkingen toevoegen kan met behulp van de VI JournalItemEntry.vi. In het bestand JournalTab example.vi is te zien hoe een tab gemaakt kan worden waarin journaalitems toegevoegd kunnen worden.
pagina 5 van 11
2.3
Dataopslag op de centrale server Het is mogelijk om gemeten data op te slaan en deze automatisch na afloop van het experiment naar de centrale server te laten transporteren, waar deze later gedurende een bepaalde periode toegankelijk blijven voor de student. Om dit te bewerkstelligen kan gebruik gemaakt worden van de VI Read_Write_data.vi. Wanneer deze sub-VI wordt aangeroepen verschijnt er een popup-venster waarin de gebruiker om een naam voor het bestand wordt gevraagd. Ook kan de gebruiker een directory kiezen of aanmaken. Feitelijk worden er twee bestanden opgeslagen: één bestand met de meetgegevens en één bestand met informatie over deze meting (bijvoorbeeld meetinstellingen). Beide bestanden blijven bij elkaar. Het totale bestand (tekst en data) kan de gebruiker later downloaden.
2.4
Gebruik van webcams In het pakket met algemene VI’s wordt ook een pakket meegeleverd om webcam-beelden te gebruiken in het experiment. Voor meer details en installatiehandleiding zie de handleiding in het pakket. Er is ondersteuning voor meerdere webcams (er kan gewisseld worden tussen webcambeelden) en er is ondersteuning voor het veranderen van de resoluties van de webcam(s). De webcambeelden (en instellingen) worden via globale variabelen beschikbaar gemaakt.
3
Tips en aanwijzingen bij het schrijven van experimentbesturingssoftware Voor het schrijven van de software voor de experimentbesturing gelden uiteraard alle gangbare richtlijnen voor programmeren zoals een goed ontwerp en goede foutafhandeling. In aanvulling daarop zijn er voor remote experimenten extra richtlijnen te bedenken. Hieronder volgen enkele tips en aanwijzingen:
3.1
Veiligheid Omdat toegang door onbekende gebruikers eenvoudiger mogelijk is dan bij een niet-remote experiment, is het belangrijk dat het onmogelijk is om schade aan het experiment toe te brengen via de remote interface. Het is nuttig te inventariseren waar mogelijke gevaren liggen, zoals een stappenmotor die te ver door kan lopen of een te hoge spanning op een apparaat.
−
Het is aanbevolen om altijd een hardwarematige bescherming in te bouwen zoals een veiligheidsschakelaar die een stroomkring onderbreekt wanneer een motor te ver doorloopt. Op deze manier wordt voorkomen dat er schade kan ontstaan wanneer er bugs of zwakheden in de software zitten.
Ook op softwarematig gebied moet er op gelet worden dat de besturing niet in een ongewenste toestand kan worden gebracht. Zo moet bijvoorbeeld voorkomen worden dat de gebruiker de software in een veel te lange loop kan brengen, waardoor of veel te veel data gegenereerd wordt of de indruk wordt gewekt dat het experiment vaststaat.
−
Geef ALTIJD een maximale en een minimale waarde op voor controls, met name numerieke controls (waar een getal kan worden ingevoerd). Op deze manier wordt voorkomen dat bijvoorbeeld onbedoeld de harde schijf van de experimentserver wordt volgeschreven met enorme hoeveelheden meetdata.
pagina 6 van 11
3.2
Robuustheid Omdat ‘even opnieuw opstarten’ voor een remote experiment veel lastiger is omdat er vaak niemand fysiek aanwezig is ten tijde van het experiment, is de robuustheid van een remote experiment nog veel belangrijker dan de robuustheid van een niet-remote experiment. Het is belangrijk dat het programma niet vastloopt. Een goed ontwerp en goede structuur van de programmacode is hiervoor onontbeerlijk.
3.3
Duidelijkheid interface Omdat het volgen van een experiment op afstand (via een webcambeeld) lastiger is dan een nietremote experiment, is het van groot belang dat de software interface zeer duidelijk en goed georganiseerd is. De noodzaak van een duidelijke interface wordt nog veel groter wanneer het experiment ook door een student thuis (met minder begeleiding) moet kunnen worden uitgevoerd.
3.4
−
Geef duidelijke namen aan elke control en indicator.
−
Gebruik Tabs om de user interface te structureren.
−
Voeg waar nodig opmerkingen toe.
Gebruik webcams Uit tests in voorgaande en andere projecten is gebleken dat het gebruik van één of meerdere webcams door bijna alle gebruikers wordt ervaren als zeer belangrijk. Het geeft een soort ‘echtheidsgevoel’ en maakt het experiment ‘leuker’. In 1.2.4 is meer informatie te vinden over gebruik van webcams binnen LabVIEW.
3.5
Omgaan met vertragingen Een typische eigenschap van remote interfaces is dat er vertragingen kunnen optreden in de interface op vaak onvoorspelbare momenten. De terugkoppeling naar de gebruiker kan hierdoor (even) op zich laten wachten, waardoor het lijkt alsof ‘er niets gebeurt’. In het ergste geval klikt de gebruiker ondertussen op allerlei controls in de hoop een reactie aan het systeem te ontlokken, waardoor de af te handelen commando’s zich gaan ophopen…
−
Gebruik zoveel mogelijk Submit-knoppen bij controls: wanneer er naast bijvoorbeeld een Slider een Submit-knop zit, dan is voor de gebruiker duidelijk dat de verandering pas doorgegeven wordt na het klikken van de Submit-knop en komt het ook natuurlijker over dat het doorvoeren van de verandering even kan duren. Bij niet-remote software is het gebruikelijk acties uit te voeren wanneer de waarde van een bepaalde Control, bijvoorbeeld een Slider VERANDERT. Bij een remote-versie wordt deze methode sterk afgeraden, omdat door de extra vertragingen van het netwerkverkeer het soms onduidelijk wordt hoever het experiment ‘achterloopt’. Gebruik ook hier een Submit-knop en voer de actie pas uit wanneer deze Submit-knop wordt gebruikt om ervoor te zorgen dat de actie slechts eenmaal wordt uitgevoerd.
−
Wanneer een bepaalde handeling/commando/meting enige tijd in beslag neemt (of kan nemen), zorg dan dat dit duidelijk is voor de gebruiker bijvoorbeeld door middel van een lampje of een (knipperende) tekst.
3.6
Minimaliseren datatransport Omdat niet elke gebruiker een zeer snelle internetverbinding heeft is het aan te bevelen het datatransport binnen de perken te houden.
pagina 7 van 11
−
Update het webcambeeld niet vaker dan nodig is: webcambeelden genereren veel netwerkverkeer. Minimaliseer het aantal over te sturen beelden. Zo kan ervoor gekozen worden om stilstaande beelden maar af en toe te updaten.
−
Geef de gebruiker de mogelijkheid om de webcam ‘uit te zetten’, dit kan softwarematig door de globale variabele active op false te zetten.
−
Maak het webcambeeld niet groter dan nodig is. Eventueel kan een optie worden aangeboden om het webcambeeld op verschillende groottes weer te geven, zodat gebruikers met een snellere internetverbinding een groter beeld kunnen bekijken.
−
Update alleen grafieken die zichtbaar zijn. Als grafieken worden geüpdate die niet zichtbaar zijn, omdat ze bijvoorbeeld op een andere Tab staan, wordt er toch netwerkverkeer gegenereerd.
−
Gebruik (waar mogelijk) Waveform graphs in plaats van XY-graphs omdat er voor XY-graphs tweemaal zoveel dataverkeer nodig is.
3.7
Initialiseren experiment Omdat het experiment door meerdere gebruikers achter elkaar kan worden gebruikt is het vaak noodzakelijk of wenselijk dat het experiment voor (of na) een reservering in een bepaalde begintoestand wordt gebracht. Een goede werkwijze is de software zo te ontwerpen dat de besturing normaalgesproken altijd blijft draaien en dat er getest wordt of de globale variabele user_id verandert. Bij een verandering kan het experiment in een begintoestand worden gebracht. Wanneer er gebruik wordt gemaakt van een Warmup time, zie ook 1.4, kan dit eventueel al gebeuren voordat de gebruiker inlogt, door ook te kijken naar de variabele power_on. De globale variabele power_on kan ook gebruikt worden om apparatuur aan of uit te schakelen. Dit kan zinvol zijn om de levensduur van de apparatuur te vergroten en om energie te besparen.
3.8
Zelftests Vaak is het relatief eenvoudig om bij het initialiseren van een experiment tevens een zelftest uit te voeren. Er kan bijvoorbeeld gecontroleerd worden of een stappenmotor nog functioneert, en of detectoren of sensoren een normaal signaal afgeven (vaak wordt hiermee tevens gecontroleerd of bijvoorbeeld de voedingen nog werken). In de globale variabelen zit ook een variabele selftest_on. Deze kan gebruikt worden om een extra zelftest uit te voeren wanneer het experiment een (lange) tijd niet gebruikt is. De zelftest dient normaalgesproken alleen te worden uitgevoerd wanneer de variabele selftest_on van 0 in 1 verandert, zie ook 1.4. Het rapporteren van het resultaat van een zelftest gebeurt door de globale variabelen (uit Globals.vi van de algemene LabVIEW VI’s) status en description. De status kan de waarden ok, warning of error aannemen en in description kan een beschrijving van de status worden opgenomen. De status wordt automatisch doorgegeven aan de centrale server via het monitoring systeem en bij een verandering van de status wordt de operator van het experiment via een email op de hoogte gebracht.
3.9
Gebruik tabs Zoals in 1.3.3 al werd opgemerkt biedt het gebruik van tabs een mogelijkheid om de interface te structureren. Andere voordelen kunnen zijn dat het dataverkeer kan worden beperkt door alleen Controls en Indicators die zichtbaar zijn te updaten. Een andere belangrijke reden om tabs te gebruiken is dat de schermgrootte van de gebruiker niet bekend is, en omdat het experiment normaalgesproken binnen een browserwindow wordt
pagina 8 van 11
uitgevoerd is er ook minder ruimte beschikbaar dan voor een stand-alone applicatie. Met behulp van tabs is het eenvoudig de grootte van de interface binnen de perken te houden. 3.10
LabVIEW problemen Helaas treden er af en toe nog om onverklaarbare redenen problemen op in LabVIEW waardoor de remote interface of de browser waarin hij draait crasht. Soms kan opnieuw opstarten van LabVIEW op de experimentserver uikomst bieden. Soms lost dit het probleem echter niet op. In dit geval moet er een manier gevonden worden om het probleem te omzeilen. Tussentijds testen op een andere computer via het remote panel mechanisme kan helpen dit soort problemen tijdig op te sporen. Helaas is niet altijd duidelijk wat het probleem veroorzaakt. Enkele malen werd geconstateerd dat voorkomen van gebruik van References en de properties Disabled en Visible van Front Panel objecten deze problemen verhielp.
4
Opname van experimentgegevens in de centrale database Om gebruik te kunnen maken van het reserveringssysteem, statusmonitoring en opslag van logs en data is het nodig dat een nieuw experiment wordt aangemeld in de database van eXperimenteren+. Gebruikers die de rol operator hebben kunnen experimenten aanmelden (en de gegevens later eventueel wijzigingen). Om de rechten van een operator te verkrijgen kunt u contact opnemen met het beheer van e-Xperimenteren+. Wanneer u over de juiste rechten beschikt verschijnt er na inloggen in de e-Xperimenteren+omgeving in het linkermenu een optie Manage experiments. Hier kunt u kiezen Add experiment. Hier vult u de volgende gegevens in: Name: de naam van het experiment: deze naam is erg belangrijk omdat hij op verschillende plaatsen in het systeem zichtbaar wordt. Description: korte beschrijving in ongeveer één regel van het experiment. Experiment login URI: dit is de locatie waar de student door het systeem heengeleid wordt om in te loggen op het experiment. Normaalgesproken is dit het webadres van de experimentserver met daarachter als poortnummer (voorafgegaan door een ‘:’) 2040 en het pad /cgi-bin/LoginByServer.vi. Voorbeeld: http://pc-amstel021.science.uva.nl:2040/cgi-bin/LoginByServer.vi. Experiment log location: de locatie waar het log van het experiment beschikbaar wordt gesteld voor de centrale server. Normaalgesproken is dit het webadres van de experimentserver met daarachter het poortnummer 2020 (voorafgegaan door een ‘:’). Voorbeeld: http://pc-amstel021.science.uva.nl:2020/. Information website URI: webadres van een eventuele website met informatie over het experiment. Opening time / closing time: hier kan eventueel een periode worden ingesteld dat het experiment geopend is elke dag. Default staat hier 24 hours/day available, maar dit kan veranderd worden in Only avaliable between… waarna een start- en eindtijd kan worden ingevoerd. Break time (between reservations): hier kan een aantal uren en minuten worden ingevuld dat nodig is tussen twee reserveringen. Default staat hier 0 uur en 0 minuten. Wanneer het nodig is dat er een bepaalde (minimale) tijd tussen twee opeenvolgende reserveringen zit (bijvoorbeeld als het terugbrengen van het experiment in een begintoestand veel tijd kost) kan hier een tijd worden opgegeven. Warmup time: deze tijd lijkt op de break time (zie hierboven) met het verschil dat de warmup time groter kan zijn dan de break time wanneer het voor het eerst opstarten van een opstelling meer tijd
pagina 9 van 11
kost dan het terugbrengen van het experiment naar een begintoestand wanneer het reeds opgestart was. Monitoring interval: met deze periode vinden statusupdates van het experiment plaats. Bij een statusupdate geeft de experimentserver de status van het experiment door aan de centrale server. De status kan zijn ok, warning of error met een optionele beschrijving erbij. Wanneer de status van een experiment veranderd (of de experimentserver down raakt), wordt er een email naar de operator van het experiment gestuurd (waarschijnlijk u) waarin deze statusverandering wordt genoemd. Standaard staat deze tijd op 5 minuten ingesteld. Selftest time: het aantal uren (en minuten) vóór een reservering dat een zelftest moet worden uitgevoerd. Wanneer een geplande reservering over minder dan deze tijd in de toekomst ligt wordt de globale variabele selftest_on van LabVIEW aangezet. Het experiment kan dan een zelftest uitvoeren. De defaultwaarde is 48 uur. Wanneer experimenten een zelftest uitvoeren bij het beëindigen of starten van een experiment, is het uitvoeren van een zelftest niet nodig wanneer er minder dan de selftest time tussen reserveringen zit. Let op: de variabele selftest_on blijft op 1 staan totdat de reservering weer voorbij is. Hij wordt slechts 0 wanneer een reservering geeindigd is EN de volgende reservering verder dan de zelftesttijd in de toekomst ligt. Normaalgesproken hoeft een experiment dus alleen een zelftest uit te voeren waneer de variable selftest_on VERANDERT van 0 naar 1.
5
Configuratie van de experimentserver Momenteel wordt LabVIEW versie 7.1 gebruikt op de experimentserver. Voor de communicatie met de centrale server moet de Internet Connectivity Toolkit van LabVIEW geïnstalleerd zijn (bij de Enterprise Edition, de versie die gebruikt wordt voor site licenses binnen onderwijsinstellingen, wordt de Internet Connectivity Toolkit meegeleverd). Verder is het nodig de algemene LabVIEW VI’s te installeren die voor communicatie met de centrale server zorgen. Zie ook Gebruik van de algemene LabVIEW VI’s. Omdat de experimentserver continu met het internet verbonden is, is het aan te raden om een firewall te draaien. De firewall software moet zo geconfigureerd worden dat inkomende connecties op de twee poorten die door de LabVIEW web server en de LabVIEW G-web server worden gebruikt worden doorgelaten. Wanneer de ingebouwde firewall van Windows XP SP2 (of later) wordt gebruikt wordt deze automatisch door LabVIEW geconfigureerd.
pagina 10 van 11
