[gelöst] SerialPort - TCommTimeouts - was einstellen ?

[PeterS]

Die 10ms funktionieren nur in der Theorie (in deinem speziellen Fall) gut, in der Praxis hat man als Umgebung Windows, das nicht Echtzeittauglich ist und dazu noch Netzwerke, das ebenfalls nichts mit Echtzeit am Hut hat.

Diese 10 ms hier werden auf Serial-Port-Treiber-Ebene gesetzt.

Code: Alles auswählen

    ReadIntervalTimeout         := 10;       // @ 9600 Bits / sec = 1200 byte / sec

Und der Adapter sammelt ebenfalls Daten, wie er gerade zufällig programmiert ist.

Daher empfehle ich ja grundsätzlich die RS485-To-ETH Adapter.
Die funktionieren zuverlässiger als dieser RS485-USB-Kram.

[MmVisual]

Nochmal:
- Timeout: Schlecht, Fehlerbehaftet, Zufall dass es geht, bad, eklig, schei**e
- Datenanalyse: Gut, Perfeckt, Geht, einfacher, sicherer, super, hakuna matata

[PeterS]

Nochmal:
- Timeout: Schlecht, Fehlerbehaftet, Zufall dass es geht, bad, eklig, schei**e
- Datenanalyse: Gut, Perfeckt, Geht, einfacher, sicherer, super, hakuna matata

Mag ja auf Anwendungsebene stimmen. Aber hier sind wir auf Treiber-Ebene.

=>

Code: Alles auswählen

ReadIntervalTimeout

Die maximal zulässige Zeit bis zum Eintreffen des nächsten Byte auf der Kommunikationsleitung in Millisekunden.
Wenn das Intervall zwischen dem Eintreffen von zwei Bytes diesen Betrag überschreitet, 
wird der ReadFile-Vorgang abgeschlossen, und alle gepufferten Daten werden zurückgegeben.
Der Wert null gibt an, dass Intervalltimeouts nicht verwendet werden.

https://learn.microsoft.com/de-de/windo ... mmtimeouts

Und genau das paßt gut zu dem Hersteller-spezifischen Kommunikations-Protokoll, das ich "belausche".
Die Daten kommen paketweise. Mit aus Computer-Sicht riesigen Pausen dazwischen.

Fakt ist daß meine Anwendung läuft. Und ich nur hin und wieder
ein in der Mitte zerschnittenes Datenpaket wieder zusammen kleben muss.

[PeterS]

- Timeout: Schlecht, Fehlerbehaftet, Zufall dass es geht, bad, eklig, schei**e

Dann sag mir, warum Microsoft diesen Mechanismus explizit zur Verfügung stellt.

https://www.lookrs232.com/com_port_prog ... meouts.htm

[PeterS]

Okay, gehen wir ein wenig rückwärts in der Geschichte .. Windows 95 ..

Code: Alles auswählen

.. allows all timeout values to be set to zero.
This is in fact the default setting for devices that have never before had their timeouts configured. 
However, it is very dangerous to set these values to zero if you are performing any reads or writes.
If timeouts are not used, a read operation will not complete until all the requested bytes
have been read; if the connection is bad, this could take a very long time, like forever. 
The same is true for write operations when timeouts are not set.

57.pdf

(142.73 KiB) 109-mal heruntergeladen

Ohne gesetzte Timeouts muss man natürlich mit mindestens einem secondary Thread arbeiten,
um den Input zu pollen .. sonst blockiert man sich den MainThread

[siro]

Guten Morgen,
ich habe mir grade den Hexdump mal angesehen und die Blöcke farbig markiert:

Hex_Bloecke.jpg (111.37 KiB) 2423 mal betrachtet

grün:Start
rot:Ende
blau: Länge
orange: Fehlt da nicht ein Byte ???

Die Länge sind alle Bytes zwischen $32 und $34
$32 und $34 werden nicht mitgezählt.

Nach dem Ende Zeichen $34 folgen meistens 5 Bytes, aber einmal auch nur 4 Bytes,
vierte Zeile von unten.....

Die Synchronisierung ist jetzt garnicht so trivial wie man denken würde.
Eine $32 muss nicht unbedingt der Start eines Blockes sein, es könnte auch ein Byte von der Länge sein
oder eines von der Checksumme ???
ebenso mit dem Endbyte $34

Es muss also nicht unbedingt am Timing liegen wenn Fehler auftreten....

[PeterS]

Die Synchronisierung ist jetzt garnicht so trivial wie man denken würde.
Eine $32 muss nicht unbedingt der Start eines Blockes sein, es könnte auch ein Byte von der Länge sein
oder eines von der Checksumme ???
ebenso mit dem Endbyte $34

Es ist im Grunde trivial.

Ich muss nur die Daten als Pakete annehmen, aber eben nicht als "endlosen Datenstrom".
Das macht meine Implementierung. Nur noch nicht sauber mit diesen realen RS485-To-USB Sticks.


Alles außerhalb des Datenpakets zwischen $32 und $34
ist irrelevant und enthält keine verwertbaren Daten.
Scheint aber für die beiden Geräte, die da miteinander sprechen,
irgendwie relevant zu sein. Vielleicht auch nur als "staying alive" Pakete, keine Ahnung ..


So kommt das jetzt übrigens von der Virtuellen COM Schnittstelle (Sender ist ein RS485-To-ETH).
Muss man nur noch alles außerhalb von $32 und $34 "wegschnibbeln",
und hin und wieder ein mittendrin getrenntes Datenpaket wieder zusammen kleben.

Code: Alles auswählen

[2025-01-07, 10:56:51:664] FD FD FD FD
[2025-01-07, 10:56:51:665] 32 00 11 10 00 00 B0 00 FF C0 14 7D 01 80 31 00 E6 D2 34 FD
[2025-01-07, 10:56:52:203] FD FD FD FD FD 32 00 12 10 00 00 B0 00 FF C0 14 81 01 82 25 01 55 9E 1D 34
[2025-01-07, 10:56:52:205] 32 00 3D 10 00 00 B0 00 FF C0 14 7F 0D 82 3F 00 C8 80 8D 00 80 01 02 82 48 00 FF 82 49 00 FF 80 03 02 84 04 04 80 82 02 82 44 00 00 82 47 00 FF 80 61 FF 80 62 00 80 75 FF 80 5E 01 3A 49 34 FD
[2025-01-07, 10:56:53:208] 7D FD FD FD 32 00 12 10 00 00 B0 00 FF C0 14 83 01 82 25 01 56 25 3E 34
[2025-01-07, 10:56:53:212] 32 00 12 10 00 00 B0 00 FF C0 14 81 01 82 25 01 55 9E 1D 34 7D
[2025-01-07, 10:56:53:416] FD 7D FD FD 32 00 30 10 00 00 B0 00 FF C0 14 85 09 82 33 00 44 82 98 00 00 82 A8 00 44 82 A9 00 44 82 AA 00 00 

Nach dem "sauber machen" bleibt das hier übrig:

Code: Alles auswählen

[2025-01-07, 10:56:51:665] 32 00 11 10 00 00 B0 00 FF C0 14 7D 01 80 31 00 E6 D2 34
[2025-01-07, 10:56:52:203] 32 00 12 10 00 00 B0 00 FF C0 14 81 01 82 25 01 55 9E 1D 34
[2025-01-07, 10:56:52:205] 32 00 3D 10 00 00 B0 00 FF C0 14 7F 0D 82 3F 00 C8 80 8D 00 80 01 02 82 48 00 FF 82 49 00 FF 80 03 02 84 04 04 80 82 02 82 44 00 00 82 47 00 FF 80 61 FF 80 62 00 80 75 FF 80 5E 01 3A 49 34
[2025-01-07, 10:56:53:208] 32 00 12 10 00 00 B0 00 FF C0 14 83 01 82 25 01 56 25 3E 34
[2025-01-07, 10:56:53:212] 32 00 12 10 00 00 B0 00 FF C0 14 81 01 82 25 01 55 9E 1D 34
[2025-01-07, 10:56:53:416] 32 00 30 10 00 00 B0 00 FF C0 14 85 09 82 33 00 44 82 98 00 00 82 A8 00 44 82 A9 00 44 82 AA 00 00 80 3F 00 82 43 00 00 82 35 00 00 80 BF 00 A8 BB 34

[PeterS]

Ein abschließendes Wort zu der Datenverarbeitung mit Serial Port
und der Problematik, die ich hier angesprochen hatte - geschredderte Datenpakete.

Ich habe mir letzte Woche einen Stick von Waveshare bestellt, mit CH343G Chipsatz.
Der schreddert die Datenpakete nicht, sie laufen sauber rein.



Die "Schuld" für die geschredderte Datenübertragung liegt beim PROLIFIC Chipsatz,
den einige meiner User verwenden, resp. vielleicht auch beim Treiber dieses Chipsatzes.
Damit ist für mich die Thematik geklärt.