Hallo an alle,
zwar gab es hier (unter dem o.a. Suchbegriff, jedoch für die
Programmiersprache C) schon mal so eine Anfrage, aber als nicht allzu
perfekter VB-Hobbyprogrammierer habe ich davon absolut nichts begriffen.
Meine Frage an Euch: Wie bekomme ich unter Visual Basic die VID- und
PID-Nummer einer Virtuellen COM-Schnittstelle heraus?
Der Hintergrund ist folgender: Wenn man den PC über die
USB-Schnittstelle erstmalig mit einen neuen FT232RL, bzw. mit einem
Gerät verbindet, welches diesen Chip als USB/UART-Konverter verwendet,
dann sucht sich das Betriebssystem beim Hersteller (FTDI) selbsttätig
den zugehörigen virtuellen COM-Treiber, installiert diesen und ordnet
genau diesem Chip eine eigene, neue Serielle COM-Schnittstelle zu, z.B.
COM37. Diese Schnittstelle wird von nun an jedes Mal bereit gehalten,
sobald der Anwender das mit diesem Chip bestückte Gerät erneut
anschließt.
Damit nun das PC-Programm mit dem Gerät kommunizieren kann, muss es aber
den Namen dieser COM-Schnittstelle kennen. Sofern der Anwender bei der
Erstinstallation gut aufgepasst hat, kann er diesen Namen über eine
Edit- oder ListBox in sein Programm manuell eintragen. Wenn er bei der
Erstinstallation aber nicht aufgepasst oder wenn er die Nummer
schlichtweg vergessen hat und er sich außerdem mit dem
Windows-Gerätemanager nicht auskennt, sollte das Programm auch später
noch jederzeit in der Lage sein, selbsttätig nach dieser bisher
unbekannten Schnittstelle zu suchen.
Ich hatte das bisher so implementiert, dass das Programm eine Liste
aller aktuell verfügbaren COM-Schnittstellen anlegt und nacheinander
folgendermaßen abarbeitet:
* Schnittstelle geschlossen?
* Wenn nein => sofort nächste Schnittstelle! Wenn ja => weiter!
* aktuelle Einstellung (Baudrate, etc.) sichern
* korrekte Baudrate einstellen
* Schnittstelle öffnen
* Schlüsselwort hineinrufen
* maximal 100 Millisekunden auf Antwort vom angeschlossenen Gerät warten
* Wenn keine Antwort => Schnittstelle schließen,
alte Einstellung restaurieren,
nächste Schnittstelle ausprobieren (s.o.)!
* Wenn letzter Eintrag =>
Message-Dialog mit entsprechender Meldung,
nochmal versuchen / Programm schließen
* wenn Antwort => Suche beenden, Schnittstelle verwenden,
Name fürs nächste Mal in Registry eintragen!
Leider ist dieses Verfahren ein ziemlich übler Programmierstil, denn das
Programm vergreift sich dabei an Schnittstellen, an denen es absolut gar
nichts zu suchen hat. Denn sobald irgendeine andere laufende Anwendung
auf dieselbe (ihre eigene!) COM-Schnittstelle zugreift, d.h. wenn es sie
öffnen will, während die eigene Anwendung diese Schnittstelle gerade
geöffnet hat, muss es zwangsläufig zu einer schweren Störung des fremden
Programms kommen. Dies geschieht bei mindestens einem der Anwender
wiederholt.
Ich hatte zuletzt die Idee, die Liste der COM-Schnittstellen wenigstens
insoweit einzudampfen, dass nur noch diejenigen mit der VID
(Hersteller-Identifikations-Nr.) und PID (Produkt-Indentifikations-Nr.)
des FT232RL abgefragt werden (die ebenfalls abzufragende einzigartige
Seriennummer des Chips ist zu diesem Zeitpunkt ja noch unbekannt). Das
Abfragen dieser Nummern geht auf manuellem Weg über den Gerätemanager
sehr leicht, aber unter Visual Basic fand ich keinerlei diesbezügliche
Funktionen. Aber selbst wenn ich das hinkriegen würde, wäre es immer
noch Murks, denn es kann ja durchaus sein, dass an einem PC mehrere
gleiche oder unterschiedliche Geräte mit einem FT232RL angeschlossen
sind. Als letzten Ausweg hätte ich nur noch die Idee, dem Anwender bei
der Erstinstallation den Betrieb fremder Anwendungen komplett zu
verbieten - eine eigentlich nicht mehr zeitgemäße Empfehlung!
Deshalb meine Frage: Hat jemand von Euch eine Idee, wie man das Problem
sonst noch irgendwie vernünftig lösen kann? Gibt es unter VB vielleicht
eine Funktion, wonach man die verfügbaren COM-Schnittstellen nach der
Zeitdauer ihrer aktuellen (USB-) Steckverbindung abfragen kann? Dann
könnte man dem Anwender ausgeben, er möge doch mal kurz den USB-Stecker
zum Gerät rausziehen und wieder reinstecken. Natürlich sollte das alles
auch noch von einem VB-Hobbyprogrammierer realisierbar sein ...
:
Bearbeitet durch User
Hallo. Falls du nur FTDI hast, dann kannst du die FTDI Bibliothek nehmen (ftd2xx.dll) und dir die API anschauen: FT_ListDevices und FT_GetComPortNumber sind deine Freunde. Grüße
Hallo Marcus, wie kriegt man diese DLL (oder einen Verweis dorthin) in das VB-Programm??
Hi. Ich selber programmiere nicht in VB, aber hier mal der Guide: http://www.ftdichip.com/Support/Documents/ProgramGuides/D2XX_Programmer's_Guide(FT_000071).pdf Und hier: http://www.ftdichip.com/Support/SoftwareExamples/CodeExamples/VB.htm Grüße Marcus
Norbert G. schrieb: > (oder einen Verweis dorthin) Zur DLL gibt es eine Header Datei FTD2XX.H welche die Bezüge (API) liefert. Wie man das in VB macht wird wohl die Hilfefunktion liefern. (wenn es überhaupt geht)
Hallo Marcus, hallo "InschenJöhr", herzlichen Dank für Eure Tipps! Ich fürchte aber, dass mir das nicht weiterhilft. Bekanntlich gibt's für den FT232RL zwei unterschiedliche Treiber, nämlich das anscheinend sehr mächtige so genannte DirectDriver-Interface (FTD2XX.DLL) und den wesentliche einfacheren Virtuellen-COM-Port (VCP). Weil ich damals (beim Gesamtentwurf) bei den Erläuterungen zum D2XX-Interface nur Bahnhof verstand (und auch nur die Funktionen einer Seriellen Schnittstelle zu benötigen glaubte - eine DLL ist für mich heute immer noch "Höhere Mathematik" - hatte ich mich für den sehr einfach zu handhabenden VCP entschieden. Eine Umstellung meines Programms (sofern ich das überhaupt hinbekäme) würde so ziemlich alles auf den Kopf stellen. Zudem schreibt der Hersteller FTDI (in der von Euch genannten Quelle): For Linux, Mac OS X (10.4 and later) and Windows CE (4.2 and later) the D2XX driver and VCP driver are mutually exclusive options as only one driver type may be installed at a given time for a given device ID. In the case of a Windows system running the CDM driver, applications may use either the D2XX or VCP interface without installing a different driver but may not use both interfaces at the same time. Ich kann also den VCP-Treiber und das DirectDriver-Interface nicht gleichzeitig verwenden. Ich hatte stattdessen gehofft, dass es direkt unter Visual Basic Funktionen gibt, mit deren Hilfe man auf VID und PID zugreifen kann. Schließlich geht das ja (in manueller Form) über den Geräte-Manager - also übers Betriebssystem - sehr wohl. Aber anscheinend hat Microsoft als Entwickler von Visual Basic solche Funktionen für überflüssig gehalten :-(
Hallo Norbert. Das heißt hier nur, dass du nicht Gleichzeitig zugreifen kannst, ist ja klar. Wenn du die ftdi dll aber nur dazu verwendest, anfangs herauszufinden wie der richtige Comport zum Device heißt, dann kannst du normal mit VCP weiterarbeiten... So, Feierabend. Marcus
Hast Du schon mal auf der FTDI Seite unter FTDI Utlities geschaut. Da gibt es div. Tools um einen FTDI Chip zu erkennen. Hier gibt es auch ein Tool FT Prog, wo der Chip programmiert werden kann. Es kann die Serien Nr. die Kennung usw. verändert werden. Die Werte werden im EEProm gespeichert, das ist z.B. auch notwendig um den Chip beim einstecken zu erkennen, es könnten auch andere FTDI am Pc dran sein, wie willst Du " Deinen " Chip wieder erkennen. Das kann auch über die Serien Nr. gemacht werden. Aber Achtung niemals zwei FTDI mit gleicher Serien Nr. am PC anstecken, der Treiber verabschiedet sich dann. Ist leider sehr umfangreich, aber vielleicht hilft Dir das weiter.
Hier gibts ein Bsp. in VB: http://community.silabs.com/t5/Interface-Knowledge-Base/Obtaining-Device-Notification-for-USB-Device-Arrival-and/ta-p/137957 Hier die verwendete API-Funktion: https://msdn.microsoft.com/en-us/library/windows/desktop/aa363431(v=vs.85).aspx
Hallo, herzlichen Dank für Eure zahlreichen Tipps! Tatsächlich habe ich inzwischen auf den Seiten von FTDI ein für mich halbwegs verständliches VB-Beispielprogramm gefunden und runtergeladen. Ich finde es sehr reizvoll, in einem eigenen Programm selbst auf die ganzen Möglichkeiten, die der Chip bietet, zugreifen zu können. Natürlich kenne ich auch das Tool FT-Prog, aber damit kann man eben nur manuell auf die Daten im Chip zugreifen, nicht aber über ein eigenes Programm. Das Problem ist nämlich, dass inzwischen mindestens 100 Geräte mit je einem FT232RL ausgeliefert sind und ich den Anwendern in einem Update unmöglich zumuten kann, dass sie dessen Seriennummer oder irgendein anderes Merkmal individualisieren. Das überarbeitete PC-Programm muss also irgendwie mit (alten und neuen) jungfräulichen Chips klarkommen. OS trifft mit seiner Frage "Wie willst Du 'Deinen' Chip wiedererkennen?" genau ins Schwarze. Ich denke, ich wähle für das fällige Update die Methode mit dem Abziehen und erneuten Draufstecken des USB-Steckers. Dabei verändert sich im Betriebssystem die Liste der verfügbaren COM-Schnittstellen um genau diejenige, deren Namen das Programm zu suchen hat. Es muss nur noch genau diesen Eintrag ausfiltern. Das sind alles Funktionen, die in VB verfügbar sind und deshalb krieg ich das auf jeden Fall hin. Trotzdem werde ich mich anschließend intensiv mit den VB-Beispielprogrammen für die FTD2XX-Funktionen befassen. Herzliche Grüße und Danke für Eure Zuschriften! Norbert
Mit FT_Prog kann man zumindest in den Chip eine eigene Hersteller- und Produktbeschreibung im Chip hinterlegen. Das könnte es Dir künftig leichter machen. Was man tunlichst nicht tun sollte ist, an den PID- und VID-Einstellungen zu spielen, wenn man keine Möglichkeit hat den Treiber neu zu signieren.
:
Bearbeitet durch User
Hi. Schon mal serialdevice probiert? https://docs.microsoft.com/en-us/uwp/api/Windows.Devices.SerialCommunication.SerialDevice
:
Bearbeitet durch User
Wolfgang H. schrieb: > Hi. Schon mal serialdevice probiert? Das gibt es aber nur für Win10 UWP Apps. Noch besser wäre dann aber wohl die DeviceInformation Klasse: https://docs.microsoft.com/en-us/uwp/api/windows.devices.enumeration.deviceinformation
Übrigens kann man auch mal die Registry durchgraben. Dort bekommt man erstaunlich viel über COM Ports heraus. VID:PID sollte mit drin sein.
Dachte hätte UWP irgendwo gelesen. Kommt ja auch auf das Gerät an wo das Programm läuft. Als UWP geht's auch auf dem Handy oder raspberry weil dort keine DeviceInformation gibt.
@ Guest:
In meiner Entwicklungsumgebung (Visual Basic 2010 Express unter Win7)
finde ich leider keinen "Namespace" (?) mit der Zeichenfolge
"Windows.Devices.Enumeration". Nach dem Punkt hinter Windows wird nur
noch "{Forms}" angeboten, alles andere ist unbekannt. Das Gleiche
geschieht, wenn ich vor dem Schlüsselwort Windows noch "System."
schreibe. Offenbar handelt es sich um eine relativ neue Funktion, die
nur unter Win10 verfügbar ist. Hierauf deutet auch die in der zitierten
Quelle enthaltene Angabe hin:
Device family: Windows 10 (introduced v10.0.10240.0)
Hingegen muss die Anwendung auch unter älteren Betriebssystem-Varianten
lauffähig bleiben. Schade! Trotzdem danke.
@ TurboJim:
Ja - in der Windows-Registry habe ich auch gestöbert und bin in
Abteilungen fündig geworden, wo ich es nie erwartet hätte. Allerdings
fand ich dort auch "Leichen" von COM-Schnittstellen, die ich
(wohlgemerkt über den Gerätemanager!) längst gelöscht hatte (weil die
Anzahl der vergebenen COM-Schnittstellen wegen zahlloser Fremdgeräte,
die mal irgendwann bei mir waren, einfach zuviele geworden waren). Das
war mir dann doch zu joker.
Ich bleibe also bei der Lösung, die zugehörige COM-Schnittstelle durch
einen Listenvergleich beim Ziehen/Wiedereinstecken des USB-Steckers zu
bestimmen.
Norbert G. schrieb: > In meiner Entwicklungsumgebung (Visual Basic 2010 Express unter Win7) > finde ich leider keinen "Namespace" (?) mit der Zeichenfolge > "Windows.Devices.Enumeration"... Ich schrieb doch extra, daß das nur für Win10 UWP Apps ist. Hier hatte ich schon ein Beispiel gepostet, wie es auch bei älteren Windows geht: Beitrag "Re: virtuelle COM-Schnittstelle; VID & PID einlesen?" Norbert G. schrieb: > ... (wohlgemerkt über den Gerätemanager!) ... Im Gerätemanageer ist normalerweise sowieso nicht alles zu sehen, läßt sich aber deutlich verbessern: https://support.microsoft.com/en-us/help/315539/device-manager-does-not-display-devices-that-are-not-connected
So richtig zuverlässig ist das leider nur wenn man den Hersteller des USB Wandlers kennt. Bei FTDI ist das recht einfach, da gibts auch eine AppNote von denen. Man muss zwei Zweige der Registry durchsuchen, einmal den ftdibus um die FTDI Devices zu finden und dann noch den allgemeinen Windows COM Port Zweig um zu schauen ob der COM Port wirklich momentan gerade angesteckt ist. Das klappt dann zuverlässig. Bei Silabs und Prolific geht's sicher ähnlich.
Christian R. schrieb: > So richtig zuverlässig ist das leider nur wenn man den Hersteller des > USB Wandlers kennt. Nö. Solange der Treiber des Wandlers diesen ganz normal als COM/LPT-Schnittstelle im System registriert (und damit eine universelle Verwendung ohne genaue Kenntnis der konkreten Hardware unterstützt), genügt das API von Windows selber vollkommen, um Hinzufügen und Entfernen einer solchen Hardware zu erkennen und auch dafür, die Hardwareinstanz einer COM/LPT-Port-Nummer zuzuordnen. Es ist sogar relativ leicht, wenn man in der nativen Sprache des Win32-API programmiert, also C. Von .Net-Programmen aus ist es allerdings einigermaßen Sackstand, aber definitiv ebenfalls möglich. Nur leider eben relativ aufwendig, insbesondere dann, wenn man sowohl 32- als auch 64-Bit-Umgebung mit einem einzigen .Net-Assembly als Wrapper unterstützen möchte. Dann kommt man leicht auf >>1000 Zeilen Quelltext. Das liegt daran, dass Microsoft gerade in den hierfür relevanten APIs wirklich fast jeden grindigen Schmutz genutzt hat, den C erlaubt, der aber für eine sichere Laufzeitumgebung wie .Net Gift und deswegen einfach mal nicht erlaubt ist. Das treibt den Aufwand für das Marshalling an der Grenze zwischen sicherer Umgebung und potentiell unsicherem C-Dreck in ungeahnte Höhen...
Norbert G. schrieb: > Ich bleibe also bei der Lösung, die zugehörige COM-Schnittstelle durch > einen Listenvergleich beim Ziehen/Wiedereinstecken des USB-Steckers zu > bestimmen. Norbert, ich habe den Eindruck, daß du dich da ein wenig verrannt hast. Deine Darstellung im ersten Post ist nicht ganz richtig, denn die COM-Nummer ändert sich immer dann, wenn das USB-Gerät keine eindeutige Seriennummer hat und man es an unterschiedliche USB-Buchsen des PC's ansteckt. Dann kann Windows es nämlich nicht individuell wiedererkennen, denn vid&pid gelten ja für die ganze Geräteklasse. Normalerweise ist es herzlich ungefährlich, wenn man die COM-Ports von 1 bis 99 oder so einfach mal durchscannt, also versucht, sie probeweise zu öffnen. Ein Programm, das mit einem USB-Gerät gerade in Verbindung steht, kann man damit nicht stören, denn es besitzt die betreffende COM-Schnittstelle exclusiv. Das Einzige, was evtl. passieren kann ist, daß man bei einem sicherheitsmäßig völlig zugenagelten PC von einem übereifrigen Sicherheitstool rausgeworfen wird, weil dieses darin einen Angriff auf irgendwen sieht. Ist mir einmal passiert - aber im Normalfall hat man sowas nicht. Was ich dir hier "ankreiden" muß, ist meine Vermutung, daß es in OM-Kreisen noch immer die Unart gibt, bei Geräten wie z.B. dem FA-Netzwerk-Analysator und der Software von Andreas immer noch rein binär und ohne ein wirklich tragfähiges Protokoll herumzumurksen. Mit sowas wirst auch du nie wirklich glücklich werden - und auch Andreas hat seit dem "Nicht-Protokoll" von Bernd Kernbaum nichts dazugelernt. Ich mache das so, daß ich immer eine Gerätemeldung (Name, FW-Revision, momentaner Zustand der Hardware oder so - je nach Gerät) und ein Kommando dazu implementiere - und zwar im Klartext. Damit kann man dediziert das Gerät abfragen - und wenn man keine passende Antwort von der grad gewählten Schnittstelle bekommt, dann weiß man, daß dort was Anderes dranhängt als das eigene Gerät und daß man diesen COM-Port wieder schließen kann. Also, verbeiße dich lieber nicht darin, vid&pid herauszubekommen oder mit Abziehen&Anstecken zu arbeiten, sondern baue lieber in deine Firmware eine aussagekräftige Gerätemeldung ein. Das hilft. W.S.
Hallo W.S., ich wollte, Du hättest Recht und ich hätte mich nur verrannt! In der Tat hatte ich die Abfrage der Schnittstellen genau so implementiert, wie Du das beschreibst (im Eröffnungsbeitrag zu diesem Thread hatte ich das bereits beschrieben). Auch die gerätespezifische Kommunikation ist vorhanden: das PC-Programm öffnet die unbekannte Schnittstelle, ruft die Klartext-Zeichenfolge "COM?" hinein und wartet maximal 100 Millisekunden auf die Antwort des angeschlossenen Geräts; diese muss nämlich "conn" lauten. Wenn die nicht kommt, wird die nächste Schnittstelle ausprobiert. Das Dumme ist nur, dass die Sache in der Praxis eben doch nicht immer störungsfrei funktioniert. Ausgerechnet auf dem privaten PC von FA-Chefredakteur Werner Hegewald (ja - ich bin der Entwickler des 200-Watt-Antennenkoppler-Bausatzes, der seit knapp 2 Jahren beim Leserservice der Zeitschrift FUNKAMATEUR vertrieben wird) zeigt sich wiederholt ein Problem mit dem ebenfalls darauf laufenden Programm namens UcxLog (dem "wichtigsten Programm auf diesem PC überhaupt"). Anscheinend ist es so, dass UcxLog die ihm zugeordnete Schnittstelle immer nur kurzzeitig öffnet und dann sofort wieder schließt. Wenn dann mein Koppler-Programm zufällig diese Schnittstelle öffnet, seine Kennung hineinruft und UcxLog in der Wartezeit nun aber ebenfalls wieder darauf zugreifen möchte, gibt's eben eine Schwere Fehlermeldung. Zudem könnte es sein, dass die hinein gerufene Zeichenfolge noch im Receive-Buffer steckt und beim nächsten Öffnen durch UcxLog von diesem gelesen und natürlich als Fehler interpretiert wird. Jedenfalls war Werner außer sich, als er erfuhr, wie mein Programm die einzelnen Schnittstellen abfragt und meinte, mein Programm habe "an fremden Schnittstellen nichts, aber auch gar nichts zu suchen!" Obwohl ich bei schätzungsweise 100 bereits ausgelieferten Geräten keinerlei ähnliche Fehlerrückmeldungen bekommen habe, muss ich angesichts der bei Werner auftretenden Störung doch zugeben, dass er Recht hat. Er ist halt Perfektionist, stellt sich in diesem Fall ganz bewusst wie ein DAU an und fordert eine wirklich saubere und narrensichere Lösung. Das Problem ist, dass ich den Anwendern der bereits ausgelieferten Geräte (Funkamateure; OMs - also "Old Men") unmöglich zumuten kann, mithilfe des doch recht speziellen Hilfsprogramms FT-Prog nachträglich eine projekt-spezifische Kennung in den Schnittstellen-IC zu brennen - nur damit künftige Programm-Updates möglich bleiben - zumal sich bei diesen Leuten das Problem gar nicht mehr stellen dürfte, weil die zugehörige Schnittstelle längst ordnungsgemäß in der Windows-Registry eingetragen ist. Im Übrigen ist die vom Betriebssystem vergebene Schnittstellennummer NICHT davon abhängig, in welche der am PC vorhandenen USB-Buchsen das Kabel gesteckt wird - ich hab's ausprobiert! Sehr wahrscheinlich benutzt das Betriebssystem die im FT232RL einmalig vergebene Serien-Nummer des Chips für die Identifikation.
W.S. schrieb: > Normalerweise ist es herzlich ungefährlich, wenn man die COM-Ports von 1 > bis 99 oder so einfach mal durchscannt, also versucht, sie probeweise zu > öffnen. Das ist Pfusch.
Die Geräte über einen der String-Descriptoren für die Anwendungssoftware leicht erkennbar zu machen, wäre vermutlich das einfachste gewesen (und Vendor-ID und Produkt-ID auf FTDI Default zu lassen, damit man kein eigenes Treiberpaket bauen muss und Kunden die aktuellen ftdi-Treiber automatisch via Windows-Update erhalten) Aber da ist der Zug ja nun abgefahren (zumindest für schon ausgelieferte Geräte) ;D Norbert G. schrieb: > Sehr wahrscheinlich benutzt > das Betriebssystem die im FT232RL einmalig vergebene Serien-Nummer des > Chips für die Identifikation. Stimmt, so sollte es auch sein - Zur Unterscheidung verschiedener Produkt-Instanzen mit gleicher Vendor-ID und gleicher Produkt-ID am gleichen PC ist die Seriennummer ja unter anderem da. https://blogs.msdn.microsoft.com/oldnewthing/20041110-00/?p=37343
bluppdidupp schrieb: > Die Geräte über einen der String-Descriptoren für die Anwendungssoftware > leicht erkennbar zu machen, wäre vermutlich das einfachste gewesen (und > Vendor-ID und Produkt-ID auf FTDI Default zu lassen, damit man kein > eigenes Treiberpaket bauen muss und Kunden die aktuellen ftdi-Treiber > automatisch via Windows-Update erhalten) > Aber da ist der Zug ja nun abgefahren (zumindest für schon ausgelieferte > Geräte) ;D Sag ich auch... dann muss man halt Stück für Stück beim Update mal die FTDI's umflashen. COM-Ports durchscannen halte ich auch für nicht geschickt.
Norbert G. schrieb: > Jedenfalls war Werner außer sich, als er erfuhr, wie mein Programm die > einzelnen Schnittstellen abfragt und meinte, mein Programm habe "an > fremden Schnittstellen nichts, aber auch gar nichts zu suchen!" Nun ja, es sind eben Redakteure - und die Einbildung ("aber das ist doch MEIN!!! Comport und nicht deiner") macht's. Wahrscheinlich ist es zwecklos, ihm klarmachen zu wollen, daß es am PC und sonstwo keine "fremden" Schnittstellen gibt und daß ein Programm eine Schnittstelle oder eine Datei (ist API-technisch fast dasselbe) eben exclusiv belegen muß, wenn es sich nicht der Gefahr aussetzen will, daß selbige auch von anderen Programmen belegt wird. Die Alternative wäre, die zuletzt verwendete Portnummer in einer Datei oder der Registry zu speichern, bei Bedarf drauf zuzugreifen und dann, wenn sich dort nicht das erwartete Gerät meldet, ein Klagefenster aufzumachen "kann xyz nicht finden..". Dann darf der Redakteur selber zusehen, wo er den richtigen Port findet. Norbert G. schrieb: > Im Übrigen ist die vom Betriebssystem vergebene Schnittstellennummer > NICHT davon abhängig, in welche der am PC vorhandenen USB-Buchsen das > Kabel gesteckt wird - ich hab's ausprobiert! Nana.. Du hast also mit USB-Geräten zu tun gehabt, die eine eindeutige Seriennummer oder Seriennummer-"Bezeichnung" enthalten. Bei denen stimmt es, so wie du es sagst. Wenn du sowas nicht hast, wie z.B. bei FTDI's ohne programmiertes EEPROM, dann kriegst du an verschiedenen Buchsen auch verschiedene COM-Nummern. Das wiederum hab ich "ausprobieren" dürfen... Aber das ist ja eigentlich nicht der Kern des Problems. Im Grunde hast du 3 davon: 1. was für COM-Ports sind denn aktuell vorhanden? 2. welcher davon ist denn mein COM-Port bzw. mein Gerät? 3. was bzw. welche Firmware steckt denn in meinem Gerät? Die Nr. 1 kann man nach meinem Kenntnis-Stand eben nur durch Scannen des aktuellen Zustandes feststellen. Es gibt zwar System-Meldungen auch über das Verbinden und Abtrennen von USB-Geräten, aber ob du diese mit VB erhalten und auswerten kannst, weiß ich nicht. Und ob das gerade deiner ist, steht dort auch nicht dabei. Die Nr. 2 wird für dich schwierig, denn als Gegenstück am USB hast du ja in jedem Falle einen Standard-IC von FTDI, der von ganz vielen Leuten verbaut wird. Ob nun an so einem Chip eben dein Gerät hängt oder was ganz Anderes, kannst du nur dadurch feststellen, daß du den Port öffnest und ne Anfrage stellst. Nur dann kann eine Information von deinem eigentlichen Gerät kommen. So, und nun komme ich zu unserem "Zwischen-Rufus-er": Rufus Τ. F. schrieb: > Das ist Pfusch. So ein Zwischenruf ist überhaupt nicht hilfreich. Also Rufus, dann beschreibe DU mal, wie man es deiner Meinung nach besser machen kann. Ich sag's nochmal mit anderen Worten: Vertrauen ist gut, Kontrolle dessen, was an COM-Ports aktuell vorhanden ist, ist besser. Aber man könnte sich auf nen Kompromiß einigen: COM Nummer speichern und benutzen und falls es nicht funktioniert, dem Anwender eine Suchfunktion (aka Ports scannen) ins Menü des Programmes einbauen. Dann braucht das Programm auch nicht immerzu beim Start zu suchen und alle sind happy. W.S.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.