![]() |
AW: COM Port Daten auslesen und auf bestimmtes Char reagieren
Das mit dem puffern und selbstständig abarbeiten würde wahrscheinlich funktionieren.
Dachte nur ich komme mit den Windows API Funktionen soweit zurecht. |
AW: COM Port Daten auslesen und auf bestimmtes Char reagieren
Hallo,
mein Ablauf sieht jetzt so aus: ComPortInit Daten vorhanden an Schnittstelle?
Delphi-Quellcode:
Thread prüft Overlapped Event auf WAIT_OBJECT_0 im Execute
TmpMask := EV_RXFLAG;
WaitCommEvent(SerHandle, TmpMask, @rOverlapped);
Delphi-Quellcode:
Wieder auf Daten vorhanden prüfen an Schnittstelle
if ReadFile (MyHandle, ReceiveBuffer, 1024, ReceivedBytes, @rOverlapped) then
begin //Tue irgendwas mit den Daten //Now als Zeitstempeleingang nutzen //Protokolliere Daten end;
Delphi-Quellcode:
Daten vorhanden? Dann wird Thread wieder angetriggert usw. usw. usw.
TmpMask := EV_RXFLAG;
WaitCommEvent(SerHandle, TmpMask, @rOverlapped); Das läuft soweit auch ganz gut auf meinem Rechner. Trotzdem passiert es ab und zu, dass ich 2 oder 3 Strings rein bekomme (bzw. in meinem Protokoll sehe), die genau den gleichen Zeitstempel haben (Now wird genutzt nach dem ReadFile für den Zeitstempel). Jetzt habe ich das auf einem anderen Rechner probiert und da sieht das Protokoll noch "schlechter" aus. Der String den ich bekomme hat immer 14 Byte + #13#10 Inhaltsbeispiel: abcdefghijklmn#13#10 Auf meinem Rechner sieht es erstmal ganz gut aus, bis auf dem Problem mit den 2-3 Werten, die alle den gleichen Zeitstempel haben. Auf dem anderen Rechner sieht das Protokoll so aus (jede Zeile ist ein Wert): abcdefghijklmn#13#10 abcdefghijklmn#13#10 abcdefghijklmn#13#10 abcdefghi jklmn#13#10 abcdefghijklmn#13#10 abcdefghijklmn#13#10 abcdefghijklmn#13#10 abcdefghijklmn#13#10 abcde fghijklmn#13#10 abcdefghijklmn#13#10 abcdefghijklmn#13#10 abcdefghijklmn#13#10 abcdefghijkl mn#13#10 abcdefghijklmn#13#10 abcdefghijklmn#13#10 abcdefghijklmn#13#10 abcdefghijklmn#13#10 Das ist nur ein Beispiel... Wie man aber sieht, sind die Werte nicht immer am #10 beendet wurden sondern auch irgendwo dazwischen. Das sieht für mich so aus, als wenn das WaitCommEvent kommt (#10 erkannt) und ich dann mit ReadFile auslese aber noch nicht alle Daten vollständig im Cache sind. Kann das sein? Ansonsten würde ja das ReadFile nicht angetriggert werden wenn das WaitCommEvent nicht kommt. Habt ihr dazu noch eine Idee? |
AW: COM Port Daten auslesen und auf bestimmtes Char reagieren
Das ist wohl immer so bei Comports. Man braucht einen Puffer, in dem man die Teile der Übertragung sammelt und dann weiter verarbeitet. Das kann z.B. einfach eine globale String-Variable sein.
|
AW: COM Port Daten auslesen und auf bestimmtes Char reagieren
@Neumann:
Wieso das denn? Ich dachte mit dem WaitCommEvent wird mir signalisiert, dass an der Schnittstelle mein gesetztes Zeichen angekommen ist (=#10). Dann müssen die Daten die sich davor befinden (können ja nur davor stehen) auch irgendwo schon im Cache liegen oder wo sind die sonst? |
AW: COM Port Daten auslesen und auf bestimmtes Char reagieren
Warum nimmst du nicht sowas wie
![]() Rollo |
AW: COM Port Daten auslesen und auf bestimmtes Char reagieren
Rollo, hatte ich auch schon so ähnlich vorgeschlagen. Vielleicht gibt es Gründe warum alles selbst gebaut werden soll.
Noch mal zu den zerteilten Strings: Muss man wohl einfach mit leben. |
AW: COM Port Daten auslesen und auf bestimmtes Char reagieren
@Rollo62: Ja ich muss leider alles selber bauen.
@Neumann: Zitat:
|
AW: COM Port Daten auslesen und auf bestimmtes Char reagieren
Noch mal:
Das mit dem Asynchron Lesen ist deutlich schwieriger als synchron. Probier doch mal die zweite Variante aus oder gib mal eine Rückmeldung dazu, falls du das schon hast. CreateFileA ohne FILE_FLAG_OVERLAPPED aufrufen und auf das ganze Overlapped Gedöns :) verzichten. Dann kommt der Rücksprung aus WaitCommEvent auch wirklich nur wenn dein Char im Buffer ist und die ganzen Waitfor... Aufrufe erledigen sich auch. |
Alle Zeitangaben in WEZ +1. Es ist jetzt 12:39 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024-2025 by Thomas Breitkreuz