summaryrefslogtreecommitdiff
path: root/app/gs.process/1.02/doc/gs-Prozess-2
blob: 376143ef049ff41409dea5882fd0d44dc68b4286 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
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")#