Praxissemesterbericht - The MMT Observatory

Praxissemesterbericht 

für das 2.Praxissemester des 

Diplomstudiengangs Mechatronik 

der Hochschule Karlsruhe 

In Zusammenarbeit mit dem Institut 

Instituto de Astrofísica de Andalucía 

Departamento UDIT 

Granada, España 

Verfasser: Inés Seiler 

Matrikelnummer: 19332 

Praktikumzeitraum: WS07/08, 03.09.07 – 31.01.08 

Betreuer: José Luis Ramos, Luis Costillo 

Datum: 31.01.08 

( José Luis Ramos )

Hoocchhsscchhuul lee Kaarrl lssrruuhhee 

University of Applied Sciences 

Hochschule für Technik 

IIAA 

Instituto Astrofísica 

de Andalucía 

Vorwort 

Im Rahmen des Diplom-Studienganges Mechatronik der 

Hochschule Karlsruhe ist es vorgesehen ein (zweites) 

Praxissemester im Hauptstudium zu absolvieren. Für die rechtmäßige 

Anerkennung wird im Anschluss dieser Tätigkeit ein Bericht 

angefertigt und ein kurzer Vortrag im darauf folgenden Semester an 

der Hochschule gehalten. 

Mein Praxissemester im Ausland und zwar am Institut für 

Astrophysik in Andalusien (IAA) in Spanien zu absolvieren, erschien 

mir in zweifacher Hinsicht vorteilhaft. Zum Einen erhoffte ich mir 

kulturelle und sprachliche Herausforderungen und Erweiterung meiner 

Kenntnisse, zum Anderen Erfahrungen in einem für mich neuen 

Bereich der Technik und der naturwissenschaftlichen Disziplin der 

Astrophysik. Meine Erwartungen wurden nicht enttäuscht. 

Danksagung 

Ich danke vor allem dem Chef der Abteilung Luis Costillo 

(Doctor en Electrónica) und meinem Betreuer José Luis Ramos (Físico 

Electrónico) des IAA für die hervorragende Betreuung meiner 

Tätigkeiten während meines gesamten Aufenthalts. Sie ermöglichten 

es mir eigenständig zu arbeiten und unterstützten mich jederzeit 

soweit erforderlich. Die Einführung in die Abteilung UDIT und deren 

Tätigkeiten, verbunden mit der Rücksichtnahme auf anfängliche, 

sprachlich bedingte Kommunikationsprobleme waren eine wertvolle 

Hilfe. 

Mein besonderer Dank gilt ebenso den übrigen Mitarbeitern der 

Abteilung, für ihr freundliches Entgegenkommen und ihre 

Unterstützung bei der Arbeit, sowie bei privaten Angelegenheiten, 

beispielsweise bei der Wohnungssuche. Die Arbeitsatmosphäre war 

besonders freundlich und angenehm, und ich bin froh, dass ich in 

dieser Abteilung mein Praxissemester absolvieren konnte. 

Den Professoren Prof. Dr.-Ing. Edwin Hettesheimer und Prof. 

Dipl. Wirtsch.-Ing. Fritz. J. Neff der Hochschule Karlsruhe möchte ich 

für ihre Beratung und Unterstützung danken. 

Ein insgesamt außerordentlich positives Erlebnis! Vielen Dank 

an alle Beteiligten! 

Inés Seiler 

Inés Seiler 2. Praxissemesterbericht I




IIAA 


de Andalucía 

Erklärung 

Zur Erstellung dieses Dokumentes wurden folgende Hilfsmittel 

verwendet. 

Software: 

• Microsoft ® Office Word 2003 

• Modbus Poll Ver. 4.3.2. (Trial Edition) 

• National Instruments LabView v7.1 und v8.5 

Literatur und Dokumente: 

• siehe Literaturverzeichnis 

Ich erkläre darüber hinaus keine weiteren Hilfsmittel verwendet zu 

haben. Der vorgelegte Praxissemesterbericht wurde von mir ohne 

fremde Hilfe verfasst. Fremde Inhalte sind entsprechend 

gekennzeichnet, Quellen und (sofern bekannt) Autoren werden 

vollständig aufgeführt. Hervorhebungen im Text (Fettdruck) dienen 

hauptsächlich der verbesserten Lesbarkeit. 

Granada den 31. Januar 2008 

( Inés Seiler ) 

Inés Seiler 2. Praxissemesterbericht II




IIAA 


de Andalucía 

Inhaltsverzeichnis 

Danksagung............................................................................... I 

1.0 Instituto de Astrofísica de Andalucía ........................................1 

1.1 Die Umgebung ...................................................................1 

1.2 Das Institut .......................................................................1 

2.0 Übersicht der Tätigkeiten .......................................................4 

3.0 Das Observatorium OSN ........................................................5 

3.1 Einleitung: Die Teleskope und das aktuelle System.................5 

3.2 Das neue System ...............................................................7 

3.3 Die Steuerung der Alpha-Achse ............................................9 

3.4 Das Model „Modelo de Eje“ ................................................10 

4.0 Quadrature Encoder ERN 1070 (3600) ...................................12 

4.1 Einleitung ........................................................................12 

4.2 Das Auslesen ...................................................................13 

4.2.1 Die Hardware .............................................................13 

4.2.2 Die Software ..............................................................14 

4.2.3 Auslesen des Z-Signals................................................16 

4.3 Verwendung der Programme..............................................16 

5.0 Serielle 232-485 Kommunikation mit dem MODBUS-Protokoll ...17 

5.1 Einleitung ........................................................................17 

5.1.1 Aufgabenstellung ........................................................17 

5.2 Allgemeines und Konfigurationen........................................17 

5.2.1 Die Hardware .............................................................17 

5.2.2 Das MODBUS Protokoll ................................................18 

5.2.3 Modbus Nachrichten ....................................................18 

5.2.4 Konfiguration des N2300..............................................20 

5.3 RS-485 zu RS-485 Übertragung .........................................20 

5.3.1 Konfiguration der RS485-PCI-Karte ...............................20 

5.3.2 Einstellung der Software „Modbus Poll“ ..........................20 

5.4 RS-232 zu RS-485 Übertragung .........................................21 

5.4.1 Konfiguration des Patton RS-232-485 Konverters, Model 

2085 .................................................................................21 

5.4.2 Einstellung der Software „Modbus Poll“ ..........................22 

6.0 Steuerung der Kuppel des Teleskops .....................................23 

6.1 Übersicht.........................................................................23 

6.1.1 Aufgabenstellung ........................................................23 

6.3 Die Programmstruktur ......................................................25 

6.3.1 VI-Hierarchie..............................................................26 

6.3 Grundlagen......................................................................27 

6.3.1 CAN-Bus Basics ..........................................................27 

6.3.2 Verwendung des CAN-Busses .......................................28 

6.3.3 Übersicht der Kommandos ...........................................31 

Inés Seiler 2. Praxissemesterbericht III




IIAA 


de Andalucía 

6.4 Programa Principal............................................................33 

6.4.1 Abschnitt 1: Abfrage des User-Interfaces .......................33 

6.4.2 Abschnitt 2: CAN-Nachrichten als RS232 weiterleiten ......35 

6.4.3 Abschnitt 3: RS232-Nachrichten als CAN weiterleiten ......36 

6.4.4 Abschnitt 4: Weitere Tasten und Funktionen ..................37 

6.5 Ergebnisse.......................................................................37 

7.0 Absolutwert-Encoder RCN 829 ..............................................38 

7.1 Einleitung ........................................................................38 

7.1.1 Vorgehensweise der Entwicklung ..................................39 

7.2 Grundlagen und Hardware .................................................39 

7.2.1 Übersicht des Aufbaus .................................................39 

7.2.2 Der Encoder ...............................................................40 

7.2.3 Das FPGA...................................................................40 

7.2.4 Kommunikation über die parallele Schnittstelle ...............41 

7.3 Das Spannungspegel-Problem............................................41 

7.3.1 Lösung: Buffer Triestado Externo ..................................42 

7.4 Die Software....................................................................45 

7.4.1 Kommunikationsbausteine ...........................................45 

7.4.2 EnDat2.2: zu lesende/schreibende Register....................46 

7.4.3 Hauptprogramm .........................................................47 

7.5 Ergebnisse.......................................................................49 

7.6 Weiteres Vorgehen ...........................................................50 

8.0 Fazit ..................................................................................51 

9.0 Anhang ..............................................................................52 

9.1 Abkürzungsverzeichnis & Glossar........................................52 

9.2 Abbildungsverzeichnis .......................................................52 

9.3 Tabellenverzeichnis...........................................................54 

9.4 Quell- und Literaturverzeichnis...........................................55 

9.4.1 Bildquellen .................................................................55 

9.4.2 Softwarequellen..........................................................56 

Inés Seiler 2. Praxissemesterbericht IV




IIAA 


de Andalucía 

1.0 Instituto de Astrofísica de Andalucía 

1.1 Die Umgebung 

Das Instituto de Astrofísica de Andalucía (IAA) liegt im Süden 

Spaniens in der autonomen Region Andalusien. Die Region ist 

weiterhin in 8 Provinzen unterteilt, darunter die Provinz Granada, in 

welcher sich in der gleichnamigen Hauptstadt das Institut nahe des 

Zentrums befindet. 

Bild 1: Granada in Spanien 

Die Stadt Granada ist 

aufgrund einiger 

Sehenswürdigkeiten 

ein beliebter 

Touristenort. Bekannt 

ist vor allem die aus 

maurischen Zeiten 

stammende Festung 

Alhambra, welche aus 

einer Ansammlung 

von Palästen aus dem 

13. und 14. 

Jahrhundert besteht. 

Die Stadt liegt zudem nahe der Sierra Nevada, welches das 

größte Gebirge der iberischen Halbinsel ist - 1996 fand hier die alpine 

Skiweltmeisterschaft statt. Neben dem Skigebiet ist dort ebenso das 

Observatorio Sierra Nevada (OSN) vorhanden, welches vom IAA 

geführt und betrieben wird. 

1.2 Das Institut 

Das Consejo Superior de Investigaciones 

Científicas (CSIC) ist die Spanien weit größte staatliche 

Forschungseinrichtung die in 8 technischnaturwissenschaftlichen 

Bereichen agiert. 148 

Einrichtungen der CSIC beschäftigen sich mit 

Universitäten und anderen Instituten. Eines hiervon ist 

das IAA, dessen Aufgabe darin besteht sich mit der 

Feldforschung im Bereich Astrophysik sowie der 

Entwicklung der Instrumentierung von Teleskopen und 

Raumflugkörpern auseinander zusetzen. Ziel ist es, 

Bild 2: CSIC 

Logo 

naturwissenschaftliche Informationen über das Universum zu 

sammeln – vom kleinsten Partikel, über das Sonnensystem hinaus bis 

hin zu einer Skala, die das vollständige Universum abdeckt. 

Inés Seiler 2. Praxissemesterbericht 1




IIAA 


de Andalucía 

Bild 3: Organigramm des IAA 

Dem Organigramm (Bild 3) ist zu entnehmen, dass sich der 

Hauptsitz (Sede Central) aus den Bereichen Forschung 

(Investigación) und Dienstleistung (Servicio) zusammensetzt. 

Insgesamt werden ungefähr 180 Personen an dem Institut 

beschäftigt. Die Dienstleistungen werden weiterhin unterteilt in 

allgemeine Dienstleistungen (wie beispielsweise die Bibliothek vor 

Ort), das Rechenzentrum (Centro de Cálculo) sowie die 

Entwicklungsabteilung (Unidad de Desarrollo Instrumental y 

Tecnológico - UDIT). In Letzterem werden Mitarbeiter beschäftigt die 

in den technischen Bereichen Optik, Elektronik, Mechanik und 

Informatik ausgebildet wurden, welche Passenderweise mit dem 

Inhalt des Mechatronik Diplom-Studiengangs der HS-Karlsruhe 

übereinstimmen. (Scherzhafterweise wurde vorgeschlagen, dass die 

Mitarbeiter dieser Abteilung in Urlaub gehen könnten, während ich als 

Mechatronikerin für alle gleichzeitig die Stellung halten könne.) 





IIAA 


de Andalucía 

Die Abteilung UDIT spaltet sich weiterhin auf in die Bereiche 

instrumentos para observación astrofísica en tierra e instrumentos 

para observación astrofísica en el espacio (Instrumente für 

Astrophysische Beobachtungen „auf der Erde“ und „im Weltraum“). 

Für die Entwicklung des Ersteren, d.h. für die Teleskope, ist Luis 

Pedro Costillo Iciarra verantwortlich. Zusammen mit meinem 

Betreuer, José Luis Ramos Más, beschäftigt er sich mit der damit in 

Verbindung stehenden Elektronik. 

Vor Ort besteht das Institut aus zwei Gebäuden (in naher 

Zukunft soll ein Drittes in Betrieb genommen werden), wobei eines 

davon ausschließlich die UDIT-Abteilung beinhaltet, während die 

restlichen Abteilungen im Hauptgebäude untergebracht sind. 

Bild 4: Observatorio Sierra Nevada (OSN) 

Bild 5: Logo OSN 

Sehr wichtig und nicht zu vergessen sind natürlich die beiden 

Observatorien Observatorio Sierra Nevada (OSN) und Observatorio 

Calar Alto. Letzteres befindet sich in dem Gebirge Sierra de los 

Filabres, nördlich von Almeria. Es wird vom IAA zusammen mit dem 

Max-Plack-Institut für Astronomie (MPIA, Heidelberg) betrieben. 

Insgesamt sind dort 4 Teleskope vorhanden, allerdings steht eines 

davon unter der Leitung des Observatorium Madrid. Das OSN 

hingegen verfügt über 2 optische Nasmyth-Teleskope von den Größen 

150cm („T150“) und 90cm („T90“), sowie ein IR Ritchey-Chrétien- 

Teleskop der Größe 60cm. Es liegt 2800m über dem Meeresspiegel. 

Bild 6: Prinzip des Nasmyth- 

Teleskops 

Bild 7: Prinzip des Ritchey-Chrétien- 

Teleskops 





IIAA 


de Andalucía 

2.0 Übersicht der Tätigkeiten 

Folgende Tabelle enthält einen groben chronologischen Abriss 

der von mir im Zeitraum 03.09.2007 – 31.01.2008 durchgeführten 

Tätigkeiten. Einzelne kleinere Aufgaben sind in der Tabelle nicht 

enthalten. Im Anschluss an einige Tätigkeiten war es erforderlich die 

Ergebnisse in einer Dokumentation festzuhalten. 

Tätigkeiten 

- Kennen lernen des Instituts, Einarbeitung in die 

Thematik 

- Einarbeitung in das Programm LabView mit 

Erstellung verschiedener Programme zu 

Lernzwecken. 

- Erstellen eines LabView Programms zum Auslesen 

eines Quadratur Encoders (ERN 1070). 

- Kennen lernen der Kommunikation mittels CAN- 

Bus anhand einer Testflachbaugruppe. 

- Gedanken zur Auswahl der Servomotoren für das 

Teleskop. 

- Kommunikation mit RS232 und RS485 zwischen 

einem PC und einem Temperaturregler. 

- LabView Programm zur Steuerung der Kuppel des 

Teleskops: Implementierung der Kommunikation 

über CAN-Bus bzw. RS-232. 

- LabView Programmierung zur Kommunikation 

zwischen einem PC über ein NI DAQ-Pad und dem 

EnDat2.2 Masterbaustein der Firma MAZeT. Ziel: 

Auslesen eines Absolutwert-Encoders. 

Tabelle 1: Chronologischer Tätigkeitsabriss 

Die nachfolgenden Kapitel werden nur die wichtigsten 

Tätigkeiten abhandeln, da es im Rahmen diesen Berichts nicht 

möglich ist auf alle Einzelheiten einzugehen. Die Reihenfolge der 

Kapitel ist chronologisch. 





IIAA 


de Andalucía 

3.0 Das Observatorium OSN 

3.1 Einleitung: Die Teleskope und das aktuelle System 

Die beiden Teleskope T150 und T90 des Observatoriums OSN 

sind abgesehen von der Größe weitgehend baugleich. Unterschiede 

sind lediglich in Details, wie beispielsweise der Anzahl der Lager zu 

finden. Sie befinden sich innerhalb eines gemeinsamen Gebäudes 

(siehe Bild 4), sind aber baulich vom Gebäude getrennt um zu 

vermeiden, dass Schwingungen auf die Teleskope übertragen werden. 

Bild 8: Das T150 innerhalb der Kuppel. Die Hauptachse ist parallel zum 

Äquator ausgerichtet (equatorial mount). 

Die Steuerung und Elektronik der Teleskope sind nahezu 

identisch, jedoch etwas veraltet. Momentan ist ein zentrales, für 

damals übliches, VME-Modul aus dem Jahre 1995 für jedes Teleskop 

installiert. Es gibt jedoch diverse Probleme. Beispielsweise werden 

Daten und Energie über ein Bündel Kabel am unteren Ende der 





IIAA 


de Andalucía 

Teleskope übertragen. Werden die Teleskope auf gewünschte 

Koordinaten gefahren, verursacht die Bewegung jedes Mal eine 

enorme mechanische Belastung der Kabel. Außerdem führen 

Wartungen oder Fehlerbehebungen der Elektronik sowie die harten 

Wetterbedingungen oft zu weiteren Defekten, was regelmäßige 

akribische Fehlersuchen nach fehlerhaften Kontakten notwendig 

macht. Wartungen werden somit teilweise sehr zeitaufwändig. 

Bild 9: Das aktuelle System 

Es erschien somit sinnvoll das System mit durch ein Neueres 

und Effizienteres zu ersetzen. Dies ermöglicht es auch, im Rahmen 

der Überarbeitung, neuere Technologien einzusetzen, welche zu 

erhöhter Genauigkeit und Präzision beitragen. 

Da parallel zu den technischen Weiterentwicklungen die 

Teleskope jedoch auch für Forschungszwecke genutzt werden, ist es 

nicht möglich die Systeme, wenn erforderlich, für einige Zeit einfach 

abzuschalten um Änderungen vorzunehmen. Der normale Betrieb der 

Teleskope wird nur einmal pro Monat für eine Woche unterbrochen 

um Reparaturen und dergleichen vorzunehmen. Außerdem kann nicht 

vor Ort mit der Trial-and-Error-Methode vorgegangen werden, da bei 

fehlerhaftem Verhalten eventuell sehr teuere Schäden entstehen 

könnten. 

Es kommen organisatorische und geographische Restriktionen 

hinzu, da die Entwicklungsabteilung sich in der Stadt, die Teleskope 

jedoch auf dem Berg befinden. Die Anfahrt erfordert ungefähr eine 





IIAA 


de Andalucía 

Stunde Fahrzeit sowie ein 4-Rad-betriebenes Fahrzeug um die letzten 

Höhenmeter einer Schotterpiste mitten im Skigebiet zu überwinden. 

Bei Schnee im Winter ist die Station nur mit Schnee-mobilen 

(Motorschlitten) zu erreichen und je nach Wetterlage von der 

Außenwelt sogar für einige Zeit physikalisch abgeschnitten. Das 

Observatorium verfügt daher über eine im Winter reichlich mit 

Lebensmitteln ausgestattete Vorratskammer. 

Es ist also notwendig anhand eines Models, welches dem 

Original sehr genau und maßstäblich entsprechen muss, das neue 

System ausgiebig zu entwickeln und zu testen um Fehler zu quasi 

hundert Prozent zu beseitigen bevor es im OSN eingesetzt wird. Da 

die Teleskope baugleich sind, reicht es für beide nur ein Model zu 

nutzen. Da die Präzisionsanforderungen an das T150 höher sind als 

an das T90 wird das neues System für das T150 entwickelt. Später 

soll dies dann lediglich für das kleinere Teleskop dupliziert werden. 

3.2 Das neue System 

Jedes der beiden Teleskope soll mit einem dezentralen System 

gesteuert werden. Die einzelnen Knoten werden mit einem seriellen, 

linearen Bus verbunden. Gleichzeitig sollen jedoch alle 

Systemressourcen überall und jederzeit einer zentralen Einheit über 

das Internet zur Verfügung stehen. Die verschiedenen Aufgaben 

wurden eingeteilt in die folgenden Knotenpunkte: Steuerung der 

Alpha-Achse, Steuerung der Delta-Achse, die Kuppel, die 

Fokussierung, und eine zentrale Einheit als Schnittstelle für einen 

PC. 

Die Knoten für Alpha, Delta und die Kuppel werden mit FPGA’s 

realisiert um ein effizientes Einlesen und Verarbeiten der Encoder 

(Winkelmessgeräte) und der Steuerungsalgorithmen zu 

gewährleisten, sowie um die Ausgänge für die Motoren und die 

Servo’s zu generieren. Der Fokus wird über einen Mirkokontroller 

verfügen und das System wird einfach zu erweitern sein, falls mehr 

Knoten erforderlich werden sollten. 

Für die Kommunikation wurde der CAN-Bus aufgrund seiner 

Zuverlässigkeit und der Möglichkeit des Broadcastings (ein Sender, 

mehrere Empfänger) ausgewählt, so dass alle wichtigen 

Informationen auf dem Bus stets vorhanden sind, und jeder Knoten 

(Empfänger) jederzeit Zugriff auf diese Informationen hat. 

Das aktuelle System (Bild 9) verfügt über: 

• die Steuerung der Alpha und Delta Bewegungen, 

• des sekundären und tertiären Spiegels, 

• sowie die Steuerung des primären Spiegels. 





IIAA 


de Andalucía 

• Außerdem gibt es noch Sicherheitssysteme für das Teleskop, 

• sowie solche die der Astrophysischen Beobachtungen dienen. 

Die Verteilung der Steuersysteme des neuen Systems (Bild 10) 

soll wie folgt aufgeteilt werden: 

Alpha-Achse: 

Delta-Achse: 

Die Kuppel: 

Die Ausrichtung und Führung müssen korrekt 

gesteuert werden. Absolute, relative und 

inkrementale Bewegungen müssen mit mindestens 

drei Geschwindigkeiten durchführbar sein. Ebenso 

muss die Winkelsicherheit gewährleistet sein 

(Vermeidung gefährlicher Winkel) und die 

Gegengewichte angepasst werden. Ein GPS- 

Empfänger ermöglicht den Betrieb im 

astronomischen Koordinaten-System. 

Absolute, relative und inkrementale Bewegungen 

mit drei verschiedenen Geschwindigkeiten und der 

Genauigkeit von einer Bogensekunde müssen 

möglich sein. 

Steuerung der positiven und negativen Asimuth- 

Bewegungen. 

Sekundärspiegel: Auslesen der Positionen und Limits, sowie 

Fokusbewegungen. Ein Hexapod der den Spiegel 

stützt muss ebenso gesteuert werden. 

Tertiärspiegel: 

Muss zwischen dem Ost- und West-Nasmyth-Fokus 

schalten können. 

Primäre Abdeckungen: Die Abdeckung des Primärspiegels muss 

geöffnet und geschlossen werden, und die Position 

ermittelt werden. 

Computer Instrument: Jedes Instrument des Teleskops braucht 

einen Computer für die Steuerung. Dieser ist mit 

dem globalen Kontrollsystem verbunden und steuert 

das Instrument mit entsprechenden Standardkommandos. 

Aus Bild 10 ist ersichtlich, dass alle Module von dem zentralen 

Modul kontrolliert werden. Die Kuppel, die Alpha- und Delta-Achsen 

können manuell oder automatisch gesteuert werden. Mit dem Modul 

„Others“ wird der Zugriff auf die Spiegel und den Fokus 

gewährleistet. 





IIAA 


de Andalucía 

Bild 10: Struktur des neuen dezentralen Systems 

Das Zentralmodul ist über Ethernet mit einem PC (Instruments 

Computer) verbunden und kann daher auch fernbedient (remotely 

controlled) werden. Der Benutzer kann also in drei verschiedenen 

Modi das Teleskop betreiben: manuell, automatisch und durch remote 

control über das Internet. 

3.3 Die Steuerung der Alpha-Achse 

Die Alpha- und die Delta-Achsen sind ähnlich in ihrem 

physikalischen Aufbau. Jede Achse verfügt über zwei Motoren (Motor 

und Gegenmotor) und eine Notbremse. Im ersten PID-Regelkreis 

wird ein relativer Encoder (Winkelmessgerät) direkt mit dem Motor 

verwendet. Die Achsenstellung wird mit einem 10-Bit absolutem 

Encoder ausgelesen, bei einer Genauigkeit von 21 Bogenminuten, 

wobei die Bogensekundengenauigkeit von einem relativen 

Inductosyn ® Encoder geliefert wird. Ein HCTL-Controller steuert die 

Bewegungen. Die siderische Bewegung wird mit einem Quarz 

entsprechender Frequenz gemessen. 

Neben weiteren Veränderungen sollen im neuen System die 

Motoren durch Neuere, und das Kodierungs-System durch einen 29- 

Bit absoluten Encoder ersetzt werden. 





IIAA 


de Andalucía 

Dies ist eines der komplexesten Module des Systems, da viele 

Stellgrößen berücksichtigt werden müssen und ein bestimmtes Maß 

an Präzision gewährleistet sein muss. Zudem sollen beide Achsen 

(Alpha und Delta) durch ein einziges Modul gesteuert werden. Es 

sollen daher COTS (Commercial Off The Shelf) Produkte verwendet 

werden um den Aufbau und die Umsetzung zu vereinfachen und vor 

allen Dingen um die erforderliche Entwicklungszeit gering zu halten. 

Bild 11: Altes System der Achsen 

Bild 12: Neues System der 

Achsen 

Aus diesem Grund wurde entschieden das Reconfigurable 

Compact Embedded System (cRIO) von National Instruments (NI) 

zu verwenden. Mit dessen 200 MHz Prozessor sind zuverlässige Real- 

Time Applikationen möglich, und 3M Gates stehen für die 

Handhabung der I/O’s zur Verfügung. Die FPGA’s können mit der 

höheren Programmiersprache LabView programmiert werden. Dieses 

Modul wird direkt an dem Teleskop angebracht da die kompakte 

Größe und der geringe Stromverbrauch dies zulassen. Somit wird die 

Anzahl der Kabel erheblich reduziert. 

3.4 Das Model „Modelo de Eje“ 

Das Ziel ist es ein Modell bzw. eine Arbeitsvorlage zu 

entwickeln, welche sich in mechanischer und elektronischer Weise 

sowie bei der Datenverarbeitung den echten Teleskopen gleicht. Ein 

mechanisches Modell der Alpha-Achse besteht bereits, an welchem 

damals (1988) erste Versuche mit dem Mikrokontroller (HCTL 1000) 

zur Steuerung der Motoren durchgeführt wurden. Nach diesen ersten 

Proben am Modell wurden die Teleskope direkt weiterentwickelt. 

Folgende Punkte sollen dabei beachtet werden. 





IIAA 


de Andalucía 

• Das bereits bestehende mechanische Modell soll verwendet 

und weiterentwickelt werden. 

• Anders als zuvor, soll das neue Modell immer auf dem 

aktuellen Stand des Teleskops gehalten werden. Zukünftige 

Verbesserungen sollen zuerst am Modell vorgenommen werden, 

um die Arbeitszeit am Teleskop zu minimieren. 

• Das zukünftige Modell soll nicht nur die Bewegungen des 

Teleskops simulieren, sondern das vollständige System 

abbilden. 

Alpha-Achse des 

Modells 

Bild 13: Mechanisches Modell des Teleskops 

Positionen des 

Motors und 

Gegenmotors 





IIAA 


de Andalucía 

4.1 Einleitung 

4.0 Quadrature Encoder ERN 1070 (3600) 

Ein relativer Quadrature Encoder wird im Zusammenhang mit 

dem ersten PID-Regelkreis der Motoren der Alpha-Achse verwendet 

um eine Rückmeldung der angefahrenen Position zu erhalten. Hierfür 

soll der ERN 1070 mit 36000 Perioden pro Umdrehung von 

Heidenhain verwendet werden. 

Ein Quadrature Encoder (Bild 14) 

verfügt über 3 Signale, die Informationen 

zur gemessenen Position liefern. Diese 

Signale werden intern optisch erzeugt. 

Signal B (oder U a2 ) ist immer um 90º 

phasenversetzt zu Signal A (U a1 ). Bei einer 

Drehung im Uhrzeigersinn folgt B dem 

Signal A (Bild 15); gegen den Uhrzeigersinn 

ist B dem Signal A um 90º voraus. Aus 

diesem Phasenversatz lässt sich somit die 

Drehrichtung bestimmen. 

Bild 14: ERN 1070 

Diese Ausführung des Encoders liefert insgesamt 4x36000 = 

144000 Flanken, da eine Umdrehung aus 36000 Perioden pro Signal 

besteht und jede Periode über eine Auf- und eine Abflanke verfügt. 

Somit ist eine Genauigkeit von 0,0025º = 9 Bogensekunden möglich 

sofern alle 4 Flanken pro Periode ausgelesen werden. 

Als dritte und zusätzliche Information ist das Signal Z (U a0 ) 

vorhanden, welches nur einmal pro Umdrehung immer an der 

gleichen Position einen Impuls erzeugt. 

Bild 15: Signale eines relativen Quadrature Encoders (Uhrzeigersinn) 





IIAA 


de Andalucía 

Je nachdem ob man 

eine (X1), zwei (X2) oder 

vier (X4) Flanken ausliest 

erhält man verschiedene 

Positionsgenauigkeiten (Bild 

16). Da für das Teleskop 

die 

höchstmögliche 

Genauigkeit erforderlich ist, 

wird die X4 Variante 

gewählt. 

4.2 Das Auslesen 

Zum Auslesen des 

Encoders soll sowohl Hardware 

als auch Software des Bild 16: X1, X2 und X4 Encoder 

Herstellers National 

Instruments verwendet werden, da eine Auswahl dieser Produkte 

bereits im Institut vorhanden sind. Als Software wird das Programm 

LabView verwendet. Für die Auswahl der Hardware muss zunächst ein 

geeigneter Zähler gefunden werden. Zwei verbreitete Zähler von NI 

sind der DAQ-STC und der NI-TIO. 

4.2.1 Die Hardware 

Da zunächst nur ein DAQ-6016 Board zur Verfügung stand 

wurde somit der STC-Zähler verwendet. Dieser unterstützt jedoch 

nicht direkt Quadrature Encoding. Für jede einzelne Flankenart die zu 

zählen ist, wird je ein Counter erforderlich. Das 6016 Board verfügt 

jedoch nur über 2 Counter, somit ist nur X1 oder X2 möglich. Das 

Auslesen des Z-Signals ist außerdem nicht gleichzeitig möglich und 

die Programmierung erwies sich insgesamt als etwas umständlich. Da 

dies ohnehin keine geeignete Lösung war und die erforderliche 

Genauigkeit nicht erreicht werden konnte, wird an dieser Stelle nicht 

weiter auf die erfolgte Ausarbeitung eingegangen. 

Nachdem ersichtlich wurde, dass ein NI-TIO Zähler für eine X4- 

Messung notwendig und unumgänglich ist, war es mir möglich eine 

entsprechende NI-Karte im Institut aufzutreiben: eine PCI-6601 

Karte. Dieser Zählertyp unterstützt sowohl X1-X4 Encoding, als auch 

das Z-Signal. Hierfür ist nur ein einziger Zähler erforderlich und die 

Art des Encodings wird per Software ausgewählt. Ein Zähler verfügt 

über mehrere Eingangspins. Sie werden wie folgt verbunden: 

• Signal A mit Eingang „Source“. Dies ist die eigentlich Quelle für 

den Zähler. Je nach Einstellung wird bei entsprechender Flanke 

(auf, ab, oder beide) der Zählerwert um den Wert „1“ 

verändert. 





IIAA 


de Andalucía 

• Signal B mit „Aux“ (oder „up/down“). Dieser Pin legt die 

Zählrichtung fest, also ob der Zählwert erhöht oder herabgesetzt 

wird. Wird beispielsweise bei einer Abflanke von A ein 

High von B gelesen wird hochgezählt, bei einem Low wird 

heruntergezählt (oder umgekehrt, je nach Softwareeinstellung). 

• Das zusätzliche Signal Z wird mit dem „Gate“ des Zählers 

verbunden und führt bei Detektion einer Flanke zu einem Reset 

auf 0 des Zählers. 

4.2.2 Die Software 

Bild 17: Foto der Hardware 

Das GUI der Software ist in Bild 18 zu sehen. Bevor das 

Programm gestartet wird muss zuerst das Gerät und der 

entsprechende Zähler des Geräts aus der Drop-Down-Liste 

ausgewählt werden. Erzeugt man nun Signale indem man den 

Encoder dreht wird die Bewegung numerisch und grafisch angezeigt. 

Bild 18: GUI des LabView Programms für ERN 1070 

Abbildung 19 zeigt den dazugehörigen Quellcode. Die roten 

Markierungen gehören nicht zum Code, sondern zeigen die Struktur 





IIAA 


de Andalucía 

auf: Initialisierung, Routine des Datenauslesens und die Beendigung 

des Programms. 

Initialisierung: Zuerst werden die Einstellungen für die 

Hardware festgelegt. Es wird der Zähler ausgewählt (Counter), der 

Startwinkel (Data) geladen, das Hardware-Offset zur Nullmarke 

geladen (Z Index Value), die Dekodierungsart festgelegt (X4), das 

Z-Signal verwendet (Enable = true), die Z-Index Phase festgelegt (A 

High B High, siehe Bild 15), und die Anzahl der Pulse pro 

Umdrehung (pro Kanal) auf 36000 gesetzt. Danach wird der Prozess 

zum Hardwareauslesen gestartet (DAQmx Start Task). 

Initialization 

Read Data 

End Task 

Bild 19: LabView Blockdiagram für ERN 1070 

Daten Auslesen: Der eigentliche Kern des Programm läuft in 

einer While-Schleife ab. Diese wird beendet sobald ein 

Hardwarefehler auftritt oder der STOP-Knopf gedrückt wird. Mit 

einem DAQmx Read Piktogramm wird bei jeder Ausführung der 

Schleife der aktuelle Zählerstand ausgelesen. Dieser wird bereits in 

der Einheit „Grad“ geliefert, so dass keine weitere Umrechnung des 

Zählerwertes notwendig ist. Das Ergebnis wird direkt angezeigt 

(Data). Die Daten sind auch drehrichtungsabhängig, so dass sich eine 

Datenbandbreite von -360º bis +360º ergibt. Jede detektierte Flanke 

verändert den Zählerstand um ±0,0025º. 

Beenden: Der gestartete Hardwareprozess wird vor Schließung 

des Programms beendet (DAQmx Clear Task) und mit einer 

Fehlerbehandlungsroutine versehen. 

Mit diesem Programm ist es jedoch nur möglich die aktuelle 

Winkelposition zu ermitteln. Der Verlauf wird dabei jedoch nicht 





IIAA 


de Andalucía 

überwacht, bzw. die Anzahl von Umdrehungen wird nicht gezählt. Um 

dies zu realisieren wird ein weiterer Zähler verwendet in Verbindung 

mit dem Z-Signal. 

4.2.3 Auslesen des Z-Signals 

Zusätzlich zu den bereits verwendeten Signalen A, B und Z sind 

auch die invertierten Signale /A, /B und /Z vorhanden. Z steht nicht 

mehr zur Verfügung, also wird Kanal /Z mit dem Eingang „Source“ 

eines zweiten Zählers verbunden. Das Programm ähnelt dem Vorigen. 

Zur Initialisierung der Hardware wird festgelegt, dass fallende 

Flanken gezählt werden sollen (siehe Bild 15, Invertierung des 

Signals U a0 ). „Count up“ legt fest, dass grundsätzlich hochgezählt 

wird, unabhängig von der Drehrichtung – dies muss später per 

Software ausgewertet werden, welche dieses Programm als 

Unterfunktion verwendet. „Initial Count“ wird auf einen Wert (in 

diesem Beispiel 0) gesetzt, welcher den Anfangszählwert festlegt. 

Initialization 

Read Data 

End Task 

Bild 20: LabVIEW Blockdiagram zum Auslesen des /Z-Kanals 

4.3 Verwendung der Programme 

Ziel der Arbeit war es herauszufinden wie es möglich ist den 

Encoder ERN1070 mit der erforderlichen Präzision auszulesen. Die 

beiden VI’s (Virtual Instrument = Programmdatei von LabVIEW) 

können nun als Sub-VI’s in andere LabVIEW Programme eingebunden 

werden. Diese erscheinen als Piktogramme mit Ein- und Ausgängen. 

Eingänge sind diverse Einstellungen wie z.B. die Zählerauswahl, die 

Ausgänge sind die Zählerstände sowie Fehlermeldungen. 





IIAA 


de Andalucía 

5.0 Serielle 232-485 Kommunikation mit dem 

MODBUS-Protokoll 


Neben Aufgaben, die direkt mit dem Projekt des Teleskops in 

Verbindung stehen, fielen auch kleinere Aufgaben an welche nur 

indirekt mit den Teleskopen zu tun haben. Als Beispiel einer dieser 

Aufgaben wird in diesem Abschnitt auf die Kommunikation zwischen 

einem PC und einem Temperaturregler eingegangen. Temperaturregler 

werden in den Laboren des IAA eingesetzt um bei Versuchen 

die Temperaturschwankungen zu minimieren. 

5.1.1 Aufgabenstellung 

Das Ziel dieser Aufgabe ist es eine Kommunikationsmöglichkeit 

herzustellen zwischen einem Temperaturregler des Modells WEST 

N2300-1222 mit einer seriellen RS-485 (halb duplex) Schnittstelle 

und einem PC. Der PC verfügt über zwei verschiedene verwendbare 

Schnittstellen (Tabelle 2). Es soll das Protokoll MODBUS für die 

Kommunikation verwendet werden. Anschließend werden die 

Lösungsmöglichkeiten in einem Bericht dokumentiert. 

Schnittstellen: 

Beschreibung 

PC - N2300 

RS485 - RS485 PCI-RS485 Karte notwendig 

RS232 - RS485 RS232-RS485 Umwandler notwendig 

Tabelle 2: Übersicht serieller Kommunikationsmöglichkeiten 

5.2 Allgemeines und Konfigurationen 

5.2.1 Die Hardware 

Die verwendete Hardware besteht aus der Karte UC-313 

Universal Dual Velocity RS422/485 von der Firma Brainboxes Ltd. 

(PCI-Karte mit zwei RS485 COM Ports), dem Umwandler RS232 to 

RS485 Converter Model 2085 der Firma Patton Electronics, und dem 

Temperaturregler WEST N2300-Y1222 von West Instruments. 





IIAA 


de Andalucía 

Bild 21: UC-313 Bild 22: RS485 Converter Bild 23: WEST N2300 

5.2.2 Das MODBUS Protokoll 

Für die Kommunikation verwendet der Temperaturregler das 

Protokoll Modbus. Dieses Protokoll kann mit jeder seriellen 

Verbindung genutzt werden, ob RS232 oder RS485. Allgemein gibt 

es zwei verschiedene Nachrichtenformate: ASCII und RTU. Der 

Temperaturregler verwendet das Modbus/RTU Format mit einer 

RS485 Schnittstelle. 

Bild 24: Eigenschaften von Modbus ASCII & RTU 

Es werden die Einstellungen nach Bild 24 mit „no parity“ und 

zwei Stop-Bits verwendet. Im Anschluss zu jeder Nachricht wird ein 

CRC-Check versandt um die Daten zu verifizieren. 

Im Rahmen dieser Arbeit wurde die kostenlose Trial-Version des 

Programms „Modbus Poll Ver. 4.3.2“ als Kommunikationssoftware 

des PCs verwendet. 

5.2.3 Modbus Nachrichten 

Die Struktur von Modbus-Nachrichten ist sowohl für das ASCII 

als auch das RTU-Format gleich (Bild 25). Die darin enthaltenen 

Funktionscodes sind standardisiert (Bild 26). 





IIAA 


de Andalucía 

Bild 25: Modbus Nachrichtenstruktur 

Bild 26: Modbus Function 

Codes 

Eine Nachricht kann beispielsweise so aussehen (hexdezimal): 

Nachricht vom PC: 

Antwort des Sensors: 

01 03 00 7A 00 01 A5 D3 

01 03 02 08 FC BF C5 

Tabelle 3: Modbus Nachrichtenbeispiel 

Wie aus Bild 27 ersichtlich lässt sich mit dem Parameter 122 die 

Gerätenummer des Sensors abfragen. Als Antwort erhält man 2300 

(dezimal) bzw. 08FC (hexadezimal). 

Erläuterung der Nachrichten 

PC-Anfrage 

Sensorantwort 

01 Modbus Adresse des N2300 01 Modbus Adresse des N2300 

03 Modbus Funktionscode 03 Modbus Funktionscode 

00,7A Adresse des ersten Wortes 02 Anzahl der Bytes der Daten 

(high,low byte) = “122” 

(dezimal) 

00,01 Anzahl der Worte (high, low 08,FC Antwortdaten (“2300”) 

byte) 

A5,D3 CRC BF,C5 CRC 

Tabelle 4: Erläuterung Modbus Nachrichtenbeispiel 

Bild 27: Kommando-Codes des N2300 





IIAA 


de Andalucía 

5.2.4 Konfiguration des N2300 

Der Regler wird in den Softwareeinstellungen so konfiguriert, 

dass die Kommunikation über die RS485-Schnittstelle möglich ist bei 

einer Baudrate von 9600. Als Gerätenummer erhält der Regler die 

Nummer „1“. 

5.3 RS-485 zu RS-485 Übertragung 

5.3.1 Konfiguration der RS485-PCI-Karte 

Der Temperaturregler unterstützt ausschließlich halb duplexe 

Übertragungen. Die PCI-Karte muss also entsprechend konfiguriert 

werden. Auf der Karte werden zwei Jumper gesetzt, welche die Tx+ 

mit Rx+ und Tx- mit Rx- Signale, entsprechend Bild 28, miteinander 

verbinden. 

Die Karte wird über einer der beiden COM-Anschlüsse der Karte 

mittels eines D9 pin-to-pin Kabels mit dem Regler verbunden (Tab. 

5). Dieser Port wird in den Hardware-Settings entsprechend auf Half- 

Duplex konfiguriert. 

Bild 28: Full- vs. Half-Duplex Communication 

D9 

Pins 

N2300 

Pins 

5 6 - GND 

1 11 - B 

2 12 - A 

Tabelle 5: Pin 

Verbindungen 

RS485-RS485 

5.3.2 Einstellung der Software „Modbus Poll“ 

Die Software-Einstellungen zur Kommunikation müssen mit 

denen des Reglers übereinstimmen (Bild 

29). Anschließend kann mit dem „Test 

Center“ des Programms eine 

Verbindung hergestellt werden. Eine 

erfolgreiche Kommunikation zeigt Bild 

30. 

Bild 29: Connection Setup 

Bild 30: Beispiel der Kommunikation 





IIAA 


de Andalucía 

5.4 RS-232 zu RS-485 Übertragung 

5.4.1 Konfiguration des Patton RS-232-485 Konverters, Model 2085 

Um mittels des Standard COM Port1 (RS232) eines PCs mit 

dem Temperaturregler N2300 zu kommunizieren wird ein RS 232-485 

Umsetzer benötigt, in diesem Fall den Patton 2085. Innerhalb des 

Gehäuses wird der Converter mittels einer Reihe von Schaltern 

entsprechend der Tabelle (Bild 31) konfiguriert. Die Art der 

Verbindung ist Point-To-Point (PC – Regler) und halb duplex (2 

„wires“ statt 4). Der DCE/DTE-Schalter wird auf DCE gestellt (Bild 

33). 

Bild 31: Converter DIP-Switch Settings 

Bild 32: Anschlüsse N2300 

Bild 32 zeigt die Anschlüsse 

des Reglers für die DC Stromversorgung. 

Die RS485 Kommunikationsanschlüsse 

(A & B) des 

Reglers werden mit den 

Anschlüssen des Konverters wie 

folgt verbunden: 

Bild 33: Unter-/Oberseite des 

Konverters 

Converter N2300 

XMT+ B (Pin 11) 

XMT- A (Pin 12) 

G Ground (Pin 6) 

Tabelle 6: Pin Verbindungen RS232- 

RS485 





IIAA 


de Andalucía 

5.4.2 Einstellung der Software „Modbus Poll“ 

Die Softwareeinstellungen für die RS232-RS485 Verbindung 

sind nahezu identisch mit den Einstellungen für die direkte RS485 

Kommunikation (Bild 29). 

Unterschiede bestehen nur 

in der Auswahl der zu 

verwendenden 

Schnittstelle (COM Port1) 

und in den „Advanced 

Settings“, in denen ein 

„RTS Toggle“ mit „8ms 

RTS disable delay“ 

eingestellt wird. 

Die Antwort (Rx) des 

Bild 34: Kommunikationsbeispiel RS232- 

RS485 

Reglers unterscheidet sich bei einer Kommunikation insofern, als dass 

vor der Antwort zuerst die Anfrage (Tx) wiedergegeben wird (Bild 

34). 





IIAA 


de Andalucía 

6.1 Übersicht 

6.0 Steuerung der Kuppel des Teleskops 

Die Steuerung der Kuppel (Controlador de Cúpula) verfügt über 

zwei Kommunikationsschnittstellen. Über einen CAN-Bus wird eine 

Verbindung mit dem Computer „Ordenador de Control“ hergestellt. 

Dieser schickt Befehle und Anweisungen, woraufhin der „Controlador“ 

die angeforderten Informationen zurück sendet. Diese 

Kommunikation wird über die RS-232 Schnittstelle dupliziert, d.h. 

empfangende Anweisungen und gesendete Daten werden an den 

Computer „Ordenador Técnico“ weitergeleitet. Zudem gibt es noch 

erweiterte Kommandos die bei der seriellen Kommunikation 

verwendet werden, wie beispielsweise das Auslesen des EEPROMs. 

Bild 35: Steuerung der Kuppel 

Die angestrebte 

Endlösung sieht vor, 

dass der Computer 

(„Ordenador“) TCS 

direkt mittels einem 

CAN-Bus mit dem 

Controlador kommuniziert. 

Vorerst wird 

jedoch eine provisorische 

Lösung nach 

Bild 35 eingeführt, da 

die Umstellung nur in 

kleinen Schritten 

erfolgen kann, ohne den 

normalen Betrieb des 

Teleskops dabei zu 

stören. 

Die „technische Schnittstelle“ zum „Ordenador Técnico“ wird 

ausschließlich für technische Angelegenheiten verwendet, d.h. in 

bestimmten Fällen wie Tests oder Ausfälle etc. 

Der provisorische „Ordenador de Control“ kann ebenso 

eigenständig (d.h. unabhängig vom TCS) die Kuppel steuern, und 

verfügt hierfür über einen Touch-Screen. 

6.1.1 Aufgabenstellung 

Die bereits bestehende Programmierung der Steuerung der 

Kuppel wurde mit der Software LabView realisiert. Dieses Programm 

soll nun für den Ordenador de Control angepasst werden, so dass die 

Kommunikationsschnittstellen CAN und RS232 zur Verfügung stehen. 

Folgende Anforderungen müssen dabei beachtet werden: 





IIAA 


de Andalucía 

• Verwendung und Anpassung des bestehenden Programms: 

o Verwendung des CAN-Busses einführen (wurde vorher 

nicht verwendet). 

o Verwendung der RS-232 Schnittstelle. 

o Anpassung des GUI (neue Befehlsoptionen einführen, 

veraltete löschen). 

o Empfangene RS-232 Befehle in CAN-Nachricht 

übersetzen und weiterleiten. 

o Empfangene CAN-Nachrichten in RS-232 Nachrichten 

übersetzen und weiterleiten. 

o Empfang und Versandt von Nachrichten über GUI 

darstellen. 

o Versandt von Nachrichten über GUI ermöglichen. 

Anmerkung: erste Schritte zur Anpassung wurden bereits vor 

meiner Übernahme der Aufgabe durchgeführt, wie beispielsweise das 

Einlesen einer Befehlsliste (Text-Datei) sowie die Grafik für das 

manuelle Versenden einer CAN-Nachricht (Bild 36, Abschnitt „ENVÍO 

MANUAL“). Die CAN- sowie RS232-Kommunikationsschnittstellen an 

sich wurden jedoch noch nicht implementiert. 

Bild 36: Screenshot des bereits bestehenden LabView Programms 





IIAA 


de Andalucía 

6.3 Die Programmstruktur 

Folgendes Bild zeigt die vereinfachte Struktur des PROGRAMA 

TÉCNICO CÚPULA T150.vi. Auf der obersten Ebene befindet sich eine 

“stacked sequence structure” bestehend aus den Sequenzen: 

Initialisierung der Variablen, Initialisierung der Geräte, 

Hauptprogramm, und das Schließen der Verbindungen zu den 

Kommunikationsschnittstellen. 

PROGRAMA TÉCNICO CÚPULA T150.vi 

Inicialización de variables 

Definición de variables 

Valores iniciales 

Inicialización de dispositivos 

Inicialización RS232C 

Inicialización BUS CAN 

Lee fichero de los comandos 

activa los canales del CAN 

Programa principal 

se ha pulsado una tecla ? 

tecla 1 tecla 2 tecla 3 

comando 1 

tecla n 

comando 2 comando 3 tecla ... 

comando n 

comando ... 

envia comando por CAN 

recibe del CAN lo enviado por el módulo de control: Actúa y lo envía por RS232 al TCS 

comando 1 comando 2 

actúa 

comando 3 

caso 1: actúa 

comando n 

caso 2: actúa caso 3: actúa comando ... 

caso n: actúa 

caso ... 

envía comando por RS232 

Recibe RS232C 

traduce RS232 -> CAN 

RS232 comando 1 

RS232 comando 2 

RS232 comando ... 

CAN comando 1 

CAN comando 2 

RS232 comando n 

CAN comando... 

CAN comando n 

envía comando por CAN 

otras teclas y funciónes 

se ha pulsado el botón "borrar" ? 

J 

N 

borra el mensaje de error 

repite continuamente hasta ha pulsado "FIN DEL PROGRAMA" 

Cierra conexiónes de CAN 

Bild 37: Vereinfachte Struktur des PROGRAMA TÉCNICO CÚPULA T150.vi 





IIAA 


de Andalucía 

Die einzelnen Programmteile beinhalten weitere „Programm- 

Strukturen“ d.h. Sequence- oder Case-Structures, wie in Bild 37 

angedeutet. 

1. Inicialización de variables: keine nennenswerten Änderungen 

wurden vorgenommen. 

2. Inicialización de dispositivos: die Initialisierung der 

Kommunikationsschnittstellen wurde ohne Änderungen übernommen. 

Das Einlesen der Kommando-Textdatei („lee fichero 

de comandos“) enthielt jedoch einen Fehler welcher behoben 

werden musste. Die Textdatei selbst wurde ebenso modifiziert 

(siehe unten). 

3. Programa principal: dieser Teil des Programms besteht aus 

einer 4-teiligen Sequenzstruktur, welche in einer While-Schleife 

endlos wiederholt wird. Zum Ausstieg aus der Schleife (und 

zum Beenden des gesamten Programms) muss der Knopf „FIN 

DEL PROGRAMA“ des User-Interface gedrückt werden. 

Der Abschnitt 6.4 geht näher auf diese Sequenz ein, da 

die meisten Änderungen in diesem Programmteil vorgenommen 

wurden. 

4. Cierra conexiónes: Dieser Abschnitt wurde neu eingeführt und 

wird vor Beendigung des Programms ausgeführt. Er sorgt für 

ein sachgerechtes Schließen der offenen Verbindungen. 

6.3.1 VI-Hierarchie 

Die LabView-Programmierung ermöglicht es Unterprogramme 

(Sub-VI’s) in einem Hauptprogramm (VI) einzubinden. Diese 

erscheinen als Piktogramme. Sind Eingänge vorhanden, müssen diese 

ggf. mit entsprechenden Daten gefüttert werden. Sofern Ausgänge 

vorhanden sind können die gelieferten Daten im Hauptprogramm 

weiter verwendet werden. Sub-VI’s können ebenso weitere Sub-VI’s 

enthalten. Um einen Überblick über die gesamte VI-Struktur zu 

behalten, kann man sich mit LabView eine VI-Hierarchie anzeigen 

lassen. 

Die gelb und orange dargestellten Sub-VI’s in Bild 38 werden 

alle für die Kommunikationsschnittstelle des CAN-Busses verwendet. 

Das Hauptprogramm ist durch die rote Umrandung gut zu erkennen. 

Die weißen Symbole dienen, mit Ausnahme des linken, welches zum 

Einlesen einer Text-Datei verwendet wird, der Kommunikation 

mittels der RS232-Schnittstelle. 





IIAA 


de Andalucía 

Bild 38: VI-Hierachie des PROGRAMA TÉCNICO CÚPULA T150.vi 

6.3 Grundlagen 

6.3.1 CAN-Bus Basics 

Der CAN-Bus wurde ursprünglich von BOSCH für den Einsatz in 

Kraftfahrzeugen entwickelt. Aufgrund der hohen Zuverlässigkeit wird 

er heutzutage jedoch auch in vielen anderen Bereichen eingesetzt. 

Die Idee eines CAN-Busses ist es, nicht Geräte mit Nummern 

(bzw. Codes oder Identifiern) auszustatten, sondern stattdessen 

Nachrichten zu „nummerieren“. Dies ermöglicht, dass alle an den 

Bus angebundenen Geräte selbst entscheiden können ob eine 

Nachricht für sie relevant ist oder nicht (Bild 39). Umgekehrt ist es 

jedoch nicht möglich ein bestimmtes Gerät direkt anzusprechen. 

Stattdessen sind alle auf dem Bus vorhandenen Informationen für 

jedes angeschlossen Gerät uneingeschränkt zugänglich. 

Prioritäten der Nachrichten werden durch deren ID festgelegt: 

je niedriger die ID desto höher die Priorität. Dies funktioniert so, dass 

logisch 0 als dominant und logisch 1 als rezessiv eingestuft wird. 

Versuchen nun mehrere Sender zur selben Zeit eine Nachricht zu 

schicken, so wird die niedrigere ID gewinnen, da die entsprechenden 

Bits auf logisch 0 gezogen werden auch wenn andere Sender an der 

selben Stelle eine logische 1 senden möchten. 





IIAA 


de Andalucía 

Bild 39: CAN-Bus Broadcasting 

CAN-Nachrichten gibt es im Standard-Format mit einem 11-Bit 

Identifier oder im erweiterten Format mit 29-Bit. Im Rahmen dieses 

Projektes wird das Standard Format verwendet (Bild 40). Der ID folgt 

das RTR-Bit (Remote Transmission Request) welches, sofern gesetzt, 

die Nachricht als Anforderungsrahmen ohne Datenbytes kennzeichnet. 

Danach folgt ein Feld mit weiteren Informationen, z.B. ob 

das Standard- oder das erweiterte Format verwendet wird und wie 

viele Datenbytes die Nachricht enthält (bei RTR=1 ist die Datenlänge 

immer 0 Bytes). Das Datenfeld enthält bis zu 8 Bytes, gefolgt von 

einem „CRC-Field“. Das Ack-Bit (Acknowledgement) dient der 

Bestätigung des korrekten Empfangens durch den oder die 

Empfänger. 

Bild 40: CAN-Nachrichten im Standard Format 

6.3.2 Verwendung des CAN-Busses 

Die LabView Software läuft auf einem PC, welcher über ein 

CAN-Bus Kabel mit einem weiteren PC zum testen der 

Kommunikation verbunden wurde. Dieser zweite PC steuert einen 

kleinen Motor, von welchem Informationen verwendet werden 

(Position, Verbrauch etc.). Dieses System simuliert die Steuerung der 

Kuppel des Teleskops und liefert authentische Daten. 





IIAA 


de Andalucía 

Bei erfolgreicher Programmierung 

ist es somit möglich, 

diesen Motor direkt per CAN- 

Bus anzusprechen und zu 

steuern. Beispielsweise kann 

der Befehl „Stop“ den Motor 

anhalten, oder ein Befehl 

zum Anfahren einer Position 

den Motor wieder in 

Bewegung setzen. 

Bild 41: vorne links: angesteuerter Motor 

Für die Kommunikationsschnittstelle 

wird eine PCI-Karte benötigt. Hierfür 

wurde die CAN-PCI/331 von esd 

electronic system design GmbH verwendet. 

Sie verfügt über zwei CAN-Schnittstellen 

von welcher eine verwendet wird. 

Bild 42: CAN-PCI/331 

Zum Vorabtest einer korrekten Hardware-Verbindung wird das 

Programm CANscope der selben Firma zur Kommunikation mit dem 

zweiten PC verwendet (Bild 43). 

Bild 43: Screenshot des Programms CANscope 

Des Weiteren wurden, im Rahmen 

einer anderen Aufgabe, bereits vorher 

Kommunikationstest mit einer Testflachbaugruppe 

durchgeführt, um die 

CAN-Schnittstelle zu erproben. Bild 44 

zeigt die Karte mit den Anschlüssen zur 

Spannungsversorgung rechts, links das 

CAN-Kabel welches mit dem PC 

verbunden wird, und oben eine Reihe 

von Schaltern mit welchen man den IC 

konfigurieren kann. 

Bild 44: Testflachbaugruppe 





IIAA 


de Andalucía 

Hardware der Firma National Instruments kann mittels der 

„Measurements & Automation“ Software sehr einfach in ein VI 

eingebunden werden. Da die eingesetzte PCI-Karte jedoch von einem 

anderen Hersteller ist, erscheint die Hardware nicht in diesem 

Programm und muss anderweitig angesprochen werden. 

Hierfür werden DLL’s des Herstellers verwendet, welche 

vorgefertigte Funktionen zum Ansprechen des CAN-Busses enthalten. 

Die einzelnen Funktionen der DLL werden mit den LabView Symbolen 

„Call Library Function Node“ aufgerufen (Bild 45). Mit dem 

„Configure...“ Menüpunkt kann die CAN.DLL und eine der darin 

enthaltenen Funktion (z.B. canOpen) für ein Symbol ausgewählt 

werden. Das Ergebnis ist in Abb. 45 und 47 zu sehen. 

Bild 45: Einige CAN-Funktionen 

Bild 46: CAN-Initialisierung 

Bild 46 zeigt die 

CAN-Initialisierungsroutine 

des Programms PROGRAMA 

TÉCNICO CÚPULA T150.vi. 

Es werden Sub-VI’s 

verwendet, wie z.B. das 

canOpen Symbol. Öffnet 

man den Inhalt dieses VI´s 

wird man den Quellcode 

aus Abb. 47 vorfinden. 

Hiermit wird, wie 

Bild 47: canOpen.vi 

oben beschrieben, auf die 

in einer DLL enthaltenen Funktion zugegriffen, und somit die CAN 

PCI-Karte angesprochen. Diese Funktionen können als Black-Boxen 

betrachtet werden, welche über Ein- und Ausgänge verfügen. 





IIAA 


de Andalucía 

6.3.3 Übersicht der Kommandos 

Nachfolgende Liste führt alle gültigen Kommandos auf. Sie ist 

in der Datei COMANDOS.txt enthalten, welche vom LabView Programm 

eingelesen wird. 

COMANDOS DE LA CUPULA 

44 número comandos 

0000 STOP - stop TODOS 

0040 STOC - stop CUPULA - STOP MOVIMIENTOS 

0041 AZABxxx - MOV. ABSOLUTO 

0042 AZR+xxx - MOV. RELATIVO 

0042 AZR-xxx - MOV. RELATIVO 

0043 PARK - APARCAR 

0044 AZC+ - MOVIMIENTO CONTINUO - 

0044 AZC- - MOVIMIENTO CONTINUO - 

0050 WREE - GRABAR EEPROM - COMANDOS 

0051 SEGA - SEGUIMIENTO AUTOMÁTICO - 

0052 FSEG - FIN DE SEGUIMIENTO AUTOMÁTICO 

0053 AOFF - FIN ENVÍO AUTOMÁTICO TRAMAS - 

0054 A_AZ - ENVÍO AUTOMÁTICO ACIMUT - 

0055 A_CO - ENVÍO AUTOMÁTICO CONSUMO - 

0056 A_ZE - ENVÍO AUTOMÁTICO PASO CERO - 

0060 ¿AZ? - RTR - ACIMUT ACTUAL - PETICIONES 

0061 ¿CO? - RTR - PIDE CONSUMO 

0062 VER? - RTR - PIDE VERSIÓN PROG 

0063 PAR? - RTR - ACIMUT DE APARCADO RAM 

0064 PAE? - RTR - ACIMUT DE APARCADO EEPROM 

0065 ZER? - RTR - ACIMUT DE PASO POR CERO RAM 

0065 ZEE? - RTR - ACIMUT DE PASO POR CERO EEPROM 

0067 ZMR? - RTR - MARGEN DE PASO POR CERO RAM 

0068 ZME? - RTR - MARGEN DE PASO POR CERO EEPROM 

0069 INR? - RTR - CONSTANTE DE INERCIA RAM 

006A INE? - RTR - CONSTANTE DE INERCIA EEPROM 

0060 ¡AZ!xxx - ACIMUT ACTUAL 

0061 ¡CO! - ENVÍA CONSUMO: Exx.xx 

0062 VER! - ENVÍA VERSIÓN PROG 

0063 PAR!xxx - ENVIA POSICIÓN APARCADO RAM 

0064 PAE!xxx - ENVIA POSICIÓN APARCADO EEPROM 

0065 ZER!xxx - ENVIA POSICIÓN PASO CERO RAM 

0066 ZEE!xxx - ENVIA POSICIÓN PASO CERO EEPROM 

0067 ZMR!xxx - ENVÍA MARGEN PASO CERO RAM 

0068 ZME!xxx - ENVÍA MARGEN PASO CERO EEPROM 

0069 INR!xxx - ENVÍA CONSTANTE DE INERCIA RAM 

006A INE!xxx - ENVÍA CONSTANTE DE INERCIA EEPROM 

0070 CPARxxx - APARCADO - ENVIO CONSTANTES 

0071 CZERxxx - PASO POR CERO - 

0072 CZEMxxx - MARGEN PASO CERO - 

0073 CINExxx - INERCIA - 

0080 FIN!xxx - FIN DEL MOVIMIENTO EJECUTADO 

0081 ¡ZE!xxx - HA PASADO POR CERO 

0090 ERR!xxx - ERROR 

Tabelle 7: Comandos de la cúpula (COMANDOS.txt) 





IIAA 


de Andalucía 

Da ein Mitarbeiter gleichzeitig an anderer Stelle des Projekts 

tätig war (siehe z.B. Bild 41), war es notwendig im Laufe der 

Programmierarbeit die Befehlsliste ständig zu erweitern und zu überarbeiten. 

Die erste Spalte entspricht den CAN-Codes (hexadezimal), 

wobei die ersten 4 Zeichen der zweiten Spalte die entsprechenden 

Kommandos der seriellen Schnittstelle wiedergibt. Angehängte „xxx“ 

bedeuten dass dem Kommando ein Parameter folgt. Die dritte Spalte 

entspricht einem Kommentar. Von dem LabView Programm werden 

jedoch nur die ersten beiden Spalten (ohne „xxx“-Parameter) sowie 

die Anzahl der Kommandos (44) eingelesen. 

Auffällig ist, dass einige CAN-Kommandos (0060-006A) doppelt 

in der Liste auftauchen. Dies liegt daran, dass die entsprechenden 

seriellen Kommandos sich nur durch ein „!“ bzw. „?“ unterscheiden. 

Ein Ausrufezeichen bedeutet, dass Parameter übermittelt werden, 

wobei ein Fragezeichen eine Anfrage darstellt. Zur Unterscheidung 

wird bei den CAN-Kommandos bei Anfragen das RTR Bit bei der 

Übertragung gesetzt. Sobald dieses Bit gesetzt ist können per 

Definition keine Parameter übertragen werden (siehe oben). 

Bild 48: Routine zum Einlesen der COMANDOS.txt 

Bild 48 zeigt die vollständige Routine zum Einlesen der 

Textdatei. Die Liste der CAN-ID’s wird in der Array-Variablen „CAN 

Comandos“ gespeichert, die entsprechenden seriellen Befehle in 

„RS232 Comandos“. Da die beiden Arrays unterschiedliche 

Datenformate besitzen, ist es nicht möglich die Informationen als 2D- 





IIAA 


de Andalucía 

Array zu speichern. Die spätere Zuordnung von RS232 zu CAN- 

Komando ist nur durch die Reihenfolge der Elemente innerhalb der 

Arrays möglich, d.h. der Inhalt des Elements mit dem Index 0 des 

einen Arrays (STOP), entspricht dem Inhalt des Anderen (0000). Die 

eindeutige Zuordnung wird in den Programmteilen wichtig, in denen 

Nachrichten von einem Format ins Andere übersetzt werden sollen. 

6.4 Programa Principal 

Das Hauptprogramm besteht aus vier sequenziellen 

Abschnitten (in einem sogenannten „Booklet“), welche in einer 

Endlos-While-Schleife wiederholt werden, bis das Programm durch 

drücken der „FIN DEL PROGRAMA“-Taste auf der Benutzeroberfläche 

beendet wird. In den folgenden Beschreibungen wird nur auf 

Programmteile eingegangen, welche durch mich neu erstellt oder an 

denen Änderungen von mir vorgenommen wurden. 

6.4.1 Abschnitt 1: Abfrage des User-Interfaces 

Taste gedrückt? korrektes CAN-Kommando? Versand CAN-Nachricht 

Bild 49: Programa Principal: Abschnitt 1 

Es wird überprüft, ob eine Taste auf dem GUI vom Benutzer 

gedrückt wurde. Ist dies nicht der Fall, geht das Programm direkt 

zum nächsten Abschnitt weiter. Andernfalls wird zunächst der der 

Taste zugewiesene Hex-Code mit der CAN-Comandos Tabelle 

verglichen um die Gültigkeit des Befehls zu überprüfen. Ebenso ist es 

möglich manuell eine Nachricht über der GUI zu erstellen; dieser 





IIAA 


de Andalucía 

Code wird selbstverständlich 

ebenso überprüft. 

Weiter wird eine Case- 

Struktur aufgerufen um zu 

überprüfen welche Taste 

gedrückt und welche Funktionen 

ausgeführt werden 

sollen (Bild 51). Danach 

wird der Befehl als CAN- 

Nachricht über die Schnittstelle 

versandt. 

Das Drücken einer 

der ENVIAR Tasten oder die 

STOP CÚPULA Taste auf der 

Benutzeroberfläche ruft die 

in Bild 49 dargestellten 

Strukturen auf. Möchte der 

Bild 50: Benutzeroberfläche 

Benutzer beispielsweise 

Informationen der Kuppel erhalten, kann er diese über die CAN- 

Schnittstelle anfordern (PETICIÓN DE INFORMACIÓN) indem er den 

gewünschten Wert aus einer Drop-Down-Liste auswählt und den 

Befehl dann sendet (ENVIAR, Bild 50). 

Bild 51: Case-Struktur der Kommandos 

Die Case-Struktur (Bild 51) enthält eine für jedes CAN- 

Kommando individuelle Funktion die es entsprechend auszuführen 

gilt. Die Case-Nummern entsprechen den CAN-Befehlen. Fall 41 (in 

hex) beispielsweise entspricht dem Senden des Befehls 0041 (siehe 

auch Tabelle 7) an den Motor der Kuppel zum Anfahren einer 

bestimmten absoluten Azimut (Winkel-)Position. Die Position wird als 

Parameter in der Nachricht versandt und einer Variablen der 

Benutzeroberfläche entnommen (Bild 50: ABSOLUTO: 0 → ENVIAR). 





IIAA 


de Andalucía 

Das Versenden des Befehls wird zur Bestätigung in einem 

Informationsfeld auf der Oberfläche angezeigt und durch das Sub-VI 

can Put Msg gesendet. 

6.4.2 Abschnitt 2: CAN-Nachrichten als RS232 weiterleiten 

Folgende Darstellung zeigt einen Ausschnitt des Quellcodes zum 

Umwandeln einer erhaltenen CAN-Nachricht in eine Serielle. Sofern 

keine CAN-Nachricht empfangen wurde, wird dieser Schritt übergangen 

und der nächste Abschnitt behandelt. 

Bild 52: Programa Principal: Ausschnitt von Abschnitt 2 

Wurde eine Nachricht erhalten, wird diese nach dem Einlesen 

(can Read Msg) auf ihre Gültigkeit überprüft und hierfür mit der 

Kommando-Liste verglichen. Bei erfolgreichem Vergleich, wird 

zunächst „gehandelt“ (-> actúa), d.h. die Informationen auf der 

Benutzeroberfläche dargestellt. Als zweiter Schritt einer Stacked- 

Sequence-Structure wird der Befehl in ein serielles Kommando 

umgesetzt und über die RS232-Schnittstelle gesendet (in Bild 52 

nicht zu sehen). 

Das Sub-VI canReadMsg.vi (Ausschnitt Bild 53) musste 

insofern modifiziert werden, als dass in der vorher bestehenden 

Version nur das erste Byte der eigentlich 11-Bit langen CAN-ID (d.h. 

Befehlsnummer) verwendet wurde. Dies limitiert die Anzahl der 

möglichen Befehle unnötig, und behindert u.U. eine spätere 

Weiterentwicklung des Systems. Die oben dargestellte Routine 

jedoch, liest die ersten 11-Bit der CAN-Nachricht aus und setzt sie in 

eine CAN-ID um. Des Weiteren wurde bisher das RTR-Bit nicht 

verwendet. Da dieses Bit jedoch für die Anforderung von 

Informationen notwendig ist, wurde ein Auslesen des Bits in dieser 

Version realisiert. 





IIAA 


de Andalucía 

Bild 53: canReadMsg.vi 

6.4.3 Abschnitt 3: RS232-Nachrichten als CAN weiterleiten 

Das Prinzip in diesem 

Abschnitt ist das gleiche wie im 

Vorherigen, nur umgekehrt. Hier 

werden RS-232 Nachrichten 

eingelesen, auf der Benutzeroberfläche 

dargestellt und anschließend 

über die CAN- 

Schnittstelle weitergeleitet. 

Wurden keine Nachrichten 

erhalten, wird der Abschnitt übersprungen. 

Vorher wurden die doppelt 

auftauchenden CAN-Kommandos 

bei der Umsetzung dadurch unterschieden, 

dass der Status des 

Bild 54: Programa Principal: 

Abschnitt 3 

RTR-Bit berücksichtigt wurde. Im Umgekehrten Fall nun, wird über 

die RS232-Comandos der entsprechende CAN-Befehl ermittelt. Die 

Befehle ¿AZ? Und ¡AZ! jedoch werden beide zu 0060 übersetzt. Zur 

Unterscheidung untersucht eine Routine, ob das letzte Zeichen ein „?“ 

(RTR=1, keine Daten) oder ein „!“ (RTR=0, Parameter vorhanden) 

ist, und passt die CAN-Nachricht entsprechend an. 





IIAA 


de Andalucía 

6.4.4 Abschnitt 4: Weitere Tasten und Funktionen 

Dieser Abschnitt dient rein der 

Kosmetik der Benutzeroberfläche 

und erlaubt es beim Drücken einer 

LÖSCHEN-Taste, angezeigte Fehler 

wieder zurückzusetzen. Er wurde 

von mir jedoch weder erstellt noch 

bearbeitet. 

6.5 Ergebnisse 

Bild 55: Abschnitt 4 

Nachdem alle aufgetretenen Programmierfehler behoben waren, 

wurde am Ende der Ausarbeitung erfolgreich über den CAN-Bus als 

ORDENADOR DE CONTROL mit dem simulierten CONTROLADOR DE 

CÚPULA kommuniziert (siehe Bild 35). Gesendete Befehle wurden 

sofort umgesetzt und der Empfang der Daten verlief ebenso 

einwandfrei. 

Beispiel: wurde die Einstellung SEGUIMIENTO AUTOMATICO 

gesendet (aus der Drop-Down-Liste ENVÍO DE COMANDOS, CAN-ID: 

0051) und der Motor danach in Bewegung gesetzt (z.B. durch 

kontinuierliche Bewegung in positive Richtung, CAN-ID: 0044), 

sendete der Controlador automatisch und kontinuierlich die aktuellen 

Positionsdaten zurück. In dem Feld POSICIÓN ACTUAL xxx grad der 

Benutzeroberfläche konnte somit live beobachtet werden, auf welcher 

Position sich der Motor gerade befindet. 

Zum Test der RS-232C Verbindung wurde an den PC 

(ORDENADOR DE CONTROL) über die serielle Schnittstelle ein Laptop 

angeschlossen (als ORDENADOR TCS). Auf diesem lief eine ältere 

Version der selben Software, welche bereits über eine 

Implementierung der seriellen Schnittstelle verfügt und mit den 

verwendeten Kommandos (siehe Tab. 7) kompatibel ist. Das 

Programm PROGRAMA TÉCNICO CÚPULA T150.vi leitete erfolgreich 

alle empfangene Daten weiter. Folglich konnte der TCS (bzw. Laptop) 

den Motor der Kuppel steuern, z.B. stoppen. Ebenso war es möglich 

die Daten des Motors zu empfangen, d.h. z.B. die Positionsdaten mit 

dem TCS zu erfassen. 





IIAA 


de Andalucía 


7.0 Absolutwert-Encoder RCN 829 

Zur Steuerung der Alpha-Achse des Teleskops sollen insgesamt 

zwei Encoder verwendet werden: ein Relativer in direkter 

Verbindung mit den Motoren (siehe Kapitel 4) und ein Absolutwert 

Encoder zum präzisen Auslesen der Winkelposition der Achse. Die 

beiden Encoder und weitere Komponenten sollen, wie in Abbildung 56 

dargestellt, an der Alpha-Achse angebracht werden (vgl. hierzu Bild 

13). 

Encoder Relativo Motor 

sobre Reductora (1:360) 

Encoder Absoluto (10bits) 

sobre Reductora (1:1) 

(no usado) 

Motor 

Freno 

Inductosin (no usado) 

Bild 56: Configuración para el estudio de posicionado ALFA 

Auffällig ist in der Darstellung, dass zwei Komponenten 

(markiert durch blaue Schrift), ein Absolutwert-Encoder und der 

Inductosyn, zwar an der Achse angebracht sind jedoch nicht 

verwendet werden („no usado“). Dies sind Überreste der alten (bzw. 

aktuellen) Konfiguration und sollen nun durch den Encoder RCN829 

des Herstellers Heidenhain ersetzt werden. Neu sind ebenso das 

FPGA und der cRIO, welche einen A/D-Buffer ersetzen. Mit Hilfe 

dieser Elektronik werden die Signale des RCN829 bearbeitet. 

Das bereits bestehende System bleibt deshalb vorerst parallel 

in Betrieb, um den laufenden Betrieb des Teleskops nicht zu stören. 





IIAA 


de Andalucía 

CompactRIO 

In Analógica 

24 Bits 

In Digital 

HighSpeed 

BusCAN 

Real Time 

Ethernet Programación 

Bus CAN Técnico 

Vcc CompactRIO 

PCB-FPGA 

Display LED 

Pos.ABS 

FPGA 

Transceiver 

EndDat2.0 

Buffer/Opto 

Buffer/Opto 

Manguera Asterix 

Inductosin 

Manguera Asterix 

Absoluto e Incremental 

Vcc 

Relativo 

Absoluto 

RCN 829 

ROD 230 

Bild 57: Verbindung zwischen dem RCN829, dem FPGA und cRIO 

Bild 57 zeigt eine schematische Übersicht der Verbindungen 

zwischen dem Absolutwert Encoders, dem FPGA, dem CompactRIO 

und den weiteren Anschlüssen. 

7.1.1 Vorgehensweise der Entwicklung 

1. Entwicklung der Systeme zum Auslesen der Encoder (→ dieses 

Kapitel; bzgl. des relativen Encoders siehe Kap. 4). 

2. Anbringung und Test am mechanischen Achsenmodel (s. Bild 

13). Hierbei auftauchende Schwierigkeiten sollen vor der 

eigentlichen Inbetriebnahme des Systems behoben werden. 

3. Implementierung des neuen Systems am Teleskop. 

7.2 Grundlagen und Hardware 

7.2.1 Übersicht des Aufbaus 

Der Encoder RCN829 wird mit einem Digilab D2-SB System 

Board verbunden, welches über das Xilinx XC2S200E FPGA verfügt. 

Die Kommunikation erfolgt über ein EnDat Interface. Das Board wird 

über eine parallele Schnittstelle mit einem PC verbunden (hierfür 





IIAA 


de Andalucía 

wird ein NI DAQ-Pad 6016 verwendet) auf welchem ein 

Anwenderprogramm läuft („Application“ in Bild 58, Programmierung 

mit LabVIEW, sie Kap. 7.4). 

Bild 58: Systemkonfiguration des Encoders & Folgeelektronik 

7.2.2 Der Encoder 

Der Encoder sendet die 

Winkelpositionen gemäss EnDat 2.2 

und verfügt über 29 Bit (d.h. 

536870912 Positionen pro 

Umdrehung). Diese Informationen 

werden daraufhin von dem FPGA für 

den PC über die parallele Schnittstelle 

zur Verfügung gestellt. 

Bild 59: RCN829 

7.2.3 Das FPGA 

Bild 60: Block Diagramm des Softmakro 





IIAA 


de Andalucía 

Auf den FPGA wird das EnDat2.2 Softmakro der Firma MAZeT 

GmbH geladen. Der Masterbaustein dieser Firma wurde vom Encoder- 

Hersteller Heidenhain geprüft und für den Vertrieb freigegeben. 

7.2.4 Kommunikation über die parallele Schnittstelle 

Relevant für die Kommunikation mit 

dem DAQ-Pad sind die Adresse (6 Bit), 

der Datenbus (1 oder 2 Byte, je nach 

Einstellung) und die Linien Chip-Select 

(/CS), Write (/WR), Read (/RD) sowie 

/Ready, siehe Abbildung 62. Diese Linien 

werden während der Entwicklung mit 

einem Logic Analyzer der Firma Hewlett 

Bild 61: HP Logic Analyzer 

aus den 1980’ern 

Packard überprüft. Die Einstellung zum Datenbusmodus (Mode16) 

kann über einen Schalter auf dem Board, also per Hardware, gesetzt 

werden. 

Bild 62: Read & Write Cycle 

Abgesehen vom Datenbus, welcher bidirektional ist, haben die 

Signale eine vorgesehene Richtung, gemäss der nachfolgenden 

Tabelle. 

DAQ 

FPGA 

Data (8/16 Bit): Ports 0 & 1 D(0:15) 

Address (6 Bit): Pins 2.(0:5) 

A(0:5) 

/CS: Pin 3.0 /CS 

/RD: Pin 3.1 /RD 

/READY: Pin 3.4 /READY 

/WR: Pin 3.3 /WR 

Tabelle 8: Parallele Kommunikation 

7.3 Das Spannungspegel-Problem 

Die vier digitalen Ports (0 bis 3) des DAQ (s. Bild 63) können 

als Ein- oder Ausgänge konfiguriert werden, wobei auch einzelne Pins 

eines Portes individuell konfigurierbar sind. Ein Problem hierbei ist 

jedoch, dass das DAQ-Pad mit TTL (5V) Spannungsniveaus arbeitet, 

während das Digilab Board LVTTL-Pegel (3,3V) verwendet. An für 

sich sind die beiden Standards zwar kompatibel, da jedoch eine 

theoretische Gefahr besteht die Eingänge des Boards zu zerstören, 





IIAA 


de Andalucía 

sollten die Verbindungen des parallelen Busses aufeinander eingestellt 

werden. 

Bild 63: DAQ-6016 Pin-Anschlüsse 

Bei unidirektionalen Verbindungen ist dies relativ einfach: bei 

Eingängen des DAQ-Pad können die Pins direkt miteinander 

verbunden werden, da eine logische LVTTL-Eins auch als logische Eins 

im TTL-Format interpretiert wird. In umgekehrter Richtung kann ein 

Widerstand oder ein IC zur Konvertierung zwischengeschaltet 

werden. Problematisch jedoch wird es bei dem Datenbus, da dieser 

bidirektional verläuft. 

7.3.1 Lösung: Buffer Triestado Externo 

Zur Problembehebung wurde entschieden, dass der 16 Bit 

Datenbus aufgeteilt werden soll in zweimal 8 Bit unidirektional. Auf 

der Seite des DAQ ist dies einfach: Port 0 wird als Ein- und Port 1 als 

Ausgang definiert. Das Digilab Board wird mit MODE16=0 auf einen 

8-Bit bidirektionalen Datenbus eingestellt. (Eine Aufteilung mit 8 

festen Ein- und 8 festen Ausgängen ist deshalb nicht möglich, da die 

interne Programmierung des FPGA als Blackbox zu betrachten ist und 

vom Anwender nicht geändert werden kann.) Die Umleitung dieses 

Busses auf Port 0 bzw. 1 des DAQ wird mit der Zwischenschaltung in 

Abb. 64 realisiert. 

Anmerkung: Der dargestellte Schaltplan enthält Fehler, welche 

jedoch auf dem Steckbrett korrigiert wurden. Der Plan wurde aus 

zeitlichen Gründen nicht aktualisiert, da diese Arbeit in den letzten 

Tagen meines Aufenthalts erfolgte. 

IC 

Beschreibung 

74HCT240 Octal buffer/line driver; 3-state; inverting 

74HCT10 Triple 3-input NAND gate 

74HCT04 Hex Inverter 

Tabelle 9: Übersicht verwendeter ICs 





IIAA 


de Andalucía 

Bild 64: „Esquema: Conexión buffer triestado externo“ 





IIAA 


de Andalucía 

Beschreibung: Die 8-Datenpins auf Seiten des FPGA werden direkt 

mit Port 0 des DAQ (Eingangsbus) verbunden. Die selben 8 Pins 

werden über einen 74HC240 Buffer (Inverter) auf Port 1 (DAQ 

Datenausgang) umgeleitet. Da die Stromversorgung des ICs durch 

das Digilab Board erfolgt, werden somit die Signale des DAQ auf den 

LVTTL-Pegel herabgesetzt (und zusätzlich invertiert). Der IC verfügt 

über zwei (gleichgeschaltete) Enable-Eingänge, welche so beschaltet 

sind, dass nur im Falle eines Schreibvorgangs die Signale 

durchgestellt werden. Der Default-Zustand setzt also einen 

Lesevorgang zur Sicherheit der FPGA-Pins voraus. 

Nach dem dargestellten Schaltplan werden die Enable-Pins 

direkt mit dem /WR verbunden. Dies war nur eine vorübergehende 

Lösung und wurde durch eine „sauberere“, wie folgt, ersetzt (siehe 

„Atención“ in Bild 64): 

Enable =0 

when ChipSelect=0 and Read=1 and Write=0, 

else Enable =1 

Für diese Schaltung werden die ICs 74HC10 (NAND) und 74HC04 

(Inverter) verwendet. (Anmerkung: Die Enable-Eingänge des 

74HC240 sind low-active, daher wird ein NAND statt AND verwendet.) 

Bild 65: Foto des Hardwareaufbaus 

Bild 65 dokumentiert den Hardwareaufbau. Auf der linken Seite 

ist das DAQPad zu sehen, welches mit einem Stromkabel versorgt 

wird und über einen USB-Anschluss mit einem PC (auf welchem die 

Software läuft, siehe Kap. 7.4) verbunden ist. In der Mitte ist das 

Steckbrett mit der Schaltung zu sehen, an welchem zwei Datenbusse 

des Logic Analyzers angeschlossen sind. Rechts das Digilab Board 

mit FPGA und Kabel zur Stromversorgung. 





IIAA 


de Andalucía 

7.4 Die Software 

Der Hardwareaufbau verlief parallel zur Softwareentwicklung, 

daher wurden einige Details im Nachhinein abgeändert. 

Beispielsweise wurde zunächst von einem 16 Bit Datenbus 

ausgegangen, der jedoch später auf zwei 8 Bit Busse aufgeteilt 

wurde. In den nachfolgenden Abschnitten wird der letzte Stand der 

Software beschrieben. Die Software wurde von Grund auf neu 

entwickelt; es gab keine bereits bestehenden Programmteile. 

Die Software ist nur als Zwischenschritt gedacht, um das Lesen 

des Encoders zu vereinfachen. Später, sobald die Kommunikation mit 

dem EnDat2.2 Standard bekannt ist und die Konfiguration des 

Encoders getestet wurde, wird für das Auslesen ein cRIO an Stelle 

des DAQ eingesetzt, wie in Abb. 57 dargestellt. Das Programm wird 

allerdings weiterhin, im Rahmen von Wartungsarbeiten, eingesetzt 

werden. 

7.4.1 Kommunikationsbausteine 

Um die Ports oder Pins des DAQ zugänglich zu machen und um 

sie zu konfigurieren werden sogenannte Tasks mit der Measurement 

& Automation Software von NI erstellt. Insgesamt werden 5 Tasks 

nach folgender Tabelle konfiguriert. Controls enthält die Linien /CS, 

/RD und /WR, alle Anderen sind selbsterklärend. 

DAQ- 

Konfigu- 

Port/Pin 

Task 

ration 

Data in P0 - 

Data out P1 - 

Addr P2.[0:5] - 

Controls P3.[0;1;3] invertiert 

Ready P3.4 invertiert 

Tabelle 10: Tasks 

Es wurden zwei VI’s 

erstellt, welche sich im Grunde im 

Aufbau gleichen. Eines liest Daten 

über die parallele Schnittstelle 

ein (liefert als Ausgang also die 

Daten), das Andere sendet sie 

(hat einen Dateneingang, s. Tab. 

11). Diese Bausteine sollen später 

in einem Hauptprogramm als 

SubVI’s verwendet werden. 

Eingänge 

Task: Data in/out 

Task: Address 

Task: Controls 

Task: Ready 

Data: Dirección 

(Data: Data write) 

Ausgänge 

Data: Error read/write 

Data: Error out 

(Data: Data read) 

Tabelle 11: Ein- & Ausgänge der SubVI's 

Bild 66: Front Panel des SubVI 

Parallel_Read_8bit.vi 

Die Programmierung ist unten zu sehen. Beim Aufrufen eines VI 

werden zuerst die Tasks gestartet, d.h. die Hardware konfiguriert 

und reserviert. Danach wird in einer Sequence-Structure 

nacheinander auf die einzelnen Ports bzw. Pins zugegriffen. Die 

Reihenfolge entspricht dem Diagramm aus Bild 62. Die dort 





IIAA 


de Andalucía 

eingezeichneten Minimalzeitspannen (im Nanosekundenbereich) 

werden auf keinen Fall unterschritten, da das Programm auf dem PC 

verhältnismäßig langsam abläuft. Danach werden die Tasks beendet 

(die Hardware wird freigegeben) und die eventuell aufgetretenen 

Fehler werden zu einer Fehlermeldung gebündelt, welche als Error 

Out ausgegeben wird. 

Bild 67: Block Diagramm des SubVI Parallel_Read_8bit.vi 

Sequenz Read VI Write VI 

0. 

Address-Bus = Registeradresse (dirección) 

Databus = Data Write 

1. 

/CS setzen 

/RD = setzen 

/WR = setzen 

2. 

/ready = gesetzt? Wenn nein Fehler-LED setzen 

Data Read = Databus 

3. /CS = /RD = /WR = löschen 

Tabelle 12: Reihenfolge der Kommunikationssequenzen 

7.4.2 EnDat2.2: zu lesende/schreibende Register 

Für die Software stehen die Register nach Abb. 68 zum 

Lesen/Schreiben zur Verfügung (W/R=Write & read, RO=Read-only, 

WO=Write-only). Innerhalb der Register befinden sich verschiedene 

Daten und Konfigurationsvariablen. Das „Identification 

Register“ beispielsweise enthält Versions- und Protokollnummern 

und steht gemäss der Tabelle oben nur zum Lesen bereit. Beim 

Auslesen liefert es stets 0E22 E50F. Nachfolgend wird als Beispiel der 

Inhalt des Cofiguration Register 1 in Abb. 69 dargestellt. 





IIAA 


de Andalucía 

Bild 68: Register-Zugriff 

7.4.3 Hauptprogramm 

Bild 69: Configuration Register 1 

Die Benutzeroberfläche stellt in einer Registerkartei nur die 

wichtigsten Register zur Verfügung. Des Weiteren gibt es ein Register 

zum Einstellen der Hardware (DAQ) und eines welches ein manuelles 

Lesen oder Schreiben eines Bytes auf einer bestimmten Adresse 

ermöglicht. 

Je nach Zugriffsrechte (Bild 68) können Register gelesen oder 

beschrieben werden. Die Konfigurationsregister erlauben beides. Die 

Inhalte der Register werden gemäss der Dokumentation (Bild 69) in 

ihre Inhalte aufgeteilt (Bild 70). 





IIAA 


de Andalucía 

Bild 70: Auszüge des Front Panel des Programms 

Das Einlesen der Konfigurationsregister 1 und 2 erfolgt in vier 

Schritten: 

1. Überprüfen welche Taste gedrückt wurde. Wurde Retrieve 

Settings der Konfigurationsregister gewählt wird in der Case- 

Structure „Fall 5“ ausgeführt. 

2. Es wird das Byte der Hex-Adresse 14 mit dem 

Parallel_Read_8bit.vi eingelesen sowie die nachfolgenden 7 

Bytes. Diese 8 Bytes werden in einem Byte-Array 

zwischengespeichert. 

3. Das Array wird wieder in einzelne Bytes aufgeteilt und diese so 

zusammengefügt dass die Konfigurationsregister 1 und 2 dabei 

entstehen. 

4. Die Register werden in ihre einzelnen Inhalte zerlegt (Bild 69), 

in Variablen gespeichert und auf der Benutzeroberfläche 

angezeigt. 

Das speichern der Register erfolgt bei den Punkten 2-4 in 

umgekehrter Reihenfolge (Zusammensetzen der Inhalte zu Bytes, 

Bytes zusammenfügen zu Register, Byte-Array per 

Parallel_Write_8bit.vi senden). 





IIAA 


de Andalucía 

1. 

4. 

2. 

3. 

Bild 71: Block Diagramm des Programms 

7.5 Ergebnisse 

Die Programmierung der Kommunikationsbausteine erwies sich 

als erfolgreich. Zwischenzeitlich traten zwar Kommunikationsfehler 

auf, diese waren jedoch auf ein fehlerhaftes Verhalten (aufgrund 

fehlerhafter Programmierung) des FPGAs zurückzuführen und nicht 

auf die erstellte Anwendersoftware, welche mit dem PC ausgeführt 

wurde. 

Bild 72: Foto des Logic Analyzers. Fehlerhaftes Verhalten: Daten stehen 

nur kurzzeitig zur Verfügung 





IIAA 


de Andalucía 

Beispiel: Der am häufigsten aufgetretene Fehler beim Lesevorgang 

entstand dadurch, dass die Daten auf dem Bus von dem FPGA nur 

kurzzeitig, nicht bis zum Ende des Vorgangs, zur Verfügung gestellt 

wurden. Zum Zeitpunkt der Datenerfassung durch das DAQPad 

jedoch waren die Daten manchmal entweder noch nicht, oder nicht 

mehr auf dem Bus vorhanden. Bei einigen Lesevorgängen wurden die 

Daten trotz des Fehlers korrekt erfasst. In dem Beispiel aus Bild 72 

werden die Daten (Zeile D_READ) frühzeitig zurück gesetzt. Bei 

korrekter Übertragung erfolgt deren Rücksetzung erst nach 

Rücksetzung der CS, RD und READY Signale (vgl. Bild 62). 

Die Teilweise etwas unübersichtlichen Konvertierungsvorgänge 

im Hauptprogramm (z.B. um eingelesene Bytes in einzelne 

Informationsvariablen aufzuteilen) enthielten anfangs ein paar wenige 

Programmierfehler, welche jedoch nach einer Korrektur vollständig 

behoben wurden. Danach wurden sowohl Lese- als auch 

Schreibvorgänge getestet, mit erfolgreichen Ergebnissen. 

Aufgetretene Fehler waren, wie bereits beschrieben, auf das 

Verhalten des FPGAs zurück zu führen. 

Es lässt sich also zusammenfassen, dass – korrektes Verhalten 

des FPGAs vorausgesetzt – die Anwendersoftware erfolgreich 

eingesetzt werden kann um auf die Register des FPGAs bzw. die 

Daten des RCN-829 Encoders zuzugreifen. 

7.6 Weiteres Vorgehen 

Als Nächstes soll nun die Übertragung der Daten des Encoders 

an den FPGA über die EnDat-Schnittstelle umgesetzt werden. Ist 

diese erfolgreich in Betrieb genommen, so wird mit der oben 

beschriebenen Software die Konfiguration des Encoders eingestellt. 

Die optimalen Einstellungen, der Konfigurationsvorgang, sowie der 

Auslesevorgang der Positionsdaten des Encoders sollen auf diese Art 

und Weise ermittelt und kennen gelernt werden. Daraufhin wird eine 

entsprechende Prototyp-Flachbaugruppe entworfen, welche das 

Digilab Board ersetzt. Größe und Anzahl der Anschlüsse dieses 

Prototyps sollen minimiert werden, um auch die Anzahl möglicher 

Fehlerquellen gering zu halten. 

Sind all diese Schritte abgeschlossen kann der nächste 

Entwicklungsschritt erfolgen: die Anbringung am Achsenmodel 

(siehe Abschnitt „7.1.1 Vorgehensweise der Entwicklung“). 





IIAA 


de Andalucía 

8.0 Fazit 

Im Rahmen meiner Tätigkeiten während des Praxissemesters 

wurde es mir ermöglicht meine, durch mein Studium erworbenen, 

Kenntnisse anzuwenden und zu erweitern. Im Wesentlichen kam 

mein Informatik- und Elektronikwissen zum Einsatz. Ich habe mich 

mit verschiedenen digitalen Kommunikationsmöglichkeiten befasst 

und deren jeweilige Vor- und Nachteile kennen gelernt. Ebenso 

beschäftigte ich mich mit dem Auslesen und dem Kommunizieren mit 

Sensoren. In diesem Zusammenhang waren meine Kenntnisse der 

technischen Optik sehr hilfreich, da optische Winkelmessgeräte zum 

Einsatz kamen. Ebenso ergaben sich viele Gelegenheiten die grafische 

Programmiersprache des Programms LabView von National 

Instruments kennen zu lernen. 

In einem mehr allgemeinerem Rahmen war es mir möglich 

etwas über den Aufbau und die Funktionsweise von Teleskopen zu 

lernen, sowie über die praktischen Schwierigkeiten die bei der 

Anwendung auftreten können. 

Die sprachlichen und kulturellen Erkenntnisse, die mit meinem 

Aufenthalt von 5 Monaten in Spanien verbunden waren, sind 

selbstverständlich nicht zu vergessen. Alles in Allem eine sehr 

wertvolle Erfahrung. 





IIAA 


de Andalucía 

9.0 Anhang 

9.1 Abkürzungsverzeichnis & Glossar 

ASIC Application Specific Integrated Circuit 

CAN Controller Area Network 

CISC Consejo Superior de Investigaciones Científicas 

CMOS Complementary Metal Oxide Semiconductor 

COTS Commercial Off The Shelf 

CRC Cyclic Redundancy Check 

cRIO Compact Reconfigurable Embedded System von NI 

DAQ-STC Data Aquisition - System Timing Controller (DAQ: PC-TIO-10 

User Manual) 

DLL Dynamic Linking Library 

EnDat2.2 Kommunikationsstandard der Firma Heidenhain 

FPGA Field Programmable Gate Array (programmierbarer IC) 

GUI Graphical User Interface 

HCTL ein CMOS IC der Firma Avago Technologies 

IAA Instituto Astrofísica de Andalucía 

IC 

Integrated Circuit (integrierter Schaltkreis) 

ID 

Nachrichten-Identifier (bzw. CAN-Code) 

Inductosyn® Transducer von Farrand Controls, Ruhle Companies Inc. 

IR 

Infrarot 

LVTTL Low-Voltage-TTL 

MPIA Max-Plack-Institut für Astronomie 

NI 

National Instruments 

NI-TIO „a National Instruments timing and triggering controller 

ASIC. The TIO includes four general purpose 

counter/timers … The TIO also provides advanced digital 

I/O capabilities for time-stamping multiple I/O lines and 

controlling digital output lines.” (DAQ: PC-TIO-10 User Manual) 

OSN Observatorio Sierra Nevada 

PID Proportional-Integral-Differential (Regelungstechnik) 

RTR Remote Transmission Request 

T150 Teleskop 150cm 

T90 Teleskop 90cm 

TTL Transistor-Transitor-Logik 

UDIT Unidad de Desarrollo Instrumental y Tecnológico 

VI 

Virtual Instrument, Programmdatei von LabVIEW 

9.2 Abbildungsverzeichnis 

Bild 1: Granada in Spanien ..........................................................1 

Bild 2: CSIC Logo .......................................................................1 

Bild 3: Organigramm des IAA .......................................................2 





IIAA 


de Andalucía 

Bild 4: Observatorio Sierra Nevada (OSN)......................................3 

Bild 5: Logo OSN ........................................................................3 

Bild 6: Prinzip des Nasmyth-Teleskops ..........................................3 

Bild 7: Prinzip des Ritchey-Chrétien-Teleskops ...............................3 

Bild 8: Das T150 innerhalb der Kuppel. Die Hauptachse ist parallel 

zum Äquator ausgerichtet (equatorial mount). ..........................5 

Bild 9: Das aktuelle System .........................................................6 

Bild 10: Struktur des neuen dezentralen Systems ...........................9 

Bild 11: Altes System der Achsen ...............................................10 

Bild 12: Neues System der Achsen..............................................10 

Bild 13: Mechanisches Modell des Teleskops.................................11 

Bild 14: ERN 1070 ....................................................................12 

Bild 15: Signale eines relativen Quadrature Encoders (Uhrzeigersinn) 

........................................................................................12 

Bild 16: X1, X2 und X4 Encoder..................................................13 

Bild 17: Foto der Hardware ........................................................14 

Bild 18: GUI des LabView Programms für ERN 1070......................14 

Bild 19: LabView Blockdiagram für ERN 1070 ...............................15 

Bild 20: LabVIEW Blockdiagram zum Auslesen des /Z-Kanals .........16 

Bild 21: UC-313........................................................................18 

Bild 22: RS485 Converter ..........................................................18 

Bild 23: WEST N2300 ................................................................18 

Bild 24: Eigenschaften von Modbus ASCII & RTU ..........................18 

Bild 25: Modbus Nachrichtenstruktur...........................................19 

Bild 26: Modbus Function Codes .................................................19 

Bild 27: Kommando-Codes des N2300.........................................19 

Bild 28: Full- vs. Half-Duplex Communication...............................20 

Bild 29: Connection Setup .........................................................20 

Bild 30: Beispiel der Kommunikation ...........................................20 

Bild 31: Converter DIP-Switch Settings .......................................21 

Bild 32: Anschlüsse N2300.........................................................21 

Bild 33: Unter-/Oberseite des Konverters.....................................21 

Bild 34: Kommunikationsbeispiel RS232-RS485............................22 

Bild 35: Steuerung der Kuppel....................................................23 

Bild 36: Screenshot des bereits bestehenden LabView Programms ..24 

Bild 37: Vereinfachte Struktur des PROGRAMA TÉCNICO CÚPULA 

T150.vi ..............................................................................25 

Bild 38: VI-Hierachie des PROGRAMA TÉCNICO CÚPULA T150.vi.....27 

Bild 39: CAN-Bus Broadcasting...................................................28 

Bild 40: CAN-Nachrichten im Standard Format .............................28 

Bild 41: vorne links: angesteuerter Motor ....................................29 

Bild 42: CAN-PCI/331................................................................29 

Bild 43: Screenshot des Programms CANscope .............................29 

Bild 44: Testflachbaugruppe.......................................................29 

Bild 45: Einige CAN-Funktionen ..................................................30 

Bild 46: CAN-Initialisierung ........................................................30 

Bild 47: canOpen.vi...................................................................30 





IIAA 


de Andalucía 

Bild 48: Routine zum Einlesen der COMANDOS.txt ........................32 

Bild 49: Programa Principal: Abschnitt 1 ......................................33 

Bild 50: Benutzeroberfläche .......................................................34 

Bild 51: Case-Struktur der Kommandos.......................................34 

Bild 52: Programa Principal: Ausschnitt von Abschnitt 2 ................35 

Bild 53: canReadMsg.vi .............................................................36 

Bild 54: Programa Principal: Abschnitt 3 ......................................36 

Bild 55: Abschnitt 4 ..................................................................37 

Bild 56: Configuración para el estudio de posicionado ALFA............38 

Bild 57: Verbindung zwischen dem RCN829, dem FPGA und cRIO ...39 

Bild 58: Systemkonfiguration des Encoders & Folgeelektronik.........40 

Bild 59: RCN829 .......................................................................40 

Bild 60: Block Diagramm des Softmakro......................................40 

Bild 61: HP Logic Analyzer aus den 1980’ern................................41 

Bild 62: Read & Write Cycle .......................................................41 

Bild 63: DAQ-6016 Pin-Anschlüsse..............................................42 

Bild 64: „Esquema: Conexión buffer triestado externo“..................43 

Bild 65: Foto des Hardwareaufbaus.............................................44 

Bild 66: Front Panel des SubVI Parallel_Read_8bit.vi ..............45 

Bild 67: Block Diagramm des SubVI Parallel_Read_8bit.vi ........46 

Bild 68: Register-Zugriff ............................................................47 

Bild 69: Configuration Register 1 ................................................47 

Bild 70: Auszüge des Front Panel des Programms .........................48 

Bild 71: Block Diagramm des Programms ....................................49 

Bild 72: Foto des Logic Analyzers. Fehlerhaftes Verhalten: Daten 

stehen nur kurzzeitig zur Verfügung ......................................49 

9.3 Tabellenverzeichnis 

Tabelle 1: Chronologischer Tätigkeitsabriss ....................................4 

Tabelle 2: Übersicht serieller Kommunikationsmöglichkeiten ..........17 

Tabelle 3: Modbus Nachrichtenbeispiel ........................................19 

Tabelle 4: Erläuterung Modbus Nachrichtenbeispiel .......................19 

Tabelle 5: Pin Verbindungen RS485-RS485 ..................................20 

Tabelle 6: Pin Verbindungen RS232-RS485 ..................................21 

Tabelle 7: Comandos de la cúpula (COMANDOS.txt)......................31 

Tabelle 8: Parallele Kommunikation ............................................41 

Tabelle 9: Übersicht verwendeter ICs ..........................................42 

Tabelle 10: Tasks .....................................................................45 

Tabelle 11: Ein- & Ausgänge der SubVI's .....................................45 

Tabelle 12: Reihenfolge der Kommunikationssequenzen ................46 





IIAA 


de Andalucía 

9.4 Quell- und Literaturverzeichnis 

• CAN: NI-CAN Hardware and Software Manual, May 2005, 

National Instruments. 

• Data Acquisition and Signal Conditioning (Course Manual), 

August 2003 Edition, National Instruments. 

• DAQ: PC-TIO-10 User Manual, April 1999 Edition, National 

Instruments. 

• Fundamental Astronomy, H. Karttunen et al, fourth edition, 

Springer Verlag. 

• HDL Chip Design, Douglas J. Smith, 1998 Doone Publications, 

Madison, AK, USA. 

• New Control System for the 1.5m and 0.9m Telescopes at 

Sierra Nevada Observatory, L. P. Costillo et al, Proceeding of 

SPIE Vol. 6274 62741I-12, IAA, Granada, Spain. 

• Proyecto Modelo de Telescopio (ServoMotores), J. L. Ramos 

Más, Versión 1, Oct. 2007. 

9.4.1 Bildquellen 

Bilder 9 

bis 12 

New Control System for the 1.5m and 0.9m Telescopes at Sierra 

Nevada Observatory, L. P. Costillo et al, Proceeding of SPIE Vol. 6274 

62741I-12, IAA, Granada, Spain. 

Bild 1 http://www.iaa.es/img/docs/plano-gr.gif [27.11.07] 

Bild 2 http://www.hisparob.es/images/logos/logo_csic.png [27.11.07] 

Bild 3 http://www.iaa.es/organigrama/organigrama.gif [27.11.07] 

Bild 4 http://www.osn.iaa.es/fotos/foto_portada.JPG [27.11.07] 

Bild 5 Proyecto Modelo de Telescopio.doc (Modelo de Telescopio, Propuesta de 

Proyecto de Desarrollo, José Luis Ramos Más) 

Bild 6 http://de.wikipedia.org/wiki/Bild:Nasmyth-Telescope.svg [27.11.07] 

Bild 7 http://de.wikipedia.org/wiki/Bild:Ritchey-Chretien-Cassegrain- 

Teleskop.svg [27.11.07] 

Bild 8 PROYECTO DE Controlador de la CÚPULA T150.doc (Nueva Consola, 

Control de Cúpula), IAA 2007. 

Bild 13 IAA, 2004. 

Bild 14 Heidenhain, Preliminary Product Information, ERN 1000 Series, 

Generation 2, 03/2006. 

Bild 15 http://pdf.directindustry.com/pdf/heidenhain/rotary-encoders/155-88- 

_32.html [25.10.07] 

Bild 16 DAQ PCI/PXI 6602 – User Manual, Pages 3-18, 3-19 

Bilder 17 Inés Seiler, 2007. 

bis 20 

Bild 21 http://www.serial-cards.co.uk/CategoryImages%5CUC313l.jpg 

[21.12.07] 





IIAA 


de Andalucía 

Bild 22 http://www.patton.com/manuals/2085.pdf [21.12.07] 

Bild 23 http://www.setra.com.cn/images/file_upload/img/ 

20050707134355.JPG [21.12.07] 

Bild 24 http://www.lammertbies.nl/comm/info/modbus.html#tran [12.11.07] 

Bilder http://www.lammertbies.nl/comm/info/modbus.html#mess [12.11.07] 

25, 26 

Bild 27 http://www.easytherm.cz/download.php?id=410682,17,1 [12.11.07] 

Bild 28 http://ckp.made-it.com/pictures/rs485.gif [12.11.07] 

Bilder Inés Seiler, 2007. 

29, 30, 

34 

Bilder http://www.patton.com/manuals/2085.pdf [12.11.07] 

31, 33 

Bild 32 http://www.farnell.com/datasheets/51900.pdf [12.11.07] 

Bild 35 EL SOFTWARE DEL NUEVO CONTROLADOR.doc, IAA 2007. 

Bilder 36 Inés Seiler, 2008. Bild 37 wurde mit dem Freewareprogramm husbis 

38 Struktogrammer erstellt. 

Bilder Controller Area Network – Ein serielles Bussystem nicht nur für 

39, 40 Kraftfahrzeuge, ESG GmbH, Hannover, (www.esd-elecotronics.com). 

Bild 42 http://www.esd-electronics.de/photos/PCI31-21.jpg [22.01.08] 

Bilder Inés Seiler, 2008. 

41, 43 

bis 55 

Bilder Proyecto Actualización Posicionado Alfa.doc (Informe Técnico, J. L. 

56, 57, Ramos Más, 2007.) 

60 

Bilder 

58, 60, 

62, 68, 

69 

Bild 61 

Data Sheet: EnDat 2.2 Master Component, FPGA Softmakro for Position 

Encoder Systems with EnDat & SSI Interface. MAZeT GmbH, Jena, 

2005. 

http://www.usedmeter.com/upimg/200412161172194623.jpg 

[23.01.08] 

Bild 63 Measurement & Automation Explorer, Vers. 4.3.0f0, National 

Instruments, 2007. NI-DAQmx Device Terminal Help > DAQ Devices > 

NI DAQPad-6016. 

Bild 64 J. L. Ramos Más, IAA, 2008. 

Bilder 65 Inés Seiler, 2008. 

bis 67, 

70 bis 72 

9.4.2 Softwarequellen 

• Hus-Struktogrammer, V97.05 Delphi32 (Freeware), Steck 

Hans-Ulrich. 

• Microsoft ® Office Word 2003, Eigentum des IAA. 

• Modbus Poll Version 4.3.2. (Trial Edition), 

www.modbustools.com. 

• National Instruments LabView v7.1 und v8.5, Eigentum des 

IAA. 

• National Instruments Measurement & Automation Explorer v. 

4.3.0f0, Eigentum des IAA.

Praxissemesterbericht - The MMT Observatory

Sie wollen auch ein ePaper? Erhöhen Sie die Reichweite Ihrer Titel.

Template löschen?

Als Template speichern?