VISA USB-Serial "Plug&Play"?

Hiho,

ich habe ein Gerät, das über eine USB-zu-Serial Schnittstelle betrieben wird, also einen virtuellen COM-Port erzeugt. Es funktioniert an sich auch prima mit dem VISA, nur eine Kleinigkeit verwundert mich ein wenig:
Ich will mein Programm "idiotensicher" machen, also z.B. auch den Fall berücksichtigen, dass die USB-Verbindung abgezogen werden kann.. In diesem Fall verschwindet der COM-Port komplett aus dem System und das Programm bricht (natürlich) mit einem Fehler ab. Nun wenn ich den USB-Stecker wieder reinstecke (der COM-Port ist wieder da, z.B. im Gerätemanager) und das Programm wieder starte, wird der COM-Port vom VISA nicht gefunden! Das VISA bekommt es irgendwie nicht mit, dass der COM-Port wieder da ist (oder vielleicht sogar dass er weg war )..
Interessanterweise funktionierts, wenn ich ihn in einen anderen USB-Port stecke und er dadurch von Windows eine andere COM-Port Nummer bekommt. Der "neue" COM-Port wird dann tatsächlich dynamisch vom VISA erkannt und kann angesprochen werden. Danach kann ich dasselbe nochmal machen und den Stecker wieder in den ersten USB-Port stecken (ursprüngliche COM Nummer) und er wird vom VISA erkannt!

Also es funktioniert "dynamisch" nur beim umstecken, jedoch nicht beim wieder reinstecken in denselben USB-Port. Es hilft nichtmal Labview komplett neuzustarten, der Stecker muss umgesteckt werden, sonst läufts nicht mehr. Das Problem tritt nur auf, wenn im laufenden Programm der Stecker abgezogen wird (Lese-/Schreibkommandos). Wenn nicht auf den Port zugegriffen wird, kann man ihn belibig ein- und ausstecken und er wird immer erkannt...

Das Verhalten habe ich sowohl unter XP 32bit, als auch Win 7 64bit beobachtet (Labview 2010 SP1 32bit bzw. 64bit). Ist das Problem bekannt? Gibts da eine Lösung?

Anzeige

Hi Novgorod,
interessantes Verhalten.
Bekannt ist mir das Problem nicht, Lösung somit leider auch nicht.
Als Workaround vielleicht:
Bevor auf die Schnittstelle lesend/schreibend zugregriffen wird mittels .net (WMI-Query - http://www.labviewforum.de/Thread-Name-v...#pid101388 Seba hatte hier mal Beispiele gepostet)
prüfen ob der USB-Port verfügbar ist und dementsprechend handeln.
Interessant für Dich sind bestimmt: Win32_SerialPort, Win32_SerialPortConfiguration, Win32_SerialPortSetting, Win32_USBController
Win32_USBControllerDevice

Gruß
Ralf

Danke für den Tipp, das WMI klingt zumindest recht elegant.. Kleine Frage am Rande: Muss man bei sowas auf einem XP bzw. Win7 Rechner neben der Labview Runtime auch das .NET framework (1/2/3/4?) installiert haben (aus dem vi soll eine exe gemacht werden, die mit der kostenlosen Runtime auf jedem Rechner laufen sollte)?

Das einzige Problem, was ich da evtl. sehe, ist die Performance. Das Gerät macht ca. 300 Messungen pro Sekunde - mangels internem Cache (ist ein sehr simpler A/D-Wandler) sind das auch 300 COM-Port Zugriffe pro Sekunde (senden und empfangen). Ich weiß nicht wie schnell so eine WMI-Abfrage läuft, das query-Beispielprogramm braucht schon ne Weile (fragt aber auch viel mehr ab als ich für den Betrieb brauche)..

Naja, ich werde es auf jeden Fall ausprobieren

Das .Net Framework wird meines Wissens bei der Windows-Installation mit installiert.
Aber 300* pro Sekunde ist schon mal eine Hausnummer.
Ich befürchte das die .net WMI Zugriffe nicht schnell genug sind.
Als Alternative im Anhang meine ersten Gehversuche mit der neuen System-Config -Palette.
Ich habe mal für das Beispiel auf VISA limitiert.
Wichtig - Filter vor die While-Schleife.
Ergebnis: Sollte schnell genug sein aber ob die Ports auch verschwinden kann ich hier und jetzt nicht testen.

Gruß
Ralf

Danke für den Tipp, leider sehe ich da 2 Probleme:

1. Das sind wohl Funktionen vom MAX, die diesen voraussetzen. Zum einen weiß ich nicht, ob das auch bei Stand-alone Anwendungen (Labview Runtime) funktioniert, zum anderen muss die Hardware im MAX erstmal initialisiert werden, damit sie über die Find-Funktion gefunden werden kann! Wenn man noch nie die Hardware-Suche direkt im MAX gestartet hat, findet das Find.vi garnix...

2. Hinzukommende oder verschwindende Ports werden so natürlich nicht entdeckt
Die Find.vi fragt offenbar nur die im MAX registrierte Hardware ab, aber das Registrieren selbst passiert ja nicht permanent "automatisch" im Hintergrund. Die Abfrage ist dadurch zwar super schnell, aber sie sucht nicht nach veränderter Hardware - sie fragt nur eine Datenbank an registrierter Hardware ab...

Naja, ich versuch mein Glück weiter mit dem VISA oder mit .NET...

Hallo,
die Probleme kann ich leider bestätigen.Erst wenn im MAX ein "aktualisieren" ausgelöst wird erfolgt ein VISA-Ressourcen-Update
mit diesen Vi´s.
Einen hab ich aber noch.
GerdW hat hier "http://www.labviewforum.de/Thread-VISA-Find-Resource-braucht-8-Sekunden?page=2" ein schönes Snippet gepostet für die Ressourcenerkennung.
Problem hier ist das VISA-Close ~100ms benötigt.
Workaround: Du lässt dieses Vi im Init (bzw. Event bei COM-Port Wechsel) ausführen, dann bekommst du alle vorhandenen Ports,
jetzt benötigst Du die VisaResource z.B. für COM1 - ASRL1::INSTR.
Wenn Du jetzt in der Datenerfassung vor dem Schnittstellenzugriff ein VISA Find Resource einfügst und am Eingang "expression ("?*")" die ASRL1::INSTR anklemmst,
bekommst Du am "return count" eine 0 oder 1.

Gruß
Ralf

Anzeige

Hi,

das Problem hat sich für mich erledigt
Auf die Idee mit dem VISA Find Resource bin ich auch schon gekommen - das Problem dabei ist anscheinend, dass ein COM-Port solange nicht aus dem VISA verschwindet, bis er gecloset wird! Das war auch das eigentliche Problem in meinem (bisher Test-)Programm: Bei einem Kommunikationsfehler (beim Lesen/Schreiben) wurde der Port nicht geschlossen, das Programm brach einfach nur mit nem Fehler ab - das ist fatal .. Der Port konnte dann beim erneuten Programmstart nicht initialisiert werden, weil er bereits geöffnet war.. Erst nach dem Umstöpseln (andere COM-Nummer) kann VISA den neuen Port initialisieren (weil er nicht "in use" ist) und gleichzeitig den anderen schließen, so dass er freigegeben wird - beim Zurück-stöpseln passiert dann das gleiche..

VISA Find Resource kann nur dann detektieren, dass ein COM-Port "abgezogen" wurde, wenn dieser vorher gecloset wird. Das ist der Timing-Knackpunkt, wenn man es "live" machen will (hast du ja auch gesagt), es dauert bei mir alles zusammen etwa 66ms - viel zu langsam.
Meine Lösung ist aber noch viel einfacher: Wenn man das Gerät abzieht, soll das Programm eh eine Fehlermeldung ausspucken (und natürlich aufhören zu messen) - es reicht also, wenn man bei einem Lese-/Schreibfehler einfach den Port schließt.. Dann wird z.B. gewartet bis er wieder verfügbar ist (mit VISA Find Resource) und die Messung fortgeführt.. So muss ich nicht vor jeder einzelnen Messung checken, ob der Port tatsächlich vorhanden ist..

Merke also: Führst du VISA weiter fort, schließe vorher deinen Port