Hallo *,

für eine Anwendung muss ich per serieller Kommunikation Daten austauschen. Dafür habe ich die Komponente TComPort von WinSoft eingesetzt, die bisher auch ganz sauber funktioniert hat. Jetzt habe ich bei längeren Kommunikationssequenzen (ca. 30s straight, ca. 150k) Ausfallerscheinungen. Wie diese genau aussehen kann ich ja schlecht sehen, weil das Gerät, mit dem ich kommuniziere nur sagt, dass die Daten falsch sind, aber nicht, wo genau das Problem liegt. Dann habe ich allerdings mit einer zweiten Instanz meiner Applikation die Daten zurück gelesen und stelle fest, dass dort Lücken sind. Z.B. wird das Paket x unterbrochen und dafür geht mitten in Paket x das Paket y los, welches aber erst z Pakete später gesendet wurde. D.h. es fallen mehrere Pakete, auch und üblicherweise Bruchteile, "unter den Tisch". Fast so als wäre der Lesepuffer nicht geleert worden und dann mit neuen Daten überschrieben worden. Da mein abgesetztes Gerät einen Fehler meldet (die Kommunikation mit diesem arbeitet in weiten Teilen aber problemlos) kann ich hier also zwei getrennte Fehler feststellen, ich würde daher davon ausgehen, dass der Fehler beim Senden auftritt (nicht notwendigerweise, ich denke mir nur die Wahrscheinlichkeit für zwei Fehler die gleichzeitig auftreten ist deutlich geringer, trotzdem will ich mich hier nicht festlegen).

Kennt jemand derartige Kommunikationsprobleme im Zusammenhang mit der genannten Komponente?
Kommt das jemandem aus irgendwelcher Historie heraus bekannt vor und hat evt. eine ausgefallene Idee, woran es liegen könnte?
Hat jemand eine alternative Komponente im Einsatz die ich einsetzen könnte (Ich muss RTS und DTR separat ansteuern können)?

Vielen Dank & viele Grüße,
Stephan

Du könntest auch mal mit Com0Com bzw. Hub4Com einen Comport erstellen und diesen dann splitten:



Com6+Com3 bzw. Com2+Com5 sind virtuelle Ports die jeweils mit Com0Com verbunden sind.
Com3 wird auf Com1 und Com2 aufgesplittet (Hub4Com).

Die Verbindung wird jetzt geteilt, d.h. du kannst in HTerm z.b. die Daten auslesen die dein Programm gesendet hat und somit schauen ob deine TComPort Komponente richtig funktioniert, wärend das Gerät die eigentliche Kommunikation übernimmt und du feststellen kannst wann der Fehler aufgetreten ist. Dies sollte dann in HTerm ebenfalls erkennbar sein.
Wenn nicht -> Fehler im Gerät/Kabel, wenn doch -> andere Komponente.

Hallo, danke für die Anregung. Etwas ähnliches habe ich bereits gemacht: Ich habe eine Software aus der Entwicklung, die auf demselben Rechner, mit demselben Kabel/Adapter und demselben Endgerät problemlos kommuniziert. Das ist meine Ausgangsposition und ich kann es jederzeit überprüfen. D.h. die genannten Komponenten sind alle grundsätzlich in Ordnung. D.h. auf der Basis habe ich an sich bereits - nach meiner Einschätzung - zweifelsfrei festgestellt, dass meine Software (incl. COM-Komponente) das Problem verursachen. Das wird lediglich noch gestützt durch die Tatsache, dass ich beim Zurücklesen das Problem - oder evt. sogar noch ein zweites - protokollieren kann. Da ist dann die Komponente ja zweimal beteiligt...

Aber ich bin doch nicht der einzige, der mit TComPort arbeitet, oder? Hat jemand eine Idee für eine andere Komponente, die ich leicht ausprobieren kann?

Viele Grüße,
Stephan

Hi

wir benutzen schon seit (fast) ewigen Zeiten die TSerial Komponente, die hier auch schon das ein oder andere Mal diskutiert wurde ("Toolbox").
Für unsere Zwecke (keine riesigen Datenmengen) hat dies auch schön einfach funktioniert, aber es hat hier schon Leute gegeben,
die Probleme damit hatten (sollte man auch nicht verschweigen). Wie die Komponente bei großen Datenmengen reagiert, weiß ich nicht.

Olli

Ich denke ich habe das Problem gefunden - unter Windows 7 scheinen sich die beiden COM Ports, die ich benutzt habe, gestört zu haben. Wenn ich die lesende Funktion auf einen anderen Rechner auslagere tritt das Problem deutlich seltener auf. Ganz weg ist's indes nicht... Ich vermute Probleme mit dem Timing und kann nur hoffen, dass mir das nicht wieder auf die Füße fällt, weil ich so wie's jetzt ist zwar damit leben kann, aber eine grundsätzliche Lösung ist es aber doch nicht.

vG,
Stephan

USB-Comportwandler? da gibt es tatsächlich des öfteren Probleme und große Qualitätsunterschiede...

Hab ich auch schon drüber nachgedacht, aber ich denke eher nicht. Ich nutze einen COM port "native" und einen über USB2Serial, auch nach Tausch bekomme ich das Problem, aber nur beim lesen...

vG
Stephan

Problemlösung setzte sich zusammen aus kleineren Fehlern in der Anwendung des Protokolls und Störungen der beiden COM Ports untereinander. Nur die Korrektur von beiden Sachverhalten führt natürlich zu einem korrekten Ergebnis. Das hat sich sehr lange hingezogen, weil ich mich zu jeder Zeit immer nur auf EINES der beiden Themen konzentriert habe.

Lösung vermutlich wenig wiederverwendbar. Etwas haben wir (ich) trotzdem gelernt: Auch wenn MEISTENS ein gravierender Fehler die Lösung verhindert, so gibt es doch Situationen, in denen MEHRERE Fehler zusammenspielen. Vielleicht wertvoll im Hinterkopf zu behalten.

Stephan