summaryrefslogtreecommitdiff
path: root/app/gs.process/1.02/doc/gs-Prozess-2
diff options
context:
space:
mode:
Diffstat (limited to 'app/gs.process/1.02/doc/gs-Prozess-2')
-rw-r--r--app/gs.process/1.02/doc/gs-Prozess-2255
1 files changed, 255 insertions, 0 deletions
diff --git a/app/gs.process/1.02/doc/gs-Prozess-2 b/app/gs.process/1.02/doc/gs-Prozess-2
new file mode 100644
index 0000000..376143e
--- /dev/null
+++ b/app/gs.process/1.02/doc/gs-Prozess-2
@@ -0,0 +1,255 @@
+limit (11.0)##pagelength (16.5)##block#
+#start (2.0,0.0)#
+#page (1)#
+#headodd#
+#center#gs-Prozess#right#%
+
+#end#
+#headeven#
+%#center#gs-Prozess
+
+#end#
+#center#1
+
+#on("b")#2  Allgemeines zur Prozeßdatenverarbeitung#off("b")#
+
+In diesem Kapitel erfahren Sie, warum unter EUMEL/ELAN die Prozeßdatenver­
+arbeitung bisher kaum Berücksichtigung gefunden hat und welche Probleme zu
+überwinden waren. Es wird aufgezeigt, warum unter EUMEL/ELAN nicht jedes Inter­
+facesystem verwendet werden kann; außerdem werden die Gründe für die Wahl eines
+bestimmten Interfacesystems genannt.
+
+
+#on("b")#2.1  Welche Hardware-Lösungen gibt es zur Zeit ?#off("b")#
+
+Wie schon in Kapitel 1 erwähnt, ist zum Messen, Steuern und Regeln mit dem
+Computer ein Hardware-Interface notwendig, über das der "Kontakt zur Außenwelt"
+hergestellt wird.
+
+
+#on("b")#
+ Computer <--------> Interface <--------> Modell
+#off("b")#
+
+
+Interfaces (zu deutsch etwas mißverständlich: Schnittstellen) verbinden innerhalb
+eines Systems Teilsysteme und einzelne Funktionseinheiten miteinander. Dabei
+werden z.B. #on("b")#Hardware-Schnittstellen#off("b")# (Um diese geht es vornehmlich in diesem
+Kapitel), #on("b")#Hardware-Software-Schnittstellen#off("b")# (Nach Festlegung, welche Funktionen
+eines Rechnersystems von der Hardware und welche von der Software übernommen
+werden, erfolgt hierüber die Verknüpfung der beiden Komponenten), #on("b")#Software-
+Schnittstellen#off("b")# (zwischen Programmoduln), #on("b")#Mensch-Maschine-Schnittstellen#off("b")#
+(Benutzerschnittstellen - wie z.B. #on("b")#gs-DIALOG#off("b")#) unterschieden.
+
+Wenn wir im folgenden von 'Interface' reden, ist damit immer eine 'Hardware-
+Schnittstelle' gemeint.
+
+Über ein solches Interface (eine Hardware-Schnittstelle) können an den Computer
+externe Geräte/Modelle angeschlossen werden, die vom Computer aus gesteuert
+werden. Dabei setzt das Interface die vergleichsweise schwachen Signale des
+Computers in Ströme und Spannungen um, mit denen z.B. eine Lampe oder ein
+Motor betrieben werden kann. Umgekehrt senden externe Geräte/Modelle über das
+Interface Signale an den Computer, die von ihm ausgewertet werden. So müssen z.B.
+Widerstandsveränderungen eines Temperaturfühlers oder die Stellung eines Schalters
+in eine vom Computer erfaßbare Form umgewandelt werden.
+
+Inzwischen bieten verschiedene Hersteller (FISCHER, LEGO, AKTRONIK, PHYWE,
+etc.) und Lehrmittelverlage (METZLER, CVK, etc.) eine Reihe von Lösungen an.
+Leider sind die meisten Lösungen auf ganz spezielle Computertypen zugeschnitten
+und somit nicht an anderen Computertypen verwendbar - außerdem unterscheiden
+sich die verschiedenen Lösungen z.T. ganz erheblich im Leistungsumfang.
+
+Einzellösungen, insbesondere an den gängigen Homecomputern, gibt es schon seit
+langem. Voraussetzung ist zumeist, daß der Computer über einen speziellen
+Anschluß ('Userport' oder 'Joystick-Eingang') verfügt. Oder es werden Platinen
+geliefert, die in spezielle Steckplätze (Slots) einzustecken sind, wo sie vom Computer
+aus angesprochen werden können.
+
+Bei all diesen Lösungen konnten wir 'EUMELaner' nur neidvoll zuschauen. Der
+Vorteil, den wir sonst so zu schätzen wissen, ein einheitliches Betriebssystem auf ganz
+unterschiedlicher Hardware zur Verfügung zu haben, wird hier zum Nachteil. Eine
+einheitliche Lösung schien zu Anfang völlig aussichtslos zu sein.
+
+
+#on("b")#2.2  Die besonderen Probleme unter EUMEL#off("b")#
+
+Das Betriebssystem EUMEL gestattet es nicht, beliebig auf Hardwarekomponenten des
+Rechners zuzugreifen - und das aus gutem Grund, denn sonst wäre ein reibungsloser
+Multi-User-Betrieb nicht gewährleistet. Man kann aber den Zugriff auf neue Hard­
+warekomponenten im EUMEL-System etablieren. Allerdings ist das etwas aufwendiger
+als in anderen Systemen, denn das sogenannte 'Shard', die 'Software-Hardware-
+Schnittstelle', muß angepaßt werden.
+
+Unsere ersten "Gehversuche" mit der Prozeßdatenverarbeitung unter EUMEL haben
+so angefangen. Es ist aber leicht einzusehen, daß dieser Weg nicht sinnvoll ist. Denn
+dann müßten alle EUMEL-Shards (es gibt ja für jeden Rechnertyp mindestens eines)
+entsprechend geändert werden, ggf. müßten für verschiedene Lösungen verschiedene
+Versionen entwickelt werden - eine Aufgabe, die niemand bereit wäre zu überneh­
+men.
+
+
+#on("b")#2.3  Die Wahl des Interface-Systems#off("b")#
+
+Unser Ziel war klar: Wir wollten ein gängiges, käuflich zu erwerbendes Hardware-
+Interface möglichst universell an Computern verschiedener Hersteller unter dem
+Betriebssystem EUMEL ansprechen können.
+
+Nach Sichtung der angebotenen Systeme kamen nur drei in die engere Wahl: das
+LEGO-Interface, das FISCHER-Technik-Interface und das AKTRONIK-Interface (Soft­
+ware-kompatibel dazu ist das PHYWE-Interface).
+
+Bei der Auswahl hielten wir es für sinnvoll, die Empfehlung des Landesinstituts für
+Schule und Weiterbildung in Soest zu berücksichtigen, in der folgende Anforderungen
+an Interfaces formuliert sind:
+
+ - 8 digitale Eingänge
+ - 8 digitale Ausgänge
+ - optional: analoge Ein- und Ausgabe.
+
+Allen gestellten Anforderungen wird nur das AKTRONIK-Interface gerecht. Das System
+ist modular aufgebaut, je nach Anforderungen kann mit verschiedenen Steckkarten
+gearbeitet werden. Es gibt eine "Kompaktlösung", bei der die wichtigsten Funktionen
+bereitgestellt werden (8 digitale Eingänge, 8 digitale Ausgänge, 2 analoge Eingänge).
+Darüber hinaus kann auch noch mit dem sog. 'Modul-Bus' gearbeitet werden, bei
+dem gleichzeitig mehrere Steckkarten angesprochen werden können. Mit ent­
+sprechender Steckkarte ist auch die analoge Ausgabe möglich.
+
+Die beiden anderen Interfaces erfüllen die oben genannten Anforderungen nicht: Das
+LEGO-Interface verfügt über nur 6 digitale Ausgänge und 2 digitale Eingänge; analoge
+Ein- und Ausgabe ist gar nicht möglich.
+
+Das FISCHER-Technik-Inteface verfügt über 8 digitale Ausgänge und 8 digitale Ein­
+gänge. Das Interface verfügt auch über einen analogen Eingang - allerdings nicht
+über einen Analog-Digital-Wandler-Baustein! Das bedeutet, daß der angeschlossene
+Rechner die Auswertung der eingehenden Daten übernehmen muß - ein zeit­
+kritischer Prozeß, der in einem Multi-User-System nicht garantiert werden kann. Die
+analoge Ausgabe ist grundsätzlich nicht möglich, das System ist in sich abgeschlossen
+und kann sich ändernden Anforderungen ebensowenig angepaßt werden wie das
+LEGO-Interface.
+
+
+Wir entschieden uns also dafür, die weitere Entwicklung auf der Basis des
+AKTRONIK-Interfaces zu betreiben. Es galt jedoch noch, dieses Interface mit dem
+Computer zu verbinden - und das möglichst universell: möglichst unabhängig von der
+verwendeten Computerhardware.
+
+Dieses Ziel ist nur dann zu erreichen, wenn man die 'Standardschittstellen' des
+Computers berücksichtigt, die unter EUMEL problemlos ansprechbar sind: die
+parallelen (Centronics) und seriellen (V24) Schnittstellen. Diese 'Standardschnitt­
+stellen' sind zwar nicht für den direkten Anschluß der Modelle/Interfaces geeignet,
+über einen "Adapter" aber ist ein Anschluß möglich.
+
+Die Entscheidung fiel schnell gegen eine Verwendung der parallelen (Centronics)
+Schnittstelle. Die meisten Computer verfügen nur über eine dieser Schnittstellen, die
+zumeist auch schon durch den Drucker belegt ist. Außerdem handelt es sich dabei in
+der Regel um eine unidirektionale Schnittstelle - d.h. die Daten können vom
+Computer zum Endgerät (z.B. Drucker) gelangen, nicht aber vom Endgerät zum
+Computer. Somit wären zwar Steuerungsvorgänge, nicht aber Meß- und Regelungs­
+vorgänge über die Schnittstelle möglich.
+
+Einige Hersteller nutzen die Datenleitungen, über die z.B. der Drucker dem Rechner
+mitteilt, daß der interne Speicher voll bzw. das Papier zuende ist. Über diese Leitung
+werden Daten seriell übertragen und vom Rechner ausgewertet. Unter EUMEL
+scheidet diese Lösung aber aus, denn um hier eine sichere Auswertung zu gewähr­
+leisten, müßten Maschinenspracheprogramme eingebunden werden; das ist aber
+unter EUMEL nicht möglich.
+
+Damit war festgelegt, daß die weitere Entwicklung auf der Basis des AKTRONIK-Inter­
+faces über die serielle Schnittstelle erfolgen sollte. Wie schon erwähnt, ist das Inter­
+face auf keinen Fall direkt an die serielle Schnittstelle anschließbar. Wie der Name
+schon sagt, werden die Daten bei einer seriellen Schnittstelle seriell übertragen - um
+Prozeßdatenverarbeitung zu betreiben, müssen die Daten aber parallel vorliegen.
+
+Notwendig ist also ein "Adapter", der einen Seriell-Parallel-/Parallel-Seriell-Wandler
+beinhaltet, so daß die Verbindung zwischen Computer und Interface hergestellt
+werden kann.
+
+Inzwischen sind uns hier zwei (käuflich zu erwerbende) Lösungen bekannt - der
+"RS232-Adapter" der Firma AKTRONIK und das "MUFI" (Multifunktionales Interface)
+der Firma BICOS:
+
+Das MUFI ist sicherlich der universeller verwendbare "Adapter" (leider aber auch die
+kostspieligere Lösung). Einerseits kann es ebenso wie der "RS232-Adapter" an eine
+separate serielle Schnittstelle angeschlossen werden, andererseits verfügt es über
+einen zweiten - den eigentlich interessanten Betriebsmodus: Es kann nämlich auch
+in den Terminalkanal eingebaut werden.
+
+Die Idee, die dahintersteckt, ist folgende: Das MUFI verfügt (neben der eigentlich
+wichtigen bidirektionalen parallelen Schnittstelle) über einen (seriellen) Eingang und
+einen (seriellen) Ausgang. So kann das MUFI einfach in eine Leitung zwischen
+Computer und Terminal eingebaut werden. In ausgeschaltetem Zustand hat es
+keinen Einfluß auf den Datenaustausch zwischen Rechner und Terminal - als ob es
+gar nicht vorhanden wäre. In eingeschaltetem Zustand dagegen "horcht es den
+Datenfluß zwischen Rechner und Terminal ab". Auf eine vereinbarte Parole
+(Zeichenkombination) hin, "weiß es", daß die folgenden Daten nicht für das
+Terminal, sondern eben für sich bestimmt sind. Diese, und nur diese Daten werden
+aus dem Datenstrom vom MUFI "herausgefischt" und intern sachgerecht weiterver­
+arbeitet. Alle anderen Daten werden unbeeinflußt an das Terminal weitergeleitet,
+damit ja nicht der reibungslose Betrieb gestört wird. Natürlich ist das MUFI ebenso in
+der Lage, die gerade extern anliegenden Daten zu ermitteln und in den Datenstrom
+zum Computer "einzuschleusen".
+
+Um diese Aufgaben bewältigen zu können, wurde das MUFI mit einem eigenen,
+schnellen Mikroprozessor ausgestattet, der in der Lage ist, den Datenfluß zu
+bewältigen. Zudem wurde versucht, das MUFI mit soviel Intelligenz (Firmware)
+auszustatten, daß alle zeitkritischen Prozesse bei der Ansteuerung des Interface-
+Systems vom MUFI selbst erledigt und die Daten vom MUFI so aufbereitet werden,
+daß sie möglichst einfach weitergegeben und verarbeitet werden können.
+
+Durch die Beschränkung der Baud-Rate auf maximal 19200 ist die Verarbeitungs­
+geschwindigkeit allerdings auch beschränkt. Die rechnerisch maximale Ausgabetakt­
+rate von 320 Hz bei 19200 Baud und 160 Hz bei 9600 Baud wird von #on("b")#gs-Prozess#off("b")# auf
+einem 80386-Rechner im Alleinbetrieb tatsächlich erreicht. Natürlich bedeuten
+mehrere gleichzeitig betriebene MUFIs an einem Rechner Geschwindigkeitseinbußen.
+Ebenso sinkt die Ausgabetaktrate bei Prozessoren mit geringerem Durchsatz (8088:
+maximal 120 Hz). Für die Anwendungen in der Schule sind diese Geschwindigkeiten
+aber hinreichend.
+
+Die Vorteile des MUFI für diejenigen, die EUMEL im Multi-User-Betrieb nutzen, liegen
+dennoch klar auf der Hand:
+
+ - Es werden keine weiteren seriellen Schnittstellen benötigt. (Die vorhandenen
+ sind sowieso schon weitgehend belegt. Gegebenenfalls würden zusätzliche
+ Kosten verursacht.)
+
+ - Es sind keine weiteren Kabelverlegungen zwischen Rechner und Arbeitsplatz
+ notwendig, trotzdem befindet sich das MUFI direkt am Bildschirmarbeits­
+ platz.
+
+ - Das beim Anschluß an eine separate Schnittstelle notwendige, zeitauf­
+ wendige Ansteuern des Interface-Kanals entfällt.
+
+
+Arbeiten Sie an einem Einzelplatz-System (z.B. IBM-kompatibler Rechner nur mit
+Monitor) so ist ein Betrieb des MUFIs im Terminal-Kanal nicht möglich. Hier bleibt
+nur der Betrieb des Interface-Systems an einer separaten seriellen Schnittstelle.
+Sinnvoll ist aber auch ein solcher Betrieb, wenn (zunächst) nur die Hardware für
+einen Arbeitsplatz zur Verfügung steht. Das Interface kann dann nämlich von meh­
+reren Tasks abwechselnd angesprochen werden.
+
+Beim Anschluß an eine separate serielle Schnittstelle sind die Leistungen des MUFIs
+und des RS232-Adapters gleichwertig. Da das abwechselnde Ansprechen einer
+seriellen Schnittstelle und der Tastatur/des Monitors unter EUMEL relativ zeitauf­
+wendig ist, sind hier keine hohe Ausgabegeschwindigkeiten zu erwarten: bei einem
+8088-Rechner ca. 40 Hz, bei Prozessoren mit höherem Durchsatz eben entsprechend
+mehr. Dennoch ist das für die meisten Anwendungen in der Schule schnell genug.
+
+Für Spezialanwendungen ist auch die direkte Ansprache der Schnittstelle möglich.
+Hierbei sind Ausgabetaktraten von 960 Hz bei 19200 Baud bzw. 480 Hz bei 9600
+Baud möglich. Für die schulische Praxis (in der Sekundarstufe I) ist diese "direkte
+Ansprache" aber ungeeignet, da weitergehende Programmierkenntnisse erforderlich
+sind. Zudem kann bei Programmierfehlern "die Task am Kanal hängenbleiben".
+Genaueres dazu sehen Sie bitte im Kapitel 'Hinweise für den Systembetreuer/
+Programmierer'.
+
+Die Hardware-Konstellation stellt sich im Überblick also folgendermaßen dar:
+#on("b")#
+
+ Computer <---> Adapter <---> Interface <---> Modell
+
+ (mit se- ('MUFI' (AKTRONIK)
+ rieller oder
+ Schnitt- 'RS232-
+ stelle) Adapter')
+#off("b")#
+