GPIB-Bus eines GPIBzuUSB-Wandlers prüfen

Hallo zusammen,
kennt Ihr eine einfache Möglichkeit mit Hilfe eines vi zu prüfen, ob der GPIB zu USB -Wandler (hier ein Agilent 82357A) am USB-Port angeschlossen und betriebsbereit ist? Der Status soll auch dann erfolgen, wenn kein GPIB-Gerät am Wandler angeschlossen ist.

Anzeige

Hallo DG,

du könntest die vorhandenen Schnittstellen abfragen, hier am Beispiel der COM-Ports:
   

' schrieb:Hallo DG,

du könntest die vorhandenen Schnittstellen abfragen, hier am Beispiel der COM-Ports:
[attachment=60884:check.png]

Hallo Gerd,
eine gute Idee. Dieses funktioniert auch, aber leider nur mit den original NI GPIBzuUSB-Wandlern (hier GPIB-ENET/100). Versuche ich das mit dem Agilent bekomme ich den Fehlercode -1073807302 zurückgeliefert. Die Kommunikation mit den Geräten am Bus funktioniert allerdings problemlos.

Liebe Grüße, Stephan

Siehst Du den Agilent-(USB-nach-GPIB)-Wandler im MAX?

Gruß Markus

' schrieb:Siehst Du den Agilent-(USB-nach-GPIB)-Wandler im MAX?

Gruß Markus

Hallo Markus,
ja im MAX wird er, mit allen sich zur Zeit an ihm befindenden GPIB-Geräten, angezeigt, allerdings als "Miscellaneous VISA Resources" (s. Anhang)

Ich habe heute im NI-Forum noch einen Beitrag entdeckt, leider hilft mir die vorgehensweise nicht weiter. Wie gesagt, direkt ansprechen lassen sich die Geräte z.B. mit GPIB0::16::INSTR, wobei Adressraum 0 meinem GPIBzuUSB-Wandler entspricht. Aber das VI "VISA: Ressource suchen" liefert immer noch denselben Error-Code.

Hier der Beitrag aus dem Forum:
USB->GPIB issue

Nur der vollständigkeithalber: Im Agilent Connection Expert werden meine Interfaces wie im Anhang dargestellt.
Habt ihr noch einen weiteren Tipp für mich?

Liebe Grüße, Stephan

Anzeige

Ich habe leider keinen Tip mehr, da ich nur NI-Hardware für solche Dinge verwende und da hatte ich bisher noch nie Probleme.

Gruß Markus

Hallo Stephan,

noch ein Tipp (bzw. Hinweis):
Die Agilent-GPIB-Treiber waren früher recht "biestig" - man musste immer eine bestimmte Reihenfolge bei der Installation einhalten (Erst LabVIEW, dann Treiber - oder war's umgekehrt?). Manchmal durfte man auch den Agilent-Treiber (irgendeine DLL) von Hand umbenennen und über die entsprechende LabVIEW-DLL drüberkopieren... Vielleicht ist Agilent da ja seiner Linie treu geblieben?