virtuelles GPIB-Instrument

[Meßknecht (Gast)]

Hallo Forum,

ich habe folgendes Problem, bei dessen Lösung ich im Moment
irgendwie auf dem Schlauch stehe bzw. nicht so recht weiter-
komme:

Es gibt ein Meßinstrument mit GPIB-Schnittstelle, welches ich
von einem PC aus über einen USB-GPIB-Adapter fernsteuern will.
Das Steuerprogramm auf dem PC soll in VB.Net geschrieben werden
und auf die GPIB-Schnittstelle über Agilent VISA zugreifen.

Nun ist es leider so, daß ich in real zum Programmschreiben nicht
dauernd Zugriff auf das Meßgerät habe, da es während dieser Zeit
fast dauernd auch von anderen Leuten benutzt werden muß.

Ich kann nun meine Meßprogramme zunächst "trocken" - ohne
angeschlossenes Instrument - schreiben, jedoch ist das Debuggen/
die Inbetriebnahme des Programms ohne Instrument eigentlich nicht
wirklich möglich.

Was mir nun vorschwebt ist eine Art "virtuelles" Instrument.

Auf dem Steuer-PC soll ein weiteres Programm laufen, das über
VISA am selben (virtuellen) GPIB0-Adapter hängt und dauernd
diesen virtuellen Bus abhört, also quasi Daten einliest.
Die eingelesenen Daten müssen dann sinnvoll analysiert werden,
ob sie Kommandos aus dem Command Set des Instruments enthalten.
Wenn ein solches Kommando erkannt wird, dann soll das virtuelle
Instrument antworten, z. B. indem es irgendwelche Dummymeßdaten
auf den virtuellen GPIB-Bus zurückgibt oder sonst in der Weise
antwortet, wie es ein reales Instrument auch machen würde.

Hier mal ein Beispiel, ins Unreine geschrieben:


Meßprogramm:         viOpenDefaultRM(defrm1)
Meßprogramm:         viOpen(defrm1, virt_instr1$, 0, 0, viSession1)
virt_Instrument:     viOpenDefaultRM(defrm2)
virt_Instrument:     viOpen(defrm2, virt_instr2$, 0, 0, viSession2)

Meßprogramm:         viVPrintf(viSession1, "*IDN?" + vbCrLf, 0)

virt_Instrument:     Do
virt_Instrument:       viVScanf(viSession2, strRes)
virt_Instrument:     Loop until ...viVScanf = irgendwas empfangen
virt_Instrument:     'analysiere strRes und kreiere den passenden
                     'Antwortstring dazu
virt_Instrument:     viVPrintf(viSession2, Antwort$ + vbCrLf, 0)

virt_Instrument:     viClose(viSession2)
virt_Instrument:     viClose(defrm2)
Meßprogramm:         viClose(viSession1)
Meßprogramm:         viClose(defrm1)

Ich hoffe, es ist klar geworden, auf was ich heraus will...

Wenn ich allerdings im virt-Instr-Programm ein viVScanf in einer
Schleife ablaufen lasse, detektiere ich damit nur einen Timeout,
solange das Meßprogramm nichts sendet.
Es gibt wohl irgendwelche VI_Events, auf die man dann mit reagieren 
kann,
aber angeblich funktioniert das unter VB(.net) irgendwie nicht oder
aber doch und wenn dann nicht einfach...

Die VB.Net-Beispiele, die ich gefunden habe, behandeln eigentlich
nur, wie ich die Meßprogrammseite programmatisch umsetzte, sprich,
wie ich vom PC aus ein echtes GPIB-Instrument steuere. Was ich aber
bräuchte, wäre ein Beispiel für den umgekehrten Fall, nämlich daß
der PC das GPIB-Instrument ist.

Ich gehe davon aus, daß das Printf-Scanf-Pingpong-Spiel von oben
nur die Grobstruktur einer solchen Programm-Programm-Kommunikation
sein kann, im Detail da aber noch mehr notwendig ist. Ev. muß sich
das virtuelle Instrument ja z. B. um den Status irgendwelcher (virt.)
Busleitungen kümmern (ATN, SRQ,...), damit überhaupt eine Kommunikation
zustande kommt. Und da hört es halt leider bei mir auf.

Kennt sich jemand mit dieser Thematik aus, bzw. hat so etwas
vielleicht sogar schon einmal umgesetzt oder kennt ein Beispiel,
an dem man sich orientieren kann ?

Ein Google-Suche hat leider nicht viel verwertbares zu Tage
gefördert. Es gibt für Labview im NI-Forum ein Beispiel für
ein Non-controller-Programm, da ich kein Labview habe, nützt
mir das aber nichts. Ebenfalls gefunden habe ich einen Hinweis
auf "NI-Device", was wohl so etwas in der Richtung machen soll,
wie ich es mir vorstelle, jedoch ebenfalls wenig Details und
keine Info, ob VB.Net unterstützt wird. Ich würde eigentlich
auch lieber auf der Agilent-Schiene bleiben, da der Rest der
Meßprogramme schon darauf aufsetzt.

Herzlichen Dank schon mal für die Antworten !

[hp-freund (Gast)]

Das klingt irgend wie nach dem alten Henne und Ei Problem ;)

Ich hab so etwas auch noch nicht gemacht, aber das NI 
Non-controller-Programm läuft ab Version 6 wenn ich das richtig sehe.

Bei Heise gab es mal ein freies Labview für Linux 6.1.
Wenn Du das noch findest (leider nicht mehr bei Heise?) und einen 
Linux-Rechner mit GPIB Karte hast, wäre das vielleicht eine Möglichkeit.

Aber ob der Aufwand lohnt? Wer weiß ...

[Karl H. (kbuchegg)]

Da du dich scheinbar um die unteren Schichten der Kommunkiation ohnehin 
nicht kümmern musst, weil du eine fertige Lib benutzt, tausch halt 
einfach diese Kommunikationslib zu Debug-Zwecken gegen eine aus, die 
eben nicht kommuniziert sondern dir nur das Gerät nachbildet.

Damit kannst du deine Applikation weiterschreiben und hast sowas wie ein 
gefaktes Gerät im System, mit dem du deine Datenauswertung und 
Aufbereitung etc. testen und debuggen kannst.

Du wirst ja nicht dafür bezahlt, dass du da jetzt eine möglichst 
gefinkelte Gerätesimualtion machst, sondern dass du in deiner 
Auswertesoftware weiter kommst. Also willst du da so wenig Arbeit wie 
möglich reinstecken.

[Meßknecht (Gast)]

Vielen Dank für Eure Antworten !

Ja genau, es hat ein wenig etwas von einem Henne-Ei-Problem.
Einen zweiten Rechner für die Labview-Variante habe ich leider
nicht zur Verfügung, aber trotzdem danke für den Vorschlag.

Der Vorschlag von Karl Heinz Buchegger klingt sehr gut !

Das könnte ein Weg sein, mit dem ich weiterkomme.
Ich tausche die visa32.vb-Datei gegen eine gleichnamige
eigene Variante aus, in der nicht auf die VISA-DLL
zugegriffen wird, sondern die Printf/Scanf-Aufrufe
auf eigene Netzwerkstream-Zugriffe umgeleitet werden.

Die Controller/Instrument-Kommunikation entspräche dann
einer Client/Server-Kommunikation über TCP/IP und eine solche
habe ich in ähnlicher Weise (als simuliertes Meßgerät) schon
einmal programmiert; ev. kann ich dann daraus sogar ein Teil
wiederverwenden. Der Gedanke an so etwas ist mir für das aktuelle
Problem sogar schon einmal gekommen, allerdings habe ich zu kompliziert
gedacht und wollte VISA wie gehabt benutzen, aber im Connection Expert
das Interface GPIB0 auf TCPIP0 umleiten. Für Printf/Scanf hätte das
sogar noch funktioniert, aber bei simuliertem Serial Polling wußte ich
dann nicht mehr weiter, bzw. eine einfache Readf-Schleife auf der
Instrumentenseite müßte schon mit allerhand Unwägbarkeiten zurecht-
kommen. Einfach eine Schicht höher - über VISA - anzusetzen ist 
eigentlich
naheliegend, aber manchmal sieht man halt den Wald vor lauter Bäumen
nicht, bzw. braucht halt dafür einen externen Tip.

Eine gefinkelte Gerätesimulation will ich in der Tat
nicht machen, aber ganz ohne Meßgerät bzw. ohne virtuellen
Ersatz ist so eine Meßsoftware nicht programmierbar, wenn
das Meßgerät auf eine Anfrage mit allerhand verschiedenen
Statusmeldungen reagieren kann, auf die die Steuersoftware
irgendwie sinnvoll reagieren muß und die Anfragen teilweise
nicht nur ein einfaches Write/Read sind, sondern mehrmals
zwischen PC/Meßgerät hin und hergewechselt wird, Handshakings
ablaufen, Timeouts auftreten können, etc.

Vielen Dank noch einmal für Hilfe, dafür liebe ich dieses Forum !