Delphi-PRAXiS

Delphi-PRAXiS (https://www.delphipraxis.net/forum.php)
-   Sonstige Fragen zu Delphi (https://www.delphipraxis.net/19-sonstige-fragen-zu-delphi/)
-   -   Delphi Asynchrone Kommunikation mit vielen Benutzern (https://www.delphipraxis.net/77050-asynchrone-kommunikation-mit-vielen-benutzern.html)

hirnstroem 14. Sep 2006 07:26


Asynchrone Kommunikation mit vielen Benutzern
 
'loha Folks,

ich arbeite zur Zeit an einem kleinen Projekt, bei welchem über ein Webinterface Geräte, welche an einem CAN-Bus angeschlossen sind, manipuliert werden. Kommuniziert wird über einen CAN-Dongle. Delphi intern wird aber alles über einen virtuellen COM-Port (USB) abgehandelt. Nun ist es so, das die Kommunikation asynchron ist, was mir einiges Kopfzerbrechen bereitet.

Da ich so etwas noch nie gemacht habe, würde ich gerne ein Paar Punkte theoretisch abgehandelt haben, bevor ich alles verbaue.

Um mit der Seriellen Schnittstelle (EIA-232) zu kommunizieren, wird die ComPort Library benutzt.

Die Probleme sind folgende:

- Da mehrere Benutzer auf das Webinterface zugreiffen können und somit imstande sind Geräte zu manipulieren (Fenster o. Türen öffnen und schliessen, Zutrittsberechtigungen vergeben u.v.m.), müssen die nach dem senden ankommenden Antworten identifizierbar sein. Dies habe ich auf der Hardware so gelöst, dass jeweils einfach die Daten in der Antwort (ein Paar Zahlen) eine Inkrementation der gesendeten Daten darstellen. Nun weiss ich nicht wie ich die Daten am besten dem jeweiligen Benutzer wieder anzeigen kann. Klar ist, dass ich alles was ankommt (OnRxChar) in einen Buffer schieben muss. Eigentlich müsste ich jetzt nur wissen, wie nach dem absetzen der Daten auf den Com Port, auf die Antwort gewartet werden kann.

Hierzu ein Beispiel (Relais öffnen / schliessen):

Delphi-Quellcode:
procedure Tfrm_Manipulation.SetRelay(Sender: TObject; State: String);
var
  Str: String;
  i, test: Integer;
begin
  if IWServerController.ComPort.Connected = False then
  begin
    SetCANSettings(Sender);
  end;
  Msg.ID := HexToInt('FF');
  Msg.DLC := HexToInt('8');
  Msg.Data[1] := HexToInt('1');
  Msg.Data[2] := HexToInt(State);
  Msg.Data[3] := HexToInt('0');
  Msg.Data[4] := HexToInt('0');
  Msg.Data[5] := HexToInt('0');
  Msg.Data[6] := HexToInt('0');
  Msg.Data[7] := HexToInt('0');
  Msg.Data[8] := HexToInt('0');
  Str := 'T' + IntToHex(Msg.ID and $1fffffff,8);
  Str := Str + IntToHex(Msg.DLC and $f,1);
  for i := 1 to Msg.DLC do
  begin
    Str := Str + IntToHex(Msg.Data[i] and $FF,2);
  end;
  Str := Str + #13;
  IWServerController.ComPort.WriteStr(Str);
end;
Im Prinzip wäre mir also mit hinweise, wie die auf eine Antwort vom Com Port gewartet werden kann, geholfen.

Grüsse
hirnstroem

Der_Unwissende 14. Sep 2006 08:40

Re: Asynchrone Kommunikation mit vielen Benutzern
 
Hi,
im Prinzip hast du doch schon ein Konzept. Du musst jede Antwort eindeutig identifizieren können. Ich weiß nicht genau, wie gut du die Antwort Manipulieren kannst, aber du sagtest du hast hier schon etwas eingestellt, gehe ich davon aus, dass dies kein Problem für dich darstellt.
Schickst du eine Nachricht ab, braucht sie eine eindeutige ID. Hier bietet sich natürlich der Sender an, denn dieser möchte ja auch die Antwort. Es gibt verschiedene Dinge, die an einem Rechner einzigartig sein sollten (MAC Adresse oder HD-ID oder oder oder). Nimm dir hier eine solche ID und steck die in die Nachricht rein. Die Antwort muss ebenfalls eine solche ID enthalten.
Dann geht es nur noch darum, dass deine Nachrichten eine feste Form haben. Am besten verwendest du hier immer ein Start- und ein Endzeichen (eines, dass nicht zufällig auch mal Teil der Nachricht sein sollte). Da die Kommunikation gepuffert läuft, kannst du so sicherstellen, dass du weißt ob du gerade den Teil einer Nachricht oder etwas komplettes empfangen hast.
Ja, wenn deine Nachrichten die Form SID#NACHRICHTE haben, mit S = Startsymbol, E = Endsymbol, # = Optionales Trennzeichen, die ID kann auch eine feste Länge o.Ä. haben, dann kannst du leicht die Nachricht einem Sender zuordnen.

Sendet jetzt also ein Rechner sein Kommando, versieht er es mit seiner eigenen ID. Beim Senden setzt du ein Flag, dass du nun auf eine Antwort wartest.
Kommen Daten an (onRxChar), dann werden die nur betrachtet, wenn das Flag gesetzt ist. Wartet man gerade nicht auf eine Antwort, werden die Daten wohl nicht für einen selbst sein. Natürlich kannst du statt einem Flag auch den Funktionszeiger entweder auf eine Funktion oder nil setzen.
Wartest du auf eine Antwort, werden die Daten die ankommen eingelesen und durch Start und Endzeichen in einzelne Nachrichten zerlegt. Enthält eine Nachricht die eigene ID, ist dies die Antwort der Komponente.
Damit kannst du beliebig weiter arbeiten. Natürlich kann man auch jedem Empfänger eine Eindeutige ID zuweisen. Diese sollte nicht als einzigstes in der Antwort stehen. Eine Tür könnte leicht von mehr als einem PC gesteuert werden und man würde eventuell die (falsche) Antwort erhalten, die ein anderes Kommando (von einem anderen Rechner) bestätigt. Setzt du aber die ID aus Sender und Empfänger zusammen, kann ein Sender auch auf mehr als eine Antwort warten. Das eine Antwort kommt, erkennt man dann weiterhin an der Sender ID, über die Empfänger ID sieht man dann auf welches Kommando geantwortet wird. Die abgeschickten Nachrichten gilt es dann einfach in einer Map oder einer Liste oder ähnliches zu verwalten.

Hoffe es hilft dir grob weiter,

Gruß Der Unwissende

hirnstroem 14. Sep 2006 08:53

Re: Asynchrone Kommunikation mit vielen Benutzern
 
Vielen Dank Wissender,

dies bestätigt eigentlich mehr oder weniger dies, was ich mir ausgedacht habe. Wollte einfach sicher gehen, nichts grundlegendes vergessen zu haben. Hab die Kommunikation in der Zwischenzeit schon etwas getestet, die Relais schalten bereits wie wild und die Antworten (ob es offen oder geschlossen ist) kommt auch jeweils bei dem richtigen Benutzer an. Mehrere Benutzer können auch auf ein und demselben Relais herumwüten (hab das mit for Schleifen und kleinen Pausen dazwischen getestet) und siehe da, die Sache ging sogar. Leider nur bis das Relais kaputt war, aber dies ist eine andere Geschichte.

Gruss
hirnsteom


Alle Zeitangaben in WEZ +1. Es ist jetzt 13:07 Uhr.

Powered by vBulletin® Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz