Comport-Exception abfangen und verbindung schließen

[delphifant]

Hallo messie,
ich werde nun als nächster Schritt try...except direkt beim senden und empfangen einsetzen. Bis jetzt hoffte ich, ich könne die Exceptions direkt an einen Punkt im Programm abfangen.

Das Senden läuft momentan auch schon über einen Timer... wenn du willst kann ich auch noch gerne Auszüge davon posten. Jedoch findet in der Timer-Routine nur die Verarbeitung der Antworten statt.

Fand es eine nette Lösung in der Sende-Prozedur eine gewisse Zeit auf die Antwort zu warten oder die Prozedur abzubrechen.

Aber ich lasse mich gerne eines besseren belehren und bin um jede Hilfe froh.

[messie]

Erkläre mal Deine Datenübertragung: machst Du Polling-Betrieb, bei dem vom externen Gerät nur auf einen Befehl hin gesendet wird oder schreibt das Gerät die Daten selbständig?

Grüße, Messie

[delphifant]

Hallo messie,
ich arbeite im Pooling-Betrieb. Ich sende meinen Gerät Befehle im IEEE-Standart (*RST) und mein Gerät meldet sich dann mit einer definierten Antwort z.B "OK<CR><LF>". Hier noch ein Außzug aus der

Dokumentation vom Elektroniker

Zitat:

Schnittstelle: virtueller COM-Port an USB
Baudrate: 921600
Datenbits: 8
Parität: keine
Stoppbits: 1
Handshake: OFF

Synchronisation: Es darf immer nur ein Befehl abgesetzt werden.
Jeder Befehl gibt eine Antwort, auf die der PC
warten muss. Erst dann ist das Gerät bereit für den
nächsten Befehl.
(Das erspart BUSY / READY Flags)

Ach, ich habe nun versucht direkt um meine Befehle zur Schnittstelle mit try..exception-Blöcke das Ergebnis ist jedoch das gleiche

Zitat:

... Klasse EComPort mit der Meldung WriteFile function failed (win error code: 5)' ...

[messie]

Also beim Abziehen des seriellen Kabels sollte es mit try..except klappen. Beim Abziehen des USB-Kabels trennt man die Verbindung zweischen Treiber und Hardware. Das habe ich auch noch nicht abfangen können.

Grüße, Messie

[delphifant]

Hallo messie,
genau da befindet sich mein Problem. Ich arbeite über USB.
Wenn der Konflikt zwischen Hardware und Treiber auftritt, aber ich kann mich auch täuschen, sollte ich nun die USB-Events abfragen und hoffen rechtzeitig darauf reagieren zu können.

Ich habe nun mal die USB-Events abgefangen...jedoch muss ich nun noch versuchen das Event herauszufinden welches mich betrifft.-> Also das Handle meinen Treiber zuzuordnen. Vielleicht gelingt es mir so.

Danke für die Hilfe

[Koonunga Hill]

Hallo Leute,

ich schlage mich mit genau dem gleichen Problem herum und bekomme nach dem Ziehen des USB-Kabels von der TComPort Komponente immer die Meldung PurgeComm Function failed on COM4.
Das Problem ist, daß ich den Port gar nicht mehr dis-connecten kann oder an einem anderen gültigen COM-Port anmelden kann. Auch das Abfragen der USB-Messages von WIndows hilft nicht weiter, da der Port ja schon 'weg' ist, wenn das Event auftritt.

Irgendeine Idee, wie ich den ComPort zur Laufzeit wieder DisConnected bekomme??

Gruß, Michael

[messie]

Schwierig.
Eigentlich geht es nur dann, wenn Du auch die Hardware der Gegestelle programmierst. Dann kannst Du eine Art Watchdogfunktion implementieren. Solange der Treiber keine eindeutige Antwort "Hardwareverbindung getrennt" liefert, bist Du weitgehend hilflos.
Das Problem ist, dass der Treiber bei abgezogener Hardware bisher in der Abfrage steckenbleibt. Dann kannst Du ihn auch nicht durch einen anderen Thread deaktivieren.
Wenn man es schaffen könnte, einen Windows-Treiber zur Laufzeit hart zu deaktivieren und neu initialisieren zu können, könnte das klappen, wenn der Treiber beim Fehler (Kabel abgezogen) eine Meldung macht.

Grüße, Messie