0. Einleitung

Ziel dieser Diplomarbeit ist es, ein Programmsystem zu erstellen, mit dem ein bestehender Meßcomputer auf Transputerbasis zur Signalverarbeitung genutzt werden kann. Transputer sind schnelle Prozessoren, die eine spezielle Architektur aufweisen, um bereits von Hardware-Seite aus für parallele Prozesse und Kommunikation mit mehreren Prozessoren befähigt zu sein. Die Rechenleistung von Transputersystemen läßt sich durch Erhöhen der Prozessoranzahl steigern.

Da der Meßcomputer keine eigene Peripherie wie Massenspeicher usw. besitzt, wird er von einem PC-XT/AT-kompatiblen Rechner aus gesteuert. Über eine Einsteckkarte ist der Meßcomputer mit dem PC Host-Rechner verbunden. Der Host-Rechner erfüllt in diesem Verbund die Aufgaben der Datendarstellung und Verwaltung, sowie die Steuerung der Abläufe auf dem Meßboard. Der Meßcomputer nimmt die eigentliche Signalverarbeitung vor. Dazu gehört die Ausgabe von definierten Signalen, das Aufnehmen von Meßwerten und die Berechnung der Meßergebnisse wie Spektrum oder Effektivwert.

Abbildung 1: Meßsystem

1. Programmbeschreibung

Die Quelldateien für den Server umfassen insgesamt 2,3 Megabyte an Quellcode. Da es leider den Rahmen einer Diplomarbeit überschreiten würde, alle Eigenschaften und Programmteile zu erläutern, muß sich die Beschreibung des Programmablaufs unter Windows auf die Teile beschränken, die für den Server charakteristisch sind, und die in anderen Windows-Applikationen nicht ähnlich vorkommen. Allgemeine Programmteile folgen einem Programmierschema, das auch in [2] und [3] nachgelesen werden kann.

1.1. Programmablauf auf dem Meßcomputer TA800

Das Programm auf dem Meßcomputer TA800 gliedert sich in sieben größere parallel laufende Prozeduren. Die Steuerung dieser Programmteile erfolgt über Kanäle. Die parallel laufenden Prozeduren teilen sich die Aufgaben wie Kommunikation mit dem Host-Rechner, Steuerung der Wandler oder Durchführung der Berechnungen. Entgegen des OCCAM2 Grundsatzes werden aber größere Speicherbereiche von mehreren parallel laufenden Prozeduren gleichzeitig benutzt. Diese Abkehr vom OCCAM2 Konzept erfolgte aus Gründen, die im folgenden genauer erläutert werden.

Das Occam Grundkonzept schreibt vor, Daten zwischen parallel laufenden Programmteilen nur über Kanäle auszutauschen. Dies hat unter anderem nachfolgend aufgelistete Vorteile:

Prozeduren können auf verschiedene Transputer verteilt werden die über Hardware-Links miteinander in Verbindung stehen. Dadurch kann man die Rechenleistung durch Parallelschalten von Prozessoren erhöhen.

Prozesse, die auf Daten eines anderen parallel laufenden Prozesses zur Weiterverarbeitung warten, werden über prozessorinterne Mechanismen in einen Wartezustand versetzt, bis die Daten verfügbar sind. Dadurch brauchen sich solche Prozesse nicht um die Beschaffung der Daten kümmern und vergeuden nicht unnötig Rechenzeit durch Abfragen.

Die Tatsache, daß man bei Transputern nachprüfen kann, ob ein Prozeß sendebereit ist, aber nicht, ob ein Prozeß empfangsbereit ist, ist das größte Manko dieses Konzepts. Prozesse die gerne Daten weitergeben, aber gleichzeitig auch empfangen würden, können durch fehlende Empfangsbereitschaft eines Folgeprozesses völlig angehalten werden. So ist zum Beispiel keine Stackprozedur realisierbar, in der gleichzeitig Daten abgelegt und weitergereicht werden können.

Abbildung 2: Programmstruktur auf dem Meßcomputer

Ein weiterer Grund für die Abkehr vom Occam Grundsatz ist der auf ein Megabyte begrenzte Hauptspeicher des Meßcomputers TA800, der einen sparsamen Umgang mit Speicherresourcen nahelegt.

Als letztes Argument für die globalen Speicherbereiche mag dienen, daß eine bereits erstellte Version des Transputerprogramms, die streng parallel programmiert war, durch stetig auftretende Programmblockaden und mangelnde Debugmöglichkeiten wieder verworfen wurde.

Das Transputerprogramm in der jetzigen Version benutzt zwar globale Speicherbereiche für die Daten, die Synchronisation der Prozeduren erfolgt jedoch weitgehend über Kanäle. Die Programm- und Speicherstruktur ist in den Abbildungen 2 und 3 dargestellt.

1.1.1. Struktur der Speicher

Die Speicherbereiche, die Daten enthalten können, also der Meßdatenspeicher, der Generatorspeicher und der Bearbeitungsspeicher, bestehen aus einem Kopf, in dem alle Variablen enthalten sind, die den Inhalt des Puffers beschreiben, und dem eigentlichen Datenbereich. In diesem können Daten in unterschiedlichen Formaten vorliegen, je nach dem ob sie für die Berechnung oder die Ausgabe auf einen Wandler usw. bestimmt sind.

Abbildung 3: Speicherbenutzung auf dem Meßcomputer

Abbildung 4: Struktur eines globalen Speicherbereichs

Diese Struktur wurde auch deshalb gewählt, um bei einem Transfer vom und zum Host einfach den ganzen Speicherbereich als Array von Byte senden zu können. Damit ist ein schneller und einfacher Transfer durchführbar, der auch alle Parameter der Daten im Speicher enthält. Abbildung 4 zeigt die Struktur eines solchen globalen Speicherbereichs.

Der Speicherbereich für die vom Host-Rechner gesendeten Bearbeitungsschritte, der Befehlsspeicher, unterscheidet sich von den anderen drei dadurch, daß er keine Meßdaten aufnimmt und somit keine Datenbeschreibung braucht. An deren Stelle folgen direkt die vom Host-Rechner empfangenen Bearbeitungsschritte und deren Parameter.

1.1.2. Kommunikation mit dem Host-Rechner

Der Programmablauf auf dem Meßcomputer wird von einem PC-kompatiblen Rechner aus gesteuert. Dieser überträgt zu berechnende Daten, bestimmt die Art der Berechnung und empfängt die Berechnungsergebnisse. Die Kommandos und Daten nimmt die Prozedur procCommunication entgegen, deren Programmablauf in Abbildung 5 aufgezeichnet wird.

Diese Prozedur hat die Aufgabe, die transferierten Blöcke entgegenzunehmen und entsprechend ihres Bestimmungsortes in einen der globalen Speicher einzutragen. Korrekt transferierte Blöcke müssen quittiert werden. Treten Übertragungsfehler auf, so müssen diese dem Host-Rechner mitgeteilt werden, um entsprechende Aktionen auszulösen. Desweiteren wird in dieser Stufe ein gewisse Vorsortierung der Bearbeitungsschritte vorgenommen. Befehle, die Datentransfer zum Host auslösen, werden hier analysiert und ausgeführt. Eine zweistufige Auswertung der Befehle hat den Vorteil, daß auch dann Daten aus einem gerade nicht in Bearbeitung stehenden Speicherbereich transferiert werden können, wenn im Bearbeitungsspeicher gerade Berechnungen ablaufen. Befehle, die nicht in dieser ersten Stufe zur Ausführung kommen, werden an einen Ringspeicher weitergeleitet. Dazu mehr im Abschnitt 1.1.3.

1.1.2.1. Transfer von Daten zum Host-Rechner

Bevor Daten zum Host-Rechner übertragen werden, füllt die Prozedur procCommunication den Transferheader des bestimmten Speicherbereichs mit den Parametern, die aus dem Bearbeitungsschritt zum Datentransfer im Befehlsspeicher ermittelt wurden. Dies sind das Handle des Fensters, zu dem die Daten zu übertragen sind, eine eindeutige Identifikation und eine Prüfsumme.

Der Transfer von Daten zum Host-Rechner wird von der Prozedur procSendBuffer vorgenommen, die je nach dem ob und in welches Format die zu transferierenden Daten übertragen werden sollen, wieder Prozeduren aufruft, welche die Umrechnung während des Transfers vornehmen. Im einfachsten Fall, wenn der Speicherinhalt im vorliegenden Format übertragen werden soll, beschränkt sich die zuständige Prozedur auf das Senden eines Array von Byte.

Die Prozeduren, die Daten beim Transfer in ein anderes Format wandeln oder umrechnen sollen, senden anstatt der Werte für die Datenbeschreibung, die jedem Speicherbereich voranstehen, eigene berechnete Werte. Diese Prozeduren sind in der Bibliothek PDSL.TSR implementiert.

Abbildung 5: Programmablauf Kommunikation mit dem Host-Rechner

1.1.3. Zwischenspeicherung von Bearbeitungsschritten

Eine Zwischenspeicherung der Bearbeitungsschritte wird nicht nur auf der Host-Rechner-Seite vorgenommen, sondern auch auf der Transputer-Seite. Auf der Transputer-Seite dient dies dazu, Bearbeitungsschritte zur Ausführung zu gelangen zu lassen, die unabhängig von der Ausführung eines anderen ablaufen können. Zum Beispiel kann aus dem Meßdatenspeicher ein Transfer auch dann erfolgen, wenn im Bearbeitungsspeicher eine Fourier-Transformation durchgeführt wird.

Abbildung 6: Programmstruktur für den Bearbeitungsschritte-FIFO

Die aktuelle Version von Analyse kann bis zu fünf Bearbeitungsschritte in einem FIFO-Speicher lagern. Dieser Puffer ist in einer Ringstruktur angelegt, die dafür sorgt, daß zuerst eingetragene Bearbeitungsschritte zuerst weitergeleitet werden. Zwei parallel laufende Prozeduren können auf diesen Ringspeicher zugreifen. Eine Prozedur procInFiFo ist für das Eintragen von Bearbeitungsschritten, die andere procOutFiFo für das Weiterleiten zuständig. Abbildung 6 zeigt die Struktur dieses Programmteils. Hier wurde, wie auch bei den globalen Speichern, der Occam Grundsatz aufgegeben, keine Speicherbereiche in parallel laufenden Prozeduren zu verwenden. Da das Transputer-Konzept nicht zuläßt, die Empfangsbereitschaft einer Prozedur abzufragen, würde der auf Weiterleitung wartende Kanal während der Wartezeit keine weiteren Eintragungen erlauben, und somit den ganzen FIFO überflüssig machen.

Abbildung 7: Programmablauf Eintragen von Bearbeitungsschritten in den FIFO

Die Prozedur procInFiFo, die das Füllen des Puffers vornimmt, ist eine Dauerschleife, die nach Abfragen der Aufnahmefähigkeit des FIFOs auf einen Bearbeitungsschritt vom Kanal chptcToCommandFiFo wartet. Dieser Kanal benutzt das variable Array-Protokoll PTC.CMD.FIFO, in dem zuerst die Größe des übertragenen Bearbeitungsschrittes und dann der Befehl selbst gesendet wird. Der Ablauf der Prozedur wird in Abbildung 7 gezeigt.

Dem Kanal chptcToCommandTranslation der Ausgabeprozedur procOutFiFo liegt das gleiche Protokoll PTC.CMD.FIFO zugrunde, wie dem der Einleseprozedur. Die Bearbeitungsschritte werden also im gleichen Format weitergeleitet wie sie eingetragen werden. Die Prozedur zur Weiterleitung ist ebenso wie die zum Eintragen eine Dauerschleife, die nach Überprüfen des FIFOs auf Inhalt, den zuerst eingetragenen Bearbeitungsschritt zu senden versucht. Der Adressat dieser Kommunikation ist eine Routine, welche die in einem Array von BYTE enthaltenen Befehle in ein internes, variantes Protokoll aufschlüsselt.

Abbildung 8: Programmablauf Senden von Bearbeitungsschritten aus dem FIFO

1.1.4. Übersetzung der Bearbeitungsschritte

Die Bearbeitungsschritte aus dem Bearbeitungsschritte-FIFO liegen als Array von BYTE vor. Damit die Befehle samt Parameter in den entsprechenden Routinen ausgeführt werden können, übersetzt die Prozedur procCommandTranslation den Inhalt des Bytearrays in ein internes, variantes Protokoll PTC.COMMANDS. Der Programmteil dient nicht nur zur Entschlüsselung der Befehle, sondern auch zu deren Verteilung an die für die Berechnung und die Wandlersteuerung zuständigen Prozeduren.

Die Bearbeitungsschritte, die auf dem Host-Rechner als Strukturen erzeugt wurden, müssen unter Occam mangels ähnlicher Sprachkonstrukte in ihre Elemente aufgeteilt, also retypisiert werden. Anhand des ersten Elements kann der Bearbeitungsschritt identifiziert werden. Mit ihm ist die Anzahl und die Reihenfolge der Parameter, sowie der Adressat und die zu verwendende Variante des Protokolls festgelegt.

Die Definition des Protokolls PTC.COMMANDS lautet:

PROTOCOL PTC.COMMANDS

CASE

Transfer; BYTE; BYTE; BYTE; BYTE; INT16; INT16; INT16;

REAL32; REAL32; REAL32; REAL32

ConvertFormats; INT16

WindowParameter; BYTE; BYTE; REAL32

FilterParameter; BYTE; BYTE; REAL32; REAL32; INT16

StandardFunction; INT16; REAL32; REAL32; REAL32; REAL32

Controls; INT16

Variables; INT16; INT16; INT16; REAL32

Calculation; BYTE;BYTE

Converter; INT16; INT32; INT32

Synchronize

Die Elemente des Varianten Protokolls entsprechen in Größe und Anordnung genau den Elementen der Strukturen der Bearbeitungsschritte. Tabelle 1 gibt Querverweise auf die zu den Protokollvarianten gehörigen Strukturen.

Kennzeichnung

Beschreibung der Elemente

Adressat

Tansfer

siehe Tabelle 3 auf Seite 31

procTreatment

ConvertFormats

siehe Tabelle 5 auf Seite 32

procTreatment

WindowParameter

siehe Tabelle 7 auf Seite 32

procTreatment

FilterParameter

siehe Tabelle

procTreatment

StandardFunction

siehe Tabelle 10 auf Seite 33

procTreatment

Controls

siehe Tabelle 12 auf Seite 33

procTreatment

Variables

siehe Tabelle 14 auf Seite 34

procTreatment

Converter

siehe Tabelle 19 auf Seite 35

procMeasure und procGenerator

Synchronize

Diese Protokollvariante nimmt eine Sonderstellung ein. Diese Variante wird von dem Prozeß procCommunication an den Prozeß procTreatment gesendet, um eine Quittung zu erhalten, wenn alle vorhergehenden Bearbeitungen durchgeführt sind. Damit werden Transfers zum Host-Rechner mit der Bearbeitung synchronisiert.

procTreatment

Tabelle 1: Protokoll PTC.COMMANDS

1.1.5. Ausführung der Bearbeitungsschritte

Die eigentliche Signalverarbeitung erfolgt in dieser Stufe des Transputerprogramms. Hier werden die Berechnungen durchgeführt, Daten konvertiert, innerhalb des Transputers transferiert usw.

Abbildung 9: Ausführung der Bearbeitungsschritte

Die Prozedur procTreatment, deren Programmablauf in Abbildung 9 dargestellt ist, besteht aus einer Dauerschleife, die zu Beginn die Anweisungen durch das variante Protokoll des Kanals chptcCommandsForTreatment entgegennimmt. In der Fallauswertung des Protokolls werden dann die einzelnen Arbeiten ausgeführt, die durch die Bearbeitungsschritte ausgelöst werden sollen. Die Durchführung der Arbeiten erfordern zum Teil wieder Fallunterscheidungen wie bei der Berechnung nach der Art der Berechnung, dem Format in dem die Daten vorliegen usw. Die Prozeduren zur Ausführung der Bearbeitungsschritte sind in Bibliotheken enthalten, die in Abschnitt 1.1.10. auf Seite 18 beschrieben werden.

Eine besondere Stellung nimmt die Berechnung einer schnellen Fourier-Transformation ein. Da dazu die Anzahl der Daten eine Potenz von Zwei sein muß, werden die Daten entsprechend der Einstellung im auslösenden Bearbeitungsschritt auf die nächste Potenz von Zwei erweitert bzw. auf die vorhergehende Potenz von Zwei verringert. Danach wird geprüft, ob reelle Daten transformiert werden sollen. Diese werden nämlich vor einer Transformation in sequentielle komplexe Daten umgewandelt. Dadurch werden auch die ansonsten ungenutzten Imaginärteile mit in die Rechnung miteinbezogen und die Transformation erfolgt nur mit der halben Anzahl. Das beschleunigt die Berechnung um mehr als das doppelte.

Vor der eigentlichen Transformation werden noch die Drehfaktoren berechnet. Bei der benutzten Implementierung der FFT aus [11] werden die sogenannten Drehfaktoren oder Twiddle-Faktoren bereits vor der Transformation berechnet und in Arrays für die Sinus- und Cosinuswerte abgelegt. Eine Neuberechnung ist nur dann erforderlich, wenn sich die Anzahl der zu transformierenden Werte ändert. Durch diese Abkopplung kann die Transformationsgeschwindigkeit nochmals erhöht werden.

Nach der Transformation müssen noch die Werte für die Abstände der Datensätze berechnet werden. Dies erfolgt nach der Formel:

neuer Abstand = 1 / ( alter Abstand * Anzahl der Datensätze )

Eine Transformation mit 1024 Werten, die mit einer Abtastfrequenz von 100 kHz ermittelt wurden und damit einen Abstand von 10 s haben, ergibt einen Abstand der Frequenzlinien von 97,66 Hz. Daraus ist ersichtlich, daß je mehr Punkte aufgenommen werden sich auch die Frequenzauflösung erhöht.

Bei einer Transformation vom Zeitbereich in den Frequenzbereich müssen die errechneten Werte noch durch die Anzahl der Datensätze geteilt werden. Dies ist erforderlich, da bei einer Transformation in dieser Richtung eine Multiplikation der Werte implizit in der Transformation mit enthalten ist.

1.1.6. Steuerung des Digital/Analog-Wandlers

Die Bedienung des Digital/Analog-Wandlers ist Aufgabe der Prozedur procGenerator. Diese unterteilt sich ihrerseits in zwei parallele Prozesse, deren Programmstruktur in Abbildung 10 dargestellt ist. Der eine Prozeß nimmt die Kommandos zur Ablaufsteuerung entgegen, der andere, der in der Prozedur WriteDA kodiert ist und eine höhere Priorität hat, bedient die FIFO-Speicher des Wandlers. Die höhere Priorität ist notwendig, um schnell genug Daten zum FIFO-Speicher senden zu können, damit die auszugebenden Daten unterbrechungsfrei gewandelt werden. Näheres zu den FIFO-Speichern kann in [1] nachgelesen werden.

Abbildung 10: Programmstruktur für die Digital/Analog-Wandler Steuerung

Der Programmteil, der die Befehle von der Übersetzungsprozedur procTranslation übernimmt, steuert über Kanäle den Ablauf in der Prozedur WriteDA. Der dazugehörige Programmablauf ist in Abbildung 11 skizziert. Die auszugebenden Daten werden in einem auf INT16 retypisierten Bereich des Generatorspeichers ai16DABuffer der Prozedur WriteDA bereitgestellt. Durch den Kanal chiNumberOfValues kann der Prozedur die Anzahl der auszugebenden Werte mitgeteilt werden. Der Kanal chbSingleSample weist die Prozedur an, einmalig Daten in der eingestellten Anzahl an den Wandler zu senden, chbSampleLoop startet mit dem Wert TRUE die permanente Ausgabe auf den Wandler und mit FALSE hält er die Ausgabe wieder an. Zur Synchronisation der Programmabläufe zeigt der Kanal chbSingleSampleDone dem Teil für die Ablaufsteuerung an, wann WriteDA die einmalige Ausgabe der Daten durchgeführt hat. Der Takt für den Wandler wird durch die Prozedur set.da.clk eingestellt. Ein- und ausgeschaltet werden kann der Wandlungsvorgang über den Kanal chbEnableDA, der zur Prozedur serial führt. Die zwei letztgenannten Prozeduren werden in [1] genauer erläutert.

Abbildung 11: Programmablauf Steuerung des Digital/Analog-Wandlers

Die Prozedur WriteDA ermittelt zu Beginn den Stand des Timers. Danach begibt sie sich in eine Dauerschleife, die ein Alternate-Konstrukt enthält. Dieses Konstrukt ermöglicht einem der drei Kanäle chbSingleSample, chbSampleLoop und chiNumberOfValues sowie dem Timer die Kommunikation. Ist einer der Kanäle oder der Timer kommunikationsbereit, wird der zugehörige Programmzweig ausgeführt. Der Timer wird dazu benutzt, eine gewisse Zeit verstreichen zu lassen, die klein genug ist, um den FIFO des Wandlers noch schnell genug füllen zu können, die aber groß genug ist, um Prozessen niedrigerer Priorität genügend Rechenzeit zu lassen. Nach jeder verstrichenen Timer-Periode werden die Daten in der voreingestellten Anzahl zum FIFO übertragen, sofern dies durch Setzen von Bool'schen Variablen über die Kanäle chbSampleLoop bzw. chbSingleSample gewünscht wurde. Übertragen werden die Daten in Blöcken, die der halben FIFO-Größe entsprechen. Dadurch ist gewährleistet, daß für den Wandler immer genug Daten vorhanden sind und keine Sprünge in der Ausgabe entstehen. Über den Kanal chiNumberOfValues kann die Anzahl der auszugebenden Werte eingestellt werden. chbSingleSample startet die einmalige Ausgabe der Daten in der gewählten Anzahl, währen durch chbSampleLoop solange Daten ausgegeben werden, bis dies durch Übertragen des Wertes FALSE auf diesem Kanal wieder abgestellt wird. Bei einer einmaligen Wandlung wird nachher über den Kanal chbSingleSampleDone dem parallel laufenden Steuerungsteil mitgeteilt, daß dieser über den Kanal chbEnableDA den Takt für die Ausgabe wieder abschalten kann, und so der Wandlungsvorgang angehalten wird.

1.1.7. Steuerung des Analog/Digital-Wandlers

Abbildung 12: Programmstruktur für die Analog/Digital-Wandler Steuerung

1.1.8. auf Seite 17 gegeben.[GG1]

Die Prozedur ReadAD besteht aus einer Permanentschleife, in der ein Alternate Konstrukt ausgeführt wird. Der Programmablauf erfolgt analog zu dem der Prozedur WriteDA und kann im Abschnitt 1.1.6. nachgelesen werden. Einziger Unterschied ist, daß die Daten nicht in Blöcken vom FIFO übertragen werden.

1.1.8. Bedienung der seriellen Schnittstellen

Die Prozedur serial zur Bedienung der seriellen Schnittstellen wurde direkt aus [1] übernommen, wo auch die genaue Funktion der einzelnen Programmteile, die in Abbildung 13 dargestellt sind, nachgelesen werden kann. In dieser Abbildung sind die Bezeichnungen für die Kanäle in Analyse außerhalb des Kastens von serial und die entsprechenden Kanalnamen, die in serial verwendet werden, innerhalb des Kastens abgebildet.

Abbildung 13: Programmstruktur Bedienung der seriellen Schnittstelle

Da die seriellen Ein- und Ausgänge des Meßcomputers von Analyse in der aktuellen Version nicht unterstützt werden, sind die Aufrufe der Prozeduren ser.service.rec und ser.service.send auskommentiert. Benutzt werden jedoch die Eigenschaften der Prozedur o.control. Durch sie kann über Ausgänge des seriellen Bausteins der Takt für die Digital/Analog-Wandler und Analog/Digital-Wandlers ein- und ausgeschaltet werden. Die genau Funktion von o.control bitte ich in [1] nachzulesen.

1.1.9. Überbrücken eines Transputerboards

Bei einigen Konfigurationen der Transputerhardware kann es notwendig sein, die Daten vom und zum Host-Rechner über ein Transputerboard zu führen. Dafür gibt es eine Programmversion, die so konfiguriert ist, wie es die Programmstruktur in Abbildung 14 aufzeigt. Die Daten vom Host werden zunächst an eine Prozedur procBridge auf dem Einsteckboard gesendet, das diese dann über den Link chanFromBridge an den Meßcomputer TA800 weiterleitet. Umgekehrt sendet der Meßcomputer auch die Daten zum Host über diese Prozedur.

Der Transfer dieser Prozedur wird in zwei parallel laufenden Teilen vorgenommen. Der eine empfängt ein Byte vom Host und sendet dieses dann zum Meßcomputer, um dann von vorne zu beginnen. Die andere empfängt ein Byte vom Meßcomputer und sendet dieses dann zum Host, um dann ebenfalls von vorne zu beginnen.

Abbildung 14: Programmstruktur Überbrücken eines Transputerboards

Abbildung : Programmablauf Überbrücken eines Transputerboards

In dieser Version des Programms wird leider Rechenzeit des Transputers nicht ausgenutzt, auf dem procBridge läuft. Da aber der Meßcomputer in der jetzigen Form für den Anschluß über eine Adapterkarte mit Stromtreibern vorgesehen ist und die globalen Speicherbereiche eine Aufteilung der Prozeduren auf mehrere Transputer nicht zulassen, muß man mit dieser Lösung vorliebnehmen.

1.1.10. Bibliotheken

Ein Großteil der verwendeten Prozeduren wurde in Bibliotheken abgelegt um zum einen die Programme handlicher zu machen und zum anderen die Prozeduren und Funktionen auch unter verschiedenen Transputern verwenden zu können.

In den folgenden Bibliotheken wurden die aus [1] übernommenen Routinen abgelegt:

...F "ta800lh.tsr" TA800 Library Header

...F "ta800bl1.tsr" TA800 Basics Library 1

...F "ta800bl2.tsr" TA800 Basics Library 2

...F "ta800l.tsr" TA800 Library

Unten stehende Bibliotheken enthalten alle grundlegenden Funktionen und Prozeduren. Ist in einem Namen für eine Bibliothek ein x enthalten, so ist dieses entsprechend des Transputertyps, für den die Bibliothek erzeugt ist entweder 4 für Transputertyp T4 oder 8 für Transputertyp T8.

...F "dplh.tsr" Diplom Library Header: Konstanten Definitionen für alle folgenden Bibliotheken.

...F "dpbltx.tsr" Diplom Basics Library for TX: Grundlegende Funktionen zur Berechnung für die Bibliotheken dpfltx.tsr und dpcltx.tsr.

...F "dpltx.tsr" Diplom Library for TX: Prozeduren zum Kopieren von Speicherbereichen und Berechnen der Prüfsumme.

...F "dpwltx.tsr" Diplom Window Library for TX: Prozeduren für die Fensterfunktionen.

...F "dptltx.tsr" Diplom Transfer Library for TX: Prozeduren zum Transferieren von Daten innerhalb des Transputers.

...F "dpfltx.tsr" Diplom Function Library for TX: Prozeduren zum Erzeugen von Daten nach Standardfunktionen.

...F "dpcltx.tsr" Diplom Calculation Library for TX: Prozeduren zur Durchführung der FFT und der Effektivwertberechnung sowie alle Hilfsprozeduren dazu.

...F "dpvltx.tsr" Diplom Convert Library for TX: Prozeduren zum Umwandeln von Daten in andere Formate und zum Verändern der Datenanzahl.

...F "dpaltx.tsr" Diplom Converter Library for TX: Prozeduren zum Ansteuern der Wandler.

...F "dpbh.tsr" Diplom Buffer Header: Konstanten Definitionen für die globalen Speicherbereiche auf dem Meßcomputer TA800.

...F "dpth.tsr" Diplom TEK Buffer Header: Konstanten Definitionen für die globalen Speicherbereiche auf dem Einsteckboard TEK4/8.

...F "dpch.tsr" Diplom Commands Header: Konstanten Definitionen für die Nachbildung der Strukturen der Bearbeitungsschritte.

...F "dpph.tsr" Diplom Protocol Header: Protokoll Definitionen für die Übersetzung der Bearbeitungsschritte.

...F "dpsltx.tsr" Diplom Send Library for TX: Prozeduren zum Transfer von Daten zum Host-Rechner in unterschiedlichen Formaten.

1.2. Programmablauf unter Windows

Das Programm Analyse, welches die Steuerung des Meßcomputers TA800 und für die Repräsentation und Verwaltung der Daten übernimmt, ist eine Windows Applikation. Dieser Server bietet die Möglichkeit, mehrere Fenster zur Anzeige von Meßdaten oder Spektren zu öffnen, und bedient sich dazu der MDI (multi document interface) Funktionen von Windows.

Auf die Programmierung des Windows Gerüstes der Applikation wird in den nächsten Abschnitten weniger eingegangen, da dies den Rahmen der Dokumentation sprengen würde. Vielmehr sei an dieser Stelle auf weiterführende Literatur [2] und [3] verwiesen. Dieser Abschnitt der Beschreibung geht vor allem auf die Server-spezifischen Programmteile von Analyse ein. Zum Verständnis der nachfolgenden Teile wird aber hier ein grober Grundriß einer Windows Anwendung mit MDI dargestellt.

Bei den Multitasking Fähigkeiten von Windows handelt es sich um ein Non Preemptive Multitasking. Das heißt, Programme werden nur aktiviert, wenn ihnen Windows eine Nachricht zukommen läßt. Nach Empfang einer solchen Nachricht sollte das Programm diese schnellstmöglich abarbeiten und dann die Kontrolle wieder an Windows abgeben, um nicht andere Programme zu lange in ihrer Ausführung zu bremsen.

Abbildung 15: Aussehen einer MDI Applikation

Abbildung 16: Funktion der Nachrichtenschlange

Erhält Windows von einem der Systemtreiber eine Nachricht von einem Ereignis, zum Beispiel einem Interrupt vom Zeitgeberbaustein, übergibt es diese Nachricht an die adressierte Applikation. Diese könnte die Nachricht nach eigenen Erfordernissen bearbeiten, wird aber im Normalfall die Nachricht über die Funktion DispatchMessage wieder an Windows abgeben, um dem Modul USER.EXE die Verteilung an die Fensterfunktionen zu überlassen.

Diese Fensterfunktionen sind ein sehr effizientes Mittel zur Auswertung von Nachrichten, da nicht jedes Programm selbst für die Verteilung der Nachrichten sorgen muß. Es werden Windows lediglich Fensterfunktionen, sogenannte Callback-Funktionen, angegeben, die in den Verwatungsbereich des Windows Teilprogramms USER.EXE fallen, und von dort aus aufgerufen werden. Die Callback-Funktionen bearbeiten dann die für sie jeweils relevanten Nachrichten und lassen andere Nachrichten von Windows durch Standardfunktionen auswerten.

Bei Programmen mit Multi Dokumenten Schnittstelle MDI gibt es eine Callback Funktion für das Hauptfenster, dem Rahmenfenster, und je eine eigene für jedes MDI Kindfenster. Dabei übernimmt das Rahmenfenster die Bearbeitung von Nachrichten, die das gesamte Programm beeinflussen sollen, während die Fensterfunktionen der MDI Kindfenster nur Nachrichten für die Verwaltung der Daten verwerten.

Abbildung 17: Kommunikation zwischen Kindfenster und Rahmenfenster

Eine Besonderheit von Windows ist die Speicherverwaltung. Nachdem Windows zwar auf DOS aufbaut, aber auch erweiterten Speicher verwalten kann, wird dieser nicht mehr über Bibliotheksfunktionen wie malloc vom System angefordert, sondern durch Windows-eigene Funktionen GlobalAlloc oder LocalAlloc. Der Unterschied zwischen den durch beide Funktionen belegten Speicherbereichen ist, daß die mittels GlobalAlloc belegten größer als 64 kByte sein können, und damit durch FAR oder HUGE Pointer adressiert werden müssen, während die lokalen Speicherbereiche maximal ein Segment umfassen und somit über 16-Bit-Pointer erreicht werden können. Beiden Funktionen gemeinsam ist, daß sie nicht mehr wie malloc direkt Zeiger liefern. Vielmehr geben sie Handles zurück, über die im Bedarfsfall der Zeiger auf den Speicherbereich ermittelt werden kann. Die Handles sind deshalb nötig, da Windows im Protected Mode Speicherbereiche im physikalischen Speicher an eigenen Belangen umordnen kann und somit sich auch die Lage der angeforderten Speicherbereiche ändern kann. Will man nun auf einen belegten Speicherbereich zugreifen, fordert man mittels GlobalLock oder LocalLock von Windows die im Augenblick gültigen Zeiger des mit dem Handle verbundenen Speichers an. Nach dem Aufruf einer der beiden Funktionen ist der Speicherbereich festgelegt, kann also nicht von Windows umgelagert werden, und ist damit über einen Pointer adressierbar. Nach Ende der Arbeit mit dem angeforderten Speicher ist mittels GlobalUnlock bzw. LocalUnlock die Speicherarretierung rückgängig zu machen, damit das Windows-Speichermanagement wieder normal arbeiten kann. Eine weitere Eigenschaft dieser Speicherverwaltung ist, daß nur 8192 Handles für Speicher zur Verfügung stehen. Es können also keine verketteten Listen via Handles erstellt werden, da sonst sehr schnell die Ressourcen erschöpft wären.

1.2.1. Aufgaben der Fenster

1.2.1.1. Rahmenfenster und Kindfenster

Die Menüleiste, die Teil des Rahmenfensters ist, dient zur Steuerung des Programms. Alle Nachrichten, die durch Auswählen von Menüeinträgen werden somit an das Rahmenfenster gesendet. Dieses wertet dann alle Nachrichten aus, die das gesamte Programm betreffen und gibt die Nachrichten an die Kindfenster weiter, die für jedes Kindfenster unterschiedlich auszuwerten sind.

Eine weitere Aufgabe des Rahmenfensters ist es, die grundlegende Kommunikation mit dem Transputer vorzunehmen. Dazu gehört, die einzeln vom Transputer ankommenden Daten in zusammengehörige Blöcke zu packen und an die adressierten Kindfenster zu versenden, sowie die von den Kindfenstern in Blöcken zum Transfer angemeldeten Daten einzeln zum Transputer zu übertragen. In dieser Ebene der Kommunikation werden auch Kommunikationsfehler behandelt.

Die Kindfenster nehmen vom Rahmenfenster die empfangenen Daten in Blöcken entgegen und werten diese dann aus oder Stellen sie dar. Sie sind auch für die Verwaltung und die Ausführung der Meßprogramme zuständig, die zur Steuerung der Abläufe auf dem Transputer dienen. Dazu senden sie in Blöcken Daten und Bearbeitungsschritte an das Rahmenfenster.

Im folgenden noch einmal die Aufgabenteilung unter Analyse in Stichpunkten:

Das Rahmenfenster ist zuständig für:

Grundlegende Kommunikation mit dem Meßcomputer TA800.

Multiplexen und Demultiplexen der Kommunikation zwischen Kindfenstern und Meßboard TA800.

Auswerten der Benutzereingaben, die das gesamte Programm betreffen.

Die Aufgaben der Kindfenster sind:

Darstellung und Verwaltung der Meßdaten.

Verwalten und Senden von Meßprogrammen.

1.2.1.2. Dialoge

Dialoge bieten eine sehr komfortable Möglichkeit, Eingaben für das Programm zu machen. Analyse benutzt diese Dialoge nicht nur zum verändern der unterschiedlichen Parameter des Programms, sondern auch zur Erstellung der Meßprogramme für den Transputer. Diese Dialoge sind Teil der Resource, die mittels eines Resource-Editors grafisch erstellt werden kann und dann dem Programm hinzugebunden wird. Gesteuert werden die Dialoge ebenso wie die Fenster durch Callback-Funktionen, die zwar vom Programm bereitgestellt, aber von Windows verwaltet werden. Wird in einem Dialog eine Eingabe vorgenommen, erhält die dazugehörige Callback-Funktion eine Nachricht, die sie dann auswerten kann.

Es gibt zwei verschiedene Arten von Dialogen. Die modalen Dialoge blockieren solange den Zugang zu anderen Programmteilen wie dem Menü bis die Eingaben abgeschlossen werden und der Dialog beendet wird. Solche Dialoge werden zum Vornehmen von Eingaben an das Programm verwendet. Nichtmodale Dialoge dienen zur Anzeige zusätzlicher Daten in einem getrennten Fenster. Diese beeinflussen die Bedienung der anderen Programmelemente nicht. Die Anzeige der aktuellen Cursorposition oder die Überwachung des Transfers zum Transputer werden in diesen Fenstern vorgenommen.

Die Callback-Funktionen der modalen und nichtmodalen Dialoge besitzen das Prefix Mdf bzw. Ndf und sind in den Modulen DLG.C bzw. DNM.C enthalten.

1.2.2. Verwaltung der Daten

Analyse hat im Zusammenhang mit den Kindfenstern eine Menge von Daten zu verwalten. Diese Daten liegen hauptsächlich in lokal oder global belegten Speicherbereichen, auf die über Handles zugegriffen wird. Zum Festhalten der Handles stellt Windows eine elegante Lösung zur Verfügung. Jedem Fenster können benutzereigene Daten angehängt werden. Dazu ist beim Festlegen der Fensterklasse anzugeben, wieviele zusätzliche Bytes man benutzen möchte. Dieser Speicher kann dann mittels SetWindowWord, SetWindowLong bzw. GetWindowWord, GetWindowLong beschrieben bzw. gelesen werden. Parameter der Funktionen sind das Fensterhandle und der Offset in Byte. Letztgenannten Funktionen können auch zum Verändern der internen Fensterdaten dienen.

Daten die dem gesamten Programm zugänglich sein sollen, werden dem Rahmenfenster angehängt, Daten, die jedes Kindfenster für sich braucht, werden den Kindfenstern angehängt. Die Offsets der Daten bzw. der Handles darauf, sind in WNM.H definiert und beschrieben. Sie haben alle das Prefix WW_. Hier seien nur exemplarisch einige davon aufgeführt:

WW_FILE_TYPE: Anhand des Wertes dieses Eintrags kann bestimmt werden, ob im zugehörigen Kindfenster Meßdaten oder Spektren angezeigt werden. Der Wert ist dann TYPE_DATA bzw. TYPE_SPECTRUM.

WW_CALCUALTE_FLAGS: In diesem Wert wird für jede der acht möglichen Kurven durch ein gesetztes Bit angezeigt, ob die Daten schon in für ein Fenster benötigte Koordinaten umgerechnet wurden sind.

WW_MEASURE_HANDLE: Enthält das Handle auf den Speicherbereich mit dem zum Kindfenster gehörigen Meßprogramm.

1.2.2.1. Programminterne Daten

Eine Vielzahl von Parametern und Einstellungen wird in allozierten Speicherbereichen festgehalten, die dann über Handles anzusprechen sind, die in den oben beschriebenen Extra-Words festgehalten werden.

Somit können Daten, die jedes Fenster für sich getrennt haben muß, für jedes Fenster getrennt bereitgehalten werden. Dazu gehören die Meßprogramme, die in Abschnitt 1.2.3.4. auf Seite 28 genauer erläutert werden, die Meßdaten und Spektren, die in Abschnitt 1.2.2.2. erklärt werden, und die Darstellungsparameter und Vektor-Arrays, die in den Abschnitten 1.2.4.2. und 1.2.4.3. ab Seite 38 beschrieben sind. Ein Speicherbereich mit Parametern ist dem Rahmenfenster angehängt und mittels des Handles zugänglich, das im Extra-Wort WW_FRAME_PRINT_STRUCT_HANDLE enthalten ist. In ihm sind alle Einstellungen zum Aussehen der Druckseite für alle Kindfenster enthalten.

1.2.2.1.1. Verwaltung der Initialisierungsdatei

Die Einstellungen, die im Programm vorgenommen werden können, lassen sich in einer Initialisierungsdatei ablegen und sind damit bei einem neuen Start des Programms wieder verfügbar. Bei diesen Dateien handelt es sich um reine Textdateien, bei denen unter verschiedenen Überschriften Einträge vorgenommen werden können. Zugegriffen wird auf diese Datei durch Funktionen des Moduls INI.C.

Die grundlegenden Funktionen zum Verändern der Einträge bauen alle auf die Windows-Funktionen WritePrivateProfileString, GetPrivateProfileString und GetPrivateProfileInt auf. Im Gegensatz zu diesen wird aber überprüft, ob der abzufragende oder zu beschreibende Eintrag schon existiert hat. War dies nicht der Fall, wird der Eintrag mit einem Default-Wert erzeugt. Außerdem sind durch die Funktionen auch Einträge im Fließkomma-Format oder als Bool'sche Werte usw. möglich.

Diese grundlegenden Funktionen werden benutzt, um ganze Einstellungsbereiche auf einmal verändern oder lesen zu können. Zum Beispiel können alle getroffenen Einstellungen zur Darstellung der Kurvenzüge im dazugehörigen Dialog gespeichert werden.

1.2.2.2. Meßdaten und Spektren

Jedes Kindfenster kann in der aktuellen Version des Programms bis zu acht verschieden Kurven, sprich Datenreihen, anzeigen. Die Daten liegen in globalen Speicherbereichen, die über die Handles zugänglich sind, die in den Extra-Worten WW_MEMORY_HANDLE_N jedes Meßdaten- und Spektrum-Kindfensters festgehalten werden. N steht für eine Zahl von Eins bis Acht. Zusätzlich dazu sind die Handles mit den dazugehörigen Dateinamen in der Eigenschaftsliste enthalten. Mehr dazu im Abschnitt 1.2.2.3..

Zu Beginn der eigentlichen Daten steht ein Kopf, in dem die Eigenschaften der Daten festgehalten sind.

Abbildung 18: Datenkopf zu Beginn der Datenspeicherbereiche

Dieser Kopf GeneralPropertyHeader, der im Modul DAT.H deklariert ist, besteht aus dem Kopf GeneralHeader, der auch zu Beginn jeder Datei mit Meßdaten oder Spektren steht, und zwei weiteren Einträgen. Der erste gibt die Anzahl der Zugriffe auf diesen Speicherbereich an, das heißt wieviele Kurvenzüge dieser Daten dargestellt werden. Erreicht dieser Zähler beim entfernen der Kurvenzüge aus dem Speicher Null, so ist damit erkennbar, daß die Daten in keinem Fenster mehr benötigt werden und aus dem Speicher entfernt werden können. Der zweite Eintrag enthält Flags, die angeben, ob die Daten im Speicher verändert wurden. Damit kann beim Entfernen der Daten aus dem Speicher nachgefragt werden, ob diese in der Datei aktualisiert werden sollen. Die Elemente der Struktur GeneralHeader geben an, wieviele Daten im Speicher enthalten sind und in welchem Format sie vorliegen.

1.2.2.3. Die Eigenschaftsliste

Eine Möglichkeit, Handles von Speicherbereichen, Fenstern und anderem mit Zeichenketten zu verknüpfen, bietet die Eigenschaftsliste. Sie wird für jede Applikation getrennt verwaltet. Analyse benutzt diese Liste, um überprüfen zu können, ob Dateien schon geladen wurden und damit im Speicher vorhanden sind. Soll eine Datei in zwei Fenstern gleichzeitig dargestellt werden, ist es so nicht notwendig, die Daten dazu auch zweimal im Speicher zu halten. In den beiden Fenstern werden als Grundlage für die Anzeige die selben Daten verwendet. Verändern sich die Daten so verändert sich auch die Anzeige der beiden Fenster.

Die Eigenschaftsliste funktioniert nun so, daß zu einem beliebigen String, bei Analyse sind das die geladenen Dateien, ein Handle zugeordnet werden kann. Fordert der Benutzer das Programm zum Einladen einer Datei auf, wird zuerst mittels GetProp überprüft, ob zu dem Dateinamen ein Handle in der Liste steht. Ist dies der Fall, so wird die Datei nicht geladen sondern die Daten des Speicherbereichs mit dem Handle verwendet. Ist das Funktionsergebnis Null heißt das, daß der Dateiname noch nicht in der Liste enthalten und die dazugehörige Datei noch nicht geladen war. Die Datei wird dann geladen und die Eigenschaftsliste mit dem neuen Handle und dem Dateinamen erweitert. Die Funktion SetProp ist dafür vorgesehen.

1.2.3. Kommunikation Server und Meßcomputer

Da das Programmpaket Analyse sich in zwei Programmteile untergliedert, die auch auf verschiedenen Rechnern laufen, ist zwangsläufig eine Kommunikation zwischen beiden Teilen notwendig. Vom Transputer aus erfolgt diese Kommunikation über Links und Protokolle. Das sind schnelle serielle Schnittstellen und Formatierungen der übertragenen Daten. Der Host-Rechner bedient sich zum schnellen Datentransfer einer parallelen Busstruktur. Die Verbindung beider Systeme bildet ein Linkadapter, der die serielle Übertragungsform des Transputers in eine parallele für den PC umsetzt und umgekehrt.

1.2.3.1. Stufen der Kommunikation

Die Kommunikation mit dem Meßcomputer ist unter Analyse in zwei Stufen geteilt. Die erste Stufe, die in der Callback Funktion des Rahmenfensters kodiert ist, nimmt den fundamentalen Datenaustausch über den Link Adapter vor. Die zweite Stufe liegt bei den Kindfenstern von Analyse. Diese sind für die Erstellung und Verwaltung der Transferblöcke verantwortlich, die dann vom Rahmenfenster an den Meßcomputer gesendet werden.

Zum Anstoßen der Kommunikation versenden die Kindfenster Nachrichten an das Rahmenfenster. Diese Nachrichten WM_START_TRANSFER sind benutzerdefiniert. Als Parameter der Nachricht wird das Handle des Speicherbereiches übergeben, in dem der zu transferierende Block enthalten ist. Umgekehrt werden Transferblöcke vom Meßcomputer mit der benutzerdefinierten Nachricht WM_TRANSFER_RECEIVED vom Rahmenfenster an die Kindfenster verteilt.

1.2.3.2. Aufbau der Transferblöcke

Die Sprache Occam, in welcher der Transputerteil von Analyse programmiert ist, erlaubt es durch sogenannte Protokolle, verschiedene Daten in unterschiedlichen Formaten auf einem Kanal bzw. Link weiterzugeben. Das Format dieser Daten ist dann mittels eines Bytes, das den eigentlichen Daten vorangeht, zu identifizieren. Zur Übertragung von Daten zwischen dem Server und dem Transputerteil wurde allerdings ein anderer Weg gewählt, der mehr Sicherungsmöglichkeiten zuläßt.

Damit die zu transferierenden Daten entsprechend verwaltet werden können, besitzen sie einen Kopf, anhand dessen Sender und Empfänger identifiziert werden können. Zur Erkennung von Übertragungsfehlern ist eine Prüfsumme vorgesehen.

Die einzelnen Felder haben folgende Bedeutungen und Belegungsmöglichkeiten:

Typ des Transfers: Anhand dieses Wertes kann unterschieden werden, ob es sich bei dem übertragenen Block um Daten oder lediglich um eine Quittung oder Fehlermeldung handelt. Folgende Werte sind möglich:

TRANSFER_COMMAND: Die im Transferblock enthaltenen Daten repräsentieren einen Bearbeitungsschritt für die Bearbeitungsroutine.

TRANSFER_COMMAND_BREAK: Die im Transferblock enthaltenen Daten repräsentieren einen Bearbeitungsschritt für die Bearbeitungsroutine. Analyse wartet nach dem Versenden eines so gekennzeichneten Transferblocks auf einen Transferblock vom Meßcomputer. Auf diese Weise kann verhindert werden, daß Analyse schon neue Daten sendet, bevor eine erwünschte Antwort vom Transputer erfolgte.

TRANSFER_STATUS: Um auch während der Übertragung von Bearbeitungsschritten den Status des Programms auf dem Meßcomputer erfragen zu können, kann mittels eines Befehls der Transputer veranlaßt werden, einen solchen Block zu senden.

TRANSFER_TREATMENT: Die im Transferblock enthaltenen Daten sind für den Bearbeitungspuffer auf dem Meßcomputer vorgesehen.

TRANSFER_MEASURE: Die im Transferblock enthaltenen Daten sind für den Meßdatenpuffer des Analog/Digital Wandlers auf dem Meßcomputer vorgesehen.

TRANSFER_MEASURE: Die im Transferblock enthaltenen Daten sind für den Generatorpuffer des Digital/Analog Wandlers auf dem Meßcomputer vorgesehen.

TRANSFER_CURVE_n: Die im Transferblock enthaltenen Daten sind für ein Kindfenster in Analyse vorgesehen. Die Kurve n wird durch die Daten im Block ersetzt. Zu Beginn der eigentlichen Daten der obigen vier Transferblöcke steht zusätzlich noch eine Struktur zur Charakterisierung der übertragenen Daten.

TRANSFER_MESSAGE: Dieser Block dient zur Übertragung von Meldungen hauptsächlich vom Meßcomputer zu Analyse.

Abbildung 19: Aufbau der Transferblöcke

Abbildung 20: Aufbau der Acknowledge bzw. Error Blöcke

ACKNOWLEDGE_VALUE: Jeder korrekt übertragene Block wird mit einem Acknowledge Block quittiert.

RETRANSMIT_BLOCK: Ist ein Fehler in der Übertragung eines Blockes erkannt worden, wird durch Senden der Wiederholungsaufforderung eine nochmaliger Transfer ausgelöst. Wird auch der wiederholt gesendete Block gestört übertragen, erfolgt eine Fehlermeldung.

ERROR_GENERAL: Dieser Wert signalisiert einen Fehler, der nicht genauer spezifiziert werden kann

ERROR_BUFFER_UNDERFLOW: Ist die im Transferblock angegebene Zahl von Bytes kleiner als die mindestens zu übertragende, so wird diese Fehlermeldung ausgelöst. Die Anzahl der zu transferierenden Byte ist mindestens die Größe des Transferkopfes.

ERROR_BUFFER_OVERFLOW: Bei diesem Fehler übersteigt die Größe des Blocks die Größe des Zielpuffers.

ERROR_ACKNOWLEDGE_EXPECTED: Die abwechselnde Folge von Blöcken und Quittungen wurde unterbrochen, indem zwei Blöcke in Folge gesendet wurden.

ERROR_NEGATIVE_BLOCK_SIZE: Die abwechselnde Folge von Blöcken und Quittungen wurde unterbrochen, indem zwei Quittungen in Folge gesendet wurden.

ERROR_BUFFER_MISALIGNMENT: Es wurde ein Transferblock gesendet, dessen Anzahl an Bytes nicht gerade durch die Elementgröße des Puffers teilbar ist.

Anzahl der Bytes: Dieser Wert gibt einfach die Größe des Transferblockes in Byte an.

Fensterhandle: Das Handle des Fensters, das den Transfer initiert hat, ist hier abgelegt. Dieses Handle dient als eindeutige Zuordnung für Reaktionen vom Meßcomputer auf den Transferblock.

Identifikation: Durch ein fortlaufende Numerierung von Transferblöcken wird eine eindeutige Zuordnung von Block und Quittung bzw. Fehlermeldung möglich.

Prüfsumme: Fehler in der Übertragung können durch Vergleich der Prüfsumme vor und nach der Übertragung erkannt werden.

Bei Datentransfer der Art TRANSFER_TREATMENT, TRANSFER_MEASURE, TRANSFER_GENERATOR und TRANSFER_CURVE_n wird zu Beginn der eigentlichen Daten noch eine Struktur mit übertragen, die die Art der übertragenen Daten genauer spezifiziert.

Abbildung 21: Beschreibung der Transferdaten

Format der Daten: Angabe des Formats, in dem die Daten vorliegen. Bisher sind möglich:

FORMAT_DATA_COMPLEX: Im Transferblock ist ein Feld von komplexen Meßdaten mit abwechselnd Realteil und Imaginärteil.

FORMAT_DATA_SEQUENCE: Im Transferblock sind Meßdaten deren Realteile in der ersten und deren Imaginärteile in der zweiten Hälfte liegen.

FORMAT_DATA_REAL: Die Meßdaten im Puffer sind reell.

FORMAT_SPECTRUM_AMPLITUDE: Im Puffer liegt ein Spektrum mit abwechselnd Amplitude und Phase vor.

FORMAT_SPECTRUM_COMPLEX: Im Puffer liegt ein Spektrum in komplexer Form mit abwechselnd Realteil und Imaginärteil vor.

FORMAT_SPECTRUM_SEQUENCE: Im Puffer liegt ein komplexes Spektrum mit den Realteilen in der ersten und den Imaginärteilen in der zweiten Hälfte vor.

Elementgröße: Größe der Werte in Byte. Liegen zum Beispiel komplexe Meßdaten vor, so bedeutet hier ein Wert 4, daß Realteil und Imaginärteil als IEEE Fließkommazahl mit 32 Bit Länge vorliegen. Ein Wert 8 heißt Fließkommazahl mit 64 Bit. Bei Wandlerdaten ist dieser Wert 2.

Anzahl der Datensätze: Dieser Wert gibt die Anzahl der Datensätze an. Ein Datensatz ist bei komplexen Daten ein Paar aus Realteil und Imaginärteil, bei Spektren im Format FORMAT_SPECTRUM_AMPLITUDE ein Paar aus Amplitude und Phase und bei reellen Meßdaten einfach der Realteil.

Abstand der Datensätze: Bei Meßdaten steht hier der zeitliche Abstand zwischen den einzelnen Datensätzen in Sekunden, bei Spektren steht hier der Abstand der Frequenzlinien in Herz.

1.2.3.3. Auslösung der Kommunikation mit dem Meßcomputer

Alle Aktionen auf dem Meßcomputer werden durch die Bearbeitungsschritte ausgelöst. Diese liegen in einer Art verketteter Liste als Bearbeitungsfolge vor, welche wiederum in einer Folge ein Meßprogramm darstellen. Jedes Fenster von Analyse kann ein eigenes Meßprogramm besitzen. Die Bearbeitungsfolgen können als Einträge im Menü Messung gestartet werden.

Ist ein solcher Menüeintrag selektiert worden, werden alle Bearbeitungsschritte der Bearbeitungsfolge in Transferblöcke verpackt. Die Speicherhandles dieser Blöcke sendet das Kindfenster als Parameter einer WM_START_TRANSFER Nachricht an das Rahmenfenster, das die enthaltenen Daten und Befehle einzeln zum Transputer überträgt.

Abbildung 22: Senden der WM_START_TRANSFER Nachricht an das Rahmenfenster

1.2.3.4. Aufbau des Meßprogramms

Die Steuerung des Meßcomputers TA800, also die eigentliche Aufgabe von Analyse, erfolgt durch Meßprogramme. Diese Meßprogramme können für jedes Kindfenster getrennt erstellt werden und liegen im Speicher in einer Art von verketteten Liste vor.

In der oberste Ebene der Hierarchie des Meßprogramms steht ein Speicherbereich, der zwar dynamisch zu Beginn der Kindfenstererstellung belegt wurde, aber währen der Existenz des Fensters fest mit ihm verbunden ist. Dieser Speicher ist für die Aufnahme von 32 Bearbeitungsfolgen vorgesehen. Mehr Einträge sind nicht sinnvoll, da diese mit ihren Titeln Aufnahme in das Menü Messung finden sollen.

Zu Beginn dieses Speicher steht die Struktur MEASURE_HEADER, die Auskunft über die Anzahl der Bearbeitungsfolgen gibt, also der Strukturen MEASURE_ITEM, sowie den Dateinamen, unter dem das Meßmenü schon einmal gespeichert wurde. In den Strukturen für die Bearbeitungsfolgen MEASURE_ITEM steht der Menütitel und ein Handle auf einen lokalen Speicherbereich, in dem sich die einzelnen Bearbeitungsschritte befinden. Dieses Handle zeigt bei gültigen Einträgen immer auf einen allozierten Speicherbereich, der auch wieder mit einem Kopf COMMAND_HEADER über die Belegung des Speichers Auskunft gibt.

Werden Einträge eingefügt, so verschieben sich Einträge, die nachher folgen sollen einfach nach hinten. Beim Löschen von Einträgen verschieben sich die nachfolgenden nach vorne. Funktionen zur Verwaltung der Einträge sind im Modul MSR.C implementiert und beschrieben und haben alle einen Bezeichner, der MeasureItem enthält.

Abbildung 23: Aufbau des Meßprogramms im Speicher

Der Kopf COMMAND_HEADER, der zu Beginn der Speicherbereiche für die Bearbeitungsschritte steht, informiert darüber, wieviele Einträge vorhanden sind, wieviel Speicher für die Bearbeitungsfolge insgesamt vom System angefordert wurden und wieviel Byte tatsächlich belegt sind. Damit kann beim Einfügen von neuen Schritten erkannt werden, ob der Speicherbereich realloziert, sprich vergrößert werden muß. Dem Header folgen dann die Bearbeitungsschritte, die im folgenden Abschnitt beschrieben werden.

1.2.3.5. Aufbau der Bearbeitungsschritte

Die Aktionen, die auf dem Transputerboard vorgenommen werden sollen, können durch die Bearbeitungsschritte ausgelöst werden. Die Art des Befehls, der Adressat und die Anzahl und Reihenfolge der Parameter kann an der Identifikation des Bearbeitungsschrittes abgelesen werden. Eine Auflistung aller bisher implementierten Befehle kann Tabelle 2 entnommen werden.

Abbildung 24: Aufbau der Bearbeitungsschritte

Für den Aufbau der Liste der Bearbeitungsschritte sind folgende Eigenschaften der Speicherverwaltung von Windows verantwortlich:

Es sind insgesamt nur 8192 Speicherhandles verfügbar. Das heißt man kann nicht für jeden Bearbeitungsschritt einen eigenen Bereich belegen, da man sonnst sehr schnell an die Speichergrenzen stößt. Außerdem legt Windows für jeden Speicherbereich interne Verwaltungsstrukturen an, die dann unnötig Speicher verschwenden würden.

Der belegte Speicher ist verschiebbar. Das bedeutet Windows kann zur ökonomischeren Nutzung des Hauptspeichers die Lage der Blöcke verändern oder sogar auf Festplatte auslagern. Damit verändern sich auch die Zeiger auf diese Bereiche. Verkettete Listen über Zeiger sind somit nicht machbar.

Auf Grund dieser Einschränkungen wird der Speicherbereich für die Bearbeitungsschritte als eine Art von Array verwaltet, in dem die Elemente unterschiedliche Länge haben können. Um zu einem bestimmten Element zu gelangen, muß sich die entsprechende Funktion über die Längenangabe durch die Liste hangeln.

In der Bearbeitungsfolge geht jedem Bearbeitungsschritt eine Variable mit der tatsächlichen Größe des Bearbeitungsschrittes voran. Damit kann bei einigen Befehlen bestimmt werden, wieviele Bytes der eigentlichen Befehlsstruktur folgen. So errechnet sich zum Beispiel bei einem Kontrollelement zur Erzeugung eines Labels die Länge des Bezeichners aus der Anzahl der insgesamt belegten Bytes minus der Größe der Struktur COMMAND_CONTROLS.

Da die Bearbeitungsschritte auch innerhalb eines Typs unterschiedlich lang sein können, muß beim Einfügen eines neuen die notwendige Verschiebung der nachfolgenden Bearbeitungsschritte aus der Größe des Bearbeitungsschrittes errechnet werden, an dessen Stelle die Einfügung erfolgen soll. Der Vorgang ist analog beim Löschen von Einträgen vorzunehmen. Die Funktionen zur Verwaltung der Bearbeitungsschritte sind im Modul MSR.C enthalten und beschrieben. Sie haben alle Bezeichnungen mit CommandItem.

Die Beschreibungen der möglichen Bearbeitungsschritte, deren zugehörige Datenstrukturen und Definitionen der Parameter werden in den folgenden Tabellen gegeben.

Identifikation des Bearbeitungsschrittes

Beschreibung

CMD_TRANSFER_SYNCHRON

Befehl, der einen synchronen Datentransfer auslöst. Das heißt, alle vorhergehenden Bearbeitungsschritte müssen ausgeführt worden sein. Die dazugehörige Befehlsstruktur ist COMMAND_TRANSFER.

CMD_TRANSFER_ASYNCHRON

Befehl, der einen synchronen Datentransfer auslöst. Die dazugehörige Befehlsstruktur ist COMMAND_TRANSFER.

CMD_CONVERT_FORMATS

Befehl, der im Bearbeitungsspeicher Daten in andere Formate umwandelt. Die dazugehörige Befehlsstruktur ist COMMAND_CONVERT_FORMATS.

CMD_WINDOW_PARAMETER

Befehl, der die Parameter für die Fensterfunktion verändert. Die dazugehörige Befehlsstruktur ist COMMAND_WINDOW_PARAMETER

CMD_FILTER_PARAMETER

Befehl, der die Parameter für die Filterfunktion verändert. Die dazugehörige Befehlsstruktur ist COMMAND_FILTER_PARAMETER.

CMD_STANDARD_FUNCTION

Befehl, der im Bearbeitungsspeicher des Transputers Daten nach Standardfunktionen erzeugt. Die dazugehörige Befehlsstruktur ist COMMAND_STANDARD_FUNCTION.

CMD_CONTROLS

Elemente, die zur Ablaufsteuerung des Meßprogramms dienen. Die dazugehörige Befehlsstruktur ist COMMAND_CONTROLS.

CMD_VARIABLES

Befehl zur Manipulation von Variablen. Die dazugehörige Befehlsstruktur ist COMMAND_VARIABLES.

CMD_CALCULATION

Befehl zur Manipulation von Daten. Die dazugehörige Befehlsstruktur ist COMMAND_CALCULATION.

CMD_CONVERTER

Befehl zur Steuerung der Wandler. Die dazugehörige Befehlsstruktur ist COMMAND_CONVERTER.

Tabelle 2: Identifikation der Bearbeitungsschritte

Strukturelement

Beschreibung

WORD wCommand;

Wort, in dem die Kennzeichnung für Transfer CMD_TRANSFER steht.

char cSourceIdentifier;

Gibt die Quelle des Transfers an. Mögliche Werte sind in Tabelle 4 angegeben.

char cDestinationIdentifier;

Gibt das Ziel des Transfers an. Mögliche Werte sind in Tabelle 4 angegeben.

char cSourceCurve;

Hier steht die Nummer der Kurve des Quellfenster.

char cDestinationCurve;

Hier steht die Nummer der Kurve des Zielfenster.

HWND hWndSource;

Hier steht je nach Art der Quelle ein Fensterhandle. Ist die Quelle jedoch kein Fenster sondern ein Speicherbereich auf dem Transputer, ist dieses Feld unbestimmt.

HWND hWndDestination;

Hier steht je nach Art des Ziels ein Fensterhandle. Ist das Ziel jedoch kein Fenster sondern ein Speicherbereich auf dem Transputer, ist dieses Feld unbestimmt.

short int nDestinationFormat;

Dieser Wert bestimmt, ob die zu transferierenden Daten in ihrem Format verändert werden oder mit Offset und Faktor verrechnet werden sollen. Die Formate sind in Tabelle 6 beschrieben.

float flTransferRealFactor;

Faktor, mit dem die Realteile der Daten zu multiplizieren sind.

float flTransferRealOffset;

Offset, mit dem die Realteile der Daten zu beaufschlagen sind.

float flTransferImagFactor;

Faktor, mit dem die Imaginärteile der Daten zu multiplizieren sind.

float flTransferImagOffset;

Offset, mit dem die Imaginärteile der Daten zu beaufschlagen sind.

Tabelle 3: Bearbeitungsschritt COMMAND_TRANSFER

Wert

Beschreibung

TF_TREATMENT

Bearbeitungspuffer auf dem Transputer.

TF_MEASURE

Meßwertepuffer auf dem Transputer.

TF_GENERATOR

Generatorpuffer auf dem Transputer.

TF_ACTIVE_WINDOW_ACTIVE_CURVE

Aktive Kurve des Fensters, das den Befehl zum Transfer sendet.

TF_ACTIVE_WINDOW_CURVE

Kurve des aktiven Fensters. Die Nummer der Kurve steht in cSourceCurve bzw. cDestinaionCurve der Struktur COMMAND_TRANSFER.

TF_WINDOW_ACTIVE_CURVE

Aktive Kurve des Fensters, dessen Handle im Wort der wSourceWord bzw. wDestinationWord der Struktur COMMAND_TRANSFER steht.

TF_WINDOW_CURVE

Kurve des Fensters, dessen Handle im Wort der wSourceWord bzw. wDestinationWord der Struktur COMMAND_TRANSFER steht. Die Nummer der Kurve steht in cSourceCurve bzw. cDestinaionCurve der Struktur COMMAND_TRANSFER.

Tabelle 4: Quelle und Ziel von COMMAND_TRANSFER

Strukturelement

Beschreibung

WORD wCommand;

Wort in dem die Kennzeichnung für Formatkonvertierung steht.

WORD wNewFormat;

Zielformat in das die Daten umgewandelt werden sollen.

Tabelle 5: Bearbeitungsschritt COMMAND_CONVERT_FORMATS

Wert

Beschreibung

FORMAT_CALCULATE_DATA

Ist dieses Bit bei einem der nachfolgenden Formaten gesetzt, so sollen die Daten bei einem Transfer mit einem Faktor und einem Offset verrechnet werden.

FORMAT_SOURCE

Die zu konvertierenden Daten sollen nicht in ein spezielles Format umgewandelt werden.

FORMAT_DATA_COMPLEX

Das Zielformat ist ein Feld von komplexen Meßdaten mit abwechselnd Realteil und Imaginärteil.

FORMAT_DATA_SEQUENCE

Das Zielformat sind Meßdaten deren Realteile in der ersten und deren Imaginärteile in der zweiten Hälfte liegen.

FORMAT_DATA_REAL

Das Zielformat sind reelle Meßdaten.

FORMAT_SPECTRUM_AMPLITUDE

Das Zielformat ist ein Spektrum mit abwechselnd Amplitude und Phase.

FORMAT_SPECTRUM_COMPLEX

Das Zielformat ist ein Spektrum in komplexer Form mit abwechselnd Realteil und Imaginärteil.

FORMAT_SPECTRUM_SEQUENCE

Das Zielformat ist ein komplexes Spektrum mit den Realteilen in der ersten und den Imaginärteilen in der zweiten Hälfte.

FORMAT_CONVERTER

Wandlerdaten von 16 Bit Breite.

Tabelle 6: Zielformate für COMMAND_CONVERT_FORMATS

Strukturelement

Beschreibung

WORD wCommand;

Wort, in dem die Kennzeichnung für Fensterparameter steht.

unsigned char cWindowType;

Gibt die Art des Fensters an.

unsigned char cNumberTreatment;

Gibt an, wie zu verfahren ist, wenn die Anzahl der zu berechnenden Werte keine Potenz von zwei ist.

float flAlpha;

Parameter für manche Fensterfunktionen.

Tabelle 7: COMMAND_WINDOW_PARAMETER

Wert

Beschreibung

WT_RECT

Rechteck Fensterfunktion.

WT_BARTLET

Bartlet Fensterfunktion.

WT_BLACKMAN

Blackman Fensterfunktion.

WT_HAMMING

Hamming Fensterfunktion.

WT_HANNING

Hanning Fensterfunktion.

WT_VON_HANN

Von Hann Fensterfunktion.

WT_RIESZ

Riesz Fensterfunktion.

WT_RIEMANN

Riemann Fensterfunktion.

WT_DE_LA_VALLE

Da La Valle-Poussin Fensterfunktion.

WT_TUCKEY

Tuckey Fensterfunktion.

WT_BOHMAN

Bohman Fensterfunktion.

WT_POISSON

Poisson Fensterfunktion.

WT_HANNING_POISSON

Hanning-Poisson Fensterfunktion.

WT_CAUCHY

Cauchy Fensterfunktion.

WT_GAUSS

Gauss Fensterfunktion.

WT_DOLPH_CHEBYSHEV

Dolph-Tschebyscheff Fensterfunktion.

WT_KAISER_BESSEL

Kaiser-Bessel Fensterfunktion.

WT_BARCILON_TEMES

Barcilon Fensterfunktion.

WT_USER_DEFINED

Benutzerdefinierte Fensterfunktion.

Tabelle 8: Fensterfunktionen von COMMAND_WINDOW_PARAMETER.

Wert

Beschreibung

WP_UNCHANGED_NUMBER

Ist die Anzahl der Datensätze keine Potenz von Zwei diese unverändert übernehmen.

WP_ZERO_PADDING

Ist die Anzahl der Datensätze keine Potenz von Zwei, Anzahl auf nächste Potenz von Zwei aufrunden. Die zusätzlich entstehenden Werte werden mit Null initialisiert.

WP_CUT_NUMBER

Ist die Anzahl der Datensätze keine Potenz von Zwei, Anzahl auf nächstniedrigere Potenz von Zwei abrunden.

Tabelle 9: Anpassung der Anzahl bei COMMAND_WINDOW_PARAMETER.

Strukturelement

Beschreibung

WORD wCommand;

Wort, in dem die Kennzeichnung für Standardfunktion steht.

short int nFunction;

Hier kann die zu verwendende Funktion ausgewählt werden. Verfügbare Funktionen sind in Tabelle 11 aufgelistet.

float flFrequency;

Frequenz der Funktionsberechnung.

float flRatio;

Tastverhältnis der Funktionsberechnung.

float flHighVoltage;

Maximum der Funktionsberechnung.

float flLowVoltage;

Minimum der Funktionsberechnung.

Tabelle 10: Bearbeitungsstruktur COMMAND_STANDARD_FUNCTION

Wert

Beschreibung

SF_SINUS

Es sollen Daten nach einer Sinusfunktion erstellt werden.

SF_RECTANGLE

Es sollen Daten nach einer Rechteckfunktion erstellt werden.

SF_TRIANGLE

Es sollen Daten nach einer Dreieckfunktion erstellt werden.

SF_PULSE

Es sollen Daten nach einer Impulsfunktion erstellt werden.

SF_RAMP

Es sollen Daten nach einer Rampenfunktion erstellt werden.

Tabelle 11: Standardfunktionen von COMMAND_STANDARD_FUNCTION

Strukturelement

Beschreibung

WORD wCommand;

Wort, in dem die Kennzeichnung für Ablaufsteuerung steht.

short int nControlType;

Typ des Kontrollelements. Eine Erklärung der Werte folgt in Tabelle 13.

Tabelle 12: Bearbeitungsschritt COMMAND_CONTROLS

Wert

Beschreibung

CT_LABEL

Erzeugt an der Stelle des Bearbeitungsschrittes in der Folge ein Sprungziel.

CT_JUMP_ALWAYS

Sprung, der immer ausgeführt wird.

CT_JUMP_ON_EXPRESSION

Sprung, der dann ausgeführt wird, wenn der Ausdruck, welcher der Struktur folgt, ungleich Null ist. Der Ausdruck liegt als nullterminierter ASCII-String vor.

Tabelle 13: Kontrollelemente von COMMAND_CONTROLS

Strukturelement

Beschreibung

WORD wCommand;

Wort, in dem die Kennzeichnung für Variable steht.

short int nAction;

Hier steht die Art der Variablenbearbeitung. Tabelle 15 erläutert die verfügbaren Werte.

short int nSourceIdentification;

Identifikation der Quellvariablen oder des Quellwertes.

short int nDestIdentification;

Identifikation der Zielvariablen.

float flValue;

Quellwert.

Tabelle 14: Bearbeitungsschritt COMMAND_VARIABLES

Wert

Beschreibung

VA_CREATE

Erzeugung einer benutzereigenen Variablen. Der Bezeichner steht im Speicher direkt nach der Struktur COMMAND_VARIABLES.

VA_TRANSPUTER_TO_ANALYSE

Übertragung eines Wertes aus einer Systemvariablen in eine benutzereigene Variable.

VA_ANALYSE_TO_TRANSPUTER

Übertragung eines Wertes aus einer benutzereigenen Variablen in eine Systemvariable.

VA_TRANSPUTER_TO_TRANSPUTER

Übertragung eines Wertes aus einer Systemvariablen in eine Systemvariable.

VA_VALUE_TO_TRANSPUTER

Übertragung des Quellwertes in eine Systemvariable.

VA_VALUE_TO_ANALYSE

Übertragung des Quellwertes in eine benutzereigene Variable.

Tabelle 15: Steuerungen von COMMAND_VARIABLES

Wert

Beschreibung

VAR_SIZE_OF_TRE_BUFFER
VAR_SIZE_OF_MEA_BUFFER
VAR_SIZE_OF_GEN_BUFFER

Hier steht die Größe des Speicherbereiches in Byte. Das ist die Größe des Kopfes mit den Systemvariablen zur Beschreibung des Speicherbereiches und die Größe des durch die vorhandenen Daten belegten Speichers.

VAR_NUMBER_OF_TRE_VALUES
VAR_NUMBER_OF_MEA_VALUES
VAR_NUMBER_OF_GEN_VALUES

Hier steht die Anzahl der Werte. Bei komplexen Daten und Spektren ist dies die doppelte Anzahl der Datensätze, ansonsten ist dies die Anzahl der Datensätze.

VAR_NUMBER_OF_TRE_DATA_SETS
VAR_NUMBER_OF_MEA_DATA_SETS
VAR_NUMBER_OF_GEN_DATA_SETS

Hierin wird angegeben, wieviele Datensätze in diesem Speicherbereich vorhanden sind. Bei komplexen Daten sind das die Paare aus Realteil und Imaginärteil, bei reellen Daten und Daten für die Wandler einfach die Anzahl der Werte.

VAR_SIZE_OF_TRE_DATA_SET
VAR_SIZE_OF_MEA_DATA_SET
VAR_SIZE_OF_GEN_DATA_SET

Dieser Wert gibt an, wie groß die Elemente der Datensätze sind. Gleitkommazahlen doppelter Genauigkeit nach IEEE haben eine Größe von 8 Byte, Fließkommazahlen einfacher Genauigkeit 4 Byte und Wandlerdaten 2 Byte.

VAR_TRE_DISTANCE
VAR_MEA_DISTANCE
VAR_GEN_DISTANCE

In dieser Variable wird der Abstand zwischen zwei Datensätzen festgehalten. Bei Daten im Zeitbereich ist das Eins geteilt durch die Abtastfrequenz, also die Zeit zwischen zwei Abtastwerten in Sekunden. Bei Daten im Frequenzbereich ist das der Abstand zwischen zwei Spektrallinien in Herz.

VAR_FORMAT_OF_TRE_DATA
VAR_FORMAT_OF_MEA_DATA
VAR_FORMAT_OF_GEN_DATA

Das Format, in dem die Daten in dem entsprechenden Puffer vorliegen, kann dieser Variable entnommen werden. Die zu verwendenden Formate sind der Tabelle 6 zu entnehmen. Die Formate FORMAT_SOURCE und FORMAT_CALCULATE_DATA sind hier nicht zu verwenden.

VAR_RANGE

In dieser Variablen kann der Meßbereich des Analog/Digital-Wandlers festgelegt werden. Es sind die Bereiche 100 V, 5 V und 0.5 V vorhanden.

VAR_RMS

In dieser Variablen steht nach Durchführung einer Berechnung des Effektivwertes von Meßdaten im Bearbeitungsspeicher der errechnete Wert.

Tabelle 16: Variablen von COMMAND_VARIABLES

Strukturelement

Beschreibung

WORD wCommand;

Wort, in dem die Kennzeichnung für Berechnung steht.

unsigned char nCalculation;

Auswahl der durchzuführenden Berechnung. Die zu verwendenden Werte stehen in Tabelle 18.

unsigned char nNumberTreatment;

Vorgehensweise, wenn die Anzahl der zu verrechnenden Datensätze keine Potenz von Zwei ist. Mögliche Werte sind in Tabelle 9 angegeben.

Tabelle 17: Bearbeitungsschritt COMMAND_CALCULATION

Wert

Beschreibung

CA_FFT

Durchführung einer schnellen Fourier-Transformation.

CA_RMS

Durchführung einer Effektivwertberechnung.

Tabelle 18: Berechnungen von COMMAND_CALCULATION

Strukturelement

Beschreibung

WORD wCommand;

Wort, in dem die Kennzeichnung für Wandlersteuerung steht.

short int nConverterCommand;

Wert, der angibt, welche Wandlersteuerung durchzuführen ist. Tabelle 20 zeigt alle zulässigen Werte.

unsigned long int lSampleFrequency;

Abtast- bzw. Samplefrequenz, mit der der Wandler arbeiten soll. Dieses Feld wird nur bei den Werten CO_DA_SAMPLE_PARAMETERS und CO_AD_SAMPLE_PARAMETERS in nConverterCommand berücksichtigt.

unsigned long int lNumberOfSampleValues;

Anzahl der zu wandelnden Werte. Dieses Feld wird nur bei den Werten CO_DA_SAMPLE_PARAMETERS und CO_AD_SAMPLE_PARAMETERS in nConverterCommand berücksichtigt.

Tabelle 19: Bearbeitungsschritt COMMAND_CONVERTER

Wert

Beschreibung

CO_DA_SAMPLE_PARAMETERS

Der Bearbeitungsschritt dient zum Einstellen der Samplefrequenz und Anzahl der zu wandelnden Werte des Digital/Analog-Wandlers.

CO_AD_SAMPLE_PARAMETERS

Der Bearbeitungsschritt dient zum Einstellen der Abtastfrequenz und Anzahl der zu wandelnden Werte des Digital/Analog-Wandlers.

CO_DA_START_SAMPLING

Dieses Kommando löst den Wandelvorgang des Digital/Analog-Wandlers aus. Anhalten ist durch CO_DA_STOP_SAMPLING zu erreichen.

CO_DA_STOP_SAMPLING

Stoppt den Wandlungsvorgang des Digital/Analog-Wandlers.

CO_DA_SINGLE_SAMPLING

Einmaliger Wandlungsprozeß des Digital/Analog-Wandlers bis die Anzahl der Werte ausgegeben ist.

CO_AD_START_SAMPLING

Dieses Kommando löst den Wandelvorgang des Analog/Digital-Wandlers aus. Anhalten ist durch CO_AD_STOP_SAMPLING zu erreichen.

CO_AD_STOP_SAMPLING

Stoppt den Wandlungsvorgang des Analog/Digital-Wandlers.

CO_AD_SINGLE_SAMPLING

Einmaliger Wandlungsprozeß des Analog/Digital-Wandlers bis die Anzahl der Werte eingelesen ist.

CO_START_SAMPLING

Dieses Kommando löst den Wandelvorgang des Analog/Digital-Wandlers und Digital/Analog-Wandlers aus. Anhalten ist durch CO_STOP_SAMPLING zu erreichen.

CO_STOP_SAMPLING

Stoppt den Wandlungsvorgang des Analog/Digital-Wandlers und des Digital/Analog-Wandlers .

CO_SINGLE_SAMPLING

Einmaliger Wandlungsprozeß des Analog/Digital-Wandlers und Digital/Analog-Wandlers bis die Anzahl der Werte eingelesen bzw. ausgegeben ist.

Tabelle 20: Steuerungsmöglichkeiten COMMAND_CONVERTER

1.2.3.6. Kommunikation mit dem Meßcomputer

Der Datenaustausch mit dem Transputer wird durch das Rahmenfenster bewerkstelligt. Dazu werden zwei Zeitgeber erzeugt, die in bestimmten Zeitabständen WM_TIMER Nachrichten an die Callback Funktion des Fensters senden. Bei Empfang einer solchen Nachricht vom Empfangs Zeitgeber überprüft die Callback Funktion des Rahmenfensters, ob Daten vom Transputer gesendet werden. Dazu wird in einer Polling Schleife geprüft, ob der Port des Linkadapters mit dem Empfangsstatusregister Sendewillen anzeigt. Bei Zustandekommen einer Übertragung wird nur noch diese Pollingschleife ausgeführt, die die Daten vom Empfangsport übernimmt. Signalisiert der Meßcomputer eine gewisse Anzahl von Schleifendurchläufen keine Bereitschaft, wartet die Callback Funktion auf die nächste Timer Nachricht und ist somit wieder in die normale Nachrichtenschlange von Windows eingereiht.

Abbildung 25: Auswertung der WM_TIMER Nachricht für Empfang

Die Übertragung der Daten wird durch Funktionen des Moduls LNK.ASM vorgenommen. in ihnen ist die Abfrage der Statusregister für die Sende- und Empfangsbereitschaft und der Schleifenzähler enthalten. Die Programmierung in Assembler dürfte für schnellstmögliche Abarbeitung sorgen.

Ist die Anzahl der zu empfangenden Byte erreicht, wird das Handle des Speicherbereichs, in den die Daten eingetragen wurden, an des Fenster in einer WM_TRANSFER_RECEIVED Nachricht an das Kindfenster gesendet, für das die Daten bestimmt waren. Dieses nimmt dann die Auswertung vor.

1.2.4. Bildschirmausgabe

Für eine der wichtigsten Aufgaben von Analyse, der Bildschirmausgabe, stellt Windows sehr umfangreiche Funktionen zur Verfügung, was mit der Grund dafür war, das Programm unter dieser Oberfläche zu erstellen.

1.2.4.1. Grafikausgabe unter Windows

Die Grafikausgabe des Graphics Device Interface (GDI) von Windows benutzt zwei unterschiedliche Koordinatensysteme. Im ersten, dem logischen Koordinatensystem, finden die Zeichenoperationen des Programms statt. Das zweite Koordinatensystem, das sogenannte Viewport Koordinatensystem, gibt die Rastereinheiten des Ausgabegerätes, in diesem Falle des Bildschirms, wieder. Beide Systeme erstrecken sich im Integerbereich von -32768 bis 32767. Zur Abbildung des logischen Koordinatensystems auf das Viewport Koordinatensystem stellt das GDI verschiedene Abbildungsmodi (Mapping Modes) zur Verfügung. Diese sind verantwortlich für die Umrechnung von Punkten zwischen den Systemen. Für die Abbildung können aus den Koordinatensystemen Abschnitte definiert werden, auf die sich die Umrechnung bezieht.

Abbildung 26: Grafikausgabe unter Windows

Der in Analyse verwendete Mapping Mode MM_ANISOTROPIC bildet den gewählten Ausschnitt aus dem logischen Koordinatensystem genau auf den Ausschnitt des Viewport Koordinatensystem ab. Dabei kann die dargestellte Grafik entsprechend des aktuellen Viewport Ausschnitts unterschiedliche Seitenverhältnisse aufweisen. Welcher Ausschnitt von beiden Koordinatensystemen zu verwenden ist, wird Windows durch die Funktionen SetWindowExt und SetWindowOrg bzw. SetViewportExt und SetViewportOrg mitgeteilt. Den zu verwendenden Abbildungsmodus stellt man mittels der Funktion SetMapMode ein.

Zum Zeichnen der Kurvenzüge, der Gitterlinien und der Beschriftungstexte bietet Windows eigene Funktionen, die sich alle auf einen Display-Kontext beziehen. Das ist eine Ansammlung von Einstellungen, die zu jedem Fenster vor Beginn des Zeichnens erfragt werden muß. Über das ermittelte Handle dazu kann man die Abbildungsform eines Fensters den eigenen Erfordernissen entsprechend verändern. So beziehen sich die oben genannten Funktionen zum Verändern des Abbildungsbereiches immer auf einen Display-Kontext. Außerdem kann festgelegt werden, mit welchen Farben und Mustern Linien gezeichnet oder Flächen gefüllt werden sollen. Dazu dienen sogenannte Pinsel und Stifte, die man mittels CreatePen und CreateBrush nach den Erfordernissen erzeugen und in den Display-Kontext mittels SelectObject wählen kann. Alle Ausgaben erfolgen dann mit diesen Objekten.

1.2.4.2. Parameter der Grafikausgabe

Die Parameter für die Grafikausgabe sind in den lokalen Speicherbereichen enthalten, der Handles im Extra-Wort WW_PAINT_STRUCT_HANDLE der Kindfenster gespeichert sind. Zu den Parametern zählen die Ausmaße Ausschnitts aus dem logischen Koordinatensystem, in dem die gesamte Darstellung stattfindet, die Ausmaße des Zoombereichs und die effektive Fläche des Ausgabebereiches des Fensters ohne den Beschriftungsrand. Mittels dieser Bereiche wird die Abbildungsumrechnung durch die oben beschrieben Funktionen eingestellt. Diese Bereiche werden immer dann neu bemessen, wenn die Größe eines Kindfensters verändert wird oder wenn im Fenster gezoomt wird.

Weitere Parameter der Grafik sind die Grenzen der Darstellungsbereiche, die Abstände der Gitterlinien und die Skalierungen der Achsen. Sie dienen zur Umrechnung der Daten in das Vektor-Array, das in Abschnitt 1.2.4.3. erläutert wird. Die Pinsel, Stifte und Fonts, mit denen die Linien der Kurvenzüge und die Gitterlinien gezeichnet werden, sind ebenfalls Teil der Parameter.

1.2.4.3. Das Vector Array

Die in den Fenstern darzustellenden Daten liegen entweder als float oder double Zahlen vor. Die Koordinatensysteme von Windows erstrecken sich aber nur über den Integerbereich. Um einen schnellen Bildschirmaufbau zu gewährleisten, werden die Daten nur einmal, entsprechend der gewählten Darstellung, in logische Koordinaten umgerechnet, und danach erfolgt die Anzeige nur noch mit diesen Werten. Diese Werte befinden sich im Vector Array. Das Vector Array liegt in einem globalen Speicherbereich, dessen Handle in den Extra-Worten WW_DAT_VOCTOR_HANDLE_N bzw. WW_SPC_AMPLITUDE_HANDLE_N und WW_SPC_PHASE_HANDLE_N festgehalten wird. N gibt eine Zahl von Eins bis Acht entsprechend des Kurvenzuges an. Zu Beginn des Speicherbereiches steht in einer DWORD Variable die Anzahl der darzustellenden Punkte. Die Punkte liegen in der Struktur POINT vor, in dem die x Koordinate und die y Koordinate das darzustellenden Punktes enthalten sind.

Umgerechnet werden die Daten anhand der Grenzen der Darstellungsbereiche, die vom Benutzer in einem Dialog zur Bestimmung der Kurvenparameter eingegeben werden können. Anhand dieser Grenzen werden die Daten so in das Vektor-Array umgerechnet, daß die Grenzen der Darstellungsbereiche mit den Grenzen das Ausschnitts aus dem logischen Koordinatensystem zusammenfallen. Das heißt, liegt ein Darstellungsbereich von 0 bis 10 kHz und 0 bis 5 V vor, so werden die Daten so umgerechnet, daß diese Grenzen im logischen Koordinatensystem 0 bis 32767 und 0 bis 32767 entsprechen. Ein Datensatz 5 kHz und 2,5 V läge dann im Vektor-Array bei 16384 in X-Richtung und 16384 in Y-Richtung.

Mit den gleichen Grenzen der Darstellungsbereiche und den Gitterlinienabständen werden auch die Punkte-Arrays für die Gitterlinien errechnet. Diese liegen in einem globalen Speicherbereich, dessen Handle im Extra-Wort WW_GRID_HANDLE jedes Kindfensters gespeichert wird. Im Unterschied zum Vector Array wird jedoch nur jeweils die Koordinate einer Richtung gespeichert, da sich die Gitterlinien ja bis zu den Rändern ausdehnen. Zu Beginn des Speicherbereichs steht eine Struktur, aus der die Anzahl der horizontalen und vertikalen sowie der horizontalen und vertikalen feinen Gitterlinien und deren Offset im Speicher entnommen werden kann.

Für die Beschriftung der Achsen dient ein globaler Speicherbereich mit einem Array von Strings. Dieses Array enthält genauso viele Einträge wie das Gitterlinien-Array für die groben Gitterlinien, da jede dieser Linien einen Beschriftungstext haben kann. Der Text der jeweiligen Beschriftung wird aus den Darstellungsgrenzen und dem Abstand der Gitterlinien bestimmt.

Die Funktionen zur Berechnung der verschiedenen Arrays, die im Modul CAL.C enthalten sind, beginnen alle mit Calculate.

1.2.4.3.1. Umrechnung der Daten

Die Einträge im Vector Array werden so aus den darzustellenden Daten berechnet, daß nur Punkte zur Anzeige kommen, die innerhalb des gewählten Ausschnitts liegen. Linien, die eine der Grenzen überschreiten, werden nur bis zu dieser Grenze der Darstellung berücksichtigt. Auf diese Weise werden Punkte, die sowieso nicht dargestellt würden, nicht mit in das Vektor-Array aufgenommen und beanspruchen keine Zeit für das Zeichnen. Außerdem kann es bei Daten vorkommen, daß sie durch den gewählten Abbildungsbereich bei der Umrechnung in den Integerbereich des logischen Koordinatensystems durch einen Überlauf des Integerbereichs doch wieder dargestellt würden, obwohl sie außerhalb liegen.

Abbildung 27: Einfügen der Punkte in das Vector Array

Die obige Illustration zeigt, welche Punkte in das Vector Array aufgenommen werden. Bei Strecken, die ganz innerhalb der Grenzen liegen, wird nur der linke Punkt aufgenommen. Schneidet die Strecke mindestens eine Grenze, so ist die Lage der Schnittpunkte ausschlaggebend für Eintragung in das Vector Array. Mit einem Kreis versehene Schnittpunkte stellen berücksichtigte Einträge dar.