ApdCOMPort: Daten gehen bei großen Datenmengen verloren

[Carsten1234]

Zitat:

Zitat von user0815

Hast Du zum testen dazu mal die ApdDataPacket Komponente eingesetzt ?

Rechtsklick drauf und man kann die StartCond + EndCond setzen oder auch erstmal jeden String akzeptieren.
Evtl. den TimeOut auf 0 Stellen.
Ausgabe über das Event "ApdDataPacket1StringPacket"

Hhhmm, datt Ding will ja eine Start- und End-Condition. Als StartCond wähle ich 'scAnyData', doch was nehme ich als EndCond?
Ich weiß vorher weder etwas über das geschickte Ende noch etwas über die Datenlänge, die da kommt.
Halt, ich habe jetzt die ecPacketSize angeknipst und die Länge auf 3 gesetzt. Dann läuft es erstmal eine Weile bis zur genannten Exception ecOutputBufferTooSmall. :wall:

Gruß, Carsten

[Chemiker]

Hallo Carsten,

stelle mal InSize auf 2 ein.

InSize=2;

Da nicht bekannt ist wie viel Daten übertragen werden, ist die Einstellung 2 ganz gut.

Bis bald Chemiker

[Carsten1234]

Zitat:

Zitat von Chemiker

stelle mal InSize auf 2 ein.

Teste ich mal.
BTW: Was ist der Unterschied zw. der TRC- und LOG-Datei? In der LOG-Datei sind die empfangenen Daten i.O., in der TRC-Datei allerdings sehe ich fehlerhafte Empfangsdaten. :gruebel:

Gruß, Carsten

Nachtrag:
Bei InSize:= 2 gibt es eine Exception.
Im Projekt ist eine Exception der Klasse EBadArgument mit der Meldung 'Bad argument passed to function' aufgetreten. :evil:

Nachtrag 2:
Es waren (wozu auch) keine HWFlowOptions gesetzt. Setze ich z.B. hwUseDTR, kommt die Excpetion nicht mehr. Allerdings bricht auch mit der Einstellung 2 der Datentransfer irgendwann ab.
BTW: Ich teste zZt. nicht im eigentlichen Programm, sondern mit einem kl. Testprogrämmchen, was ganz simpel gestrickt ist.

[Carsten1234]

Zitat:

Zitat von Trigger2003

Im ersten Fall würde ich mit einer "echten" RS232 testen, um Fehler im virtuellen ComPort-Treiber auszuschließen. Nach meiner Erfahrung ist die RS232-Emulation durch den Treiber keineswegs 100% kompatibel, gerade was das Zeitverhalten der Statusregister angeht.

Hier nochmal nachgehakt:
Wie ist denn eigentlich der Datenverlauf durch den PC?

[ ] Gerät => Treiber => UART => ApdCOMPort => PC-Programm
[ ] Gerät => UART => Treiber => ApdCOMPort => PC-Programm

M.M.n. unterstützt ein Treiber die Hardware, insofern bin ich der Meinung, das erstgenannte ist richtig.

Gruß, Carsten

[Trigger2003]

Zitat:

Zitat von Carsten1234

Wie ist denn eigentlich der Datenverlauf durch den PC?

[ ] Gerät => Treiber => UART => ApdCOMPort => PC-Programm
[ ] Gerät => UART => Treiber => ApdCOMPort => PC-Programm

IMHO Weder noch. In diesem speziellen Fall emuliert der Treiber nur einen UART, ist also eigentlich ein RS232-Emulator-Treiber und kein Gerätetreiber im klassischen Sinn.

also Gerät => Emulator/Treiber => ApdCOMPort => PC-Programm

[Trigger2003]

Zitat:

Zitat von Carsten1234

BTW: Was ist der Unterschied zw. der TRC- und LOG-Datei? In der LOG-Datei sind die empfangenen Daten i.O., in der TRC-Datei allerdings sehe ich fehlerhafte Empfangsdaten. :gruebel:

TRC ist die Aufzeichnung der Kommunikation zwischen APro und dem Windows-Treiber, Du kannst nur sehen, wie Transmit und Receive grob chronologisch abgelaufen sind, aber z.B. keine genauen Timinginformationen sehen.

LOG ist die Aufzeichnung der Kommunikation und Aktionen der APro-Komponenten untereinander mit genauen Timingangaben.

Siehe auch Apro Reference Guide, Kapitel 2

[Carsten1234]

Vielen Dank für die Erklärung. Demzufolge ist also dir Trace-Datei maßgebend zur Fehlersuche.
Und hier sind ja die empfangenen Daten verkehrt, demzufolge kommen also schon die Daten "von unten irgendwo her" falsch bei mir an.

[Carsten1234]

Hallo zusammen!

So, nach einer 'etwas längeren' Debug-Session und Codeanalyse mit einem Kollegen sind wir dem Übel auf die Spur gekommen, wobei wir der Ansicht sind, dass es sich um einen Bug in ApdCOMPort (v4.07) handelt. Aber der Reihe nach:

Das Übel beginnt mit dem ApdCOMPort.GetChar in meinem Programm. Nach Aufruf des Befehls wird in die Datei 'AwUser.pas' in Zeile 1570ff verzweigt. Hier wird normalerweise im ELSE-Zweig ab Zeile 1588ff genau ein Zeichen geholt und dieses auch aus dem Empfangspuffer gelöscht. Manchmal aber kommt es vor, dass in "InAvailMessage" TRUE ist. In diesem Fall wird zwar auch ein bzw. das letzte Zeichen aus dem Empfangspuffer (PeekCharPrim(C, GetCount);) geholt, es wird aber nicht gelöscht. So kann es also vor kommen, dass ein Zeichen doppelt empfangen bzw. ausgelesen wird.
Wann jedoch wird nun "InAvailMessage" TRUE?
Die Antwort dazu findet sich in derselben Datei ab Zeile 2123ff bzw. 2146ff. Das Problem bei dieser ganzen Routine ist unserer Meinung nach: Es wird zwar hier und da mit CriticalSection gearbeitet, doch ausgerechnet die Zeile, in der "InAvialMessage" auf TRUE gehen kann (Zeile 2146), befindet sich ausserhalb einer CriticalSection. Und dies ist u.M.n. der Bug selbst.

Mit anderen Worten: Ich darf via GetChar/GetBlock nicht auf den Empfangspuffer zugreifen, so lange noch Daten eintrudeln (könnten). Dummerweise nur weiß ich leider nicht, wann die Übertragung tatsächlich beendet wurde und nix mehr kommt.
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.

Geändert habe ich die Routine für den Kopfblock erstmal wie folgt:

Delphi-Quellcode:

procedure TForm1.GetHeadBlock;
var x             : word;
    OldBuffInSize : integer;
begin
  OldBuffInSize:= -1;
  while (OldBuffInSize < 0) or
        (OldBuffInSize <> ApdComPort.InBuffUsed) or
        (ApdComPort.InBuffUsed = 0) do
  begin
    Application.ProcessMessages;
    Delay(30);
    OldBuffInSize:= ApdComPort.InBuffUsed;
    if (TimeoutFlag) then
      Break;
  end;

  if (not TimeoutFlag) then
  begin
    ApdComPort.GetBlock(Head_Block, HEADBLOCKSIZE);
  end
  else
    Memo.Lines.Add('Timeout beim Warten auf Kopfblock');
end;

Hierbei ist allerdings auch nur das Delay verschoben aus der Hauptroutine zum Empfang und zur Auswertung aller empfangenen Daten.

Eure Meinungen?

Gruß, Carsten

[Trigger2003]

Die Antwort, warum bei InAvailMessage das Zeichen nur gelesen, aber nicht entfernt wird, steht doch im Quelltext von GetChar...oder bin ich noch zu müde? :gruebel:

Versuch: Füge mal ApdCOMPort.ProcessCommunications nach Application.ProcessMessages ein und schmeiß das Delay raus

[Carsten1234]

Zitat:

Zitat von Trigger2003

Die Antwort, warum bei InAvailMessage das Zeichen nur gelesen, aber nicht entfernt wird, steht doch im Quelltext von GetChar...oder bin ich noch zu müde? :gruebel:

Als Kommentar, richtig. Nur muss man den erstmal gelesen haben. :P

Zitat:

Zitat von Trigger2003

Versuch: Füge mal ApdCOMPort.ProcessCommunications nach Application.ProcessMessages ein und schmeiß das Delay raus

Sah jetzt bei 2 Versuchen ganz brauchbar aus. Danke erstmal für den Tipp, ich werde weiter testen.

Gruß, Carsten


Grrmmpppf - NÖ! :evil: