Der Punkt Allgemeines ging sehr schnell in den Punkt Planung über, deshalb alles gleich unter Planung.
Zunächst kam ein Nachtrag von Patrick zu seinen Client-Server-Klassen. Die seien jetzt für Unix und Windows fertig. Es würde einen Server und viele Clients geben, die über diesen Werte austauschen könnten. Diese Werte würden über String-Namen identifiziert.
Es wurde nun allgemein überlegt, ob die CAN-Bus-Kommunkikation besser über einen Client oder über den Server selber gehen soll. Es tauchte die Idee auf, daß es am besten wäre, den Server damit zu beauftragen. Die Server-Klasse sollte dabei mit der PCUI-Klasse (PC-User-Interface, die PC-Seite des CAN-Busses) kombiniert werden. Diese Klasse, also der Server sollte möglichst absturzsicher laufen. Es wurde kurz angedacht, abgestüerzte Clienst vielleicht durch einen Sammelprozeß wieder zu starten. Fest stand, daß nur ein Prozeß auf den CAN-Bus zugreifen darf. Thomas machte nochmal den Vorschlag, daß es vielleicht doch besser nicht Aufgabe des Servers sein sollte. Dies scheint jedoch erstmal der Weg zu sein der gegangen werden wird.
Es folgte eine Diskussion zwischen BKB und Patrick, die von Mißverständnissen angefüllt war. Es ging darum, ob auf unterschiedlichen Plattformen nicht ein voöllig anderer Überbau nötig sei, was die Fensteroberfläche angeht. Man kam schließlich aber irgendwann zu der Übereinkunft, dß man ja zunächst einmal einen simplen Server auch als Konsolenfenster laufen lassen kann. Außerdem sollte die SimRobot Schnittstelle möglichst bald auf das Server-Client-Konzept umgestellt werden, damit SimRobot später möglichst einfach ersetzt werden kann.
BKB sah nun ein, daß es doch wichtig scheint, weiter über die Architektur zu reden und begab sich an die Tafel, um eine Zeichnung zu entwickeln, deren Entergebnis weiter unten zu sehen ist.
Es wurde nun ein eine Zeit über Oberflächen-Verhalten diskutiert. Z.B. wollte BKB wissen, ob man unter Windows 95 noch was mit einem Fenster anfangen kann, daß gerade beschäftigt ist, also ob man dort noch Befehle eingeben kann, und ähnliches. Zum Schluß kam die Sprache mal wieder auf Tcl-TK zur Fenstergestaltung unter verschiedenen Oberflächen, daß von BKB nach seinen Erfahrungen sehr empfohlen und geschätzt wird. Thomas und Andreas wiesen aber auch darauf hin, daß unter Visual C++ mit dem Application Wizard, einem Tool zur Programmentwicklung unter Windows, auch sehr kompfortabel Windowsprogramme erstellt werden können. Auch sei die Einarbeitungszeit in Tcl-TK nicht zu vernachlässigen. Auch gab es Meinungsverschiedenheiten zwischen BKB und Patrick, ob Tcl-TK Programme sich nun ohne weiteres auch für Windows übersetzten lassen. BKB meinte ja, Patrick meinte, er hätte was anderes gehört. Das konnte noch nicht geklärt werden. BKB meinte schließlich noch, daß auf jeden Fall ja unter Windows auf dem PC die entgültige Benutzerschnittstelle sein würde, und daß wir außerdem natürlich nie fertig würden.
Im folgenden ging es um die Ein- und Ausgaben während der Fahrt und hinterher. Thomas meinte, daß große Ausgaben während der Fahrt sowieso nichts bringen würden, da es zu hektisch wäre, sie zu verfolgen. Es wäre also angebracht, alle Ausgaben in eine Datei zu schreiben, so daß man sie nachträglich anzeigen lassen kann. Während der Fahrt könnte man eventuell über SimRobot anzeigen lassen, wo man ist. Im Moment kann SimRobot allerdings noch nicht so gut Eingaben wie Steuerkommandos verarbeiten.
Noch ein paar Gedanken zur Schnittstelle wurden geäußert: Sie sollte die Daten sammeln und speichern. Entweder alles, was sich ändert, oder immer nur dann, wenn etwas angefordert wird. Es könne aber auch sinnvoll sein, sich den internen Zustand von Prozeßen zu merken (wie ermittelte Position), auch wenn diese keine Daten in der Schnittstelle sind. Weiterhin sollte in der Schnittstelle vermerkt werden, ob das System sich im Simulationszustand oder in einer realen Fahrt befindet. Dann könnten Ein- und Ausgaben z.B. automatisch zum CAN-Bus oder SimRobot geleitet werden. Output, der die Anzeige von Position usw. betrifft, geht natürlich immer an SimRobot. Das ganze soll zum nächsten Mal aber noch weitergedacht werden.
(Abbildung:
)
Der Vortrag von Jan wurde irgendwie auf das nächste mal verschoben, da auch kaum Zeit mehr blieb.