Tcomport on RXChar Problem

[himitsu]

Warum nicht die Daten auslesen, merken und wenn genug verarbeiten? (siehe #3)




Kommt das Event in einem Thread an? (glaub schon)

wenn ja, dann TThread.Synchronize oder besser TThread.Queue


Die Memo1.Lines.Add, in den oberen Antworten, funktionieren "zufällig", da sie intern SendMessage nutzen und sich so indirekt synchronisieren.

[BergLoewe]

Es ist ja blöderweise nicht bekannt, wann die Sendung zu Ende ist. Keine Anzahl an Bytes, keine Ende-Erkennung durch ein bestimmtes Zeichen. Den Kommentar #3 hatte ich so verstanden, dass der nach "CHR(13)" sucht und damit sein Ende definiert. Bzw. eben auch mit einem Timer arbeitet, wie ich es vorhabe.


Hinsichtlich Threads muß ich ehrlich eingestehen, dass mein Wissen in solche Tiefen nicht reicht. Ich habe in der Anwendung keine Threads vereinbart. Wenn Delphi hier selbstständig auf verschiedene Threads verteilt, weiß ich nicht, wie genau ich das auseinanderhalten oder auf einen anderen Thread zugreifen soll.
Dann aber wär's dennoch irgendwie komisch. Schalte ich den Timer per Button-Click ein, geht's. Schalte ich den in der OnRxChar ein, reagiert der Timer nicht auf den dann wahren Enabled, bzw. läßt das Timer-Event im gleichen Thread aufschlagen.

[himitsu]

Du brauchst so oder so eine Ende-Erkennung, bzw. ob es (mindestens) genug Daten sind.

erstmal irgendwie alles mitschneiden

Delphi-Quellcode:

(Sender as TComPort).ReadStr(Received, Count);
FResponse := FResponse + Received;

oder eben Binär als ByteArray oder Stream lesen+speichern



bezüglich des Timers mußt du ihn im Event beenden und neu starten, damit die Zeit erst nach dem letzten Empfang, im Intervall, verarbeitet wird.
"Nochmal" auf True setzen, wenn schon True war, startet die Zeit nicht neu.

Oder den Timer immer laufen lassen, bzw. beim ersten Empfangen starten
dann auch noch die Empfangszeit merken oder im Timer prüfen, ob sich seit dem letzten OnTimer etwas (Zeit oder Daten im Puffer) geändert hat
und wenn vorher, aber nicht beim letzten Mal, geändert, dann erst verarbeiten (und im Notfall auch noch wenn "zuviele" Daten vorhanden sind, die auf jeden Fall ausreichen, falls etwas hing)




In einem ähnlichen Fall hatte ich bei jedem Empfang geprüft ob eine Mindestmenge an Daten vorhanden sind (der Header)
und dann versucht die Daten zu dekodieren ... gab es Probleme, weil noch was fehlt, dann Abbruch und später nochmal, wenn wieder Neues rein kommt. (wenn erfolgreich verarbeitet, dann diese Daten aus dem Puffer löschen)

[TurboMagic]

Hallo,

muss es diese Komponente sein?
Alternativ mal TComPortDrv aus GetIt probiert?

Die liefert nicht nur Zeichen für Zeichen...

Grüße
TurboMagic

[himitsu]

macht TComPort auch nicht ... es liefert garkeine Zeichen. (es sagt, gerade war was reingekommen und x Zeichen sind aktuell im Puffer)

OnRxChar liefert quasi 1 bis x Zeichen, je nach dem, wieviel bereits im Buffer gelandet ist und noch nicht abgeholt wurde, z.B. mit ReadStr.

[BergLoewe]

Hallo,


vielen Dank erst mal, dass Ihr Euch meiner Probleme annehmt! Ich hatte am Wochenende leider keine Zeit, da meine Enkelin ihren großen Tag hatte und meine Angetraute etliches am Haus gemacht haben wollte. Daher erst jetzt ein Response.

Ich habe es jetzt zunächst mal so gemacht, dass ich den Timer beim Senden starte. Das ist nicht ideal, weil damit die Reaktionszeit der Gegenseite mit berücksichtigt werden müßte und die kann sehr unterschiedlich sein. Aber jetzt zum reinen Testen erst nmal so.
Im Prinzip geht das so. Leider aber nicht immer. Stochastisch zeigt der mir mitunter falsche Daten und vor allem falsch Byte-Anzahlen an. Und irgendwann hängt sich die App dann ganz auf.

Ich versuch's jetzt doch erst mal mit einer anderen Komponente. Aber ich nehm die ASync von TMS. MIt der habe ich vor 10 oder 12 Jahren schon mal sowas gemacht, damals unter Delphi2005. Die Winsoft wollte ich, weil die auch unter FMX läuft, die TMS wohl nicht. Die Anwendung soll später mal auch auf anderen Platformen laufen. Dann auch per WLAN oder Bluetooth. Deshalb habe ich das -was mir völliges Neuland ist- unter FireMonkey angefangen und wollte eben zunächst einmal das ganze via USB/RS232 aufbauen.

[himitsu]

Wenn garnichts geht, dann kannst du es auch selbst machen ... am Besten in einem Thread, falls zwischen zwei Empfängen zu viel Zeit vergeht und der Haupthtread dann immer wieder etwas hängt.


CreateFile+ReadFile, wobei man ReadFile+Overlapped auch im Hauptthread asynchron nutzen könnte (ohne hängen)
oder TFileStream, bzw. THandleStream+CreateFile und Stream.Read***
oder Assign+Read (das alte Pascalzeugs)
oder ...

und als Dateiname z.B. 'COM1' bis 'COM9'
so lange im Windows als Standard bereits die richtige Config (Baud, StopBits, Parität usw.) eingestellt ist, mußt du im Programm nichts weiter machen.
wenn doch nicht, dann SetCommState nach dem CreateFile -> https://docs.microsoft.com/de-de/win...tions-resource


also im Thread die "Datei" (Gerät) öffnen
ein oder mehere Byte auslesen (read) ... es wird ohne Overlapped bestimmt gewartet, bis diese x Bytes da und gelesen sind (darum im Thread)
eventuell die Bytes in einer Variable (TBytes bzw. TArray<Byte>) zwischenspeichern
und dann via Synchronize oder Queue in den Haupthtead damit (oder wenn möglich auch direkt im Thread verarbeiten und das Ergebnis in den Hauptthread)

[BergLoewe]

Moin,

nachdem ich nun fluchend Tage damit verlebte, andere Komponenten zu installieren und festzustellen, dass die in FMX nicht laufen, kam ich zur ursprünglichen Winsoft-Komponente zurück.

Naja, was soll ich sagen - vielleicht bin ich zu blöd, zu alt, zu blind(leider nicht zu besoffen, dann hätt ich was davon) aber jetzt läßt sich der Timer plötzlich aus der OnRxChar-Funktion heraus starten. Was er letzte Woche ums Verrecken nicht machen wollte.

Also vielen Dank dennoch, für Eure Hilfe und Eurer Verständnis.