ApdCOMPort: Daten gehen bei großen Datenmengen verloren

[Trigger2003]

Zitat von Carsten1234:

ApdDataPacket ist auch irgendwo nur eine halbherzige Lösung, denn die EndCond könnte ja auch rein zufällig in den Binärdaten vorhanden sein.

Halbherzig? Wieso das?
Für Binärdaten kann die End-Condition doch genausogut auch durch die Blockgröße definiert sein. Kommt ganz auf die Art der Daten an....

[Carsten1234]

Zitat von Trigger2003:

Halbherzig? Wieso das?
Für Binärdaten kann die End-Condition doch genausogut auch durch die Blockgröße definiert sein. Kommt ganz auf die Art der Daten an....

Also jedes Mal umschalten in Abhängigkeit der Daten bzw. des Datentransfer. Lässt sich das bewerkstelligen, wenn der Port offen ist?

[Trigger2003]

Zitat von Carsten1234:

Also jedes Mal umschalten in Abhängigkeit der Daten bzw. des Datentransfer. Lässt sich das bewerkstelligen, wenn der Port offen ist?

Weiß ich nicht mehr auswendig. Versuch macht kluch...

Laß das ApdComPort.ProcessCommunications aber trotzdem drin, gehört einfach in die Warteschleife

[Carsten1234]

Zitat von Trigger2003:

Laß das ApdComPort.ProcessCommunications aber trotzdem drin, gehört einfach in die Warteschleife

Gut, mache bzw. lasse ich. Trotzdem überlege ich noch, die Komponente dahingehend zu erweitern, entweder den Status von InAvailMessage über eine Funktion nach außen zu führen und/oder GetChar mit einem booleanschen Flag ReadOnly:= true/false zu erweitern - oder beides.

Delphi-Quellcode:

function TApdBaseDispatcher.GetChar(var C : Char; AReadOnly: boolean = false) : Integer;
    {-Return next char and remove it from buffer}
  begin
    EnterCriticalSection(DispSection);
    try
(...)
      if (InAvailMessage) or (AReadOnly) then begin
        Inc(GetCount);
        Result := PeekCharPrim(C, GetCount);
        if Result < ecOK then begin
          Dec(GetCount);
          Exit;
        end;
      end else begin
(...)
    finally
      LeaveCriticalSection(DispSection);
    end;
  end;

Gruß, Carsten

[Carsten1234]

So, mit den beiden von mir genannten Erweiterungen geht es.
In der repeat..until-Schleife zum Auslesen der Kopfdaten weiß ich, dass deren Länge 3 Zeichen haben muss. Ich warte also so lange, bis drei Zeichen im InBuffer liegen und hole sie mir dann via GetChar raus, wobei ich diese Zeichen NICHT aus dem InBuffer lösche bzw. löschen lasse. So habe ich die Länge und kann in der nachfolgenden Schleife warten, bis 3 + errechnete Zeichenlänge im InBuffer sind.
Dann lese ich alle Zeichen aus und lasse sie löschen.
Die zweite Erweiterung der Komponenten ist die Abfrage von InAvailMessage. Ist in meinen Schleifen der Wert true, warte ich weiter.

Delphi-Quellcode:

repeat
  Application.ProcessMessages;
  ApdCOMPort.ProcessCommunications;
  if ApdComPort.Dispatcher.GetInAvailMessageState then // true, wenn InAvailMessage = true
    Continue;
until (TimeoutFlag) or (ApdComPort.InBuffUsed >= ASize);
if (not TimeoutFlag) then
begin
  ApdComPort.GetChar({true} oder {false});
end;

Gruß, Carsten

[Carsten1234]

Zitat von taveuni:

Allerdings empfangen wir im TriggerAvail.

Das muss ich nochmal aufgreifen.
Könnte man diesen Trigger aufgreifen und auf Count triggern, wenn mind. x Zeichen im Puffer liegen?
Wie oft fällt dieser Trigger eigentlich? Immer dann, wenn wieder ein Zeichen im Puffer dazu gekommen ist?

Gruß, Carsten

[taveuni]

Hmmh..
Ich weiss nicht genau was Du damit meinst.
TriggerAvail ist vergleichbar mit DataAvailable einer Socket Komponente.
Wenn Daten im Empfangsbuffer ankommen wird dieser Event ausgelöst.
Wieviele das sind hängt vom Sender, der Baudrate und den Einstellungen ab.

Wenn Du in diesem Event nun GetBlock ausführst erhältst Du den Inhalt des Buffers.
Danach wird dieser automatisch für den nächsten Event gelöscht.
Die erhaltenen Daten musst Du nun verarbeiten.

Also Pseudocode:

Delphi-Quellcode:

procedure MyComport.TriggerAvail(CP: TObject; Count: Word);
var
  buffer : array [0..4095] of byte;
  i : Integer;
  s : String;
begin
  s := '';
  TApdComPort(CP).GetBlock(buffer, Count);
  for i:=0 to Count-1 do
  begin
    // falls es ein Ascii Protokoll ist:
    s := s+char(buffer[i])  
  end;
  VerarbeiteString(s);
  // oder kopiere den Inhalt des Buffers in einen temp Buffer und rufe eine Funktion auf um diesen zu verarbeiten.
end;

So verarbeiten wir die gesamte RS232 Kommunikation Ereignis gesteuert und hatten damit noch nie Probleme.
Allerdings glaube ich mich zu erinnern dass Du USB-RS232 wandelst oder sogar simulierst.
Kann sein dass die anfallenden Daten dann von der Kompenente gar nicht verabeitet werden können?
Keine Ahnung. Bis zur "normalen" Höchstrate von 115'200 Baud funktioniert das einwandfrei.

[arnold mueller]

Ich hatte vor einiger Zeit das gleiche Problem. Laut Sysinternals Portmon kamen die Daten korrekt am PC an, der Buffer in der APDComPort Komponente enthielt aber doppelte Zeichen. Sporadisch versteht sich ... Ich konnte die ganze Sache soweit eingrenzen, dass es nur auf Maschinen mit Hyperthreading oder DualCore Prozessor auftrat.

Für mich war der Weg mit Apro damit zuende. Ich habe mir eine eigene ComPort Klasse geschrieben, die nun auch tadellos ihren Dienst tut.

-
arno