Embed Size (px)
Citation preview
Facharbeit
Physik Leistungskurs
Schuljahr 2002/2003
Entwicklung einer
Computersteuerung fur das
Radioteleskop
“Wurzburg Riese”
im Deutschen Museum Munchen
Wolfgang Draxinger
31. Januar 2003
Luitpold Gymnasium Munchen Kollegstufenjahrgang 2001/2003
Facharbeit
aus dem Fach
Physik
Thema:Test eines Computerinterface zum Radiotelesksop “Wurzburg Riese” und
Entwicklung einer Adaptionssoftware an das Softwarepaket “The Sky”
Verfasser: Wolfgang DraxingerLeistungskurs: Ph7
Kursleiter: StD. Franz MrazBetreuer: Dipl. Ing. Hermann Hagn
Abgabetermin: 3. Februar 2003
Erzielte Note: . . . . . . . . . . . . . . . . in Worten: . . . . . . . . . . . . . . . . . . . . . . . . . . .
Erzielte Punkte: . . . . . . . . . . . . . . . . in Worten: . . . . . . . . . . . . . . . . . . . . . . . . . . .(einfache Wertung)
Abgabe beim Kollegstufenbetreuer am . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2003
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .(Unterschrift des Kursleiters)
Inhaltsverzeichnis
Inhaltsverzeichnis
I. Uberblick 5
1. Das Radioteleskop “Wurzburg Riese” 5
2. Bisherige Steuerung 6
3. Zielsetzung 7
II. Apparative Grundlagen 9
4. Grundlagen der Teleskopsteuerung 9
4.1. Sternzeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
4.2. Himmelskoordinaten . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
4.3. Julianisches Datum . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
5. Mechanischer Aufbau des Radioteleskops 11
5.1. Paralaktische Montierung . . . . . . . . . . . . . . . . . . . . . . . . 11
5.2. Deklinationsstellgestange . . . . . . . . . . . . . . . . . . . . . . . . . 12
5.3. Ausgleich der Nichtlinearitat der Deklinationsbewegung . . . . . . . . 12
5.4. Positionsruckmeldung . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
5.5. Antriebssystem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
6. Das Steuerungssystem 14
6.1. Steuercomputer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
6.2. NI-DAQ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
6.2.1. Interfacekarte . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
6.2.2. Treibersoftware . . . . . . . . . . . . . . . . . . . . . . . . . . 15
6.3. Anschlussbox . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Inhaltsverzeichnis
7. Beobachtungsverfahren 15
7.1. Empfangssystem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
7.2. Beobachtungsprinzip . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
7.3. Beobachtungsablauf . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
III. Umsetzung 17
8. Simulator 17
9. Sicherheitsmechanismen 17
9.1. Passiv . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
9.2. Aktiv . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
10.Zweicomputerkonzept 19
10.1. Problem der Resourcenbegrenzung . . . . . . . . . . . . . . . . . . . 20
10.2. Funktionsprinzip . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
11.Steuersoftware 20
11.1. Implementation in Python . . . . . . . . . . . . . . . . . . . . . . . . 21
11.2. Hostsystem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
11.2.1. NI-DAQ-Python-Modul . . . . . . . . . . . . . . . . . . . . . 21
11.2.2. Python-Module der Teleskopsteuerung . . . . . . . . . . . . . 21
11.3. Clientsystem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
11.3.1. Astronomiesoftware “The Sky” . . . . . . . . . . . . . . . . . 23
11.3.2. Telescope API ( TAPI ) . . . . . . . . . . . . . . . . . . . . . 24
11.3.3. TAPI-Python-Modul . . . . . . . . . . . . . . . . . . . . . . . 24
11.4. Teleskop-Info-Panel . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
12.Bedienungsanleitung 25
12.1. Hostsystem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
Inhaltsverzeichnis
12.2. Clientsystem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
12.2.1. Verbindung aufbauen . . . . . . . . . . . . . . . . . . . . . . . 26
12.2.2. Objekte auswahlen und anfahren . . . . . . . . . . . . . . . . 26
12.2.3. Verhalten im Fehlerfall . . . . . . . . . . . . . . . . . . . . . . 27
IV. Ausblick 28
V. Anhang 30
A. Anmerkungen 30
A.1. Winkelabweichung der Rektaszension . . . . . . . . . . . . . . . . . . 30
A.2. Meßverfahren am Beispiel des Sonnenspektrums . . . . . . . . . . . . 30
B. Formeln fur astronomische Berechnungen 31
B.1. Sternzeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
B.2. Julianisches Datum . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
C. Quellcodes 32
C.1. Client - TAPI Modul . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
C.2. Host - Teleskopsteuerung . . . . . . . . . . . . . . . . . . . . . . . . . 35
Teil I.
Uberblick
1. Das Radioteleskop “Wurzburg Riese”
Abb. 1.: Der “Wurzburg Riese” im Freibe-reich des Deutschen Museums. Der Sockel,auf dem das Radioteleskop montiert ist,dient gleichzeitig als Beobachtungsraum.
Wahrend des 2.Weltkriegs entwickel-
ten die Deutschen ein Funkmeßsystem,
welches die Prazision der Luftabwehr
verbessern sollte. Diese Flakleitsysteme
mit dem Codenamen “Wurzburg Riese”
wurden entlang der Kusten von Deutsch-
land und den Niederlanden installiert um
Luftangriffe der Alliierten moglichst fruh
abzuwehren.
Nach Kriegsende wurden die meisten
der ca. 1500 Anlagen demontiert. In
den Niederlanden dagegen wurden die
mit 7, 5 m Durchmesser fur damalige
Verhaltnisse riesigen Parabolspiegel der
ehemaligen Fukmeßstationen jedoch als
ideales Instrument fur die noch junge
Wissenschaft der Radioastronomie erkannt und so blieben einige Gerate erhalten,
welche fur wissenschaftliche Zwecke verwandt wurden. So konnte z.B. 1951 mit
einem Wurzburg Riesen die Spiralstruktur unserer Galaxis nachgewiesen werden.
Als 1993 im Deutschen Museum Munchen der Bereich Astronomie erweitert wur-
de, kam auch der Wunsch nach einem funktionierenden, vorfuhrbaren Radioteleskop
auf. Zu dieser Zeit existierten nur noch 6 Wurzburg Riesen, von denen das Deutsche
5
2. Bisherige Steuerung
Museum von den Niederlanden ein Exemplar geschenkt bekam. Auf Anfrage beim
Max-Planck-Institut fur Radioastronomie nach einer qualifizierten Person, die ein
passendes Empfangssystem entwickeln konne, wurde auf Hermann Hagn von der
TU Munchen verwiesen. Zusammen mit verschiedenen Studenten und Mitarbeitern
des Deutschen Museums wurde das Radioteleskop, welches seit 1994 im Freibereich
installiert ist, restauriert und 1997 mit einem Full Power Radiometer ausgestattet.
Jedoch war die Steuerung bisher zu aufwendig und fehlertrachtig, als dass sie sich
zur Vorfuhrung des nun funktionsfahigen “Wurzburg Riesen” im Museumsbetrieb
geeignet hatte1.
2. Bisherige Steuerung
Abb. 2.: Die Bedienelemente zur manuellenSteuerung der Motoren.
Im Radioteleskop sind zur Positi-
onsruckmeldung an den zwei Ach-
sen sog. Drehfelder installiert, welche
Prazisionspotentiometer bewegen, die als
Spannungsteiler an einer hochprazisen
Spannungsquelle geschaltet sind. So-
mit lasst sich die exakte Stellung des
Parabolspiegels in Form zweier Spannungswerte ablesen, welche sich in die Him-
melskoordinaten, auf welche der Parabolspiegel ausgerichtet ist, umrechnen lasst.
Um einen bestimmten Himmelsbereich anzufahren, muss diese Rechnung um-
gekehrt ausgefuhrt werden und per Handsteuerung die Motoren, welche die Tele-
skopachsen bewegen, so lange betrieben werden, bis die gewunschte Spannung am
Messgerat angezeigt wird. Da sich durch die Erdbewegung einer der Achsenwinkel2,
welcher einer bestimmten Himmelsordinate entspricht, fortwahrend andert, mussen
1Der Wurzburg Riese wurde bereits mehrfach fur Beobachtungszwecke in Radioastronomieprak-tika der TU Munchen verwendet, jedoch unabhangig vom regularen Museumsbetrieb.
2Hierbei handelt es sich um die Rektaszensionsachse, siehe 5.1, S. 11.
6
3. Zielsetzung
diese Umrechnungen vor jeder Bewegung durchgefuhrt werden.
Es kam somit bald der Wunsch auf, die Steuerung von einem Computer
ubernehmen zu lassen, welcher sowohl die Berechnungen als auch die Motor-
steuerung wesentlich praziser durchfuhrt und dabei auch noch mogliche Fehler
erkennen und im Notfall das System abschalten kann. Da bereits gute Erfahrun-
gen in der Zusammenarbeit mit Studenten gemacht wurden, wurde von Harald
Scherg vom Gymnasium Ottobrunn, im Rahmen seiner Facharbeit (2002), eine
einfache Umsetzung einer programmgesteuerten Motoransteuerung entwickelt.
Allerdings werden von der rudimentaren Software weder die notigen Berechnungen
vorgenommen noch die gewunschte Prazision erreicht, was notig ware, um eine ein-
fach zu bedienende und exakte Steuerung zu ermoglichen. Es handelte sich vielmehr
um einen ersten Versuch die Moglichkeiten des von National Instruments zur
Verfugung gestellten Computer/Interface-Systems auszuloten.
3. Zielsetzung
Auf den Erfahrungen der vorangehenden Projekte aufbauend, sollte ein komplet-
tes rechnergestutztes System zur Steuerung des Radioteleskops entwickelt werden.
Folgende Eigenschaften sollten es auszeichnen:
Einfache Bedienung mittels eines Programms, in welchem eine beliebige Himmels-
region oder ein bestimmtes Objekt angewahlt werden kann und dieses an-
schließend per Befehl vollautomatisch mit dem Radioteleskop angefahren wird.
Sollte ein Fehler auftreten wird das Steuerungssystem abgeschaltet und dem
Benutzer eine entsprechende Meldung angezeigt.
Redundante Sicherheitsmechanismen, da ein Fehler unkontrollierte Bewegungen
des Teleskops hervorrufen wurde, was aufgrund der großen Masse des Radio-
teleskops von 9 Tonnen sowohl zu materiellen als auch menschlichen Schaden
7
3. Zielsetzung
fuhren konnte. Daher sollen diese Sicherheitsmechanismen mehrfach und auf
verschiedenen Ebenen der Steuerung angelegt sein, was die Steuersoftware und
das Interface mit einschließt, um auch bei Ausfall eines Teilsystems die Sicher-
heit zu gewahrleisten.
Leichte Erweiterbarkeit, da spatere Erweiterungen des Radioteleskops auch An-
passungen der Computersteuerung erforderlich machen werden. Diese sollten
sich daher mit geringem Aufwand in das vorhandene System integrieren lassen.
Eventuell Steuerung uber das Internet, fur welche das fertige System entspre-
chende Erweiterungen berucksichtigen soll3.
3Wie sich zeigte, war es ohnehin erforderlich die Steuerung mittels zweier getrennter Computerzu realisieren. Dabei wurde ein auf TCP/IP basierendes Protokoll verwendet, was sich ohneAnderungen auch uber das Internet verwenden lasst. Somit wurde diese Aufgabe bereits erfullt.
8
Teil II.
Apparative Grundlagen
4. Grundlagen der Teleskopsteuerung
Aufgrund der Erdrotation verandern Objekte am Himmel standig ihre scheinbare
Position, sie scheinen sich um die Rotationsachse der Erde herum zu bewegen. Es ist
somit nicht sinnvoll, die Position von Himmelsobjekten in einem Bezugssystem an-
zugeben, in welchem die Erdrotation nicht kompensiert wird. Andererseits befindet
sich das Teleskop im Bezugssystem Erde, weshalb zur Ausrichtung des Teleskops die
Himmelskoordinaten eines Objekts in die scheinbare Position am Erdhimmel trans-
formiert werden mussen. Die folgenden Uberlegungen zeigen die Grundlagen der zur
Teleskopsteuerung notwendigen Berechnung der scheinbaren Position und wie diese
zur Steuerung des Teleskops zu verwenden ist.
4.1. Sternzeit
Als Nullpunkt des Himmelsaquators wurde der Schnittpunkt der aufsteigenden Son-
nenbahn, der sog. Ekliptik, mit dem Himmelsaquator definiert. Dieser Punkt wird
als Fruhlings- oder Widderpunkt bezeichnet. Diese Festlegung erlaubt es, dass zur
Berechnung der scheinbaren Position eines Objektes aus seinen Himmelskoordinaten
allein der Rotationswinkel der Erde gegen den Fruhlingspunkt bekannt sein muss.
Dieser Rotationswinkel wird in Form eines Stundenwinkels angegeben und Sternzeit4
genannt.
4Die in den STAR-TREK -Serien oft verwendete Sternzeit hat nichts mit der Astronomischen zutun. Statt dessen ist die STAR-TREK-Sternzeit die fortlaufende Nummer der gerade eingelegtenFilmrolle. Vielen Dank an Hermann Hagn fur diese Information. Zur Berechnung der Sternzeitsiehe B.1, S. 31.
9
4. Grundlagen der Teleskopsteuerung
Stundenwinkel geben Winkel in Stunden, Minuten und Sekunden an, dabei ent-
spricht der Vollwinkel 24h00’00”.
4.2. Himmelskoordinaten
Abb. 3.:Gelb: Ekliptik;Blau: Himmelsaquator;Schnittpunkt=Fruhlingspunkt;Ein Teleskop muss nur par-allel zur Erdachse mitgedrehtwerden um die Erdrotationauszugleichen, falls eine derAchsen (grun) parallel zurErdachse steht.
Um die Position von Objekten am Himmel eindeu-
tig anzugeben werden Himmelskoordinaten verwen-
det. Dabei handelt es sich um spharische Koordinaten,
deren Komponenten die Bezeichnungen Rektaszension
und Deklination tragen.
Rektaszenzion gibt die Position eines Himmelsob-
jekts entlang des Aquators, ausgehend vom
Fruhlingspunkt als Stundenwinkel an.
Da bereits die Rotation der Erde relativ zum
Fruhlingspunkt als Stundenwinkel und die Rek-
taszension ebenfalls als Stundenwinkel angege-
ben wird, lasst sich der Ortsstundenwinkel er-
rechnen nach:
Ortsstundenwinkel = Ortssternzeit−Rektaszension
Deklination gibt den Winkel des Himmelsobjekts uber dem Himmelsaquator an.
Die Deklination wird im Gradmaß angegeben
4.3. Julianisches Datum
Zur Berechnung der Sternzeit, aber auch anderer astronomischer Daten, wird das
sog. Julianische Datum5 verwendet. Dieses gibt die vergangene Zeit seit 12 Uhr am
1. Januar 4713 v. Chr. bei 0◦ Lange in Tagen an.
5Zur Berechnung des Julianischen Datums siehe B.2, S. 32.
10
5. Mechanischer Aufbau des Radioteleskops
5. Mechanischer Aufbau des Radioteleskops
Die Mechanik des “Wurzburg Riesen” weist, was die Programmierung des Steue-
rungsprogramms betrifft, einige Besonderheiten auf. Es mussen vor allem besondere
Berechnungen bei der Steuerung der Deklinationsbewegung durchgefuhrt werden.
5.1. Paralaktische Montierung
Abb. 4.: Der Sockel des “Wurzburg Riesen”weist eine Schrage von ca 48◦07′ auf, wasder geographischen Breite des Standortsentspricht. Dadurch steht eine Achse par-allel zur Erdachse, womit sie der Rektas-zensionsachse einer paralaktischen Montie-rung entspricht.
Wahrend heutige Großteleskope meis-
tens azimutal montiert werden, wurden
vor 50 Jahren fast alle Teleskope paralak-
tisch montiert, da bei dieser zum Aus-
gleich der Erdrotation das Teleskop nur
entlang einer Achse nachgefuhrt werden
muss.
Demgegenuber mussen bei einer azimu-
talen Montierung beide Achsen gleichzei-
tig und exakt koordiniert bewegt werden,
um die standige Veranderung der schein-
baren Position der Himmelsobjekte aus-
zugleichen. Was heute aufgrund moderner
Computertechnik moglich ist, war zu Zeiten des “Wurzburg Riesen” unmoglich. Um
den historischen Tatsachen Rechnung zu tragen, wurde daher der “Wurzburg Riese”
auf dem Freigelande des Deutschen Museums, wie in den Niederlanden, paralaktisch
montiert.
Das Prinzip einer paralaktischen Montierung ist relativ einfach: Eine der Achsen
des Teleskops wird parallel zur Rotationsachse der Erde ausgerichtet, sodass mit
dieser die Richtung entlang des Aquators eingestellt werden kann. Da die Rektas-
11
5. Mechanischer Aufbau des Radioteleskops
zension eines Himmelsobjekts ebenfalls entlang des Aquators gemessen wird, wird
die entsprechende Achse des Teleskops als Rektaszensionsachse bezeichnet6.
5.2. Deklinationsstellgestange
Da der “Wurzburg Riese” ursprunglich als RADAR konzipiert war, wurde die Kon-
struktion daraufhin optimiert, vor allem den Horizont abzutasten. Zur Nutzung als
Radioteleskop musste die Konstruktion etwas verandert werden, was eine Anhe-
bung der Gesamtkonstruktion um ca. 1, 50 m und Verlangerung des Stellgestanges
zur Bewegung der Deklinationsachse mit sich brachte.
5.3. Ausgleich der Nichtlinearitat der Deklinationsbewegung
Abb. 5.: Das Stellgestangeund der Aufbau zur An-hebung des Parabolspiegelsim Detail.
Aufgrund des Stellgestanges tritt bei der Bewegung
der Deklinationsachse der Effekt auf, dass die Bewegung
des Motors – und damit des Positionsmelders – nicht
proportional zur Bewegung des Parabolspiegels erfolgt.
Wahrend bei modernen Teleskopen das Hauptaugenmerk
der Steuerung auf der Bewegung der Rektaszensionsach-
se liegt, stellt durch dieses Konstruktionsdetail die Be-
wegung der Deklinationsachse das großere Problem dar.
Es ist ein Ausgleich durch eine Anpassungsfunktion er-
forderlich, welche aus der Position des Motors den ent-
sprechenden Deklinationswinkel errechnet.
Diese sollte jedoch nicht unmittelbar in die Steuerung
aufgenommen werden, da bei diesem Schritt diverse Pa-
rameter anzupassen sind, die sich nur vor Ort bestimmen lassen. Stattdessen sollte
6Eigentlich ware Stundenwinkelachse einleuchtender, da die Achse standig der Erdrotation nach-gefuhrt werden muss und somit in Richtung des Ortsstundenwinkels ausgerichtet ist. Siehehierzu auch A.1, S. 30.
12
5. Mechanischer Aufbau des Radioteleskops
der fertige Code die Aufnahme einer solchen Funktion vorsehen.
5.4. Positionsruckmeldung
Abb. 6.: Rechts im Bild einDrehfeld, welches die Be-wegung der Achse auf einPotentiometer zur Positi-onsruckmeldung ubertragt.
Zur Positionsruckmeldung wurden sog. Drehfeld-
paare7 an die Achsen der Stellmotoren gekoppelt,
uber welche Prazisionsspindelpotentiometer bewegt
werden. Diese sind an einer hochgenauen Spannungs-
quelle als Spannungsteiler geschaltet. Das Ausgangs-
signal ist eine dem eingestellten Winkel proportiona-
le Spannung, genannt Winkelspannung. Diese Win-
kelspannung wird dem Computerinterface zur Posi-
tionsruckmeldung zugefuhrt. Die Wandlung in einen Digitalwert erfolgt mit 12Bit
Genauigkeit, was zu einer Quantisierung der Winkel in Schritte von ca. 0, 02◦ fuhrt.
5.5. Antriebssystem
Abb. 7.: Die Motoren derRektaszensionsachse: Links derSchrittmotor in extrem hoherUbersetzung, rechts der kleineund der große Motor.
Zur Bewegung des “Wurzburg Riesen” werden je
Achse zwei elektronisch gesteuerte Motoren verwen-
det:
- Ein großer Motor
zum Schwenken mit großer Geschwindigkeit
- Ein kleiner Motor
zur genauen Ausrichtung
An der Rektaszensionsachse ist ein zusatzlicher Schrittmotor fur extrem langsame
Bewegungen8, die aber sehr gleichmaßig und genau erfolgen sollen, montiert. Dieser
7Ein Drehfeld ist ein spezieller Drehstrommotor/-Generator. Werden 2 Drehfelder zusammenge-schaltet, fuhrt jede Drehung der Achse des einen Drehfelds zu einer entsprechenden Rotationder Achse des Gegenstucks. Es lassen sich hiermit elektrisch gekoppelte Achsen aufbauen.
8Sonnenmitlauf
13
6. Das Steuerungssystem
Motor soll momentan nicht von der Computersteuerung verwendet werden.
Die Steuerung durch das Computersystem erfolgt je Achse durch ein Signal zur
Wahl der Drehrichtung und ein Signal zum Betrieb des großen und des kleinen Mo-
tors. Zur Ruckmeldung des Betriebszustandes stehen eigene Signale zur Verfugung.
Aus Sicherheitsgrunden schaltet ein weiterer Steuereingang die gesamte Motorsteue-
rung ein oder aus. Diese Motorsteuerung muss aktiviert sein, bevor die Motoren
bewegt werden sollen.
6. Der Aufbau des Steuerungssystems
Zur Steuerung des Radioteleskops kommt ein Industriecomputersystem zum Einsatz,
welches fur den Einsatz in Prozesssteuerungen und Meßanwendungen vorgesehen ist
und somit den Anforderungen nach Stabilitat und Zuverlassigkeit gerecht wird. Um
das notige Maß an Flexibilitat zu erreichen, ist es modular aufgebaut.
6.1. Steuercomputer
Als Steuerrechner dient ein PXI8156 Computermodul9 von National Instruments,
das in einem PXI1000-Chasis installiert ist. Das Chasis bildet zusammen mit dem
Computermodul die Basis fur Erweiterungen mit anderen Baugruppen aus der PXI-
Reihe.
6.2. NI-DAQ
Zur Anbindung externer Baugruppen wird das NI-DAQ-System (National Instru-
ments Data Acquisition) verwendet, ein Baukastensystem, aus dem sich verschie-
denste Kombinationen von Hardware und Software zusammensetzen lassen, um jede
nur denkbare Steuerungsaufgabe zu erfullen.
9Intel Pentium 133Mhz, 32MB RAM, 2GB HDD
14
7. Beobachtungsverfahren
6.2.1. Interfacekarte
Zum Anschluss des Teleskops kommt eine Interfacekarte PXI6040E MIO zum Ein-
satz, welche 8 bidirektionale Digitalports, 16 Analogeingange und 2 Analogausgange
sowie diverse Spezialports bietet.
6.2.2. Treibersoftware
Um eine einfache Verwendung in eigenen Programmen zu ermoglichen, enthalt das
NI-DAQ-System Programmbibliotheken namens “NI-DAQ API”. Zum Konfigurie-
ren und einfachen Testen der Hardware dient der Measurement and Automation
Explorer.
6.3. Anschlussbox
Zur Adaption der unterschiedlichen Anschlusse von Radioteleskop und Computer-
interface dient eine kleine Box, welche zusatzlich zur Aufnahme erganzender Bau-
gruppen dient.
7. Beobachtungsverfahren
7.1. Empfangssystem
Das als Empfangssystem verwendete Full Power Radiometer misst die eingestrahlte
Leistung: Das Empfangssignal wird zur Messung uber mehrere Sekunden integriert,
aus der Integrationszeit und der Gesamtenergie ergibt sich direkt die Leistung. In-
teressant ist jedoch der Fluss, welcher in Wm−2Hz−1 gemessen wird10.
10Jansky [Jy]: 1Jy = 10−26Wm−2Hz−1
15
7. Beobachtungsverfahren
7.2. Beobachtungsprinzip
Da die Integrationszeit mehrere Sekunden betragt, macht es keinen Sinn, das Ra-
dioteleskop direkt auf die Quelle gerichtet zu halten, da sonst nur die abgestrahlte
Leistung gemessen wurde. Vielmehr interessiert jedoch der “Fingerabdruck” der Ra-
dioquellen, welcher sich im Strahlungsspektrum wiederspiegelt. Da das Empfangs-
system fur eine bestimmte Wellenlange ausgelegt wurde, kann dieses nicht direkt
ermittelt werden, weshalb mit einem kleinen Trick gearbeitet wird: Aus der Planck-
schen Strahlungskurve ist das Spektrum eines idealen Temperaturstrahlers bekannt,
genauso wie die Empfangseigenschaften des Radioteleskops.Wird nun das Radiotele-
skop langsam uber das interessierende Objekt bewegt, zeichnet sich eine Meßkurve
ab. Durch Vergleich dieser Meßkurve mit einer errechneten Meßkurve eines idea-
len Temperaturstrahlers lassen sich Ruckschlusse auf das ausgesandte Spektrum des
beobachteten Objekts schließen. Siehe hierzu auch die Anmerkungen in A.2, S. 30
7.3. Beobachtungsablauf
Um eine moglichst gleichmaßige Bewegung zu erreichen wird die Erddrehung aus-
genutzt: Man stellt das Teleskop etwas westlich von der Objektposition ein. Infolge
der scheinbaren Bewegung der Himmelsobjekte wird das Objekt durch den Emp-
fangskegel des Teleskops hindurchgefuhrt.
Um dieses Beobachtungsverfahren per Computer durchzufuhren, muss eine
Eingabemoglichkeit fur den Versatz der angefahrenen Himmelskoordinate zur
tatsachlichen Objektposition vorgesehen werden.
16
Teil III.
Umsetzung
8. Simulator
Ursprunglich fur den Test des Interface entwickelt, diente der “Wurzburg Riese-
Simulator” als Entwicklungsplattform und Testumgebung fur die Steuersoftware.
Einerseits ware es, aufgrund der Offnungszeiten des Deutschen Museums, zeitlich
unmoglich gewesen samtliche Entwicklungen am tatsachlichen Radiotelesktop durch-
zufuhren, andererseits kann nicht riskiert werden, durch einen Fehler wahrend der
Entwicklungsphase des Programms das Radioteleskop zu beschadigen.
Aufgrund des Wassereinbruchs Mitte November 2002 in den Raum mit den Steue-
rungssystemen (vgl. Abb. 1, S. 5 und Abb. 4, S. 11) stellte der Simulator bisher die
einzig mogliche Testumgebung dar, sodass noch keine Erfahrungen mit dem eigent-
lichen “Wurzburg Riesen” gesammelt werden konnten.
9. Sicherheitsmechanismen
Wahrend der Programmentwicklung trat ein Fehler auf, welcher im Realbetrieb
zu ernsthaften Schaden hatte fuhren konnen: Nach einem Programmabsturz
musste der Steuercomputer neu gestartet werden. Allerdings blieben sowohl
die Motorsteuerung als auch der große Motor der Rektaszensionsachse des Si-
mulators aktiviert, was zur Folge hatte, dass eines der Prazisionsspindelpoten-
tiometer irreperabel beschadigt wurde und ersetzt werden musste. Dies zeigte,
dass die Sicherheitsmechanismen solche besonderen Falle berucksichtigen mussen.
17
9. Sicherheitsmechanismen
9.1. Passiv
Abb. 8.: Einer der kapaziziven NotstopSchalter, welche bei Uberfahren der Gren-zen des Schwenkbereichs die Motoren an-halten.
Um ein derartiges “Uberlaufen” des
Teleskops zu verhindern, sind an den
Grenzen des Schwenkbereichs kapazi-
tive Schaltelemente angebracht (Abb.
8, S. 18), die bei Uberscheiten der Te-
leskopgrenzen die Motoren abschalten.
Als weitere passive Sicherheit wurden
mechanische Anschlage eingebaut, die im
außersten Notfall die Motoren abschal-
ten. Diese Abschaltung muss allerdings
mechanisch zuruckgesetzt werden und
dient somit als “ultima ratio”.
Vom Autor wurde der Vorschlag unterbreitet, als zusatzliche Sicherheit eine Schal-
tung einzubauen, die bei Unter- bzw. Uberschreiten eines festgelegten Winkelspan-
nungsbereichs ebenfalls einen Notstop auslost. Der Vorschlag wurde angenommen
und die entsprechende Schutzschaltung in den folgenden Wochen entworfen und
installiert.
9.2. Aktiv
Neben den rein passiven Schutzmechanismen, welche nur dem Verhindern der ex-
tremsten Notfalle dienen, sollte auch die Computersteuerung die Bewegung des Te-
leskops fortwahrend uberwachen und im Fehlerfall entsprechend reagieren. Im Ge-
gensatz zu den rein passiven Schutzmechanismen, die nur von Hand zu losende
Notstopps auslosen, soll der Computer die Motoren nur abschalten, sodass das Pro-
blem behoben werden kann und das Teleskop ohne weitere Maßnahmen wieder in
Betrieb zu nehmen ist.
18
10. Zweicomputerkonzept
Zudem sollte auch uberwacht werden, ob die Achsen gleichmaßig bewegt werden
und nicht blockieren, da in diesem Fall die Gefahr besteht, dass die Mechanik des
Teleskops beschadigt wird. Diese Uberwachung lasst sich am einfachsten als Teil des
Steuerungsprogramms realisieren.
Aufgrund der Anfangs geschilderten Erfahrungen mit dem Simulator, sollte die
in 9.1 angesprochene Schutzschaltung zudem die Funktionsfahigkeit des Computers
uberwachen. Die Idee ist Folgende: Es wird von der Schutzsschaltung ein Signal ge-
setzt, welches innerhalb eines bestimmten Zeitraums von samtlichen Programmteilen
beantwortet werden muss. Wird nicht innerhalb der festgelegten Zeitspanne das er-
wartete Antwortsignal gesetzt, wird die Motorsteuerung solange deaktiviert, bis zwei
Freigabesignale hintereinander innerhalb derselben Zeitspanne gesetzt werden. Da-
durch wird garantiert, dass die Bewegung des Teleskops standig unter der Kontrolle
des Computersystems steht. Sollte sich die Programmverarbeitung verzogern, wird
das Teleskop fur diese Zeit automatisch angehalten.
Die genannten Schutzschaltungen sind dabei als Erweiterung zum Kernsystem
gedacht und werden daher nicht weiter behandelt.
10. Zweicomputerkonzept
Die Steuerung wurde auf 2 getrennte Computersysteme verteilt, von denen eines,
im Folgenden Host- oder Steuerrechner genannt, die Kontrolle der Bewegung des
Radioteleskops ubernimmt. Das andere System, im Folgenden Client genannt, dient
dem Auswahlen der Objekte und dem Senden der Steuerbefehle an den Steuerrech-
ner. Durch diese Trennung ist es zudem moglich, auf dem Clientsystem auch andere
Programme, z.B. interaktive Multimediaprasentationen11 , ablaufen zu lassen, ohne
die Funktionsfahigkeit des Radioteleskops zu beeintrachtigen.
11Aus eigener Erfahrung ist bekannt, dass solche Multimedia-Systeme im Museumsbetrieb sehrbeliebt sind
19
11. Steuersoftware
10.1. Problem der Resourcenbegrenzung
Der Hauptgrund fur die Aufteilung von Teleskopsteuerung und Benutzerschnittstelle
auf zwei getrennte Rechner liegt in den begrenzten Resourcen des Steuerrechners be-
grundet. So hatte z.B. das verwendete Astronomieprogramm “The Sky” nicht mehr
auf der Programmpartition der Festplatte Platz gefunden. Zudem ist der Speicher-
ausbau des Rechners mit 32MB fur heutige Verhaltnisse recht beschrankt. Wurde
eine derart umfangreiche Software wie “The Sky” gestartet, ware das System so
weit ausgelastet, dass eine zuverlassige Steuerung des Teleskops nicht mehr garan-
tiert ware.
10.2. Funktionsprinzip der Zweicomputersteuerung
Bei einer Zweicomputersteuerung werden Steuersystem und Benutzersystem ge-
trennt um die Betriebssicherheit zu erhohen. Beide Systeme sind per Netzwerk
miteinander verbunden, uber das die Steuerkommandos sowie deren Bestatigung
zusammen mit den Nutzdaten, z.B. Meßkurven, ubertragen werden. Dabei konnen
Steuerrechner und Clientsystem im Extremfall uber das Internet verbunden sein und
sich auf verschiedenen Seiten der Erde befinden.
11. Steuersoftware
Der Hauptteil des Projekts bestand in der Entwicklung der Steuerungssoftware sowie
deren Einbindung in das Astronomieprogramm “The Sky”[5]. Es wurde Augenmerk
darauf gelegt, dass der Code moglichst einfach zu verstehen sowie kurz und pragnant
ist.
20
11. Steuersoftware
11.1. Implementation in Python
Die Skriptsprache Python12 bot sich fur das Projekt geradezu an. Zum einen ist
sie aufgrund des high-level-Charakters13 sehr einfach zu verstehen, zum anderen
wird durch die strengen Formatierungsregeln die Lesbarkeit des Codes gefordert.
Dazu bietet Python ein ausgereiftes Modulkonzept, was die Erweiterung bestehender
Programme extrem vereinfacht. Samtliche Quellcodes sind im Anhang C (S. 32) zu
finden
11.2. Hostsystem
Das Hostsystem stellt eine Netzwerkverbindung bereit und steuert das Radioteleskop
entsprechend den empfangenen Steuerbefehlen.
11.2.1. NI-DAQ-Python-Modul
Um in Python verwendet werden zu konnen, musste fur die NI-DAQ API ein
spezielles Python-Erweiterungsmodul in der hardwarenahen Programmiersprache
“C” geschrieben werden. Es handelt sich hierbei nicht um eine vollstandige Abbil-
dung der NI-DAQ API auf Python, sondern es wurden nur die fur die Teleskop-
steuerung relevanten Teile verfugbar gemacht. Zu den Details der Programmierung
von Python-Erweiterungsmodulen sei auf die entsprechenden Kapitel der Python-
Dokumentation[1, 2] verwiesen. Details zur NI-DAQ API finden sich in [3].
11.2.2. Python-Module der Teleskopsteuerung
Die Teleskopsteuerung wurde in mehrere Module aufgeteilt:
Die Einstellungen werden in dem Modul settings.py vorgenommen, dazu zahlen
z.B. der maximale Schwenkbereich oder die Spannungspegel der Positi-
12gesprochen wie die brit. Comedy Serie Monty Python, oder [paitn’].13Es gibt fur nahezu jede Programmieraufgabe bereits ein fertiges Konstrukt, sodass allein das
Programm selbst und nicht die darunter liegenden Verwaltungsstrukturen den Code ausmachen.
21
11. Steuersoftware
onsruckmeldung. Wichtig ist vor allem der Parameter timezone, welcher
die Zeitdifferenz der Ortszeit zur Universalzeit UT1 (Computeruhr) angibt.
Dabei ist nicht die Landeszeitzone zu verwenden, sondern die Zeitdifferenz
in Sekunden von der geographischen Lange des Teleskops zum Nullmeridian.
Fur den “Wurzburg Riesen” sind dies 2640 Sekunden.
Zur Sternzeitberechnung dient das Modul sidereal.py, das die Funktionen zum
Abfragen des Julianischen Ortsdatums sowie einer Umrechnung eines Juliani-
schen Datums in die entsprechende Sternzeit anbietet. Der Code wurde von der
Programmbibliothek fur astronomische Berechnungen libnova[4] ubernommen.
Das Interfacemodul interface.py dient der Bereitstellung einer Programm-
schnittstelle zum NI-DAQ-Interface. Es mussen somit keine Bitmasken14
mehr verwendet werden, um die Motoren anzusteuern. Zudem lassen sich die
Analogeingange uber das Interfacemodul mit den entsprechenden Namen der
Signale des “Wurzburg Riesen” ansprechen.
Das Modul zur Teleskopbewegung move.py dient als Universalmodul zur An-
steuerung der Motoren beider Achsen und Uberwachung der Teleskopbewe-
gung. Tritt ein Fehler auf, wird dieser durch das Modul erkannt, das daraufhin
eine Fehlerbedingung (Exception) auslost.
Die Rektaszension wird vom Modul RA.py angesteuert. Hier findet die notige Be-
rechnung des Ortsstundenwinkels fur das anzufahrende Himmelsobjekt statt.
Dabei werden 2 Varianten zur Ansteuerung implementiert: Die Funktion
move_to_abs dient dem Anfahren eines bestimmten Rektaszensionsachsen-
winkels in Grad. Die Funktion move_to nimmt als Parameter die Rektaszension
entgegen, fuhrt die Berechnung des Ortsstundenwinkels durch und gibt diesen
als Gradmaß an move_to_abs weiter. move_to_abs wandelt den eingegebenen
14Binarkombinationen zum Setzen der Digitalports.
22
11. Steuersoftware
Winkel in eine Winkelspannung und benutzt die aus move.py eingebunde-
ne Funktion move_to_V zur Steuerung der Rektaszensionsmotoren bis die
Winkelspannung innerhalb der vorgegebenen Toleranzgrenzen erreicht ist.
Die Deklination wird vom Modul DEC.py angesteuert. Da fur die Deklinationsbe-
wegung (noch) keine speziellen Berechnungen durchgefuhrt werden, wird die
Winkelspannung unmittelbar an die Funktionen move_to_V in move.py wei-
tergegeben.
Das Modul zur Positionsruckmeldung position.py stellt diejenigen Funktionen,
welche die aktuelle Stellung des Parabolspiegels aus den zuruckgemeldeten
Spannungswerten berechnen und als Ergebnis zuruckgeben.
Das Hauptmodul telescope.py fasst die soeben beschriebenen Module zusam-
men und dient als Haupteinstiegspunkt in das Kontrollprogramm. Dazu be-
reitet es die Netzwerkverbindung vor und nutzt das Modul RPCsf.py, um die
Steuerungsfunktionen zum Aufruf per Netzwerkverbindung zur Verfugung zu
stellen.
11.3. Clientsystem
Das Clientsystem dient der Benutzerinteraktion und stellt eine bequeme Steuerungs-
umgebung zur Verfugung.
11.3.1. Astronomiesoftware “The Sky”
Als Astronomieprogramm wird auf Vorschlag von Franz Mraz das Softwarepaket
“The Sky”[5] zum Einsatz kommen, das die zum Steuern von Teleskopen notwendi-
gen Schnittstellen bereits enthalt.
23
11. Steuersoftware
11.3.2. Telescope API ( TAPI )
Zur Anbindung eigener Steuerungsprogramme dient die sog. Telescope API kurz
TAPI. Diese stellt sich als ein Satz von Funktionen dar, welche vom Benutzer in Form
einer dynamisch ladbaren Bibliothek (DLL) bereitgestellt werden mussen, sodass
“The Sky” diese laden und auf die darin enthaltenen Funktionen zugreifen kann,
um ein angeschlossenes Teleskop zu steuern.
Der TAPI Proxy ist ein Zwischenmodul, das die Verwendung mehrerer TAPI-
Module auf einem System zulasst. Diese Moglichkeit bietet “The Sky” leider nicht
von sich aus. Jedoch war es fur die Programmentwicklung von Vorteil, verschie-
dene Versionen der TAPI-Module nebeneinander testen zu konnen, ohne jedesmal
samtliche Programmdateien der TAPI zu ersetzen, was einen Neustart von “The
Sky” nach sich zieht.
Das TAPI Python Plugin bindet den Python Interpreter in “The Sky” ein und lei-
tet alle Aufrufe von TAPI-Funktionen an ein entsprechendes Python-Modul weiter.
Dies erlaubt es, das eigentliche TAPI-Modul in Python zu programmieren.
11.3.3. TAPI-Python-Modul
Das in Python geschriebene TAPI-Modul tapi.py dient zur Weiterleitung der Te-
leskopsteuerbefehle an den Hostrechner. Da zudem die von “The Sky” ubergebenen
Himmelskoordinaten einige Anpassungen an die Steuerung erfordern, werden die-
se ebenfalls in diesem Modul vorgenommen. Zur Verbindung mit dem Hostsystem
wird wieder das Modul RPCsf.py verwendet, jedoch die Netzwerkverbindung erst
mit dem Aufruf der Funktion EstablishLink aufgebaut.
24
12. Bedienungsanleitung
11.4. Teleskop-Info-Panel
Eine geplante Entwicklung ist das “Teleskop-Info-Panel”, das eine erweiterte Sta-
tusanzeige bieten soll, die umfangreicher und aussagekraftiger ist als jene, die von
“The Sky” angeboten wird und die diese in einem ubersichtlichen Fenster anordnet.
Es werden zusatzlich ein manueller Notstop einzelner Motoren, sowie detaillierte
Eingriffsmoglichkeiten in den Steuerungsprozess zur Verfugung stehen.
12. Bedienungsanleitung
Es folgt eine kurze Beschreibung der Bedienung der Computersteuerung.
12.1. Start des Hostsystems
Auf Seiten des Steuerrechners ist nicht viel zu tun: Nach dem Anschalten und der
Anmeldung am Betriebssystem wird die Teleskopsteuerung automatisch gestartet
und wartet auf die Verbindung mit dem Clientsystem.
12.2. Clientsystems/Astronomiesoftware “The Sky”
Abb. 9.: “The Sky” im Sternkartenmodus. Die aktuelle Stellung des Teleskops wird durchein Fadenkreuz angezeigt.
25
12. Bedienungsanleitung
Als Benutzeroberflache kommt das Astronomieprogramm “The Sky” zum Einsatz.
Nach dem Start wird der Startbildschirm angezeigt. Oben rechts befindet sich die
“Teleskop-Toolbar” uber welche die Verbindung mit dem Teleskop hergestellt und
getrennt wird.
12.2.1. Verbindung aufbauen
Abb. 10.: Teles-kop-Symbolleistevon “The Sky”.
Zum Aufbauen der Verbindung dient entweder der Menubefehl
Teleskop → V erbindung → Aufbauen oder der entsprechende
Schaltknopf (das grune Verbindungssymbol) in der “Teleskop-
Symbolleiste”.
Hier finden sich auch die Befehle um die Verbindung zeitweise zu unterbrechen
oder ganz abzubauen.
Sollte der Verbindungsaufbau fehlschlagen, wird eine entsprechende Fehlermel-
dung angezeigt und der Fehler an “The Sky” weitergegeben.
12.2.2. Objekte auswahlen und anfahren
Abb. 11.: Die Objektinfo Box von “TheSky” mit dem Befehl zum Schwenken desTeleskops.
Um ein Objekt anzufahren wird die-
ses durch einfachen Klick ausgewahlt, wo-
durch die Objektinfo Box geoffnet wird.
Rechts befindet sich eine Karteikarte “Te-
leskop”, auf welchem sich der Befehl zum
Bewegen des Teleskops befindet. Es er-
scheint nun ein Dialog, in dem eine Opti-
on zum Einstellen des Versatzes der Rek-
taszensionsposition (siehe 7.2, S. 16) zur
angegebenen Objektposition eingestellt und der Schwenk gestartet werden kann.
Nach dem Start wird die Fortschrittsanzeige geoffnet, welche den Betrieb der Mo-
toren signalisiert und einen Abbruchbefehl anbietet.
26
12. Bedienungsanleitung
12.2.3. Verhalten im Fehlerfall
Sollte ein Fehler auftreten wird eine entsprechene Meldung ausgegeben und je nach
Fehler die Verbindung getrennt oder beibehalten. Im Moment existieren folgende
Fehlerbedingungen, welche dem Benutzer im entsprechenden Fall angezeigt werden:
motor block im Falle eines unerwarteten Motorstops;
motor control disabled falls die Motorsteuerung nicht freigegeben wurde;
control not enabled falls das Steuerprogramm die Motorsteuerung nicht aktivieren
konnte;
angle voltage out of range falls eine Zielposition ausserhalb des Schwenkbereichs
vorgegeben wurde;
(socket.error, ...) im Falle eines Netzwerkfehlers;
Je nach Erweiterung mit Zusatzmodulen konnen weitere Fehlerbedingungen (Ex-
ceptions) hinzukommen.
27
Teil IV.
Ausblick
Innerhalb des Rahmens der gestellten Aufgabe wurden alle Anforderungen erfullt. Es
steht nunmehr ein stabiles, sicheres und leicht zu bedienendes System zur Steuerung
des “Wurzburg Riesen” zur Verfugung.
Der Anforderung nach einfacher Erweiterbarkeit wurde durch die Verwendung der
Programmier-/Skriptsprache Python Rechnung getragen, die durch ihr modulares
Konzept offen fur jede denkbare Idee ist.
Leider konnte aufgrund eines Regeneinbruchs Mitte November 2002 in den
Raum mit den Steuerungssystemen (vgl. Abb. 1, S. 5 und Abb. 4, S. 11) die
Computersteuerung bislang noch nicht am “Wurzburg Riesen” selbst getestet
werden. Allderdings sollte aufgrund der identischen Anschlusse von Simulator und
“Wurzburg Riese” das System ordnungsgemaß funktionieren, da samtliche Tests
am “Wurzburg Riese-Simulator” erfolgreich verliefen.
Es wurden zwar samtliche Anforderungen erfullt, dennoch sind noch folgende
Erweiterungen geplant:
- Aussagekraftigere Fehlermeldungen
- Eine ubersichtliche Statusanzeige, in welchem samtlicher Betriebsparameter
angezeigt werden
- Steuerung mittels Java-Applet in einem normalem Web-Browser
Zudem sollen auch am “Wurzburg Riesen” weitere Erganzungen vorgenommen
werden: So wird z.B. eine Fernsehkamera hoher Auflosung montiert werden, die den
momentan anvisierten Himmelsbereich zeigt. Eine Ubertragung dieses Bildes uber
Netzwerk in Echtzeit steht bereits auf der Wunschliste.
28
Abschliessend lasst sich sagen, dass das Teilprojekt “Computersteuerung” erfolg-
reich verlief, dies aber noch lange nicht das Ende der Tatigkeiten am “Wurzburg
Riesen” darstellt, aufgrund eines immer vorhandenen “Spieltriebes” mit der Technik
und der vielfaltigen Moglichkeiten, welche das nun vorhandene System bietet.
29
Teil V.
Anhang
A. Anmerkungen
A.1. Winkelabweichung der Rektaszension
Rein theoretisch ergibt sich bei der beschriebenen paralaktischen Montierung ein
Winkelfehler (Paralaxe), hervorgerufen durch die Radialbewegung auf der Erdober-
flache, doch ist dieser extrem klein: Da die maximale Abweichung (hervorgerufen
durch die Erdrotation) hochstens 12736km betragt (Erddurchmesser am Aquator
nach [6]), die Entfernung zum nachsten Objekt im Weltraum, dem Mond, bereits
60,3 mal großer ist, liegt die Winkelabweichung nach
tan−1
(1
60, 3
)≈ 0, 95◦ < Offnungswinkelλ=17cm = 1, 8◦
bereits innerhalb des Offnungswinkels des “Wurzburg Riesen”. Daher muss diese
Abweichung nicht mit berucksichtigt werden. Demgegenuber ist die Winkelabwei-
chung, die durch die Bewegung der Erde um die Sonne hervorgerufen wird, bereits
messbar. Jedoch wird diese von “The Sky” berechnet und an die Telescope API wei-
tergegeben, sodass auch dies nicht von der Steuerungssoftware berucksichtigt werden
muss.
A.2. Meßverfahren am Beispiel des Sonnenspektrums
Wie sich erkennen lasst, unterscheidet sich das tatsachliche Strahlungsspektrum der
Sonne erheblich von dem rein rechnerisch ermittelten Planck Spektrum fur einen
gleich heißen Korper. Dabei variiert das Spektrum im Laufe des 11 Jahre wahrenden
Sonnenzyklus. Auf der Wellenlange des “Wurzburg Riesen” ergibt sich eine Fluss-
30
B. Formeln fur astronomische Berechnungen
Abb. 12.: Das Strahlungsspektrum der Sonne. (modifiziert nach Hermann Hagn)
differenz von beinahe 3 Zehnerpotenzen zwischen aktiver und inaktiver Sonne und
sogar 4 Zehnerpotenzen zwischen aktiver Sonne und errechnetem Spektrum.
B. Formeln fur astronomische Berechnungen
B.1. Sternzeitberechnung nach VSOP87
T :=JD − 2451545
36525T1 := 280, 46061837 + 360, 98564736629 · (JD − 2451545)
T2 := 0, 000387933 · T 2 − T 3
38710000
Sternzeit := (T1 + T2) · 24
360
31
C. Quellcodes
B.2. Berechnung des Julianischen Datums nach VSOP87
monatkorrigiert :=
{monat + 12 falls monat > 3monat ansonsten
jahrkorrigiert :=
{jahr − 1 falls monat > 3jahr ansonsten
a :=jahrkorrigiert
100
b :=
2− a + (a/4) falls jahrkorrigiert > 1582oder jahrkorrigiert = 1582 ∧monatkorrigiert ≥ 10 ∧ tag ≥ 4
0 ansonsten
tagkorrigiert := tag +stunde
24+
minute
1440+
sekunde
86400
JD := 365, 25·(jahrkorrigiert+4716)+30, 6001·(monatkorrigiert+1)+tagkorrigiert+b−1524, 5
C. Quellcodes
Es folgen die Quellcodes der Teleskopsteuerung in Python. Die Quellcodes der C-Module finden sich auf der beigelegten CD-ROM, da diese ca. 50 Seiten einnehmenund fur die eigentliche Steuerung nicht relevant sind. Zur Beachtung: Einer stil-len Konvention bezuglich dem Verfassen von Quellcodes folgend, wurden samtlicheBezeichner Englisch benannt.
C.1. Client - TAPI Modul
./client/tapi/tapi.py
import time
import threading
import RPCsf
goto_state=1
_rpc=None
sock=None
def infobox(message, title="info"):
import os
os.spawnv(os.P_NOWAIT,
"C:\\Programme\\Python22\\pythonw.exe",
("C:\\Programme\\Python22\\pythonw.exe",
32
C. Quellcodes
"infobox.pyw \"%s\" \"%s\""%(message,title)))
def Settings():
pass
def goto_thread(ra, dec):
global _rpc, goto_state
goto_state=0
ra=(ra-12.0)%24.0
try:
try:
_rpc.call("DEC.move_to", (dec,))
_rpc.call("RA.move_to", (ra,))
except Exception, msg:
infobox(msg, "Warnung")
raise
finally:
goto_state=1
def GotoRaDec(ra, dec):
global goto_state
goto_state=0
t=threading.Thread(target=goto_thread, args=(ra, dec))
t.start()
pass
ra=0
dec=0
def GetRaDec():
global _rpc, ra, dec
try:
ra=(_rpc.call("RA")+12.0)%24.0
dec=_rpc.call("DEC")
except:
pass
return (ra, dec)
def SetRaDec(ra_, dec_):
pass
def IsGotoComplete():
global goto_state
33
C. Quellcodes
return goto_state
def AbortGoto():
try:
_rpc.call("stop")
except:
pass
pass
def EstablishLink():
global _rpc, sock
import socket
import time
try:
sock=socket.socket(socket.AF_INET, socket.SOCK_STREAM)
sock.connect(("192.168.10.30", 1234))
_rpc=RPCsf.RPC_from_socket(sock)
_rpc.start()
except:
import sys
infobox("%s, %s"%(sys.exc_type,sys.exc_value), "Warnung")
raise
pass
def TerminateLink():
global _rpc, sock
import time
try:
_rpc.stop()
except:
pass
sock.close()
pass
./client/tapi/infobox.pyw
from wxPython.wx import *
if __name__=="__main__":
import sys
app=wxPySimpleApp()
dlg=wxMessageDialog(None, sys.argv[1], sys.argv[2],
34
C. Quellcodes
wxOK | wxICON_INFORMATION)
dlg.ShowModal()
app.MainLoop()
dlg.Destroy()
C.2. Host - Teleskopsteuerung
./host/rangeconverter.py
class range_converter:
def __init__(self, A_min, A_max, B_min, B_max):
self.delta_max_A=(A_max-A_min)
self.A_0=A_min
self.delta_max_B=(B_max-B_min)
self.B_0=B_min
def A_in_range(self, A):
return A >= self.A_0 and A <= self.A_0 + self.delta_max_A
def B_in_range(self, B):
return B >= self.B_0 and B <= self.B_0+self.delta_max_B
def B_to_A(self, B):
return self.delta_max_A*(B-self.B_0)/(self.delta_max_B)+self.A_0
def A_to_B(self, A):
return self.delta_max_B*(A-self.A_0)/(self.delta_max_A)+self.B_0
./host/converter.py
from range_converter import *
import settings
DEC_conv=range_converter(settings.dekl[0][0],
settings.dekl[0][1],
settings.dekl[1][0],
settings.dekl[1][1])
RA_conv=range_converter(settings.rekt[0][0],
settings.rekt[0][1],
settings.rekt[1][0],
settings.rekt[1][1])
35
C. Quellcodes
hour_angle_conv=range_converter(0, 24, 0, 360)
./host/settings.py
dekl=((-27, 70), (1.5, 9.0))
rekt=((30, 275), (0.0, 9.8))
timezone=2640 # seconds from Greenwich
./host/sidereal.py
def get_julian_day(timezone=0):
import math
import time
t=time.gmtime(time.time()+timezone)
years=t[0]
months=t[1]
days=t[2]
hours=t[3]
minutes=t[4]
seconds=t[5]
if months < 3:
years=years-1
months=months+12
a=years/100
if years > 1582 or ( years==1582 and months >= 10 and days >= 4):
b = 2 - a + (a/4)
else:
b = 0
days=float( days + hours/24.0 + minutes/1440.0 + seconds/86400.0 )
JD= math.floor(365.25*(years+4716))+
math.floor(30.6001*(months+1))+days+b-1524.5
return JD
def range_degrees(angle):
import math
temp=math.fmod(angle, 360)
36
C. Quellcodes
if temp<0.0:
temp=360+temp
return temp
def get_mean_sidereal_time(JD):
T=(JD-2451545.0)/36525.0
sidereal=280.46061837+(360.98564736629*(JD-2451545.0))+
(0.000387933*T**2)-(T**3/38710000.0)
sidereal=range_degrees(sidereal)
sidereal=sidereal*24.0/360.0
return sidereal
./host/interface.py
from nidaq import Device
import settings
d=Device(8)
def In_Prt():
return d.DIG_In_Prt(0);
def Out_Prt(pattern):
d.DIG_Out_Prt(0, pattern)
def motor_ctrl(on):
motor_off=2**0
old_state=In_Prt() & ~( motor_off )
new_state=0
if not on:
new_state=new_state|motor_off
Out_Prt(new_state|old_state)
def motor_ctrl_state():
motor_off=2**0
return not (In_Prt() & motor_off)
def control_state():
return d.AI_VRead(12, -1) > 2.5
def motor_DEC(speed):
37
C. Quellcodes
north=2**1
DEC_big=2**3
DEC_sm=2**4
threshold_1=0.25
threshold_2=0.75
old_state=In_Prt()& ~( north | DEC_big | DEC_sm )
new_state=0
if speed > 0:
new_state=new_state | north
if abs(speed)>0 and abs(speed)<threshold_1:
new_state=new_state | DEC_sm
elif abs(speed)>=threshold_1 and abs(speed)<=threshold_2:
new_state=new_state | DEC_big
elif abs(speed)>threshold_2:
new_state=new_state | DEC_big | DEC_sm
Out_Prt(new_state|old_state)
def motor_RA(speed):
west=2**2
RA_big=2**5
RA_sm=2**6
threshold_1=0.25
threshold_2=0.75
old_state=In_Prt()& ~( west | RA_big | RA_sm )
new_state=0
if speed > 0:
new_state=new_state | west
if abs(speed)>0 and abs(speed)<threshold_1:
new_state=new_state | RA_sm
elif abs(speed)>=threshold_1 and abs(speed)<=threshold_2:
new_state=new_state | RA_big
elif abs(speed)>threshold_2:
new_state=new_state | RA_sm | RA_big
Out_Prt(new_state|old_state)
38
C. Quellcodes
def V_RA():
return d.AI_VRead(2, -1)
def V_DEC():
return d.AI_VRead(3, -1)
def stop():
motor_ctrl(0)
motor_DEC(0)
motor_RA(0)
def start():
if not control_state():
stop()
raise Exception, "control not enabled"
motor_ctrl(1)
d.DIG_Prt_Config(0,0,1)
stop()
./host/move.py
def move_to_V(voltage, conv, motor, V_now, threshold=0.005):
import time
import interface
if not conv.B_in_range(voltage):
raise ValueError, "angle voltage out of range"
def delta():
return voltage-V_now()
for i in range(0, 5):
last=(time.time(), V_now())
while abs( delta() )>=threshold:
if not interface.motor_ctrl_state():
raise Exception, "motor control disabled"
if not interface.control_state():
39
C. Quellcodes
raise Exception, "control not enabled"
speed=delta() / 3.0
motor( speed )
if time.time()>last[0]+0.5:
if abs(V_now()-last[1])<threshold*speed*10:
motor(0)
raise Exception, "motor block"
last=(time.time(), V_now())
motor(0)
time.sleep(0.25)
./host/RA.py
import settings
import interface
import converter
import sidereal
from math import *
from move import *
def move_to_abs(ra):
# print "moving to A=", ra
try:
interface.start()
move_to_V(voltage=converter.RA_conv.A_to_B(ra),
conv=converter.RA_conv,
motor=interface.motor_RA,
V_now=interface.V_RA)
finally:
interface.stop()
def move_to(ra):
# print "moving to RA=", ra
ha=(sidereal.get_mean_sidereal_time(
sidereal.get_julian_day(settings.timezone)
)-ra)%24.0
ha=converter.hour_angle_conv.A_to_B(ha)
move_to_abs(ha)
def get_abs():
40
C. Quellcodes
return converter.RA_conv.B_to_A(interface.V_RA())
def get():
ha=get_abs()
ha=converter.hour_angle_conv.B_to_A(ha)
ra=(sidereal.get_mean_sidereal_time(
sidereal.get_julian_day(settings.timezone)
)-ha)%24.0
return ra
./host/DEC.py
import interface
import converter
from move import *
def move_to(dec):
try:
interface.start()
move_to_V(voltage=converter.DEC_conv.A_to_B(dec),
conv=converter.DEC_conv,
motor=interface.motor_DEC,
V_now=interface.V_DEC)
finally:
interface.stop()
def get():
dec=converter.DEC_conv.B_to_A(interface.V_DEC())
return dec
./host/telescope.py
import RA, DEC, interface
rpc=None
def init_rpc():
global rpc
rpc.add_proc("RA", RA.get)
rpc.add_proc("RA_abs", RA.get_abs)
rpc.add_proc("DEC", DEC.get)
rpc.add_proc("RA.move_to", RA.move_to)
rpc.add_proc("RA.move_to_abs", RA.move_to_abs)
41
C. Quellcodes
rpc.add_proc("DEC.move_to", DEC.move_to)
rpc.add_proc("control_state", interface.control_state)
rpc.add_proc("motor_ctrl_state", interface.motor_ctrl_state)
rpc.add_proc("stop", interface.stop)
if __name__=="__main__":
import socket
import RPCsf
# while 1:
try:
sock=socket.socket(socket.AF_INET, socket.SOCK_STREAM)
sock.bind(("", 1234))
sock.listen(1)
print "listening"
con=sock.accept()
print "connected with", con
sock.close()
rpc=RPCsf.RPC_from_socket(con[0])
init_rpc()
print "ready to go"
rpc.run()
except:
pass
con[0].close()
42
Quellenverzeichnis
Quellenverzeichnis
[1] Python Software FoundationPython Documentationhttp://www.python.org/doc/current
Auf der CD-ROM enthalten
[2] Python Software FoundationWriting Python Extensions Moduleshttp://www.python.org/doc/current/ext/ext.html
Auf der CD-ROM enthalten
[3] National InstrumentsNI-DAQ API Reference ManualNur erhaltlich in Verbindung mit der NI-DAQ Software.Auf der CD-ROM enthalten
[4] Nova ProjectlibnovaProgrammbibliothek fur astronomische Berechnungenhttp://nova.sourceforge.net
http://libnova.sourceforge.net
Auf der CD-ROM enthalten
[5] Software Bisque 912 12th Street Golden, Colorado 80401-1114 USA“The Sky” Astonomy Softwarehttp://www.bisque.com
Bezug in Deutschland uber diverse Fachhandler,z.B. INTERCON SPACETEC
[6] Dr. Anton Hammer †Dr. Hildegard HammerDr. Karl HammerPhysikalische Formeln und Tabellen6. Auflage1994 J. Lindauer Verlag(Schaefer), Munchen
43
Abbildungsverzeichnis
Abbildungsverzeichnis
1. Der “Wurzburg Riese” im Freibereich des Deutschen Museums. . . . 5
2. Bedienelemente zur manuellen Steuerung . . . . . . . . . . . . . . . . 6
3. Die Erde mit Ekliptik und Himmelsaquator . . . . . . . . . . . . . . 10
4. Sockel des “Wurzburg Riesen” . . . . . . . . . . . . . . . . . . . . . . 11
5. Das Stellgestange im Detail . . . . . . . . . . . . . . . . . . . . . . . 12
6. Ein Drehfeld . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
7. Die Motoren der Rektaszensionsachse . . . . . . . . . . . . . . . . . . 13
8. Kapazitiver Notstop Schalter . . . . . . . . . . . . . . . . . . . . . . . 18
9. Astronomiesoftware “The Sky” . . . . . . . . . . . . . . . . . . . . . 25
10. Teleskop-Symbolleiste . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
11. Objektinfo Box . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
12. Strahlungsspektrum der Sonne . . . . . . . . . . . . . . . . . . . . . . 31
44
Danksagung - Erklarung
Danksagung
Ich mochte vor allem Hermann Hagn danken, da ich ihn oft zu den “unmoglichsten”
Tageszeiten angerufen habe und er mir stets freundlich die Antworten zu meinen
spontan auftauchenden Fragen gab.
Ebenfalls danken will ich meinem Freund Bassem Salem, der mir seine Digi-
talkamera zur Verfugung stellte, mit der die Photos in dieser Arbeit gemacht
wurden.
Erklarung
Ich erklare, dass ich die Facharbeit ohne fremde Hilfe angefertigt und nur die im
Quellenverzeichnis angefuhrten Quellen und Hilfsmittel benutzt habe.
Munchen, den 31. Januar 2003 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .(Unterschrift des Schulers)
45
