[C#] USB COM Poort - Toegang Geweigerd

[Tepel]

Hallo allemaal,

Ik zit met het volgende probleem. Ik heb een applicatie die de COM poort die door een USB naar COM driver wordt gemaakt inleest. Tot dusverre geen probleem, alles werkt zoals het moet. Wanneer ik echter de USB kabel eruit trek kan ik niks meer met mijn poort.
Ik praat met de poort via de "SerialPort" class, deze verteld mij dat de poort nog open is terwijl de kabel er al lang en breed uit is. Ook is de poort niet meer de vinden in de SerialPort.GetPortNames() functie.
Ook wanneer ik mijn applicatie laat wachten totdat de poort er weer is, is de poort nog steeds ontoegankelijk.
Ik kan wel een nieuwe instantie maken van de SerialPort class maar dit lost mijn probleem slechts tijdelijk op. Wanneer ik mijn applicatie sluit geeft hij een melding dat hij de poort niet kan disposen omdat het een refentie is naar en null-object.
Ik hoop dat jullie het snappen (mijn verhaal en het probleem) want ik heb geen idee meer.

Oplossing!
Een drietal threads aanmaken die elk een dispose op de instance aanroepen. Allemaal in een try/catch en voila! Het is misschien niet de meest nette oplossing, maar het werkt!

[ Voor 9% gewijzigd door Tepel op 21-12-2006 22:16 . Reden: Solved!! ]

[H!GHGuY]

Jij kan er niet zoveel aan doen. Die driver handelt blijkbaar disconnect events slecht af.

Los daarvan is een COM-poort standaard helemaal niet pluggable tijdens het draaien van een PC.
Dit zorgt ervoor dat de SerialPort klasse niet opgewassen is tegen het verdwijnen van de unmanaged resource.

Misschien moet je proberen registreren op de USB disconnect event van het toestel en dan je SerialPort sluiten en wachten tot ie terug is.

[Tepel]

Mjah maar dan los ik het probleem niet op denk ik. De SerialPort instance die ik reeds heb zal nog steeds corrupted zijn aangezien die niet snel genoeg de poort kan disposen. Maar ik had al zo'n idee dat ik er niks aan kon doen.
Momenteel is het enigszins opgelost door de oude instance te overschrijven met een instance met hier en daar wat sleeps omdat het anders een exception geeft En voor de rest is het hopen dat de garbage collector de de oude opschoont. De ene keer gaat het wel goed de andere niet, maar veel meer kan ik dus blijkbaar niet doen.

In ieder geval bedankt voor je bijdrage!

[ Voor 3% gewijzigd door Tepel op 12-10-2006 19:31 ]

[farlane]

Ik zou zeggen genrbruik een andere USB<->serial converter want er zit nogal wat verschil in de kwaliteit van de drivers die er bij die dingen zitten.

Zelf gerbuik ik een kabel gebaseerd op een FTDI chip en die doet het behoorlijk goed.

[CodeIT]

Ik ben zelf ook bezig met een project die tegen ons apparaat praat via een USB<->Serial (TUSB3410 van TI). Als ik deze eruit trek krijg ik netjes een exception van de SerialPort class. Ik dispose dan die COM poort en dan gaat het programma wachten tot de compoort weer in de lijst komt te staan.
Ik denk dus dat je misschien even moet kijken naar een ander converter chip (of kant en klare converter) of naar nieuwe drivers voor je bestaande.

[Tepel]

Ik heb geen converter er tussen hangen. De USB connector gaat direct in de PC. Een driver daarop zorgt ervoor dat er een COM poort voor wordt aangemaakt.
Het is momenteel redelijk opgelost, het programma crasht niet meer en kan zonder al te veel problemen een nieuwe SerialPort instance maken. Het zit als volgt:

Via een <app>.exe.config geef ik aan dat ik alle exceptions zelf wil afhandelen.
(Microsoft Feedback site gaf me deze oplossing)

code:

<configuration>
    <runtime>
        <legacyUnhandledExceptionPolicy enabled="1"/>
    </runtime>
</configuration>

SerialPort geeft exception wanneer kabel eruit getrokken wordt en gaat in slaap modus.
Ander thread wat draait heeft (meestal) het USB disconnect event gesignaleerd (ManagementOperationObserver, WqlEventQuery en ManagementEventWatcher) en gaat vervolgens de SerialPort instance disposen (om de een of andere reden mag het in deze thread wel) En zegt daarna tegen het andere thread dat ie weer een nieuwe instance moet maken. Daarna draait alles weer vrolijk verder.
Het enige probleem is dus dat het USB disconnect event niet altijd binnenkomt. Hoe dit precies zit weet ik nog niet en ik betwijfel dat ik daar achter kom.

En meer valt er niet te doen, er zit dus blijkbaar een probleem in die driver die de boel niet netjes afhandeld. Maar ach, als het niet gaat zoals het moet dan moet het maar zoals het gaat.

[ Voor 3% gewijzigd door Tepel op 13-10-2006 16:20 ]

[farlane]

Tepel schreef op vrijdag 13 oktober 2006 @ 16:20:
Ik heb geen converter er tussen hangen. De USB connector gaat direct in de PC. Een driver daarop zorgt ervoor dat er een COM poort voor wordt aangemaakt.

Dat werkt bij alle USB<->RS232 kabels zo. Bij sommige krijg je een API om direct de USB driver aan te spreken en die maakt dan geen virtuele compoort aan.

Het enige probleem is dus dat het USB disconnect event niet altijd binnenkomt. Hoe dit precies zit weet ik nog niet en ik betwijfel dat ik daar achter kom.

Is er misschien nog een of andere status die je kunt pollen?

[Tepel]

Het aparte is dat wanneer ik hetzelfde usb detectie gebeuren in een console-app gooi ik wel alle events zie ongeacht hoe snel ik dat ding in en uit plug. Het is puur wanneer ik hem in mijn UI zet dat ik niet alle events binnenkrijg. Heb al geprobeert thread priority hoger te zetten maar dat mocht niet baten.
Dus ik ontvang het event wel, dus de WqlQuery is goed. Alleen de UI is te traag om te reageren of iets dergelijks. De WqlEventQuery draait in event mode, dus zolang mijn applicatie draait, draait dat event ook en zou hij af moeten vuren zodra ik de usb unplug. Ik denk dat er op het moment dat ik de usb-connector unplug en dus de SerialPort instance 100% cpu gaat vreten er te weinig over is voor de rest van de threads. Dat zou verklaren waarom de detectie wel goed werkt wanneer de usb-connector lang uit het systeem is.
In ieder geval, ik pruts nog even verder. Wanneer ik het echt niet meer weet dan laat ik het zoals het nu is, de applicatie blijft nu ten aller tijden draaien. Database mag wegvallen en hij schijft alles tijdelijk weg in een bestand totdat de DB weer up is. USB mag wegvallen en dan meestal de SerialPort instance opnieuw aangemaakt. Dus het is bijna perfect, alleen deze verkeersdrempel nog.

[farlane]

Tepel schreef op zondag 15 oktober 2006 @ 15:13:
Ik denk dat er op het moment dat ik de usb-connector unplug en dus de SerialPort instance 100% cpu gaat vreten er te weinig over is voor de rest van de threads.

Dan zit er een manco in je applicatie. 100% CPU vreten is niet goed.

[Tepel]

Nope, het is echt een probleem in de SerialPort instance. Want zodra mijn app ontdekt dat de poort gaar is gaat hij naar slaapstand. Dat wil zeggen, een loop die iets controleerd of hij nog moet slapen om vervolgens weer verder te slapen, 0% CPU load dus. Het zit hem echt in de .NET resource. Dit is bij mij nog eens bevestigd op een microsoft site, ff zoeken ....
[100% CPU load]
[Exception uit SerialPort thread]
Dus, het is echt iets waar ik niks aan kan doen.

[farlane]

Tepel schreef op zondag 15 oktober 2006 @ 19:00:
Nope, het is echt een probleem in de SerialPort instance. Want zodra mijn app ontdekt dat de poort gaar is gaat hij naar slaapstand. Dat wil zeggen, een loop die iets controleerd of hij nog moet slapen om vervolgens weer verder te slapen, 0% CPU load dus. Het zit hem echt in de .NET resource. Dit is bij mij nog eens bevestigd op een microsoft site, ff zoeken ....
[100% CPU load]
[Exception uit SerialPort thread]
Dus, het is echt iets waar ik niks aan kan doen.

Mijn God je hebt gelijk, had er even niet bij stilgestaan dat je .Net code aan het rammelen ben. Ik verbaas me elke keer weer over hoe die gasten een heel simpel ding toch weer moeilijk kunnen maken.

[Tepel]

Hehe
Het is misschien niet een van de meest perfecte programmeer talen, of de meest performance gerichte, of iets anders. Maar het is wel makkelijk
Ik heb er nog over gedacht om geen gebruik te maken van de SerialPort class en dus zelf met een setje dlls aan de slag te gaan. Maar dat was mij in eerste instantie teveel gedoe maar zoals het programma nu is opgebouwt kan ik dat, mocht dat nodig zijn, nog steeds doen. Dus is er een kans dat wanneer ik zelf een soort van SerialPort class maak dat dit probleem dan verdwijnt? Want dan is het misschien de moeite waard.