Protokoll zum Projekttreffen vom 11.7.2000 Michael Mueller 1. Anmerkungen zum letzten Protokoll... --------------------------------------- keine Anmerkungen der Anwesenden 2. Kurzbeitraege zu den kurzfristig vergebenen Aufgaben ------------------------------------------------------- - Formatierung der RTK-Files (*.c, *.cpp) mit astyle - keine Aktivitaeten - Verfuegbarmachung des Testzaehlers in der .ide (Kay Schuetzler) - [B. Buss] Testzaehler steht zur Verfuegung - .ide-Einstellungen (Bernhard Buss) - Einstellungen wurden vorgenommen - Nur Verzeichnisse und Pfade muessen noch von den Beteiligten individuell an die jeweilige Umgebung angepasst werden - CVS unter NT benutzen (Stephan Luetzkendorf) - Ist eingerichtet, ide-Files sind als Binaerfiles zu behandeln - Fuer eine Dll-Versionsverwaltung muesste das Repository entsprechend konfiguriert werden - Soweit bleibt alles beim Alten: CVS auf Eiche, nur das man beim auschecken jetzt automatisch die Zielrechnerkonventionen erhaelt - Dokumentation unter Werkzeuge | CVS; fuer die spezielle Behandlung von Binaerfiles wird eine entsprechende Dokumentation geliefert - Anmerkungen zu Borland 4.5 vs. 5.02 (Derrick Hepp/Sebastian Freund) - keine Neuigkeiten - Einziges Problem: Ressourcen-Files sind nur aufwaertskompatibel, d.h. Ressource-Files sollten mit der Version 4.5 erstellt werden - Bibliotheken werden von der Version 5.02 uebernommen - Vorteil der Version 4.5: 16-Bit Debugging moeglich - Hinweis: Zeichenlaenge fuer Dateinamen bei der Version 4.5 auf 8 Zeichen beschraenkt - Hinweise hierzu werden unter News veroeffentlicht - Help-Files mittels Visuall C++-Tool? (Derrick Hepp/Sebastian Freund) - Help-Workshop unter Visual C++ nicht ergiebig - Problem: Editieren der im RTF-Format vorliegenden Textdateien - Abhilfe schafft hier ein Shareware-Tool 'Help-Scribble', das eine Entwicklungsumgebung fuer Help-Projekte zur Verfuegung stellt - Das Programm arbeitet gut und schnell; Es erzeugt als Ausgabe ein gut formatiertes RTF-File, welches dann entsprechend in das Borland-Projekt eingebunden werden muss - [U. Sacklowski] * Tool wird im Umfang einer Lizenz bestellt und auf einem Rechner eingerichtet; Kosten 150 DM / Lizenz * Bis dahin kann jeder mit der Shareware seine eigenen Help-Files erstellen - Eine Anleitung, wie man mit diesem Tool arbeitet, wird geliefert 3. Berichterstattung zu den eigenen Arbeiten -------------------------------------------- - Projektportierung 16 -> 32 Bit (Michael Mueller) - Vorstellung der Projektplanung 1) Portierung des SW-Systems von Win16 nach Win32 2) Wechsel von Borland nach Visual 3) Durchgaengige OO-Implementierung des SW-Systems unter Nutzung der MFC - Aufwandsabschaetzung: praktische Erfahrungen aus Portierungsprojekten zeigen unterschiedliche Zeitrahmen, wobei versch. Zeitfaktoren die Abschaetzung des Zeitaufwands nur ungenuegend zulassen - Portierungsplan - Welche Vorgehensweise? Bottom-Up oder Top-Down; Gegenueberstellung und Wertung der beiden Strategien; Entscheidung, beide Strategien einzusetzen, mit Schwerpunkt Top-Down in der Anfangsphase - Top-Down: Ausgehend vom portierten Hauptmodul des SW-Systems werden schrittweise die noch nicht portierten Programmteile eingebunden - Problem: Sicherstellung der Rueckwaertskompatibilitaet: [U. Sacklowski] Win16-Version wird spaeter nicht mehr gebraucht, bis die Win32-Version fehlerfrei laueft, muss ein 2-Versionen-Handling stattfinden - Problem: 2-Versionen-Handling - Entscheidungsproblem Quellenbearbeitung: - 16-Bit spezifischer Code wird einfach ausdokumentiert und durch 32-Bit-Variante ersetzt (Vorteil: geringer Aufwand; Nachteil: 16-Bit-Version muss separat gepflegt werden) - Aenderungen werden durch bedingte Compilierung eingefuegt (Vorteil: 16-Bit-Version wird nicht separat verwaltet; Nachteil: hoher Aufwand: Makros, Schale mit Hilfsfunktionen) - Problem: Aktualisierung der 32-Bit-Version nach Aenderungen der aktuellen 16-Bit-Version durch Projektmitglied: * [S. Luetzkendorf] CVS-Subpfad "Portierung" denkbar, indem die aktuelle 32-Bit-Version gepflegt wird; CVS bietet darueberhinaus dann Moeglichkeiten, die so entstandenen Versionen (16 <-> 32) abzugleichen * [U. Sacklowski] Projekt fuer gewisse Zeit sperren, in dieser Zeit das System nach Win32 portieren und dann die so entstandene 32-Bit-Version als aktuelle Version pflegen; Danach werden nur noch Fehlerkorrekturen in die 16-Bit-Version uebernommen, d.h. es wuerde doch eine 16-Bit-Version in minimalster Weise weitergepflegt werden - Motorentest (Stephan Luetzkendorf) - Problem: Kommunikation zwischen motor.dll und Hardware anzapfen - Funktionen Put/Get in motor.cpp fuer diesen Zweck umgeschrieben - Grundsaetzlich drei Verhaltensweisen: 1) Motor.dll schickt Befehle direkt an Hardware 2) Protokollierung der Hardware-Kommunikation in einem Log-File (Motor hat insgesamt ca. 80 Befehle) 3) Kommunikation wird zu einem Simulator umgeleitet, wobei die Hardware voellig abgekoppelt wird - zu Schritt 1) praktisch realisiert - zu Schritt 2) Mit den Tools Lex und Yacc einen Parser realisiert, der die Kommandos der motor.dll parst. Jetzt muss aus diesen Teilen noch ein entsprechendes Protokoll generiert werden. - zu Schritt 3) Hier muesste ein Testtreiber zwischengeschaltet arbeiten [K. Bothe] Anfrage bzgl. Dokumentation der Befehle und dem Verstaendnis hierfuer [S. Luetzkendorf]Verstaendnis ist kein Problem; 25 Motorbefehle bisher verarbeitet [U. Sacklowski]Anfrage bzgl. des Zeitverhaltens bei Motoren, da bei Detektor Zeitprobleme eine Rolle spielen [S. Luetzkendorf]Moeglichkeit der Sollwertberechnung, womit ein Bewegungszyklus berechenbar ist. Zeitverhalten ist fuer den Motor nicht relevant Einschub Diskussion bzgl. des Angebots das URCA-Tool auf Borland aufzusetzen (siehe E-Mail vom 09 Jul 2000 "zur Information") ------------------------------------------------------------------------------ Fragen: Sollen wir auf das Angebot eingehen. Wie sieht es insbesondere mit dem Borland-Profiler aus, der als altenative Voraussetzung genannt wird? Oder aber, wir lassen die Ausgabe-Liste der Funktionen, die von der Detektoren-Gruppe ueber ihre Tools erzeugt wird, als Eingabe des URCA-Tools verarbeiten? Oder kommen wir mit den bisher geschaffenen Tools aus? [A. Paschold, R. Harder, J. Picard] * Notwendigkeit fuer dieses Tool besteht grundsaetzlich nicht * Struktur der Counter ist schon eindeutig genug * Fuer die spaetere Erstellung der Wrapperklassen ist es sicherlich eine sinnvolle Unterstuetzung -> Ja, das Angebot sollte wahrgenommen werden Fortsetzung 3. Berichterstattung zu den eigenen Arbeiten -------------------------------------------- - Umgebungssimulator (Kay Schuetzler) - Verweis auf Link-Info im Projektprotokoll vom 4.7.00 'http://www.informatik.hu-berlin.de/~schuetzl/umgebungssimulator/' - Vorstellung der Web-Seite - Problem: Wartung des Programms [K. Bothe] Zielgruppe klaeren [K. Schuetzler] Einarbeitung in das Programm sollte nicht dazu fuehren extra zur Physik reisen zu muessen - [U. Sacklowski] Anfrage bzgl. des Intensitaetsverteilungsmodells bei Topographie; Bei Topographie steht der Detektor fest und bei der Diffraktometrie wandert der Detektor [K. Schuetzler] Wo welche Intesitaeten auftreten, muss man noch herausfinden (anhand physikalischer Vorgaenge simulieren) - [Bothe] Folgerung: Teil der statischen Umgebung fuer 0-dim. Detektor abgeschlossen; Fuer 1-dim. muessen noch Vermessungen folgen - [B. Buss] Messungen sind kein ausreichender Hintergrund fuer das dynamische Verhalten des Systems [K. Schuetzler] Man hat Erfahrungswerte aus der Regelung und eine repraesentative Probe und es ist bekannt, was passiert, wenn sie sich erwaermt [U. Sacklowski] Dynamik bezieht sich nur auf die Probe, nicht auf die Anlage (Probe erwaermt sich) 4. Probleme des Projektmanagements (K. Bothe) --> soweit Zeit verbleibt --------------------------------------------- wegen Zeitmangel verschoben 5. jede(r) Beteiligte: kurze Wortmeldung zu aktuellen Arbeiten -------------------------------------------------------------- ebenfalls wegen Zeitmangel entfallen 6. Sonstiges ------------ - Festlegung von Konsultationsterminen mit den Gruppen - B. Buss, J. Ullrich, S. Bernd: Di 18.7. 13.00 - S. Luetzkendorf: Di 18.7. 10.00 - A. Schad, S. Luehnsdorf: Di 18.7. 14.00 - A. Paschold, R. Harder, J. Picard: Fr 21.7. 10.00