#13#10 bei Datenempfang mit TApdComPort

[oki]

Hi Leute,

ich kämpfe schon seit zei Tagen mit dem Problem und finde keine Lösung. Folgender Sachverhalt:

ich empfange Daten mit der Kompo TApdComPort. Jedesmal wenn in der Mitte eines empfangenen Teilstrings das Ereignis OnTrigger ausgelöst wird, hängt mir die Compo ein #13#10 zusätzlich ans Ende. damit geht natürliche meine Decodierung in die Tonne.

Hier mein Trace nach dem Auslesen:

Zitat:

PTCarphone
PTC V0.01.00 16.01.2007

?: Hilfetext
T: Liste Telefonbuch
C: Konfiguration
A.. Befehlseingabe
ESC: Ende Servicemode

OK

Hier der Trace des Kompoeigenen Trace-Files:

Zitat:

Receive:
[0D][0A]PTCarphone[20]PTC[20]V0.01.00[20]16.01.2007[0D][0A][0D][0A]?:[20][20]
[20]Hilfetext[0D][0A]T:[20][20][20]Liste[20]Telefonbuch[0D][0A]C:[20][20][20]K
onfiguration[00][00][0D][0A]A..[20][20]Befehlseingabe[0D][0A]ESC:[20]Ende[20]S
ervicemode[0D][0A][0D][0A]OK[0D][0A]

Hinter dem Eintrag "PTCarphone" wird also definitiv kein #13#10 gesendet. Warum empfange ich dann aber eins? Dabei ist zu bedenken, das mein Trace den String aus FReceiveData darstellt. Somit befindet sich der Zeilenumbruch im FReceiveData und wird nicht etwa durch eine Zeilenweise Ausgabe im Memo erzeugt.

Ich gebe euch hier mal meinen komplette Code incl. auskommentierter Testzeilen der Ereignisbehandlungsroutine. So könnt ihr auch sehen, was ich alle so ausprobiert habe.

Delphi-Quellcode:

procedure TTransactionComPort.OnTrigger(CP: TObject; Msg, TriggerHandle,
  Data: Word);
var Counter : Integer;
    C : Char;
    s : string;
    RLen : Word;
begin
  case Msg of
    APW_TRIGGERAVAIL : begin           //Corresponds to OnTriggerAvail.
{
      for Counter := 1 to Data do begin
        if FComPort.InBuffUsed > 0 then begin
          try
            C := FComPort.GetChar;
            FReceivedData := FReceivedData + c;
          except end;
        end;
      end;
}
//      DoReceiveMsg(FReceivedData);
{
      RLen := FComPort.InBuffUsed;
      SetLength(s, RLen);
      FComPort.GetBlock(s[1], RLen);
      FReceivedData := FReceivedData + s;
}
    end;
    APW_TRIGGERDATA : begin           // Corresponds to OnTriggerData. erwarteter Rückgabewert empfangen
{
      for Counter := 1 to Data do begin
        if FComPort.InBuffUsed > 0 then begin
          try
            C := FComPort.GetChar;
            FReceivedData := FReceivedData + c;
          except end;
        end;
      end;
}
      RLen := FComPort.InBuffUsed;
      SetLength(s, RLen);
      FComPort.GetBlock(s[1], RLen);
      FReceivedData := FReceivedData + s;

      if TriggerHandle = FResulttrigger then begin
        FComPort.RemoveTrigger(FResultTrigger);
        FResultTrigger := 0;
      end;
      DoReceiveMsg(FReceivedData);
    end;
    APW_TRIGGERTIMER : begin           // Corresponds to OnTriggerTimer. Timeout des Befehls erreicht

    end;
    APW_TRIGGERSTATUS : ;           // Corresponds to OnTriggerStatus.

  end;
end;

Ich habe persönlich das Gefühl, das die Compo nach jedem leeren des Windows-Buffers und übertragen in den eigenen Buffer einen Zeilenumbruch einfügt.

Ich habe mehrere DataTrigger gesetzt, die aber nicht zu diesem Zeilenumbruch passen.

Ich hoffe jemand hat da eine Idee was da los ist.

dank und Gruß oki

[oki]

push

[oki]

Ähmm, letzter Versuch

oki

[marabu]

Hallo,

spontan habe ich bei deinem ersten Posting vermutet, dass da WordWrap = True in einem Memo zu sehen ist.

Freundliche Grüße

[oki]

Hi marabu,

leider nicht. Ich füge den String wie folgt ins Memo ein:

Delphi-Quellcode:

procedure TLogForm.Add(Sender: TObject; Data, AdditionalData: string);
var HeaderString, DataString : string;
  function DeleteChar(OldString : String; AChar : Char) : String;
  var Counter : Integer;
  begin
    Result := '';
    for Counter := 1 to Length(OldString) do
      if OldString[Counter] <> AChar then
        Result := Result + OldString[Counter];
  end;
begin
  if not EnableLog then
    Exit;
  RichEdit1.Lines.Add(BlockHeaderStr);
  HeaderString := '';
  if EnableLogTime then
    HeaderString := '[' + FormatDateTime('dd.mm.yyyy hh:nn:ss:zzz', Now) + ']';
  if EnableLogSender then
    HeaderString := HeaderString + Format('[Sender: %s ]',  [Sender.ClassName]);
  if FEnableAdditionalLogData then
    HeaderString := HeaderString + Format('[Additional: %s ]',  [AdditionalData]);
  if HeaderString <> '' then
    RichEdit1.Lines.Add(HeaderString);
  DataString := DeleteChar(Data, #0);
  RichEdit1.Lines.Add(DataString);
  RichEdit1.Lines.Add(BlockFooterStr);
end;

Dadurch, dass ich Kopf- und Fußzeile mit eintrage kann ich eindeutig sehen, dass das ODOA im Datenstring enthalten ist.

gruß oki

[marabu]

Wie oft wird denn OnTrigger() bei deinen Beispieldaten ausgeführt - genau zweimal?

[oki]

soweit ich das mitbekommen habe ja. Läßt sich im debug-Modus schlecht testen, da dann die Schnittstelle immer schneller ist als ich. Bin mir aber recht sicher, dass das Triggerereignis beim zusätzlichen Zeilenumbruch unnötigerweise(?) kam.
Das würde aber implizieren, dass die Kompo nach einem Trigger ein ODOA anfügt. Das tut es aber nach den "ordnungsgemäßen" Triggerereignissen nicht. Hab ich geprüft.

Gruß oki

[marabu]

Wie hast du geprüft? Das überflüssige CRLF wird ja im internen Trace nicht ausgewiesen. Hast du mal einen eigenen Trace geschrieben, bei dem du auch alle Zeichen #0..#32 mit dem Format '[%2x]' ausgibst? Ich kann mir nicht vorstellen, dass CRLF mal angehängt wird und mal nicht, kann aber momentan nicht selbst testen.

[oki]

Hi Marabu,

ich reiche mit DoReceiveMsg(FReceivedData) den empfangenen String komplett nach oben durch. Dann geht er mittels beschriebenem Add ins Log. Das ist eigentlich mein Trace. Ich habe mit einem externen Tool auch ein seperates Trace zur Kontrolle geschrieben. Überall alles korrekt. Nur mein FReceiveData spinnt.

Eigentlich hatte ich gehofft, jemand kennt so was vom TAPDComPort und sagt so lapidar: "Tust du so, tust du hier und alles klappt!"

gruß oki

[marabu]

Sorry, aber ich bin momentan etwas handicapped.

Welchen Trigger-Typ entfernst du da mit RemoveTrigger?
Hast du irgendwo AddDataTrigger() in deinem Code verwendet?

Wenn dein Device kein CRLF gesendet hat, du aber ein überflüssiges CRLF in deinem FReceiveBuffer vorfindest, dann bleibt für mich nur der Verdacht, dass es sich um ein früher gesendetes CRLF handelt, welches nicht aus dem Puffer entfernt wurde und deshalb erneut ausgelesen wird.