Unable to open Comport (Error 1117) nach einigen Connects

[Captnemo]

Hi,

ich habe eine Anwendung, in der ich folgende Komponente verwende: http://comport.sf.net/
Eine Komponente für die Ansteuerung des Com-Ports.

Ich verbinde mich regelmäßig mit einen Gerät, lese Daten aus, und trenne die Verbindung wieder.

Nach einiger Zeit, also einigen Hundert Connects, tritt plötzlich der Fehler "unable to open comport (Error 1117)" auf. Dann kann ich nicht mehr über den Comport connecten.
Wenn ich meine Anwendung beende und direkt wieder starte, geht es wieder einige hundert Male, bis der Fehler wieder auftritt.

Nach dem was ich bisher über den Fehler herausgefunden habe, ist dass ein Windowsfehler beim Zugriff auf das IO-Device aufgetreten ist. Aber ich brauch nur die Anwendung neu starten, schon geht's wieder.

Das einzige, was beim Start zusätzlich passiert, ist das erzeugen des Objektes TComport.
Hat einer eine Idee, woran das liegen kann?

[himitsu]

Und warum lässt du die Verbindung nicht einfach offen?

[dummzeuch]

Zitat von Captnemo:

Ich verbinde mich regelmäßig mit einen Gerät, lese Daten aus, und trenne die Verbindung wieder.

Nach einiger Zeit, also einigen Hundert Connects, tritt plötzlich der Fehler "unable to open comport (Error 1117)" auf. Dann kann ich nicht mehr über den Comport connecten.
Wenn ich meine Anwendung beende und direkt wieder starte, geht es wieder einige hundert Male, bis der Fehler wieder auftritt.

Das kenne ich nur, wenn der Port nicht sauber geschlossen wird, z.B. noch ein Thread darauf wartet, dass Daten kommen. Dann blockiert die Anwendung sich selbst dabei, den Port zu oeffnen.

twm

[mensch72]

leider ist das Beschriebene im Bereich des Vorstellbaren, aber ohne weitere Details kaum zu analysieren...

1. Sind es wirklich "noch echte Comports", oder doch PICe oder gar USB Ports ?
2. z.B. bei USB etwas irgendwas "bekanntes" wie FTDI oder was "exotisches"
3. sicher, das auch alle Puffer sauber threadsicher freigegeben werden? (Also nach ComClose alle genutzten(einmal übergebenen) ReadBuffer noch eine Zeit lang gültig sind?
4. warum eigentlich den Port nicht offenlassen?
5. auch wirklich alle möglichen Errors "richtig" behandelt (BufferOverflow,TimeOut,Frameing,Parity,CommBreak, ...) ?


Fragen über Fragen...

[Captnemo]

Danke für eure Antworten.

Zur Frage, warum ich den Comport nicht einfach über die gesamte Laufzeit offen lasse:
Leider ist es so, dass das auszulesende Gerät (in meinem Fall ein Scheitholzofen) zwar diese Funktion unterstützt in festen Abständen Werte zu senden, aber nach einer gewissen Zeit kamen die Werte immer mehr zeitversetzt.
Darum habe ich versucht, Verbindung aufbauen, Werte abfragen, Verbindung wieder schließen.

Zur Verbindung nutze ich ein IPEther von IPCAS (RS323 over Ethernet) und habe auf meinem Computer eben nur einen virtuellen Comport.
Natürlich prüfe ich vorher, ob der TComport noch connected ist, was er mit False zurückliefert.
Aber die Theorie, dass wohl irgendwas nicht richtig geschlossen ist, erscheint mir an naheliegendsten.

Ich werde mal eine andere Kompoente ausprobieren.

[himitsu]

Solange über RS232 keine Softwarseitige Rückmeldung vorhanden ist, bekommt man eh nicht mit, ob am anderen Ende einer mitliest (Comport offen) oder nicht (geschlossen).
Demnach kann man im Prinzip den Comport auch einfach offen lassen und braucht maximal die Komunikation neu zu initilisieren. (z.B. Startcodes erneut senden)

Das Einzige wo man wirklich den Port schließen muß, ist wenn der Comport verschwand. (bei dir z.B. durch trennen der IP-Verbindung)


Sicher daß das Problem nicht auf Seite des Netzwerks (LAN/WLAN) liegt?
IP-Verbindungen bleiben gern mal offen.

[Klaus01]

Guten Morgen,

kann das IPCAS nicht so betrieben werden, dass Du dich nicht um den Comport kümmern musst.
Und das Endgerät via IPCAS über TCP (Telnet, TCP-Client/Server) ansprechen kannst?

Grüße
Klaus