PureBoard

Scheint noch ein anderes Problem zu sein.
Ich habe jetzt auch das Timeout, so wie du es bei dir hast
einmal im Dialog mit aufgenommen mit dem ersten Wert 300,
sowie nach dem OpenSerialPort() eingefügt. Da ändert sich anscheinend
nicht viel. Nun bleibt mir wohl noch die Abfrage der Leitungen über.

Schade, das ich Spätschicht habe, sonst könnte ich mich intensiver damit
beschäftigen und einiges hinzufügen, wie die Abfrageleitungen usw. .
Ich danke dir erst mal für deine schnelle Hilfe

Gruß,
Falko

Bei älteren Anlagen mit seriellen Schnittstelle ist es manchman hilfreich den FIFO für den COM-Port in der Gerätesteuerung von Windows herunterzunehmen oder auszuschalten.

XON und XOFF sind keine Hardwareüberprüfung, sondern Steuerzeichen. Siehe ASCII-Tabelle. Mit XON wird die Empfangsbereitschaft gemeldet und mit XOFF wieder abgemeldet. Somit reichen die Signal RX,TX und GND für den Datenaustausch.

Das steuern der RTS und CTS übernimmt immer der COM-Port im Datenverkehr. Dazu muss dieser aber auf beiden Seiten gleich eingestellt werden.
Die möglichkeit diese Signale zu steuern ist nur bei besonderen Fällen erforderlich. Zum Testen oder bei Sondermachinen die sich nicht an die Spezifikationen halten.

Übertragungsfehler bei hoher Übertragungsrate sind natür zu erwarten. Die entstehen bei schlecht abgeschirmte Kabel, fehlerhafte Erdung, Kabel zu lang oder nur dadurch das der COM-Port einfach nur alt ist. Ich stelle für eine sichere Übertragung meistens die Rate nicht über 19200 Baud ein.

FF

Stimmt alles was du geschrieben hast.
Ich habe für die Heidenhainsteuerung max. 2400Baud zur Verfügung. die maximale Com-Geschwindigkeit habe ich nur auf meinem PC getestet. Beide Seiten sind gleich. Even ist eingestellt, RTS/CTS auch. Sogar die TimeOut, habe ich verschiedene
Werte probiert. StopBit ist 1.0, aufgrund der Variable Float in PB.

Testweise habe ich ein 3m Nullmodemkabel dort zwischen zwei USB2Serial-Adapter in ein und den selben PC gesteckt.
Egal ob langsam oder max. Geschwindigkeit, die Fehlermeldung ist die gleiche über die drei Hardwarefehler, wie oben beschrieben. Ich hatte zuerst ohne diese Funktion alles getestet.

Also tausend Zeilen CNC-Code laufen komplett durch und werden auch komplett ohne Fehler empfangen. Nur die PB-Fehlerroutine meldet Fehler. Ich habe dort auch im Programm noch kein Xon und Xoff mit ASCII-Code eingebaut.
Also rein nur Com-Portname, Baudrate, Parität,Handshake, Data, Stopbit, welche sich über Comboboxen mit allen
Einstellungen einstellen lassen sowie TimeOut, wo ich in einem StringGadget 300 eingegeben habe und wie Alexander nur
den letzten Wert ändere. An RTS und CTS per Software steuern habe ich keine Funktion eingebaut, die eigentlich der PC
automatisch machen sollte. So sieht es wenigsten im SerielPort-Tester mit seinen roten und grünen LEDs, weiter oben beschrieben aus. Warum dann trotz Paritätsfehler und die beiden anderen Hardwarefehlermeldungen trotzdem die Daten ohne Verlust rüber kommen ist mir ein wunder.
Da es läuft ist es ja soweit gut. Die Fehlermeldungen brauche ich ja nicht unten in der Statusleiste ausgeben, wenn sonst
alles bei allen Geschwindigkeiten funktioniert.

Gruß,
Falko

@Dari
Ich habe jetzt den Fehler durch den Vergleich mit deinem Programm endlich beseitigen können.
Das war wohl ein Fehler von mir. Ich dachte, man müsste nur einfach nach dem WriteSerialPort sowie
ReadSerialPort einfach nur die Fehlerroutine aufrufen. Dabei fiel mir auf, das du eine Variabel für den
Rückgabewert (tick) benutzt die bei 0 erst die Fehlerroutine aufruft und nicht so wie bei mir, ohne
Rückgabevariable einfach die Errorabfrage jedes mal aufruft. Ich habe jetzt auch die Bedingung mit
der Variable so wie du es gemacht hast eingefügt und nun läuft es korrekt, denke ich.
Sobald Daten nicht gesendet oder empfangen werden, kommt die Errorabfrage in Aktion.

Somit hat sich dieses Problem erledigt.

Gruß,
Falko