"Befehle" sequentiell verarbeiten

[moelski]

Moin !

Ok, ich fange in einem neuen Fred nochmal an, denn ich merke dass mich das "Warten auf ein Flag" nicht wirklich weiter bringt. ( http://www.delphipraxis.net/internal...ct.php?t=99083 )

Vielleicht kommt ja auf diesem Wege eine ganz andere Lösung zum Vorschein, die mir eher weiterhilft.

Ich erkläre mal das Problem:
Wir haben da ein Gerät X. Dieses Gerät wird über eine Schnittstelle angesprochen. Nun muss man mit dem Gerät aber jeweils mehrere "Frage - Antwortspielchen" machen, bis man alle gewünschten Informationen hat.
BsP: Ich muss z.B. zum Auslesen von bestimmten Werten erst Hex 11 an das Gerät senden, dann Hex 21 und danach noch Hex 12. Also Antwort erhalte ich immer eine Zeichenkette. Jeder vorherige Befehl muss erst abgearbeitet sein, damit ich den nächsten abschicken kann.
In meiner bisherigen Lösung hat mich das halt veranlasst, einfach auf den Zustand eines Flags zu warten. Ganz glücklich war ich damit nicht und wie man aus dem "alten" Fred erkennen kann, wirft das auch eine Menge Probleme auf.

Die Frage wäre nun also, wie kann man mit möglichst einfachen Mitteln erreichen, dass ich sequentiell eine Folge von Befehlen abschicken kann und dazwischen immer die Antwort abgreife?

Meine jetzige Idee wäre folgende:
Ich schreibe eine Prozedur, die den ersten Befehl an das Gerät schickt. Diese Procedur ist allgemein ausgelegt und wir nennen sie mal SendeAnforderung.
Wenn das Gerät dann was sendet, schlägt ja die Empfangsroutine zu. Hier würde ich dann nach dem Auswerten der Daten die Prozedur SendeAnforderung erneut starten und zwar mit dem nächsten Befehl.

Probleme die sich hieraus ergeben:
Da ich eine unterschiedliche Anzahl von Befehlen senden muss (je nach Anforderung) müsst is irgend ein Array oder sowas geben, wo dirn steht, was noch abgearbeitet werden muss. Und evtl. auch was schon abgearbeitet ist.

Aber vielleicht hat einer von euch für diese Geschichte auch noch ne viel bessere Idee ?!

Greetz Dominik

[mbamler]

Du könntest doch vielleicht EINE Funktion bauen, die beides macht:
- Das Zeichen zum Gerät schicken UND anschliessend gleich
- auf den Antwortstring warten

sowas wie:

Delphi-Quellcode:

function SendAndReceive(zeichen: char): string;
begin
  Send(zeichen);
  result := ReceiveAnswerString;
end

und das rufst du beliebig oft auf
(bis z.B. der Antwortstring leer ist oder du in ein TimeOut läufst)

Gruß
Matthias

[moelski]

Moin !

Ne das geht so leider nicht.
Weil Senden und Empfangen an 2 Stellen abgehandelt werden.

Greetz

[Muetze1]

Meine Idee dazu:

- ein Buffer der immer die zu senden Befehle in der Reihenfolge enthalten
- In der Senderoutine wird immer der erste Befehl gesendet aus dem Buffer
- in der Empfangsroutine wird die Antwort empfangen - auf welchen Befehl das die Antwort ist, sieht man am ersten Befehl im Buffer. Manchmal hängen ja auch Antwortlängen vom Befehl ab, daher ist dies damit handelbar. Wenn die Antwort vollständig empfangen wurde, dann die Antwort vermerken, im Buffer den ersten Befehl entfernen und die Senderoutine einmalig aufrufen.

[Der_Unwissende]

Hi,
sorry, vielleicht übersehe ich irgendwas, aber ist doch die gleiche Frage wie im "alten" Thread? Da gab es aber schon einige (imho) gute Hinweise, wie du es angehen kannst/solltest.

Ehrlich gesagt finde ich es etwas unhöflich, dass du hier nur auf die dortigen Beiträge verweist, eine kurze Zusammenfassung was genau das Problem (hier aktuell in dem Thread) ist, ist doch um einiges netter. So müssen sich Leute die dir helfen wollen erst die Mühe machen dort alle Beiträge zu lesen und erfahren nur so, um was für eine Kommunikation es sich überhaupt handelt. Was noch völlig unklar ist (oder ich habe es übersehen), wann / wodurch wird das Flag gesetzt?

Ich gehe mal davon aus, dass es immer noch um die Kommunikation per RS232 geht. Da stellt sich dann schon die Frage, was für eine Komponente verwendest du zur Kommunikation?
Ich empfehle dir an dieser Stelle einfach mal die TComport (gibt's bei Sourceforge) Komponente, diese bietet dir recht komfortabel alles was du (wahrscheinlich) benötigst und kann ein Ereignis auslösen, wenn etwas empfangen wird. Genau dieses Ereignis sollte bei dir ja zum Auslösen bzw. setzen des Flags führen.

An sich hast du auch schon eine gute Methode gefunden, das DP Delay (sollte sich unter dem Namen oder ähnlich in der Codelib finden lassen). Der Ansatz beruht auf der WaitForMultipleObjects-Funktion. Diese solltest du dir einfach mal näher anschauen. Sie legt einen Prozess schlafen, bis ein bestimmtes Ereignis signalisiert wird. Dabei gibt es hier die Möglichkeit, dass verschiedene Ereignisse das "Aufwachen" ausgelöst haben können. Einerseits natürlich ein Timeout, andererseits Fensternachrichten (verschieben, schließen,...) und zu guter Letzt kannst du auch ein Array von Handle auf Signale übergeben. Da das Delay wirklich immer eine feste Zeit warten soll, wird hier natürlich absichtlich auf das Timeout gewartet. Das ist aber nur ein spezieller Fall, wie man die Methode verwenden kann. Schau dir einfach mal dazu die Hilfe an. Da findest du dann, dass (und wie) die Funktion zurückgibt, welches Signal ausgelöst wurde. Du musst also im Prinzip nicht mehr machen, als ein eigenes (globales) Signal verwenden, dass du immer zurücksetzt, bevor du einen Befehl verschickst und mit dem Eintreffen der Daten über RS232 (wie gesagt eigenes Event bei der TComPort-Komponente) setzt du dieses Signal. In der Methode, in der du den Befehl sendest wartest du dann mittels MsgWaitForMultipleObjects und muss nur noch unterscheiden, ob ein Timeout, dein Signal oder etwas anderes zum Verlassen der Methode führt und entsprechend handeln.

Wie du die Befehle serialisiert absetzt ist dann sicherlich trivial.

[ADD nach roten Kästen]
Das Senden und Empfangen würde ich an deiner Stelle wirklich eher in eine Methode packen, da hier eine Beziehung zwischen gesendetem Befehl und empfangener Antwort besteht. Um hier mal auf der Idee von Muetze1 aufzubauen, du kannst so leicht mit einem Sperrobjekt (z.B. ein Mutex) das erste Element der Liste entfernen und lokal speichern. Damit könntest dann theoretisch auch parallel die Liste abarbeiten, wenn du mehr als eine (gleichartige) Schnittstelle bedienst. Ist für Ladegeräte wohl eher nicht nötig, aber es kann ja mal andere Aufgabenfelder mit gleicher Idee geben
[/ADD

Gruß Der Unwissende

[chaosben]

Total OffTopic, aber es muss sein:

Zitat von moelski:

... in einem neuen Fred nochmal ..
..aus dem "alten" Fred erkennen kann ...

Das Ding heißt im normalerweise Thread.
Natürlich kann man auch Thema oder auch Diskussion sagen.

[thkerkmann]

Hi,

wie wäre es denn mit folgendem Schema:

Delphi-Quellcode:

...
var
  iStep: integer;

procedure TForm1.Create(Sender:tObject);
begin
   ...
  iStep := 1;
  SendeAnfrage;
  ...
end;

procedure TForm1.SendeAnfrage;
begin
  case iStep of
    1: Sende(Frage1);
    2: Sende(Frage2);
    3: Sende(Frage3);
  end;
end;

procedure TForm1.AntwortErhalten (const s:string);
begin
  case iStep of
    1: Verarbeite1 (s); // spezielle Verarbeitung je nach Anfrage
    2: Verarbeite2 (s);
    3: Verarbeite3 (s);
  end;
  inc(iStep);
  if iStep>3 then
    iStep := 1;
  SendeAnfrage;
end;

Das ist nur Pseude-Code, aber es zeigt die Vorgehensweise.

Gruss

Thomas

@chaosben: Fred find ich aber auch lustig

[moelski]

Moin !

@thkerkmann: Genau das ist auch mein neuer Ansatz. Und er funktioniert gar prächtig.
Auch die CPU Last ist auf wenige % gesunken, was aber eher an den Berechnungen danachliegt.

@Der_Unwissende:

Zitat:

sorry, vielleicht übersehe ich irgendwas, aber ist doch die gleiche Frage wie im "alten" Thread? Da gab es aber schon einige (imho) gute Hinweise, wie du es angehen kannst/solltest.

Sicher gab es da gute Hinweise. Aber einen Thread zu implementieren hätte ich so schnell nicht hinbekommen. Und die CPU Last wäre auch geblieben. Die anderen Vorschläge waren auch gut (danke an dieser Stelle noch mal). Aber alles was mit Warten zu tun hatte, bedingt auch das der Rest der Anwendung nicht mehr richtig flüssig läuft. Zumindest war das bei meinen ganzen Versuchen so.

Meine jetzige Lösung hat da kein Problem mehr. Alles rennt wie gewohnt und die CPU Last ist niedrig.

Sorry, wenn ich mit den 2 Beiträgen für Misstimmung gesorgt habe. War nicht meine Absicht!

So, wie gesagt, ich habe eine Lösung. Werde euch dann auch heuer nimmer damit belästigen.

Ich bedanke mich bei allen für die Rat- und Vorschläge und wünsche allen noch frohe Weihnachten und happy gliding

Greetz Dominik

[alzaimar]

Nur mal so: Das entspricht dem Ansatz mit einem DEA, denn Nichts anderes ist die Idee von thkerkmann.