Diagnosetool für Delphi Software ?

[sisa2002]

Hallo,
ich bin gerade dabei ein Programm zu entwickeln in dem man mit mehreren Timern auf insgesamt 6 verschiedene Serielle Schnittstellen zugreift. Hierbei habe ich nun das Problem das meine Applikation instabil läuft, was ich auf eventuelle Timingprobleme an den zeitkritischen Schnittstellen zurückführe. Ich arbeite mit der Delphi Version 5 auf einem XP Proffesional Betriebssystem.
Meine Frage an euch wäre jetzt. Ist jemandem ein Tool bekannt mit dem man überwachen kann wieveiel Zeit die Software in welcher Prozedure bzw. Funktion benötigt ?

:( :( :(

Danke !

[WS1976]

Hallo,

ich habe zwar kein Diagnosetool aber sehr viel Erfahrung mit seriellen Schnittstellen in Delphi.
Welche Komponeneten benutzt du?
Arbeitest du im Pollingbetrieb oder rein Eventgestützt?

Vielleicht kann ich dir helfen!

[mkinzler]

Z.B.
http://www.prodelphi.de/

[Bernhard Geyer]

AQTime

Wird aber vermutlich nichts für deine Instabilitäten bringen, da hier vermutlich entweder ein Implementierungs oder ein Designfehler vorliegt.

[Der_Unwissende]

Zitat:

Zitat von sisa2002

... Serielle Schnittstellen zugreift ... zeitkritischen Schnittstellen zurückführe

Hi,
mit was für Schnittstellen arbeitest Du denn? Und welche Komponente verwendest Du?
Falls Du RS-232 meinst, die Kommunikation über diese Schnittstelle ist asynchron (gepuffert), also alles andere als zeitkritisch.
Wie Bernhard Geyer schon sagte, wahrscheinlicher ist, dass es an einem Fehler im Code liegt. Hier wäre es dann wichtig zu wissen, was Du im Moment (wie) machst.

Gruß Der Unwissende

[sisa2002]

Hallo,

ich spreche hier 3 RS 232 Schnittstellen und 3 RS422 Schnittstellen an. Ich nutzte dafür das Tool Async Pro 3. Hierbei sind jedoch die RS 422 Schnittstellen besonders kritisch, da ich diese alle 20 ms abfragen muss ! Ich denke ja auch das es ein Designfehler ist, hatte aber gehofft es gibt ein Tool was mir die Fehlersuche in der Echtzeitanwendung erleichtern könnte.

Vielleicht hat ja doch noch jemand eine Idee !

Danke !

[CCRDude]

Also Timer zu benutzen war schon ein Problem, als ich vor etlichen Jahren noch eien Meßwerterfassung geschrieben habe, in der es nur um relativ genaue Sekunden ging. Selbst da würde ich schon empfehlen, jede Schnittstellenafrage in einem eigenen Thread (bei der kurzen Zeit wahrscheinlich mit erhöhter Thread-Priority) laufen zu lassen und per Event zurückmelden. Wenn dann noch die Weiterverarbeitung passend ist, sollte nichts mehr verlorengehen. Ist natürlich ein wenig Umgestricke, um von Timern auf Threads umzustellen, aber TTimer ist (imho) wirklich nur was für relativ ungenaue Prozesse ;)

[Bernhard Geyer]

Das Problem was du vermutlich hast ist das du deine Schnittstellen fein säuerlich Programmtechnisch auseinander halten mußt und auch nocht verhindern mußt das dies Eventtechnisch "zuschlagen" wenn du es nicht gebrauchen kann.

Folgende Ideen:

1, Jede Schnittstelle wird in einer Instanz einer eigenen Schnittstellen-Kompo gekapselt. Diese handelt das auf der Schnittstelle vorhanden Protokoll und gibt an übergeordnete Schnittstellen nur fertige Pakete ab

2, Die Paketzustellung erfolgt in einer Manager-Klasse welche auch die Eventtechnisch entkopplung Schnittstellen <-> Hauptprogramm erledigt. Hier brauchst du ein eigens Protokoll um die Schnittstellen auseinander zu halten.

3, Evtl. werden jede einzelne Schnittstelle oder auch die Managerklasse in Threads verlagert und die Kommunikation erfolgt über Windows-Messages und/oder Threadsichere Listenklassen (TThreadList) zum Hauptprogramm.

4, Eine Manager-Klasse welche jetzt die Verteilung an die zuständigen GUI-Fomulare/Komponenten durchführt.