Praxissemesterbericht

Transcrição

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:
Matrikelnummer:
Praktikumzeitraum:
Betreuer:
Datum:
Inés Seiler
19332
WS07/08, 03.09.07 – 31.01.08
José Luis Ramos, Luis Costillo
31.01.08
( José Luis Ramos )
H
Hoocchhsscchhuullee K
Kaarrllssrruuhhee
IIA
AA
A
University of Applied Sciences
Hochschule für Technik
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
H
Kaarrllssrruuhhee
IIA
AA
A
de Andalucía
Erklärung
Zur Erstellung
verwendet.
dieses
Dokumentes
wurden
folgende
Hilfsmittel
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
II
H
Kaarrllssrruuhhee
IIA
AA
A
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
III
H
Kaarrllssrruuhhee
IIA
AA
A
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
IV
H
Kaarrllssrruuhhee
IIA
AA
A
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
CSIC
beschäftigen
sich
mit
Einrichtungen
der
Universitäten und anderen Instituten. Eines hiervon ist
das IAA, dessen Aufgabe darin besteht sich mit der
Feldforschung im Bereich Astrophysik sowie der Bild 2: CSIC
Logo
Entwicklung der Instrumentierung von Teleskopen und
Raumflugkörpern auseinander zusetzen. Ziel ist es,
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
1
H
Kaarrllssrruuhhee
IIA
AA
A
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.)
Inés Seiler
2
H
Kaarrllssrruuhhee
IIA
AA
A
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étienTeleskop der Größe 60cm. Es liegt 2800m über dem Meeresspiegel.
Bild 6: Prinzip des NasmythTeleskops
Inés Seiler
Bild 7: Prinzip des Ritchey-ChrétienTeleskops
3
H
Kaarrllssrruuhhee
IIA
AA
A
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 CANBus 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.
Inés Seiler
4
H
Kaarrllssrruuhhee
IIA
AA
A
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
Inés Seiler
5
H
Kaarrllssrruuhhee
IIA
AA
A
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
Inés Seiler
6
H
Kaarrllssrruuhhee
IIA
AA
A
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,
verbunden.
Gleichzeitig
sollen
jedoch
alle
linearen
Bus
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.
Inés Seiler
7
H
Kaarrllssrruuhhee
IIA
AA
A
•
•
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:
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 GPSEmpfänger
ermöglicht
den
Betrieb
im
astronomischen Koordinaten-System.
Delta-Achse:
Absolute, relative und inkrementale Bewegungen
mit drei verschiedenen Geschwindigkeiten und der
Genauigkeit von einer Bogensekunde müssen
möglich sein.
Die Kuppel:
Steuerung der positiven und negativen AsimuthBewegungen.
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.
Inés Seiler
8
H
Kaarrllssrruuhhee
IIA
AA
A
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 29Bit absoluten Encoder ersetzt werden.
Inés Seiler
9
H
Kaarrllssrruuhhee
IIA
AA
A
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 RealTime 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.
Inés Seiler
10
H
Kaarrllssrruuhhee
IIA
AA
A
•
•
•
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
Positionen des
Motors und
Gegenmotors
Bild 13: Mechanisches Modell des Teleskops
Inés Seiler
11
H
Kaarrllssrruuhhee
IIA
AA
A
de Andalucía
4.0 Quadrature Encoder ERN 1070 (3600)
4.1 Einleitung
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 Ua2) ist immer um 90º
phasenversetzt zu Signal A (Ua1). 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 (Ua0)
vorhanden, welches nur einmal pro Umdrehung immer an der
gleichen Position einen Impuls erzeugt.
Bild 15: Signale eines relativen Quadrature Encoders (Uhrzeigersinn)
Inés Seiler
12
H
Kaarrllssrruuhhee
IIA
AA
A
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 X4Messung 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.
Inés Seiler
13
H
Kaarrllssrruuhhee
IIA
AA
A
•
•
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.
Bild 17: Foto der Hardware
4.2.2 Die Software
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
Inés Seiler
14
H
Kaarrllssrruuhhee
IIA
AA
A
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
Inés Seiler
15
H
Kaarrllssrruuhhee
IIA
AA
A
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 Ua0). „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.
Inés Seiler
16
H
Kaarrllssrruuhhee
IIA
AA
A
de Andalucía
5.0 Serielle 232-485 Kommunikation mit dem
MODBUS-Protokoll
5.1 Einleitung
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.
Beschreibung
Schnittstellen:
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.
Inés Seiler
17
H
Kaarrllssrruuhhee
IIA
AA
A
Bild 21: UC-313
de Andalucía
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).
Inés Seiler
18
H
Kaarrllssrruuhhee
IIA
AA
A
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
03
00,7A
00,01
A5,D3
Modbus Adresse des N2300
Modbus Funktionscode
Adresse des ersten Wortes
(high,low byte) = “122”
(dezimal)
Anzahl der Worte (high, low
byte)
CRC
01
03
02
Modbus Adresse des N2300
Modbus Funktionscode
Anzahl der Bytes der Daten
08,FC
Antwortdaten (“2300”)
BF,C5
CRC
Tabelle 4: Erläuterung Modbus Nachrichtenbeispiel
Bild 27: Kommando-Codes des N2300
Inés Seiler
19
H
Kaarrllssrruuhhee
IIA
AA
A
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 HalfDuplex konfiguriert.
D9
Pins
5
1
2
Bild 28: Full- vs. Half-Duplex Communication
N2300
Pins
6 - GND
11 - B
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
Inés Seiler
Bild 30: Beispiel der Kommunikation
20
H
Kaarrllssrruuhhee
IIA
AA
A
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:
Converter
N2300
XMT+
B (Pin 11)
XMTA (Pin 12)
G
Ground (Pin 6)
Bild 33: Unter-/Oberseite des
Konverters
Inés Seiler
Tabelle 6: Pin Verbindungen RS232RS485
21
H
Kaarrllssrruuhhee
IIA
AA
A
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
Bild 34: Kommunikationsbeispiel RS232RTS
disable
delay“
RS485
eingestellt wird.
Die Antwort (Rx) des
Reglers unterscheidet sich bei einer Kommunikation insofern, als dass
vor der Antwort zuerst die Anfrage (Tx) wiedergegeben wird (Bild
34).
Inés Seiler
22
H
Kaarrllssrruuhhee
IIA
AA
A
de Andalucía
6.0 Steuerung der Kuppel des Teleskops
6.1 Übersicht
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.
Die angestrebte
Endlösung sieht vor,
Bild 35: Steuerung der Kuppel
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:
Inés Seiler
23
H
Kaarrllssrruuhhee
IIA
AA
A
•
de Andalucía
Verwendung und Anpassung des bestehenden Programms:
o Verwendung des CAN-Busses einführen (wurde vorher
o
o
o
o
o
o
nicht verwendet).
Verwendung der RS-232 Schnittstelle.
Anpassung des GUI (neue Befehlsoptionen einführen,
veraltete löschen).
Empfangene RS-232 Befehle in CAN-Nachricht
übersetzen und weiterleiten.
Empfangene CAN-Nachrichten in RS-232 Nachrichten
übersetzen und weiterleiten.
Empfang und Versandt von Nachrichten über GUI
darstellen.
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
Inés Seiler
24
H
Kaarrllssrruuhhee
IIA
AA
A
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
comando 1
tecla 3
comando 2
comando 3
tecla n
tecla ...
comando ...
comando n
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
caso 1: actúa
comando 3
caso 2: actúa
caso 3: actúa
comando ...
caso ...
actúa
comando n
caso n: actúa
envía comando por RS232
Recibe RS232C
traduce RS232 -> CAN
RS232 comando 1
CAN comando 1
RS232 comando 2 RS232 comando ...
CAN comando 2 CAN comando...
RS232 comando n
CAN comando n
envía comando por CAN
otras teclas y funciónes
se ha pulsado el botón "borrar" ?
J
borra el mensaje de error
repite continuamente hasta ha pulsado "FIN DEL PROGRAMA"
N
Cierra conexiónes de CAN
Bild 37: Vereinfachte Struktur des PROGRAMA TÉCNICO CÚPULA T150.vi
Inés Seiler
25
H
Kaarrllssrruuhhee
IIA
AA
A
de Andalucía
Die einzelnen Programmteile beinhalten weitere „ProgrammStrukturen“ d.h. Sequence- oder Case-Structures, wie in Bild 37
angedeutet.
1. Inicialización de variables: keine nennenswerten Änderungen
wurden vorgenommen.
de
dispositivos:
die
Initialisierung
der
2. Inicialización
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.
Inés Seiler
26
H
Kaarrllssrruuhhee
IIA
AA
A
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.
Inés Seiler
27
H
Kaarrllssrruuhhee
IIA
AA
A
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.
Inés Seiler
28
H
Kaarrllssrruuhhee
IIA
AA
A
de Andalucía
Bei erfolgreicher Programmierung ist es somit möglich,
diesen Motor direkt per CANBus 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
esd
wurde
die
CAN-PCI/331
von
electronic system design GmbH verwendet. Sie verfügt über zwei CAN-SchnittBild 42: CAN-PCI/331
stellen von welcher eine verwendet wird.
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.
Inés Seiler
Bild 44: Testflachbaugruppe
29
H
Kaarrllssrruuhhee
IIA
AA
A
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.
Bild 47: canOpen.vi
Hiermit
wird,
wie
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.
Inés Seiler
30
H
Kaarrllssrruuhhee
IIA
AA
A
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
0040
0041
0042
0042
0043
0044
0044
0050
0051
0052
0053
0054
0055
0056
0060
0061
0062
0063
0064
0065
0065
0067
0068
0069
006A
0060
0061
0062
0063
0064
0065
0066
0067
0068
0069
006A
0070
0071
0072
0073
0080
0081
0090
STOP
STOC
AZABxxx
AZR+xxx
AZR-xxx
PARK
AZC+
AZCWREE
SEGA
FSEG
AOFF
A_AZ
A_CO
A_ZE
¿AZ?
¿CO?
VER?
PAR?
PAE?
ZER?
ZEE?
ZMR?
ZME?
INR?
INE?
¡AZ!xxx
¡CO!
VER!
PAR!xxx
PAE!xxx
ZER!xxx
ZEE!xxx
ZMR!xxx
ZME!xxx
INR!xxx
INE!xxx
CPARxxx
CZERxxx
CZEMxxx
CINExxx
FIN!xxx
¡ZE!xxx
ERR!xxx
-
stop TODOS
stop CUPULA - STOP
MOVIMIENTOS
MOV. ABSOLUTO
MOV. RELATIVO
MOV. RELATIVO
APARCAR
MOVIMIENTO CONTINUO MOVIMIENTO CONTINUO GRABAR EEPROM COMANDOS
SEGUIMIENTO AUTOMÁTICO FIN DE SEGUIMIENTO AUTOMÁTICO
FIN ENVÍO AUTOMÁTICO TRAMAS ENVÍO AUTOMÁTICO ACIMUT ENVÍO AUTOMÁTICO CONSUMO ENVÍO AUTOMÁTICO PASO CERO RTR - ACIMUT ACTUAL PETICIONES
RTR - PIDE CONSUMO
RTR - PIDE VERSIÓN PROG
RTR - ACIMUT DE APARCADO RAM
RTR - ACIMUT DE APARCADO EEPROM
RTR - ACIMUT DE PASO POR CERO RAM
RTR - ACIMUT DE PASO POR CERO EEPROM
RTR - MARGEN DE PASO POR CERO RAM
RTR - MARGEN DE PASO POR CERO EEPROM
RTR - CONSTANTE DE INERCIA RAM
RTR - CONSTANTE DE INERCIA EEPROM
ACIMUT ACTUAL
ENVÍA CONSUMO: Exx.xx
ENVÍA VERSIÓN PROG
ENVIA POSICIÓN APARCADO RAM
ENVIA POSICIÓN APARCADO EEPROM
ENVIA POSICIÓN PASO CERO RAM
ENVIA POSICIÓN PASO CERO EEPROM
ENVÍA MARGEN PASO CERO RAM
ENVÍA MARGEN PASO CERO EEPROM
ENVÍA CONSTANTE DE INERCIA RAM
ENVÍA CONSTANTE DE INERCIA EEPROM
APARCADO ENVIO CONSTANTES
PASO POR CERO MARGEN PASO CERO INERCIA FIN DEL MOVIMIENTO EJECUTADO
HA PASADO POR CERO
ERROR
Tabelle 7: Comandos de la cúpula (COMANDOS.txt)
Inés Seiler
31
H
Kaarrllssrruuhhee
IIA
AA
A
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-
Inés Seiler
32
H
Kaarrllssrruuhhee
IIA
AA
A
de Andalucía
Array zu speichern. Die spätere Zuordnung von RS232 zu CANKomando 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
Inés Seiler
33
H
Kaarrllssrruuhhee
IIA
AA
A
de Andalucía
Code wird selbstverständlich
ebenso
überprüft.
Weiter wird eine CaseStruktur aufgerufen um zu
überprüfen welche Taste
gedrückt und welche Funktionen ausgeführt werden
sollen (Bild 51). Danach
wird der Befehl als CANNachricht ü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 CANSchnittstelle 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 CANKommando 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).
Inés Seiler
34
H
Kaarrllssrruuhhee
IIA
AA
A
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 StackedSequence-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.
Inés Seiler
35
H
Kaarrllssrruuhhee
IIA
AA
A
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
CANSchnittstelle
weitergeleitet.
Wurden
keine
Nachrichten
erhalten, wird der Abschnitt übersprungen.
Vorher wurden die doppelt
auftauchenden CAN-Kommandos
Bild 54: Programa Principal:
bei der Umsetzung dadurch unterAbschnitt 3
schieden, dass der Status des
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.
Inés Seiler
36
H
Kaarrllssrruuhhee
IIA
AA
A
de Andalucía
6.4.4 Abschnitt 4: Weitere Tasten und Funktionen
Dieser Abschnitt dient rein der
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.
Kosmetik
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.
Inés Seiler
37
H
Kaarrllssrruuhhee
IIA
AA
A
de Andalucía
7.0 Absolutwert-Encoder RCN 829
7.1 Einleitung
Zur Steuerung der Alpha-Achse des Teleskops sollen insgesamt
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).
zwei
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.
Inés Seiler
38
H
Kaarrllssrruuhhee
IIA
AA
A
de Andalucía
Real Time
BusCAN
In Digital
HighSpeed
In Analógica
24 Bits
CompactRIO
Ethernet Programación
Bus CAN Técnico
Vcc CompactRIO
Display LED
Pos.ABS
PCB-FPGA
Buffer/Opto
FPGA
Manguera Asterix
Inductosin
Buffer/Opto
Manguera Asterix
Absoluto e Incremental
Transceiver
EndDat2.0
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
Inés Seiler
39
H
Kaarrllssrruuhhee
IIA
AA
A
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
Inés Seiler
40
H
Kaarrllssrruuhhee
IIA
AA
A
de Andalucía
Auf den FPGA wird das EnDat2.2 Softmakro der Firma MAZeT
GmbH geladen. Der Masterbaustein dieser Firma wurde vom EncoderHersteller 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 Bild 61: HP Logic Analyzer
aus den 1980’ern
einem Logic Analyzer der Firma Hewlett
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.
Data (8/16 Bit):
Address (6 Bit):
/CS:
/RD:
/READY:
/WR:
DAQ
Ports 0 & 1
Pins 2.(0:5)
Pin 3.0
Pin 3.1
Pin 3.4
Pin 3.3
FPGA
D(0:15)
A(0:5)
/CS
/RD
/READY
/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,
Inés Seiler
41
H
Kaarrllssrruuhhee
IIA
AA
A
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
74HCT240
74HCT10
74HCT04
Beschreibung
Octal buffer/line driver; 3-state; inverting
Triple 3-input NAND gate
Hex Inverter
Tabelle 9: Übersicht verwendeter ICs
Inés Seiler
42
H
Kaarrllssrruuhhee
IIA
AA
A
de Andalucía
Bild 64: „Esquema: Conexión buffer triestado externo“
Inés Seiler
43
H
Kaarrllssrruuhhee
IIA
AA
A
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
else
ChipSelect=0 and Read=1 and Write=0,
Enable =1
Für diese Schaltung werden die ICs 74HC10 (NAND) und 74HC04
verwendet. (Anmerkung: Die Enable-Eingänge des
74HC240 sind low-active, daher wird ein NAND statt AND verwendet.)
(Inverter)
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.
Inés Seiler
44
H
Kaarrllssrruuhhee
IIA
AA
A
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.
DAQTask
Data in
Data out
Addr
Controls
Ready
Port/Pin
P0
P1
P2.[0:5]
P3.[0;1;3]
P3.4
Konfiguration
invertiert
invertiert
Tabelle 10: Tasks
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
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
Bild 66: Front Panel des SubVI
in einem Hauptprogramm als
Parallel_Read_8bit.vi
SubVI’s verwendet werden.
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
Inés Seiler
45
H
Kaarrllssrruuhhee
IIA
AA
A
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
0.
1.
2.
3.
Read VI
Write VI
Address-Bus = Registeradresse (dirección)
Databus = Data Write
/CS setzen
/RD = setzen
/WR = setzen
/ready = gesetzt? Wenn nein Fehler-LED setzen
Data Read = Databus
/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
Konfigurationsvariablen.
Das
„Identification
Daten
und
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.
Inés Seiler
46
H
Kaarrllssrruuhhee
IIA
AA
A
de Andalucía
Bild 68: Register-Zugriff
Bild 69: Configuration Register 1
7.4.3 Hauptprogramm
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).
Inés Seiler
47
H
Kaarrllssrruuhhee
IIA
AA
A
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 CaseStructure „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).
Inés Seiler
48
H
Kaarrllssrruuhhee
IIA
AA
A
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
Inés Seiler
49
H
Kaarrllssrruuhhee
IIA
AA
A
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“).
Inés Seiler
50
H
Kaarrllssrruuhhee
IIA
AA
A
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.
Inés Seiler
51
H
Kaarrllssrruuhhee
IIA
AA
A
de Andalucía
9.0 Anhang
9.1 Abkürzungsverzeichnis & Glossar
ASIC
CAN
CISC
CMOS
COTS
CRC
cRIO
DAQ-STC
Application Specific Integrated Circuit
Controller Area Network
Consejo Superior de Investigaciones Científicas
Complementary Metal Oxide Semiconductor
Commercial Off The Shelf
Cyclic Redundancy Check
Compact Reconfigurable Embedded System von NI
Data Aquisition - System Timing Controller (DAQ: PC-TIO-10
User Manual)
Dynamic Linking Library
Kommunikationsstandard der Firma Heidenhain
Field Programmable Gate Array (programmierbarer IC)
Graphical User Interface
ein CMOS IC der Firma Avago Technologies
Instituto Astrofísica de Andalucía
Integrated Circuit (integrierter Schaltkreis)
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
DLL
EnDat2.2
FPGA
GUI
HCTL
IAA
IC
ID
9.2 Abbildungsverzeichnis
Bild 1: Granada in Spanien ..........................................................1
Bild 2: CSIC Logo .......................................................................1
Bild 3: Organigramm des IAA .......................................................2
Inés Seiler
52
H
Kaarrllssrruuhhee
IIA
AA
A
de Andalucía
Bild
Bild
Bild
Bild
Bild
4: Observatorio Sierra Nevada (OSN)......................................3
5: Logo OSN ........................................................................3
6: Prinzip des Nasmyth-Teleskops ..........................................3
7: Prinzip des Ritchey-Chrétien-Teleskops ...............................3
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
Inés Seiler
53
H
Kaarrllssrruuhhee
IIA
AA
A
Bild
Bild
Bild
Bild
Bild
Bild
Bild
Bild
Bild
Bild
Bild
Bild
Bild
Bild
Bild
Bild
Bild
Bild
Bild
Bild
Bild
Bild
Bild
Bild
Bild
de Andalucía
48: Routine zum Einlesen der COMANDOS.txt ........................32
49: Programa Principal: Abschnitt 1 ......................................33
50: Benutzeroberfläche .......................................................34
51: Case-Struktur der Kommandos.......................................34
52: Programa Principal: Ausschnitt von Abschnitt 2 ................35
53: canReadMsg.vi .............................................................36
54: Programa Principal: Abschnitt 3 ......................................36
55: Abschnitt 4 ..................................................................37
56: Configuración para el estudio de posicionado ALFA............38
57: Verbindung zwischen dem RCN829, dem FPGA und cRIO ...39
58: Systemkonfiguration des Encoders & Folgeelektronik.........40
59: RCN829 .......................................................................40
60: Block Diagramm des Softmakro ......................................40
61: HP Logic Analyzer aus den 1980’ern ................................41
62: Read & Write Cycle .......................................................41
63: DAQ-6016 Pin-Anschlüsse..............................................42
64: „Esquema: Conexión buffer triestado externo“..................43
65: Foto des Hardwareaufbaus .............................................44
66: Front Panel des SubVI Parallel_Read_8bit.vi ..............45
67: Block Diagramm des SubVI Parallel_Read_8bit.vi ........46
68: Register-Zugriff ............................................................47
69: Configuration Register 1 ................................................47
70: Auszüge des Front Panel des Programms .........................48
71: Block Diagramm des Programms ....................................49
72: Foto des Logic Analyzers. Fehlerhaftes Verhalten: Daten
stehen nur kurzzeitig zur Verfügung ......................................49
9.3 Tabellenverzeichnis
Tabelle
Tabelle
Tabelle
Tabelle
Tabelle
Tabelle
Tabelle
Tabelle
Tabelle
Tabelle
Tabelle
Tabelle
Inés Seiler
1: Chronologischer Tätigkeitsabriss ....................................4
2: Übersicht serieller Kommunikationsmöglichkeiten ..........17
3: Modbus Nachrichtenbeispiel ........................................19
4: Erläuterung Modbus Nachrichtenbeispiel .......................19
5: Pin Verbindungen RS485-RS485 ..................................20
6: Pin Verbindungen RS232-RS485 ..................................21
7: Comandos de la cúpula (COMANDOS.txt)......................31
8: Parallele Kommunikation ............................................41
9: Übersicht verwendeter ICs ..........................................42
10: Tasks .....................................................................45
11: Ein- & Ausgänge der SubVI's .....................................45
12: Reihenfolge der Kommunikationssequenzen ................46
54
H
Kaarrllssrruuhhee
IIA
AA
A
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
Bild
Bild
Bild
Bild
Bild
1
2
3
4
5
Bild 6
Bild 7
Bild 8
Bilder 9
bis 12
Bild 13
Bild 14
Bild 15
Bild 16
Bilder 17
bis 20
Bild 21
Inés Seiler
http://www.iaa.es/img/docs/plano-gr.gif [27.11.07]
http://www.hisparob.es/images/logos/logo_csic.png [27.11.07]
http://www.iaa.es/organigrama/organigrama.gif [27.11.07]
http://www.osn.iaa.es/fotos/foto_portada.JPG [27.11.07]
Proyecto Modelo de Telescopio.doc (Modelo de Telescopio, Propuesta de
Proyecto de Desarrollo, José Luis Ramos Más)
http://de.wikipedia.org/wiki/Bild:Nasmyth-Telescope.svg [27.11.07]
http://de.wikipedia.org/wiki/Bild:Ritchey-Chretien-CassegrainTeleskop.svg [27.11.07]
PROYECTO DE Controlador de la CÚPULA T150.doc (Nueva Consola,
Control de Cúpula), IAA 2007.
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.
IAA, 2004.
Heidenhain, Preliminary Product Information, ERN 1000 Series,
Generation 2, 03/2006.
http://pdf.directindustry.com/pdf/heidenhain/rotary-encoders/155-88_32.html [25.10.07]
DAQ PCI/PXI 6602 – User Manual, Pages 3-18, 3-19
Inés Seiler, 2007.
http://www.serial-cards.co.uk/CategoryImages%5CUC313l.jpg
[21.12.07]
55
H
Kaarrllssrruuhhee
IIA
AA
A
Bild 22
Bild 23
Bild 24
Bilder
25, 26
Bild 27
Bild 28
Bilder
29, 30,
34
Bilder
31, 33
Bild 32
Bild 35
Bilder 36
bis 38
Bilder
39, 40
Bild 42
Bilder
41, 43
bis 55
Bilder
56, 57,
60
Bilder
58, 60,
62, 68,
69
Bild 61
Bild 63
Bild 64
Bilder 65
bis 67,
70 bis 72
de Andalucía
http://www.patton.com/manuals/2085.pdf [21.12.07]
http://www.setra.com.cn/images/file_upload/img/
20050707134355.JPG [21.12.07]
http://www.lammertbies.nl/comm/info/modbus.html#tran [12.11.07]
http://www.lammertbies.nl/comm/info/modbus.html#mess [12.11.07]
http://www.easytherm.cz/download.php?id=410682,17,1 [12.11.07]
http://ckp.made-it.com/pictures/rs485.gif [12.11.07]
Inés Seiler, 2007.
http://www.patton.com/manuals/2085.pdf [12.11.07]
http://www.farnell.com/datasheets/51900.pdf [12.11.07]
EL SOFTWARE DEL NUEVO CONTROLADOR.doc, IAA 2007.
Inés Seiler, 2008. Bild 37 wurde mit dem Freewareprogramm husStruktogrammer erstellt.
Controller Area Network – Ein serielles Bussystem nicht nur für
Kraftfahrzeuge, ESG GmbH, Hannover, (www.esd-elecotronics.com).
http://www.esd-electronics.de/photos/PCI31-21.jpg [22.01.08]
Inés Seiler, 2008.
Proyecto Actualización Posicionado Alfa.doc (Informe Técnico, J. L.
Ramos Más, 2007.)
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]
Measurement & Automation Explorer, Vers. 4.3.0f0, National
Instruments, 2007. NI-DAQmx Device Terminal Help > DAQ Devices >
NI DAQPad-6016.
J. L. Ramos Más, IAA, 2008.
Inés Seiler, 2008.
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.
Inés Seiler
56

Praxissemesterbericht

Transcrição

Documentos relacionados

Die Universität und ihre Aufgaben im Wandel der Zeiten

Absolventenporträt

für meinen Vater - Kaiserin-Friedrich

Newsletter 11/2013 Department Soziale Arbeit

Küferei-Besitzer gibt auf

Billigstrom kann teuer werden

Photo credits - Arquitectura Viva

Blueskidz - Bluesfestival Baden

Publikationen Dr. des. Alain Brechbühl

Johannes Seiler - Piano Filipski