Praxissemesterbericht - MMT Observatorymmto.org/~dclark/Reports/Encoder Upgrade/RCN Telescope...

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 )

HHHoooccchhhsssccchhhuuullleee KKKaaarrrlllsssrrruuuhhheee University of Applied Sciences Hochschule für Technik

IIIAAAAAA Instituto Astrofísica de Andalucía

Inés Seiler 2. Praxissemesterbericht I

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 II

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 III

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 IV

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 1

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.

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 technisch-naturwissenschaftlichen 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, 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.

Bild 1: Granada in Spanien

Bild 2: CSIC Logo




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.)

Bild 3: Organigramm des IAA




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




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.




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.

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

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

Äquator ausgerichtet (equatorial mount).




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




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.




• 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 GPS-Empfä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 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 Standard-kommandos.

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.




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.




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.




• 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.

Bild 13: Mechanisches Modell des Teleskops

Positionen des Motors und Gegenmotors

Alpha-Achse des Modells




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.

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)

Bild 14: ERN 1070




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 Hard-ware als auch Software des 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.

Bild 16: X1, X2 und X4 Encoder




• Signal B mit „Aux“ (oder „up/down“). Dieser Pin legt die Zählrichtung fest, also ob der Zählwert erhöht oder herab-gesetzt 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




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).

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

Initialization Read Data

End Task




ü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.

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.

Initialization Read Data

End Task




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. Temperatur-regler 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: PC - N2300

Beschreibung

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.




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).




Bild 25: Modbus Nachrichtenstruktur

Bild 26: Modbus Function

Codes

Eine Nachricht kann beispielsweise so aussehen (hexdezimal):

Nachricht vom PC: 01 03 00 7A 00 01 A5 D3 Antwort des Sensors: 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

(high,low byte) = “122” (dezimal)

02 Anzahl der Bytes der Daten

00,01 Anzahl der Worte (high, low byte)

08,FC Antwortdaten (“2300”)

A5,D3 CRC BF,C5 CRC

Tabelle 4: Erläuterung Modbus Nachrichtenbeispiel

Bild 27: Kommando-Codes des N2300




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




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 33: Unter-/Oberseite des

Konverters

Bild 32 zeigt die Anschlüsse des Reglers für die DC Strom-versorgung.

Die RS485 Kommuni-

kationsanschlüsse (A & B) des Reglers werden mit den Anschlüssen des Konverters wie folgt verbunden:

Converter N2300

XMT+ B (Pin 11) XMT- A (Pin 12) G Ground (Pin 6)

Tabelle 6: Pin Verbindungen RS232-RS485




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 Reglers unterscheidet sich bei einer Kommunikation insofern, als dass vor der Antwort zuerst die Anfrage (Tx) wiedergegeben wird (Bild 34).

Bild 34: Kommunikationsbeispiel RS232-

RS485




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, dass der Computer („Ordenador“) TCS direkt mittels einem CAN-Bus mit dem Controlador kommuni-ziert. Vorerst wird jedoch eine provi-sorische 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:

Bild 35: Steuerung der Kuppel




• 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




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

Inicialización de dispositivos

Programa principal

Cierra conexiónes de CAN

repite continuamente hasta ha pulsado "FIN DEL PROGRAMA"

se ha pulsado una tecla ?

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

Recibe RS232C

otras teclas y funciónes

J Nse ha pulsado el botón "borrar" ?

borra el mensaje de error

traduce RS232 -> CAN

envía comando por CAN

RS232 comando 1

CAN comando 1RS232 comando 2

CAN comando 2RS232 comando ...

CAN comando...RS232 comando n

CAN comando n

actúa

envía comando por RS232

comando 1

caso 1: actúacomando 2

caso 2: actúacomando 3

caso 3: actúa comando ...

caso ...

comando n

caso n: actúa

envia comando por CAN

tecla 1

comando 1tecla 2

comando 2tecla 3

comando 3 tecla ...

comando ...

tecla n

comando n

Inicialización RS232C

Inicialización BUS CAN

Lee fichero de los comandos

activa los canales del CAN

Definición de variables

Valores iniciales

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




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 über-nommen. 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.




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.




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 kenn-zeichnet. 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.




Bei erfolgreicher Program-mierung 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.

Für die Kommunikationsschnittstelle wird eine PCI-Karte benötigt. Hierfür wurde die CAN-PCI/331 von esd electronic system design GmbH verwen-det. Sie verfügt über zwei CAN-Schnitt-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 Test-flachbaugruppe 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 41: vorne links: angesteuerter Motor

Bild 42: CAN-PCI/331

Bild 44: Testflachbaugruppe




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 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.

Bild 47: canOpen.vi




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)




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 über-arbeiten.

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-




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

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

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




Code wird selbstverständ-lich ebenso überprüft. Weiter wird eine Case-Struktur aufgerufen um zu überprüfen welche Taste gedrückt und welche Funk-tionen ausgeführt werden sollen (Bild 51). Danach wird der Befehl als CAN-Nachricht über die Schnitt-stelle 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 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).

Bild 50: Benutzeroberfläche




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 über-gangen 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.




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 Benutzer-oberfläche dargestellt und an-schließend über die CAN-Schnittstelle weitergeleitet. Wurden keine Nachrichten erhalten, wird der Abschnitt über-sprungen. Vorher wurden die doppelt auftauchenden CAN-Kommandos bei der Umsetzung dadurch unter-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.

Bild 54: Programa Principal:

Abschnitt 3




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

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.

Bild 55: Abschnitt 4




7.0 Absolutwert-Encoder RCN 829

7.1 Einleitung

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).

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.

Motor Freno

Encoder Relativo Motor sobre Reductora (1:360)

Encoder Absoluto (10bits) sobre Reductora (1:1) (no usado)

Inductosin (no usado)




CompactRIO

FPGA

In A

nal

ógic

a

24 B

its

In D

igit

al

Hig

hS

pee

d

Ethernet Programación

BusC

AN

Bus CAN Técnico

Transceiver

EndDat2.0

AbsolutoRelativo

Manguera Asterix

Absoluto e Incremental

Manguera Asterix

Inductosin

RCN 829

ROD 230

Vcc

Vcc CompactRIO

Buffer/Opto

Buffer/Opto

Dis

pla

yL

ED

Pos.

AB

S

Rea

l T

ime

PCB-FPGA

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




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.

7.2.3 Das FPGA

Bild 60: Block Diagramm des Softmakro

Bild 59: RCN829




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 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,

Bild 61: HP Logic Analyzer

aus den 1980’ern




sollten die Verbindungen des parallelen Busses aufeinander einge-stellt 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




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




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.




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-Task Port/Pin

Konfigu- ration

Data in P0 - Data out P1 - Addr P2.[0:5] -

Controls P3.[0;1;3] invertiert Ready P3.4 invertiert

Tabelle 10: Tasks

Eingänge Ausgänge Task: Data in/out Data: Error read/write Task: Address Data: Error out Task: Controls Task: Ready

Data: Dirección (Data: Data write) (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 in einem Hauptprogramm als 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

Bild 66: Front Panel des SubVI

Parallel_Read_8bit.vi




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

Address-Bus = Registeradresse (dirección) 0.

Databus = Data Write /CS setzen

1. /RD = setzen /WR = setzen

/ready = gesetzt? Wenn nein Fehler-LED setzen 2.

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.




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).




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).




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

1.

2. 3.

4.




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“).




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.




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




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




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




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 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. 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 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 bis 20

Inés Seiler, 2007.

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




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 25, 26

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

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 29, 30, 34

Inés Seiler, 2007.

Bilder 31, 33

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

Bild 32 http://www.farnell.com/datasheets/51900.pdf [12.11.07] Bild 35 EL SOFTWARE DEL NUEVO CONTROLADOR.doc, IAA 2007. Bilder 36 bis 38

Inés Seiler, 2008. Bild 37 wurde mit dem Freewareprogramm hus-Struktogrammer erstellt.

Bilder 39, 40

Controller Area Network – Ein serielles Bussystem nicht nur für Kraftfahrzeuge, ESG GmbH, Hannover, (www.esd-elecotronics.com).

Bild 42 http://www.esd-electronics.de/photos/PCI31-21.jpg [22.01.08] Bilder 41, 43 bis 55

Inés Seiler, 2008.

Bilder 56, 57, 60

Proyecto Actualización Posicionado Alfa.doc (Informe Técnico, J. L. Ramos Más, 2007.)

Bilder 58, 60, 62, 68, 69

Data Sheet: EnDat 2.2 Master Component, FPGA Softmakro for Position Encoder Systems with EnDat & SSI Interface. MAZeT GmbH, Jena, 2005.

Bild 61 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 bis 67, 70 bis 72

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.

Praxissemesterbericht - MMT Observatorymmto.org/~dclark/Reports/Encoder Upgrade/RCN Telescope...

Documents

Transcript of Praxissemesterbericht - MMT Observatorymmto.org/~dclark/Reports/Encoder Upgrade/RCN Telescope...