Serialport: Schließen und dann wieder Öffnen?

Hallo!

Ich versuche mittels System::IO::Ports::SerialPort mit einem Gerät zu arbeiten. Das erste Öffnen eines Objekts der Klasse SerialPort funktioniert scheinbar, genauso wie das Schließen mit obj::Close(). Allerdings habe ich den Eindruck, dass nicht alles durch Close() gelöscht wird, weil ich danach nicht mehr mit dem Gerät kommunizieren kann, worin mein Problem besteht.

LG!

theta

ja dann würde ich den port einfach wieder öffnen...

Hehe. Das klappt ja grad nicht.

Also um die Unklarheit zu beseitigen:

Wenn ich nach Close wieder Open möchte, passiert nichts mehr.

Mmacher

Es kann je nach Hardware noch einige Sekunden (eher bis zu einer halben Minute) dauern, is der COM-Port geschlossen, geöffnet und wieder verfügbar wird.
Das kann am Treiber liegen (z.B. die Treibersoftware von Prolific USB-to-Serial Konverter ist da schon ein wenig "träge"), aber auch der Plug-and-Play Mechanismus von Windows blockiert den Port für einige Sekunden.

Woran erkennst Du, daß nix mehr geht?
Wertest Du die Rückgabewerte beim Close und beim Open aus?

Bin zwar aus dem "Win32-API" Lager, aber das Prinzip ist überall das gleiche.

Martin

Jochen Kalmbach

Ich vermute eher, das Close hängt... das aufmachen sollte eigentlich gehen...
Close sorgt nämlich dafür, dass alle im Sendepuffer enthaltenen Zeichen *sicher* gesendet werden; das kann bei Handshakes zu Problemen führen...

Hi, danke!

Mein Programm zeigt immer wenn vom Gerät Daten kommen diese in einer Gui an.
Wenn ich jetzt aber die Methode anwende, in der sp->Close() vorkommt endet wie erwartet auch das Anzeigen und beim Breaken steht das Programm vor dem Return des Main. Aber wenn ich wieder die Methode, die Open enthält aufrufe, bleibt es dort. Es kommt auch nichts.

Besonders fieß ist, dass ich abziehen muss, um nach einem Neustart des Programms wieder Daten zu bekommen, selbst wenn das Programm beendet worden ist.

Jochen Kalmbach

Wie Mmacher vermutet, wird es am Treiber liegen... was ist es denn für ein seriellen Port? Direkt an dem Rechner? (vermutlich nicht, oder?)

Mmacher

FromRags schrieb:

Besonders fieß ist, dass ich abziehen muss, um

Das deutet auf einen USB-to-Serial Konverter hin, bin ich richtig in der Annahme?

Darf ich erfahren, welcher Typ (Hersteller) von Konverter im Einsatz ist?
z.B. Prolific, FTDI, Silabs, ... ???

Ich benutze einen GPS-Empfänger an einem USB-Port (ublox Antaris Lea 4T).
Wie findet man heraus über welchen Converter das läuft?

Mmacher

Über Systemsteuerung -> System -> Hardware / Gerätemanager, im Tree-Baum den entsprechenden Eintrag auswählen und "Eigenschaften" wählen.

Hab auf der Homepage von u-blox nachgesehen.
http://www.u-blox.com/en/gps-modules/timing-modules/lea-5t.html

Dort ist allerdings schon der Nachfolger LEA-5T zu sehen, mit "Easy migration from LEA-4T modules".
Dies könnte auch bedeuten, daß die PC-Software und/oder der Treiber von LEA-5T abwärtskompatibel zu LEA-4T ist, muß aber nicht.

Daher nur ein vager Hinweis von mir: Versuchs mal mit der neueren Software von LEA-5T
Martin

Mmacher

Nachtrag:
Es besteht auch eine theoretische Möglichkeit, daß der (nicht ganz idiotensichere) Treiber bei "unüblichen" Zuständen in den Steuerleitungen RTS und DTR aus dem Tritt kommt?

Also vielleicht hilft da ein Workaround, bei dem Du vor dem Close die (virtuellen) Leitungen RTS explizit auf "OFF" und DTR auf "ON" setzst? (bzw. mit anderen Kombinationen experimentieren)

Weitere Möglichkeit eines Workarounds: Vor dem Close den Puffer löschen (irgendwas mit einer "Purge"-Funktion, hab nicht grad zur Hand).
Martin

Vielen Dank für Eure Hilfe.

Vermutlich sind "DiscardInBuffer" und "DiscardOutBuffer" die "Purge"-Funktionen?
Ich habe die beiden schon am Anfang eingesetzt, das Problem bestand dennoch.

Ich habe jetzt auch Permutationen von RTS und DTR ohne Erfolg probiert.

Der Treiber zu meiner Lea-4T ist auf dem neuesten Stand.

Mmacher

Zumindestens in Win32-API: PurgeComm(), mit allen 4 Flags im Parameter
http://msdn.microsoft.com/en-us/library/aa363428(VS.85).aspx

So langsam werde ich ratlos.
Bleibt noch die Möglichkeit, daß Du vor dem Öffnen des seriellen Ports immer ALLE Kommunikationsparameter (in Win32-API: alle Member von der Struktur DCB) korrekt eingestellt hast.
Auch diese, die für Deine Aufgabe scheinbar ohne Belang sind! Z.B. die oft unterschätzte Auswirkung einer Nicht-Definition von Parameter fDsrSensitivity und fAbortOnError.

Weitere Testmöglichkeit: Wie ist denn das Verhalten, wenn Du den COM-Port mit dem Windows-eigenen Hyperterminal schließt und wieder öffnest?
Gleiches Symptom?

Martin

Mmacher schrieb:

Weitere Testmöglichkeit: Wie ist denn das Verhalten, wenn Du den COM-Port mit dem Windows-eigenen Hyperterminal schließt und wieder öffnest?
Gleiches Symptom?

Da funktioniert die Verbindung völlig normal.
Ich verbinde, trenne, verbinde, trenne, alles frei Nase.

Übrigens habe ich inzwischen einen anderen uBlox-Receiver zur Probe angeschlossen. Er packt das auch ohne große Probleme. Verbinden, Trennen, Verbinden, Trennen.... mit dem gleichen Programm.

Ich denke, dass ich den Leuten von uBlox jetzt eine Mail schreiben werde.