Problem mit serieller Schnittstelle (overlapped) - CloseHandle returned nicht!
-
Mox schrieb:
Bus-Error? Es geht hier um RS232.
RS232 ist ein serieller Bus.
Mox schrieb:
Und nach irgendwelchen Übertragungsfehlern kannst du das Handle immer schließen.
In seinem Fall wohl nicht.
Mox schrieb:
ClearCommError hilft Dir in diesem Falle auch nicht.
Das vermutest du, aber wir wissen es nicht.
-
_matze schrieb:
Was zur Hölle passiert da beim Kunden? ^^
Der einfachste Weg das herauszufinden ist, dass Du einen Speicherdump mit dem Taskmanager machst.
Du benötigst dafür dann für die Analyse die entsprechenden passenden PDB Dateien der Executables. Dann könntest Du Dir auch den Callstack anstehen und kontrollieren worauf "im inneren" wirklich gewartet wird. Ist natürlich nur Usermode... aber könnte evtl. helfen.
-
Andromeda schrieb:
Das vermutest du, aber wir wissen es nicht.
Ich habe ClearCommError eingebaut. Ich hoffe, dass ich die neue DLL morgen beim Kunden aufspielen kann.
-
_matze schrieb:
Andromeda schrieb:
Das vermutest du, aber wir wissen es nicht.
Ich habe ClearCommError eingebaut. Ich hoffe, dass ich die neue DLL morgen beim Kunden aufspielen kann.
Sag bitte Bescheid, wie der Versuch ausgegangen ist.
-
Andromeda schrieb:
_matze schrieb:
Andromeda schrieb:
Das vermutest du, aber wir wissen es nicht.
Ich habe ClearCommError eingebaut. Ich hoffe, dass ich die neue DLL morgen beim Kunden aufspielen kann.
Sag bitte Bescheid, wie der Versuch ausgegangen ist.
Wird bis nächste Woche warten müssen. Der Kunde will die Produktion nicht anhalten...
-
Andromeda schrieb:
Mox schrieb:
Bus-Error? Es geht hier um RS232.
RS232 ist ein serieller Bus.
Entweder RS232 oder Bus, aber nicht beides. Klemm doch einfach mal mehrere Geräte an Deinen "Bus"...
-
_matze schrieb:
Mox schrieb:
Bus-Error? Es geht hier um RS232. Und nach irgendwelchen Übertragungsfehlern kannst du das Handle immer schließen. Wenn das nicht funktioniert, geht was ganz anderes schief. ClearCommError hilft Dir in diesem Falle auch nicht.
Die Frage ist, was das sein könnte.
Mit dem DCB hast du Recht. Werde ich korrigieren. Das ist aber sicher nicht das eigentliche Problem, oder?
Es ist auf jeden Fall ein Problem, das korrigiert werden muss. Das bringt dich jedenfalls deutlich weiter als der Schwachsinn mit ClearCommError.
_matze schrieb:
Ich habe momentan einen Test hier im Büro laufen. Fast 500000 Kommunikationsversuche, alle erfolgreich. Ich kann das USB-Kabel ziehen und wieder dranstecken, und das Weiderverbinden funktioniert problemlos. Ich kriege dann halt Access Denied, dann suche ich mir wieder den richtigen COM-Port raus und es geht anstandslos weiter. Was zur Hölle passiert da beim Kunden? ^^
Das ist sicherlich ein Problem innerhalb Deines Treibers. Dieser ist als erstes zu aktualisieren. Und dann schau Dir die verwendeten Strippen an, notfalls einfach tauschen. Danach wird Ruhe sein.
-
_matze schrieb:
Andromeda schrieb:
_matze schrieb:
Andromeda schrieb:
Das vermutest du, aber wir wissen es nicht.
Ich habe ClearCommError eingebaut. Ich hoffe, dass ich die neue DLL morgen beim Kunden aufspielen kann.
Sag bitte Bescheid, wie der Versuch ausgegangen ist.
Wird bis nächste Woche warten müssen. Der Kunde will die Produktion nicht anhalten...
Wenn wir die Lösung des Problem auf den ClearCommError-Blödsinn schieben wollen, darfst Du zu Testzwecken aber auch nur diesen Part anfassen. Sonst zieht hier jemand am Ende noch falsche Schlüsse...
-
Mox schrieb:
Entweder RS232 oder Bus, aber nicht beides.
Doch, beides.
Mox schrieb:
Klemm doch einfach mal mehrere Geräte an Deinen "Bus"...
Mehrere Slaves geht bereits so. 10 Slaves bei 115kbps und über 5m Kabellänge haut hin (ausprobiert). Die Eingänge sind hochohmig genug, um den Master nicht zu sehr zu belasten. Für Multi-Master-Betrieb ist ein Software-Protokoll nötig, das die Busarbitrierung regelt.
Natürlich ist das eine Verfremdung von Rs232, das üblicherweise Point-to-Point-Protokoll ist. Aber hey, "Bussystem" bedeutet ja nicht per definitionem, dass es mehr als 2 Teilnehmer geben muss.
Was lernen wir daraus? Spitzfindigkeiten sind doof!
-
Mox schrieb:
Wenn wir die Lösung des Problem auf den ClearCommError-Blödsinn schieben wollen, darfst Du zu Testzwecken aber auch nur diesen Part anfassen.
Er sollte ClearCommError aufrufen, sobald ein Fehler detektiert wurde und vor dem CloseHandle. Lassen wir uns mal überaschen.
-
Kann es nicht sein, daß es wirklich ein Hardware-Fehler ist?
-
Wenn ftdi-Chip eingesetzt wird: ggf. testweise mal auf die d2xx Treiber und DLL umstellen und schauen, ob der Fehler dort ebenfalls auftritt.
Man könnte ggf. als Workaround auch schauen ob es generell Momente gibt, wo man den Port einfach mal regelmässig schließen und neu öffnen könnte - vllt. läuft im Treiber irgendein Counter über und verursacht dann Probleme oder so.
Man könnte auch mal einen anderen Wandler-Chip ausprobieren:
http://www.eevblog.com/forum/reviews/alternatives-to-ftdi-usb-to-uart-converter/(oder wenn man zuviel Zeit hat: Sich mit irgendnem usb-fähigen Mikrocontroller nen eigenen Wandler RS232 auf USB basteln und je nach benötigtem Speed auf USB-HID Klasse oder WinUSB wechseln)
-
geeky schrieb:
Man könnte auch mal einen anderen Wandler-Chip ausprobieren:
Oder einen Rechner mit richtiger RS232 Schnittstelle.
Das wären weniger Fehlerquellen.
-
DirkB schrieb:
geeky schrieb:
Man könnte auch mal einen anderen Wandler-Chip ausprobieren:
Oder einen Rechner mit richtiger RS232 Schnittstelle.
Das wären weniger Fehlerquellen.Geht leider nicht. Der Rechner hat RS232, aber das Gerät ist fix und kann nicht geändert werden. Das Design ist schon seit Jahren so. Das USB-Kabel läuft durch einen Kabelschlepp. Es ist ein Scanner, und die Wandlung von USB nach RS232 passiert ganz oben auf dem beweglichen Schlitten. Ob das so sinnvoll ist, sei mal dahingestellt. Aber die Scanner sind nun mal so gebaut und stehen seit Jahren so beim Kunden.
Ich habe letzte Woche den FTDI-Treiber auf die neueste Version (2.12.18) aktualisiert. Und heute morgen kam die Meldung vom Kunden, dass das System bislang ohne Probleme durchgelaufen ist. Das muss noch nichts heißen (der Fehler ist schon öfter nach mehreren Tagen wieder aufgetreten). Aber es ist schon mal ein gutes Zeichen.
Der bisher eingesetzte Treiber funktioniert tadellos auf vielen anderen Maschinen. Die Ursache wird also definitiv was anderes sein. Aber mit ein bisschen Glück händelt der neue Treiber den Fehler besser als der alte. Das wär ja schon mal was.
-
geeky schrieb:
Wenn ftdi-Chip eingesetzt wird: ggf. testweise mal auf die d2xx Treiber und DLL umstellen und schauen, ob der Fehler dort ebenfalls auftritt.
Schaue ich mir mal an, danke.
geeky schrieb:
Man könnte ggf. als Workaround auch schauen ob es generell Momente gibt, wo man den Port einfach mal regelmässig schließen und neu öffnen könnte - vllt. läuft im Treiber irgendein Counter über und verursacht dann Probleme oder so.
Interessante Idee. Ein Neuverbinden alle paar Stunden könnte ich natürlich einfach einbauen. Ich behalte es im Hinterkopf für den Fall, dass der neue Treiber nix bringt.
-
Falls es wen interessiert: in der letzten Version, die ich dem Kunden vor knapp 2 Wochen geschickt habe, habe ich ClearCommError eingebaut und Multithreading rausgeschmissen (ich hatte bislang die Status-Bits in einem Thread abgefragt). Seitdem habe ich keine Rückmeldung mehr vom Kunden bekommen. Ich bin nicht sicher, ob das ein gutes oder schlechtes Zeichen ist.
