Autor: S. Lützkendorf.
Dokumentversion: 0.9 (Dez. 2001) Entwurf
Die Motorsteuerungs-Komponente enthält die Kernfunktionen zur Initialisierung, Ansteuerung und Verwaltung von Motoren im XCTL-Programm. Sie realisiert eine auf relativ abstraktem Niveau definierte Schnittstelle, mit deren Hilfe andere Komponenten komplexere Steuerungsabläufe implementieren können.
Die vom Motorcontroller verwaltete interne Motorposition kann in eine absolute Motorposition umgerechnet werden, wenn die Verschiebung zwischen dem Koordinatensystem der absoluten und dem der internen Motorposition bekannt ist (F1.1). Außerdem ist zur Bestimmung der absoluten Motorposition das Motorspiel zu berücksichtigen (F1.2) und es sind die Motorencoder-Schritte in physikalische Einheiten umzurechnen (F1.3).
Es gibt 2 Möglichkeiten nach dem Systemstart den Abstand zwischen der Absoluten Null und der Internen Null zu bestimmen:
Die Variante über Konfigurationsdaten kann nur dann fehlerfrei funktionieren, wenn sicher gestellt wird
Die Möglichkeit des Referenzpunktlaufes dagegen ist weniger von aktuellen Konfigurationsdaten abhängig und damit weniger fehleranfällig.
Gründe dafür trotzdem auch die zweite Variante zu implementieren sind: a) dass ein Referenzpunktlauf Zeit kostet und b) dass es für einige Achsen wegen der Lebensdauer sinnvoll ist, größere Bewegungen zu vermeiden.
Die Bestimmung der Koordinatenverschiebung aus den Konfigurationsdaten erfolgt mit dem Parameter DeltaPosition. Dieser speichert den Abstand zwischen der Absoluten Null und der Absoluten Motorposition beim letzten ordnungsgemäßen Verlassen des Programms. Beim Neustart des Programms wird die Interne Motorposition auf Null gesetzt, damit ist DeltaPosition der Abstand zwischen der Absoluten und der Internen Motorposition, entspricht also der gesuchten Koordinatenverschiebung.
| (*) | Die absolute Motorposition wird berechnet als Summe der vom Controller gelieferten Internen Motorposition und der Koordinatenverschiebung DeltaPosition. |
Ob die Konfigurationsdaten brauchbar sind, signalisiert der Konfigurationsparameter RestartPossible. Dieser wird bei der Initialisierung des Software-Systems auf False gesetzt, und wird erst beim ordnungsgemäßen Beenden des Programmes und nach dem Speichern des aktuellen Wertes von DeltaPosition auf True gesetzt. Falls also das Programm nicht korrekt beendet wurde - z.B. durch einen Absturz - ist beim nächsten Programmstart die Ungültigkeit der Konfigurationsdaten erkennbar.
Wenn die Konfigurationsdaten nicht gültig sind, muss ein Referenzpunktlauf durchgeführt werden. Dabei wird eine Motorposition angefahren, deren Abstand zur Absoluten Null bekannt ist. Dieser Abstand wird während der Kalibrierung (s.u.) bestimmt und im Konfigurationsparameter DistanceToZero gespeichert. Wenn diese Position erreicht ist, wird die Interne Motorposition auf Null gesetzt. Damit entspricht -DistanceToZero der gesuchten Koordinatenverschiebung und wird in DeltaPosition gespeichert. Damit gilt dann wieder (*).
Für jeden Motor kann temporär der Koordinatenursprung der absoluten Positionen verschoben werden. Der neue Koordinatenursprung heißt Relative Null.
Nach der Initialisierung ist bei allen Motoren die Relative Null gleich der Absoluten Null.
Das Motorspiel ist ein systematischer Anteil am Positionierungsfehler der Motoren der durch notwendige Fertigungstoleranzen bei Getrieben entsteht. Da dieser Anteil systematisch ist, kann er durch die Software korrigiert werden.
Bei jeder Änderung der Bewegungsrichtung muss berücksichtigt werden, dass der Motor eine bestimmte Anzahl von Umdrehungen durchführt ohne, dass sich der Motorschlitten bewegt. D.h. der Motorcontroller bekommt Encoderimpulse, stellte also eine Änderung der Internen Motorposition fest, ohne dass sich die Absolute Motorposition ändert. Diese Differenz zwischen Interner und Absoluter Motorposition muss die Software bei den Positionierungskommandos verrechnen.
Fall 1) wenn ein Motor als letztes eine Linksbewegung zu
Position X ausgeführt hat und dann um einen Betrag
D nach rechts bewegt werden soll, muss die Interne
Zielposition also durch X+D+Spiel,
und die Absolute Zielposition durch X+D
berechnet werden.
Eine Richtungsänderung von links nach rechts entspricht also einer
Verschiebung der Internen Null um +D.
Fall 2) wenn ein Motor als letztes eine Rechtsbewegung zu
Position X ausgeführt hat und dann um einen Betrag
D nach links bewegt werden soll, muss die Interne
Zielposition also durch X-D-Spiel,
und die Absolute Zielposition durch X-D
berechnet werden.
Eine Richtungsänderung von rechts nach links entspricht also einer
Verschiebung der Internen Null um -D.
Das experimentell zu bestimmende Motorspiel wird als Parameter Hysteresis in der Konfigurationsdatei gespeichert. Der Konfigurationsparameter Upwards speichert die Richtung der letzten Motorbewegung.
FEHLER: Die aktuelle Implementation der Behandlung des Motorspiels ist fehlerhaft (z.B. wird der Parameter Upwards zwar in der Konfigurationsdatei gespeichert aber nie gelesen)
WUNSCH4: Die im Folgenden beschriebene Methode zur Behandlung des Motorspiels ist der aktuellen Variante vorzuziehen. Sie ist genauer und viel weniger anfällig gegen Fehler bei der Bestimmung des Motorspiels und bei Änderungen im Motorspiel, die über sie Zeit eintreten.
Das Problem "Motorspiel" kann umgangen werden, wenn alle Positionen stets von der gleichen Seite angefahren werden. D.h. es wird festgelegt, dass alle Positionen stets von links anzufahren sind. Wenn eine anzufahrende Zielposition rechts der Istposition liegt, wird zuerst eine Zwischen-Position angefahren, die um einen bestimmten Betrag (backlash) links von der Zielposition liegt. Von dieser Zwischen-Position aus kann dann die tatsächliche Zielposition von links angefahren werden. Wenn der Wert des Parameters backlash so gewählt ist, dass er mit Sicherheit größer als das Motorspiel ist, kann sichergestellt werden, dass die Zielposition genau angefahren wird. (Das Problem der genauen Bestimmung des Motorspiels entfällt dadurch.)
Die Funktion realisiert die Umrechnung von internen Motorpositionen (in Encoderschritten) in absolute Motorpositionen (in physikalischen Einheiten). Ebenso werden interne Motorgeschwindigkeiten in physikalische Motorgeschwindigkeiten umgerechnet.
Dabei sind zwei Fälle zu unterscheiden:
Bei linearen Beziehungen erfolgt die Umrechnung mit Hilfe eines einfachen Linear-Koeffizienten. Bei nicht-linearen Beziehungen wird die Umrechnung durch ein kubisches Polynom angenähert.
Die Unterscheidung zwischen Motoren mit linearer bzw. nicht-linearer Umrechnung erfolgt über den Parameter Correction. Falls Correction=0 so wird eine lineare Beziehung berechnet, falls Correction=1 wird eine nicht-lineare Beziehung berechnet.
Wichtig: Bei der Umrechnung von Positionen von Motoren mit nicht-linearer Beziehung, ist die Lage der physikalischen Null für die Korrektheit der Umrechnung relevant. Daher ist bei solchen Motoren besonders auf die Gültigkeit des letzten Referenzpunktlaufes zu achten. Falls kein gültiger Referenzpunktlauf vorliegt, wird automatisch eine lineare Beziehung angenommen.
Falls Correction=0 oder ResartPossible=0 werden Motoreinheiten
in physikalische Einheiten mit Hilfe des in Parameter Koeff_1
gegebenen Linear-Koeffizienten umgerechnet.
Falls Unit ein Bogenmaß (Grad, Minute, Sekunde) ist gibt Koeff_1
das Verhältnis zwischen einer Motoreinheit und einer Winkelsekunde an
Andernfalls gibt Koeff_1 das Verhältnis zwischen einer Motoreinheit
und einer physikalischen Einheit an.
Beispiele
Koeff_1-Parameter können negative Werte enthalten. Dies führt zu einer Spiegelung des Koordinatensystems der Absoluten Positionen zu dem des Koordinatensystems der Internen Positionen. Mit anderen Worten zu einer Uminterpretation der Bewegungsrichtung des Motors. Am Beispiel: Unit=sekunden und Koeff_1=-0.25 kann man dann so lesen: ein Encoder-Schritt in negativer Richtung entspricht einer viertel Winkelsekunde in positiver Richtung.
FRAGE: Was gilt für die Softwareschranken für den Fall, dass Koeff_1 negativ ist?
Zur Umrechnung von Geschwindigkeiten aus Motoreinheiten/Sekunde in
Physikalische Einheiten/Sekunde wird der Parameter SpeedScale verwendet. Dabei gilt
Geschwindigkeit in Physikalische Einheiten/Sekunde * SpeedScale
= Geschwindigkeit in Motoreinheiten/Sekunde.
ANM: Scheinbar ist der Parameter SpeedScale redundant, da eine feste Relation zu Koeff_1 bestehen sollte.
Beispiele
Falls Correction=1 und ResartPossible=1 werden Motoreinheiten in physikalische Einheiten mit Hilfe eines Polynoms dritten Grades ungerechnet. Der nullte Koeffizient ist dabei stets 0. Der erste, zweite und dritte Koeffizient werden durch die Parameter Koeff_1, Koeff_2 und Koeff_3 gegeben.
Die Umkehroperation der Umrechnung von physikalischen Einheiten in Motoreinheiten wird mit Hilfe einer "combination of Newton-Raphson and bisection" approximiert (s. TMotor::rtsave).
Die Umrechnung der Geschwindigkeiten erfolgt, die bei F1.4.1.
FRAGE: ist es sinnvoll bzw. Korrekt, wenn Positionen über ein kubisches Polynom umgerechnet werden, Geschwindigkeiten aber über eine lineare Beziehung.
(TODO, genauer)
Die Funktion heißt auch Reference Point Handling.
DIALOGBOX
mit dieser Dialogbox lassen sich folgende Teilfunktionen ausführen:
(Leere Felder bedeuten, dass das Steuerelement für die Teilfunktion keine Bedeutung hat. Der Button mit dem Bullet löst die Funktion aus.)
Die Teilfunktionen die für einem Motor gelten, arbeiten auf dem in der Listbox ausgewähltem Motor. Die Teilfunktionen die auf allen Motoren arbeiten, ignorieren die Listbox-Einstellung und führen die Funktion für alle Motoren parallel durch. FRAGE1
Die Teilfunktion "Setzten der absoluten Null" arbeitet nur auf dem in der Listbox ausgewähltem Motor. FRAGE2
WUNSCH5: die Option "Keep Calibration Data" sollte nur im Experten-Modus enabled sein.
WUNSCH6: die Funktion "Set Absolute Zero" sollte auf den Dialog der Funktion F4 verschoben werden, der ebenfalls nur im Experten-Modus zugänglich ist.
Aufgabe der Kalibrierung ist es, das Software-System mit einer neuen bzw. veränderten Motorenkonfiguration abzustimmen. Ziel ist es den Abstand zwischen Referenzpunkt und Absoluter Null zu bestimmen. Dieser Abstand wird in dem Konfigurationsparameter DistanceToZero gespeichert. Mit Hilfe dieses Wertes lässt sich die Lage des Ursprungs des Koordinatensystems der absoluten Positionen bestimmen.
Die Kalibrierung ist zu wiederholen, wenn sich an der Motorenkonfiguration etwas verändert hat; z.B. Veränderung der Hardwareschranken, der Referenz-Schalter, ... .
(aus Dokumentation: "DistanceToZero: ... Diese Größe ist für viele Antriebe durch explizites Messen einer Kalibrierungskurve festgelegt. In anderen Fällen kann die physikalische Null mit dem Referenzpunkt in Beziehung gesetzt werden." FRAGE3: was für Kalibrierungskurven sind gemeint?)
Ziel des Referenzpunktlaufes ist es, eine Motorposition anzufahren, von welcher
der Abstand zur Absoluten Null bekannt ist. Setzt man diese Position zur Internen
Null, kann man mit dem bekannten Abstand die Internen Motorpositionen in Absolute
umrechnen. Am Referenzpunkt gilt:
Der Referenzpunktlauf wird nicht für Motoren zugelassen mit den Konfigurations-Parameter InitialMove==0.
Legt die aktuelle Motorposition als Absolute und Interne Null fest. D.h. DeltaPosition wird auf Null gesetzt und die Interne Motorposition wird ebenfalls auf Null gesetzt (Define Home).
Nach dem "Setzen der absoluten Null" ist der entsprechende Motor im Zustand "nicht kalibriert". FRAGE6
Diese Funktion wird ausschließlich während der Einrichtung eines Versuches verwendet, um die interne Motorposition auf Null zu setzten. Mit internen Motorpositionen sollte nur im Experten-Modus gearbeitet werden. Sichtbar sind interne Motorpositionen nur in Funktion F4, daher WUNSCH6.
Die Funktion heißt auch Common Settings for Drives
DIALOGBOX
Über diesen Dialog können folgende allgemeine Konfigurationsparameter für den Aktuellen Motor eingestellt werden:
Für die Konfigurationsparameter gelten die im Kapitel 3.2 aufgeführten Angaben. Es ist sicher zu stellen, dass die dort angegebenen Einschränkungen nicht verletzt werden.
Der Aktuelle Motor wird in der Listbox ausgewählt. Dieser Motor bleibt der Aktuelle Motor auch nach Beendigung der Funktion.
FRAGE8: Warum sind die Steuerelemente für PositionMin, PositionMax und RemoveLimit disabled?
Das XCTL-System verwaltet für die absolute Position 2 x 2 Softwareschranken. Zum ersten PositionMin und PositionMax deren Werte in Motorencoder-Schritten angegeben werden und zum zweiten AngleMin und AngleMax, deren Werte in physikalische Einheiten gemäß Unit angegeben werden.
FRAGE9: Wozu die doppelte Buchführung
die nur zu Fehlern führen kann? Die Werte für AngleMin und AngleMax
können problemlos aus PositionMin und PositionMax berechnet
werden. Genau dies stellt auch die Funktion "&Bereichsmaximierung" (s.u.)
zur Verfügung. AngleMin und AngleMax werden in der Implementation
nur während der Umrechnung von Nutzer-Einheiten in Motor-Schritte verwendet,
und das Ergebnis der Umrechnung wird dann noch mal gegen PositionMin
und PositionMax getestet.
Wenn AngleMin und AngleMax doch benötigt werden, sollte
das Verhältnis zu PositionMin und PositionMax definiert
werden; etwa: das Intervall AngleMin und AngleMax kann nur
im IntervallPositionMin und PositionMax liegen.
Ähnliches gilt für PositionWidth und AngleWidth.
Diese Funktion veranlasst den aktuellen Motor in regelmäßigen Abständen zu überprüfen ob eine der Hardware-Schranken erreicht wurde. Der Motor informiert (via Event) den Anwendungsrahmen über das Testen der Hardware-Schranke und gegebenenfalls über das Erreichen einer Hardware-Schranke.
Der erste Button-Click startet diese Überwachungsfunktion, der zweite Click beendet sie. (das sollte in der Button-Beschriftung erkennbar gemacht werden.)
Diese Überwachungsfunktion ist nicht an diesen Dialog gebunden. D.h. nach dem Schließen des Dialoges (und eigentlich erst dann) bleibt diese Funktion aktiv.
.FRAGE10: wann wird diese Funktion benötigt?
ANM: Die entsprechenden Methoden sind nur für den C-832er Controller implementiert.
D.h. beim C-812er passiert beim Button-Click nichts.
Die Funktion heißt auch Direct Steering, Move Drive (RAW)
DIALOGBOX
.gif)
Diese Funktion ermöglicht den Aktuellen Motor über die Angabe einer internen Motorposition in Encoderschritten zu bewegen. Die möglichen Motorpositionen werden dabei durch die Softwareschranken PositionMin und PositionMax beschränkt.
Der Aktuelle Motor wird in der Listbox ausgewählt. Dieser Motor bleibt der Aktuelle Motor auch nach Beendigung der Funktion.
Die Ziel-Position, d.h. die interne Motorposition die angefahren werden soll, kann entweder über die Textbox "New Position" oder über eine Bewegung des Scrollbars bestimmt werden.
Wird die Ziel-Position über die Textbox angegeben, wird getestet ob die angegebene Ziel-Position jenseits einer Software-Schranke liegt. Ist dies der Fall wird die Ziel-Position durch die Position dieser Software-Schranke ersetzt. Dadurch wird sichergestellt, dass die Zielposition immer zwischen den Software-Schranken liegt. Dann wird der Motor angewiesen die Zielposition anzufahren. Der Motor kann um jeden beliebig kleinen positiven Betrag bewegt werden.
Über den Scrollbar kann die Positionsänderung nur in Vielfachen des Parameters PositionWidth erfolgen. Eine "kleine" Bewegung entspricht 1 x PositionWidth, eine "große" entspricht 5 x PositionWidth. FEHLER1
Während der Motor in Bewegung ist kann keine neue Ziel-Position angegeben werden.
Das Schließen des Dialoges über den "Cancel"-Button oder über den "X"- Button während einer Bewegung stoppt den aktiven Motor unmittelbar. WUNSCH1
FEHLER2: die Auswahl eines anderen Motors während der aktuell gewählte Motor in Bewegung ist, sollte nicht möglich sein; in der gegenwärtigen Implementation ist dies möglich; wenn der aktuelle Motor in Bewegung ist, läuft er 'im Hintergrund' weiter; er wird auch nicht gestoppt wenn der Dialog geschlossen wird.
.FRAGE11: Unter welchen Umständen wird diese Funktion verwendet?
WUNSCH2: Die Einheit der Positionsangaben sollte deutlich werden.
ANM: Der Menüpunkt, der diese Funktion aufruft (Einstellungen/Antriebe/Direkte Steuerung) steht nur im Expertenmodus zur Verfügung.
Diese Funktion wird durch die Methode mlSetAngleDefault() realisiert.
Setzt für alle Motoren die Relative Null gleich der Absoluten Null (AngleBias==0). Berechnet aus den Software-Schranken für die Internen Positionen (PositionMin, PositionMax) die Werte für die Software-Schranken der Absoluten Positionen (AngleMin, AngleMax).
Unter dieser Funktion werden Optionen zur Einstellung Motor- bzw. Controllerspezifischer Parameter angeboten bzw. die Möglichkeit diese Parameter durch einen Probelauf zu testen.
Die Funktion arbeitet stets auf dem aktuellen Motor. Der Name des aktuellen Motors wird in der Titel-Leiste des Dialoges angegeben.
Vor dem Öffnen des jeweiligen Dialoges wird der Anwendungsrahmen darüber informiert (via Windows-Event), dass eventuell eine Diagrammfenster (für die Anzeige der Beschleunigungskurve) benötigt wird. WUNSCH3
DIALOGBOX
Über diesen Dialog können folgende Konfigurationsparameter für einen C-812er Motorcontroller eingestellt werden.
Für die Konfigurationsparameter gelten die im Kapitel 3.2 aufgeführten Angaben. Es ist sicher zu stellen, dass die dort angegebenen Einschränkungen nicht verletzt werden.
Der Button "Start Scan" löst die Funktion F6.3 aus.
DIALOGBOX
Über diesen Dialog können folgende Konfigurationsparameter für einen C-832er Motorcontroller eingestellt werden.
Für die Konfigurationsparameter gelten die im Kapitel 3.2 aufgeführten Angaben. Es ist sicher zu stellen, dass die dort angegebenen Einschränkungen nicht verletzt werden.
Der Button "Start Scan" löst die Funktion F6.3 aus.
Die Funktion taucht auch unter den Bezeichnungen Start Scan, CheckScan, MoveScan auf.
Ziel dieser Funktion ist es die aktuellen Bewegungsparameter aus dem "Optimierungs"-Dialog zu testen, sicher zu stellen, "dass die Endposition gleichmäßig und ohne Schwingungen angefahren wird".
Dies erfolgt durch einen MoveScan, d.h. in dem der aktuelle Motor um eine bestimmte Strecke verfahren wird, und in gleichmäßigen Abständen die Position ausgelesen wird. Damit erhält man die Daten für ein Ort-Zeit-Diagramm.
Nach Durchführung des MoveScans wird der Anwendungsrahmen (via Windows-Event) über die Beendigung informiert, und die Daten werden zur Verfügung gestellt. Der Anwendungsrahmen ist dafür verantwortlich diese Daten auszuwerten. (Im gegenwärtigen XCTL-System wird ein Weg-Zeit-Diagramm in einem "ScanFenster" angezeigt).
Der MoveScan wird wie folgt durchgeführt:
Die Daten eines MoveScans stehen solange zur Verfügung bis ein neuer MoveScan durchgeführt wird.
Die Motorenkomponente verwaltet eine Liste aller in einer Konfiguration des XCTL-Systems verfügbaren Motoren.
Es wird von der Annahme ausgegangen, dass es in jeder Konfiguration wenigstens einen Motor gibt. Die Anzahl der Motoren ist nach oben durch die Software nicht beschränkt.
Die Motorenkomponente unterstützt folgende Steuerkarten für die Motoransteuerung:
Außerdem stellt die Motorenkomponente einen Testmotor zu Verfügung, der die Verwendung der Software ohne tatsächlich vorhandene Steuerkarten bzw. Motoren ermöglicht.
Wie viele Motoren, welchen Typs und mit welchen Parametern in einer Versuchsanordnung
existieren, wird in einer Konfigurationsdatei gespeichert. Die Konfigurationsdatei wird
im "Windows"-Verzeichnis im Programm-Verzeichnis erwartet.
Ein Motor aus der Motorenliste ist stets als aktiv gekennzeichnet, und heißt Aktueller Motor. Es gibt immer einen Aktuellen Motor. Nach der Initialisierung ist der erste Motor der Konfiguration der Aktuelle Motor.
Die von der Motorenkomponente verwalteten Motoren haben, in der verschiedenen Versuchen in denen die Software verwendet wird, unterschiedliche Rollen: sie führen eine Bewegung entlang einer bestimmten Achse aus.
Im XCTL-System gibt es im Moment folgende Achsen:
Die Bedeutung der Achsen in den verschiedenen Versuchsaufbauten ist folgende:
Über den Namen eines Motors wird seine Zuordnung zu einer Achse bestimmt.
Einige Achsen (verschiedener Versuchsanordnungen) werden im XCTL-System einander gleichgesetzt; und zwar:
Es sollte in einer Konfiguration stets nur ein Motor für eine bestimmte (bzw. 2 gleichgesetzte Achsen) Achse existieren. Wenn es in einer Konfiguration mehrere Motoren gibt, die der gleichen Achse zugeordnet sind, ist die Zuordnung nur für den im Ini-File letzten Motor gültig. In der Motorliste sind aber trotzdem alle enthalten.
TODO
Achtung: an einigen Stellen der Implementation wird implizit die Annahme gemacht, dass das Vorhandensein der DF-Achse das der DC-Achse impliziert (und umgekehrt); s. z.B. TMotor::SetCorrectionState(BOOL).
ANM: Die Anwender sind der Meinung, solche Abhängigkeiten sollte es nicht geben. Die Motorsteuerung sollte unabhängig von der Rolle der Motoren im Versuchsaufbau arbeiten. (s. FRAGE15)
Die Motorenkomponente implementiert folgende Dialoge:
Allgemeine Parameter
Parameter zur Hardware-Ansteuerung
Parameter zum Referenzpunkt und zur Positionsbestimmung
Parameter zu Software-Schranken
"Parameter für das Rückspeichern von verschiedenen Einstellungen"
Sonstige Parameter zur Motorsteuerung
Parameter für Einheitenumrechnung
TODO
Obsolete Parameter
Die Parameter und ihre Verwendung in den Funktionen
Beziehungen/Bedingungen
TODO: es fehlen Angaben zu den Default-Werten, Einheiten, Wertebereichen und Abhängigkeiten.
Einige INI-Einträge sind in ihrer Bedeutung bzw. Gültigkeit vom Parameter Type abhängig.Wenn dies der Fall ist, steht der entsprechende Type in Klammern nach dem Parameternamen.
Abschnitte in Hochkommata (") sind i.d.R. aus den vorhandenen Dokumentationsfragmenten.
Für jeden Motor ist im Konfiguration-File eine Sektion anzulegen. Die Sektionen müssen [MotorX] heißen wobei X eine Zahl ist. X muss bei 0 beginnen und die Nummerierung der vorhandenen Sektionen muss durchgehend sein; d.h. die letzte Motor-Sektion, die gelesen wird, ist die [MotorX]-Sektion für die es keine nachfolgende Sektion [MotorX+1] mehr gibt. Es gibt keine Beschränkung für die Anzahl der Motor-Sektionen.
Die Parameter in den Sektionen sind folgende:
| vordefinierter Name | zugeordnete Achse |
|---|---|
| AzimutalRotation AZ AR Rotation Azimute |
AR = Phi |
| X, x Horizontal x-Achse x-Axis |
X |
| Y, y y-Achse y-Axis |
Y |
| Z, z Vertical z-Achse z-Axis |
Z |
| Theta | Theta |
| Omega | Omega = DF |
| Tilt TL |
Tilt = Psi |
| DC Diffraction coarse Beugung grob |
DC |
| DF Diffraction fine Beugung fein |
DF = Omega |
| Psi | Psi = Tilt |
| Phi | Phi = AR |
| CC Collimator Kollimator |
CC |
| Absorber | Absorber |
| Monochromator | Monochromator |
| Encoder | Encoder |
Anm.: die Absolute Null kann auch außerhalb des verfahrbaren Bereichs liegen, und kann auch negativ sein.
MaxVelocity sollte etwa auf 80% der Geschwindigkeit gesetzt werden, die tatsächlich erreichbar ist. Auf keinen Fall sollten Werte über dieser tatsächlich maximalen Geschwindigkeit verwendet werden (auch wenn diese im gültigen Wertebereich liegen), da sonst die Steuerung des Controllers die aktuelle Sollposition mit Geschwindigkeiten berechnet die nicht erreichbar sind und somit schnell große Abweichungen zur tatsächlichen Istposition feststellt. Ab einer bestimmten Größe dieser Positionsfehler stellt wird die Steuerung automatisch eingestellt.
Diese Parameter tauchen in einigen "echten" INI-Files auf, werden aber von der Software nicht verwendet. Wahrscheinlich Überreste älterer Versionen.
MoveFirstToZero; Orientation; Direction; Position; AngleZero; Koeff_0.
Die folgende Tabelle listet alle Konfigurationsparameter auf und beschreibt ob bzw. wie sie durch die einzelnen Funktionen verwendet werden.
Die Konfigurationsparameter werden bei der Initialisierung eingelesen und in entsprechenden Variablen gespeichert. Einige dieser Variablen werden beim beenden wieder in den entsprechenden Parametern der Konfigurationsdatei gespeichert. Zwischen durch werden die Variablen verwendet, d.h. gelesen und eventuell verändert. Darum werden zwei Arten des Zugriffs unterschieden.
Die Verwendungen sind wie folgt kodiert:
W - schreiben im ini-Datei
!W - schreiben im ini-Datei (von Hand)
R - lesen aus ini-Datei
w - schreiben auf interne Repräsentation des Parameters
r - lesen (verwenden) der internen Repräsentation des Parameters
In der Tabelle sind in den Spalten jeweils die Funktionen zu finden, die im Kapitel 2 aufgeführt sind. Außerdem gibt es 3 weitere "Pseudofunktionen": Init -- die Initialisierung der Motorsteuerung, Fin -- die ordnungsgemäße Beendigung der Komponente und Move -- die Funktion die das Bewegen eines Motors meint.
Es gibt einige Parameter die eine so zentrale Rolle spielen, dass sie eigentlich in jeder Funktion verwendet werden (z.B. die Parameter zur Motoransteuerung). Diese "standardmäßigen" lesenden Verwendungen sind in der Tabelle nicht aufgeführt. Als Beispiel dafür ist die "Pseudofunktion" Move eingeführt worden. Sie ist im Prinzip eine Teilfunktion die von so gut wie jeder Funktion verwendet wird, d.h. die r's in dieser Spalte müssten eigentlich in jeder Spalte stehen.
Desweiteren gibt es Motor-Parameter deren Verwendung noch nicht klar sind bzw. die nicht innerhalb der Motorsteuerung verwendet werden, sondern für andere Komponenten bereitgestellt werden (z.B. Digits, MinimalWidth).
ANM: Die Tabelle ist sicher nicht vollständig
| Init | Fin | F1.1 | F1.2 | F1.3 | F1.4 | F2.1 | F2.2 | F2.3 | F3.1 | F4 | F5 | F6.1 | F6.2 | F7 | Move | |
| Name | R | !W | w | |||||||||||||
| Type | R | !W | r | |||||||||||||
| BoardId | R | !W | r | |||||||||||||
| RamAddr | R | !W | r | |||||||||||||
| IoAddr | R | !W | r | |||||||||||||
| GPIBAddr | R | !W | r | |||||||||||||
| DifferentialEncoder | R | !W | r | |||||||||||||
| EnableInterrupts | R | !W | r | |||||||||||||
| InquireStatus | R | !W | r | |||||||||||||
| DistanceToZero | R | W | r | w | w | r | ||||||||||
| IndexLine | R | r!W | r | |||||||||||||
| MoveFirstToLimit | R | r | r | |||||||||||||
| InitialMove | R | r | r | |||||||||||||
| InitialAngle | R | r | r | |||||||||||||
| RemoveLimit | R | r | r | r | r | r | ||||||||||
| Hysteresis | R | r | r | |||||||||||||
| DeltaPosition | R | W | r | w | w | w | w | r | ||||||||
| Upwards | R | W | rw | r | ||||||||||||
| RestartPossible | RW | W | w | w | w | w | ||||||||||
| DeathBand | R | r | ||||||||||||||
| PositionMin | R | r | !W | r | r | r | ||||||||||
| PositionMax | R | r | !W | r | r | r | ||||||||||
| MinimalWidth | R | |||||||||||||||
| MaximalWidth | R | |||||||||||||||
| MaxVelocity | R | W | !W | w | w | |||||||||||
| PositionWidth | R | W | w | w | w | |||||||||||
| AngleMin | R | W | w | w | r | |||||||||||
| AngleMax | R | W | w | w | r | |||||||||||
| AngleBias | w | W | rw | w | w | r | ||||||||||
| AngleWidth | R | W | w | |||||||||||||
| Velocity | R | W | w | |||||||||||||
| Torque | R | W | w | - | ||||||||||||
| Gain | R | W | w | w | ||||||||||||
| DynamicGain | R | W | w | w | ||||||||||||
| IntegralGain | R | W | - | w | ||||||||||||
| IntegralLimit | R | W | - | w | ||||||||||||
| Acceleration | R | W | w | w | ||||||||||||
| DeccelerationPoint | R | !W | ||||||||||||||
| Unit | R | r | !W | r | ||||||||||||
| Digits | R | !W | ||||||||||||||
| SpeedScale | R | r | !W | r | ||||||||||||
| Correction | Rw | w | r | !W | r | |||||||||||
| Koeff_1 | R | r | !W | r | ||||||||||||
| Koeff_2 | R | r | !W | r | ||||||||||||
| Koeff_3 | R | r | !W | r |
Der folgende Abschnitt enthält eine Reihe von Beziehungen bzw. Bedingungen, die zwischen den Konfigurationenparameter gelten, bzw. von diesen einzuhalten sind.
Geklärte Fragen oder Probleme sind durchgestrichen.
| Version | Änderung / Anmerkung |
|---|---|
| 0.9 | Änderungen nach Gespräch mit Anwendern vom 7.12.2001: - F1.4 ausführlicher (F1.4.2 noch unvollständig) und Parameter für Einheitenumrechnung vervollständigt - Wunsch4, Wunsch5, Wunsch6, Wunsch7, Wunsch8 eingefügt - Anschnitt Die Parameter und ihre Verwendung in den Funktionen neu - sowie kleinere Korrekturen und Anpassungen |
| 0.8 | Abschnitt "Beziehungen/Bedingungen"
eingefügt kleinere Korrekturen/Eränzungen |
| 0.7.1 | kleinere Korrekturen/Eränzungen HTML/Format-Anpassungen für TeXifizierung |
| 0.7 | Angaben zu Konf.-Parametern ergänzt/korrigiert Definitionen erweitert (insb. zur genaueren Unterscheidung von Motor und Achse) Funktionen F7 eingefügt Funktion F6.3 ausgeführt |
| 0.6 | Änderung der Struktur entsprechend Vorgaben für Verhaltensspezifikation; Korrekturen nach Review durch Herrn Sacklowski |
| 0.5 | erste öffentliche Fassung |