[Gelöst] COM Port zugriff Byte Fehlt

Hallo Zusammen,

bei den zugriff auf eine COM Schnittstele über den Serial Port scheint ein Byte verloren zu gehen.
Grundlegend soll nach einem Header eine Zahl kommen in 2 Byts Encodet kommen (Rot Makiert) und zum Schluss eine Checksumme.

Ich folgenden Bytes sollte ich für 17 bekommen. [edit 1] Sie werden auch gesendet hab ich mit RealTerm kontroliert[/edit 1]

112 11 17 0 1 0 3

Folgende bekomme ich.
112 11 0 1 0 3

Für 16 Funktioniert es ich bekomme.
112 11 16 0 1 0 36

Für 18 auch.
112 11 18 0 1 0 63

Für die Zahlen 169, 170, 1170 , 1700 bekomme ich auch falsche werte. (17 hatte gewählt, da man hier wohl am besten sehen kann was ich mit fehlendem Byte meine)
Für z.B. 117 einen Dann wider den Richtigen.

Die Daten Empfange ich wie folgt.

        private void Port_SerialDataReceived(object sender, SerialDataReceivedEventArgs e)
        {
            byte[] antwort = new byte[_port.BytesToRead];
            
            _port.Read(antwort, 0, antwort.Length);

            OnDataReceived(antwort);
        }

(ReadExisting() hab ich auch schon Probiert).

Ich hoffe das jemand weiß woran es liegen kann.

Hi Palin,

ich habe zwar auch keine Idee, woran es liegen könnte. Aber ich hätte ein paar Fragen, mit denen man dem Fehler evtl. auf die Spur kommen könnte:

• Kannst du das denn mit den genannten Zahlen reproduzieren? Also, wird z.B. die 17 IMMER verschluckt, oder funktioniert das manchmal? Bzw. funktioniert die 16 IMMER?

• So wie es aussieht, enthält die Checksumme den Wert, obwohl er nicht empfangen wurde. Kannst du also bestätigen, daß die Checksumme den richtigen Wert enthält?

• Hast du evtl. Zugriff auf den Code, der die Daten sendet? Falls ja, kannst du den mal posten?

Christian

• Kannst du das denn mit den genannten Zahlen reproduzieren? Also, wird z.B. die 17 IMMER verschluckt, oder funktioniert das manchmal? Bzw. funktioniert die 16 IMMER?

Bei beiden Ja IMMER. 🙁

• So wie es aussieht, enthält die Checksumme den Wert, obwohl er nicht empfangen wurde. Kannst du also bestätigen, daß die Checksumme den richtigen Wert enthält?

Die Checksumme kann ich morgen noch mal Prüfen. Ich denke aber, das sie den Richtigen Wehrt hat.
Ich hab mit einem Y-Kabel RealTerm , dazwischen gesetzt und kann sehen, das die 17 mit gesendet wird (Dort werden genau die Byts angezeigt die ich erwarte.).

• Hast du evtl. Zugriff auf den Code, der die Daten sendet? Falls ja, kannst du den mal posten?

Müsste ich ich erst klären ob ich ihn Posten darf.
Grundlegend ist es uralter C++ Code der auf einem Controller läuft. Dementsprechend schlecht zu lesen und zu verstehen. Eine Arbeitskollege hat ihn sich aber schon Angeschaut und er wird auch von anderer Software (C++) aufgerufen. Das funktioniert einwandfrei.
Wenn jetzt nicht wirklich bedarf Besteht den Code zu Posten, würde ich es erst mal lassen.

Ich muss gestehen ich steh, da momentan absolut auf den Schlauch. Die einzige Lösung, die ich momentan sehe ist eine Ebene tiefer zugehen und den zugriff auf den Port über APIs zu machen. Was eigentlich einen neu Programmieren der Serial Port Klasse entsprechen dürfte. Und das würde ich wirklich gerne vermeiden. X(

Ich bin da wirklich für jede Anregung / Idee dankbar.

Sieht für mich wie eine Race-Condition aus.
In dem Event steht doch gar nicht fest, dass das wirklich alle Bytes sind.

Ich würde lieber mit port.ReadExisting( ) arbeiten, statt darauf zu hoffen, dass die Länge zu dem Zeitpunkt wirklich korrekt ist.

versuchs doch mal damit:

Template Serialport

Du kannst nicht davon ausgehen, das du die Daten auf einmal einlesen kannst.
Eventuell kommen die Daten in mehreren Paketen an.

Hallo miteinander,

die Einwände sind richtig, man sollte immer die ReadExisting-Methode verwenden. Aber das kann nicht die Ursache sein, denn Header und Checksumme werden ja soweit ich das übersehe immer korrekt in einem Rutsch übermittelt.

Was mich zu der Frage bringt: Was passiert, wenn die 17 im Header oder in der Checksumme auftaucht?

Und hast du die Software mal auf einem anderen Rechner getestet? Evtl. ist ja sogar die Hardware defekt? Andererseits:

Grundlegend ist es uralter C++ Code der auf einem Controller läuft. Dementsprechend schlecht zu lesen und zu verstehen. Eine Arbeitskollege hat ihn sich aber schon Angeschaut und er wird auch von anderer Software (C++) aufgerufen. Das funktioniert einwandfrei.

Klingt ein bißchen so wie: Das funktioniert, weil es immer funktioniert hat.

Aber bitte nicht posten! Uralten, schlecht lesbaren und schlecht verständlichen C++-Code will ich gar nicht sehen 😃

Christian

Erst mal danke an alle, ich bin wirklich für jede Hilfe Dankbar.

@Abt
ReadExisting habe ich auch schon probiert (war die eigentliche Implementierung), es hat leider auch nicht funktioniert.

@MartinH
Werde ich mir morgen mal anschauen. Ich denke aber nicht, das es das Problem löst. Das mit den mehreren Paketen ist durchaus verständlich. Es werden aber maximal 8 Byte gesendet. Den Anfang habe ich und das Ende auch mir fehlt halt ein Byte in der Mitte.

Was mich zu der Frage bringt: Was passiert, wenn die 17 im Header oder in der Checksumme auftaucht?

Muss ich gestehen weiß ich nicht genau. Ich meine sie ist an anderen Stellen schon vorgekommen. Aber ich Probiere Morgen vielleicht mal ein Beispiel so zu konstruieren, das es vorkommt.

Und hast du die Software mal auf einem anderen Rechner getestet? Evtl. ist ja sogar die Hardware defekt?

Da alles andere „funktionierte“ bin ich bis jetzt nicht von einen Hardwarefehler ausgegangen. Ich werde es morgen auch noch mal prüfen. (Auch wenn ich es für unwahrscheinlich halte, ist es aktuell die beste Erklärung, die ich habe.

Klingt ein bißchen so wie: Das funktioniert, weil es immer funktioniert hat.

Naja ganz so leicht haben wir es uns nicht gemacht.

1. Schritt war natürlich zu schauen ob es mit der „alten“ Software klappt.
2. Schritt war dann in die Software zu schauen (Sende und Empfänger) ob da was zu finden ist.
3. Schritt (parallel zu 2) war Hardware und ein Programm dazwischen zu schalten um zuschauen was gesendet wird. (Da bekomme ich auch die richtigen Byts)

So ich hab jetzt noch mal einen Befehl so konstruiert, das die 17 auch im Header vor kommt auch dort wird sie entfernt. Bei der Gelegenheit hab ich es auch mal so gemacht, das mehrere 17ner auftauchen. Diese werden alle Entfernt.

Könnte es vielleicht was mit der Hex (11) bzw. Binäre (0001 0001) Darstellung zu tun haben ?

Auf einen anderen Rechner hab ich die Software jetzt auch getestet mit gleichen Ergebnis.

Ok ich hab es.

der Handshake ware auf XOnXOff gestellt und das aind 17(11Hex) und 19 (13Hex) Steuerzeichen. (Schämm) .

Danke noch mal für die Hilfe.