VISA Read - Byte Count Wert

Hallo LabVIEWforumianer! Ich versuche zur Zeit einen Spektrumanalyser via GPIB bzw. mittels VISA auszulesen. Nun ist es aber so, dass jeder VISA-Read gerne einen Byte Count Wert hätte. Die Frage ist "simpel" wie komme ich an diesen? Folgendes habe ich schon probiert:
   

Im ersten Versuch habe ich die Property Node: Bytes at Port versucht zu verwenden, leider löst diese einen Fehler aus, bzw. für das GPIB Interface ist diese Node nicht definiert/nicht unterstützt.
Im zweiten Versuch habe ich einfach einen Wert gesetzt, dieser muss natürlich lang genug sein, sonst werden die Strings nicht vollständig ausgelesen. Dies ist bei einfachen Befehlen noch nicht problematisch, allerdings geht es letztlich um das Auslesen eines Kurvenverlaufs mit variierender Punktezahl (diese kann ich einfach auslesen bzw. errechnen (die Punktezahl). Wie kann ich nun vorgehen um die genaue Anzahl der Bytes herauszufinden, oder bekomme ich ein "Ende"-Zeichen, so dass ich nach x-Iterationen des Read in einer Schleife, den Read abbrechen kann?

Noch eine weitere Frage:
Ich werde öfter im Program VISA-Read und -Write benutzen müssen in verschiedenen Programmbereichen:
a) Öffne ich in jedem Programmbereich via VISA-Open und Close neu?
b) Schleppe ich die Wires für Resource und Error durch das ganze Programm?
Irgendwie hört sich beides nicht so top an, wie macht mans richtig?
Nochmal anders gefragt: Sollte ich einen Read und Write in ein SubVI kapseln, muss der Nutzer ja VISA-Open und Close wieder herumbastelen, d.h. das SubVI ist nicht ohne weiteres eigenständig lauffähig.

Anzeige

' schrieb:Hallo LabVIEWforumianer! Ich versuche zur Zeit einen Spektrumanalyser via GPIB bzw. mittels VISA auszulesen. Nun ist es aber so, dass jeder VISA-Read gerne einen Byte Count Wert hätte. Die Frage ist "simpel" wie komme ich an diesen? Folgendes habe ich schon probiert:
[attachment=46221:ByteCount.png]

Im ersten Versuch habe ich die Property Node: Bytes at Port versucht zu verwenden, leider löst diese einen Fehler aus, bzw. für das GPIB Interface ist diese Node nicht definiert/nicht unterstützt.
Im zweiten Versuch habe ich einfach einen Wert gesetzt, dieser muss natürlich lang genug sein, sonst werden die Strings nicht vollständig ausgelesen. Dies ist bei einfachen Befehlen noch nicht problematisch, allerdings geht es letztlich um das Auslesen eines Kurvenverlaufs mit variierender Punktezahl (diese kann ich einfach auslesen bzw. errechnen (die Punktezahl). Wie kann ich nun vorgehen um die genaue Anzahl der Bytes herauszufinden, oder bekomme ich ein "Ende"-Zeichen, so dass ich nach x-Iterationen des Read in einer Schleife, den Read abbrechen kann?

Noch eine weitere Frage:
Ich werde öfter im Program VISA-Read und -Write benutzen müssen in verschiedenen Programmbereichen:
a) Öffne ich in jedem Programmbereich via VISA-Open und Close neu?
b) Schleppe ich die Wires für Resource und Error durch das ganze Programm?
Irgendwie hört sich beides nicht so top an, wie macht mans richtig?
Nochmal anders gefragt: Sollte ich einen Read und Write in ein SubVI kapseln, muss der Nutzer ja VISA-Open und Close wieder herumbastelen, d.h. das SubVI ist nicht ohne weiteres eigenständig lauffähig.

Message Termination ist normalerweise das Zauberwort. Bei GPIB teilt das Gerät (ausser uralt Dynosuariers die noch nie was von IEEE 488.2 gehört haben) mittles Handshake mit wenn es das letzte Byte verschickt. Dann braucht man mit VISA nur noch einen Byte Count anzugeben der minimal so gross ist wie die längste erwartete Message. VISA Read bricht dann ab wenn:
1) dieser EOI (End of Information) gesehen wurde
2) die verlangten Bytes eingetroffen sind
3) das Timeout abgelaufen ist
4) ein Fehler aufgetreten ist

Bei serial funktioniert das auch und hier verwendet man meist einen Termination Character wie Carriage Return oder Line Feed.

Zu Deinen Fragen:
a) Nein bitte nicht!!!!!!!!!!
b) Ja!!! das ist kein Problem sondern hilft wenn sauber getan um eine eindeutige Abfolge in der Ausführung der Funktionen zu erreichen. LabVIEW ist Dataflow kontrolliert. Das heisst wenn Du mehrere Icons nebeneinander in ein Diagramm legst ohne dass da ein Wire vom einen zum anderen geht, ist die Reihenfolge der Ausführung dieser Funktionen zufällig und auf MultiCore Systemen sogar effektiv parallel. Das haben die meisten Instrumente gar nicht gern wenn man sie nicht in einer klar definierten Reihenfolge ansteuert.

Du schreibst Ja auch noch ein Programm darum, oder? Oder schreibst Du einen Instrumenten Treiber? Dann lese Dich doch mal in die Instrumenten Treiber Guidelines von NI ein. Funktionen in einem Instrumententreiber sind nicht völlig eigenständige VIs. Das wäre viel zu unflexible für eine professionelle Verwendung solcher Treiber.

Rolf Kalbermatter

Was kriegst Du da für einen Fehler? Oder ist es doch nur eine Warnung? Weil die kriegst Du da immer.

Gruß Markus

' schrieb:Im ersten Versuch habe ich die Property Node: Bytes at Port versucht zu verwenden, leider löst diese einen Fehler aus, bzw. für das GPIB Interface ist diese Node nicht definiert/nicht unterstützt.

' schrieb:Nochmal anders gefragt: Sollte ich einen Read und Write in ein SubVI kapseln, muss der Nutzer ja VISA-Open und Close wieder herumbastelen, d.h. das SubVI ist nicht ohne weiteres eigenständig lauffähig.

Natürlich geht das, daß das Sub-VI selbständig lauffähig ist. Z.B. VISA-Open-Behandlung: Die kann durchaus im Sub-VI erfolgen, aber nur beim ersten Aufruf des VI oder wenn sich die Visa-Ressource geändert hat. Ansonsten bleibt die geöffnete Visa-Referenz in einem nicht initialisiertem Schieberegister für den nächsten Aufruf gepeichert.

Zur Frage:
b) Schleppe ich die Wires für Resource und Error durch das ganze Programm?
Eine mit Vorsicht verwendende Alternative ist die Verwendung von (versteckten) Anzeigen/Bedienelementen in Verbindung mit lokalen Variablen. Nur dann anzuraten, wenn man betreffs lokaler Variablen den nötigen Durchblick hat. (Beispiel: Bei einem Prog mit State-machine im Initialisieruns-Case und im Beendigungs-Case lokale Variable für die Visa-Referenz zum Öffnen/Schließen verwenden, im Hauptteil, also beim Lesen/Schreiben, das versteckte Bedienelement. Man hat weniger Drahtwirrwar, muß nicht ein Schieberegister durch alle Cases zu ziehen.

1. Fehlercode

' schrieb:Was kriegst Du da für einen Fehler? Oder ist es doch nur eine Warnung? Weil die kriegst Du da immer.

Der Fehlercode war: -1073807331 und bezeichnet: "The specified attribute is not defined or supported by the referenced resource." laut der VISA Error Codes Liste . Heißt für mich, wie oben schon erwähnt: Mein Gerät unterstützt diesen Befehl nicht, zudem war der Property Node Eintrag auch unter Serial und nicht unter GPIB.

Warum soll bei obigem Beispiel immer eine Warnung auftreten?
Falls unklar: Die 2 Versuche sind natürlich nicht in einem VI, das ist nur im Bild so.

2. Byte Count Wert

' schrieb:Message Termination ist normalerweise das Zauberwort. Bei GPIB teilt das Gerät (ausser uralt Dynosuariers die noch nie was von IEEE 488.2 gehört haben) mittles Handshake mit wenn es das letzte Byte verschickt. Dann braucht man mit VISA nur noch einen Byte Count anzugeben der minimal so gross ist wie die längste erwartete Message.

VISA Read bricht dann ab wenn:
1) dieser EOI (End of Information) gesehen wurde
2) die verlangten Bytes eingetroffen sind
3) das Timeout abgelaufen ist
4) ein Fehler aufgetreten ist

D.h. die Lösung ist einfach nur einen ByteCount vorzugeben, der auf jedenfall groß genug ist und VISA-Read stoppt sobald nix mehr kommt?
Vorteil: Einfach
Nachteil: Verschwendung von Systemressourcen? Oder werden garnicht soviele Bytes vorweg reserviert wie ich im Bytecount vorgebe? Bzw. die ungenutzten Bytes wieder freigegeben falls nicht gebraucht? (Gut prinzipiell wird mich bzw. den PC die hier genutzte Anzahl weniger kratzen, ist rein informativ gefragt, bzw. man wills ja richtig machen)

3. VISA einmal öffnen und schließen

' schrieb:b) Ja!!! das ist kein Problem sondern hilft wenn sauber getan um eine eindeutige Abfolge in der Ausführung der Funktionen zu erreichen. LabVIEW ist Dataflow kontrolliert. Das heisst wenn Du mehrere Icons nebeneinander in ein Diagramm legst ohne dass da ein Wire vom einen zum anderen geht, ist die Reihenfolge der Ausführung dieser Funktionen zufällig und auf MultiCore Systemen sogar effektiv parallel. Das haben die meisten Instrumente gar nicht gern wenn man sie nicht in einer klar definierten Reihenfolge ansteuert.

Nummer 1 =Variante A: VISA wiederholt öffnen und schließen
Nummer 2 = Variante B: VISA einmal öffnen und schließen
Variante B so richtig mit dem einmal öffnen und schließen? Hier ist für mich zunächst ungewöhnlich, dass die VISA-Resource des Writes für den Frequenzspannenfall nicht zum Close geführt wird, sondern einfach "in der Luft" endet.
Variante A sollte gemieden werden?
In der Mittelstruktur wird jeweils geprüft ob ein erneuter VISA-Write nötig ist und für diesen Fall die entsprechende Case-Struktur ausgelöst. (Das sollte es zumindest tun)
   

4. GPIB Doppelpunkt
Letzte Frage für heute:
Wozu wird einem GPIB Befehl ein Doppelpunkt vorangestellt, obwohl dem Instrument kein weiterer Befehl übergeben wurde.
Also z.B.
- zwei Befehle von FREQUENCY kombiniert einem Write übergeben: "FREQUENCY:CENTER 100MHz;SPAN 20MHz"
- zwei Befehle einem Write übergeben, eines von FREQUENCY und eines von FORM: "FREQUENCY:CENTER 100MHz;:FORM ASC"
- und jetzt kommts, nur ein Befehl: ":FORM ASC"
wozu ist im letzten Beispiel das ":" bzw. der Zusatznutzen zu "FORM ASC"? (Heißt ausgeschrieben Format ASCII)
warum wird ":" vor den LabVIEW befehl gesetzt?

Vielen Dank euch allen! Hab genug von LabVIEW für heute:)bis morgen.

' schrieb:1. Fehlercode

Tja ich war mit nicht bewusst dass diese property für GPIB nicht funktioniert aber verwende die ehh nie, auch nicht für serial.

Zitat:Warum soll bei obigem Beispiel immer eine Warnung auftreten?

Die VISA Read liefert eine Warnung zurück (error status = FALSE, error code != 0) die besagt dass die zurückgelieferten Anzahl Bytes den angeforderten entspricht um darauf aufmerksam zu machen dass da noch mehr Bytes im Empfangsbuffer sein könnten.

Zitat:2. Byte Count Wert

D.h. die Lösung ist einfach nur einen ByteCount vorzugeben, der auf jedenfall groß genug ist und VISA-Read stoppt sobald nix mehr kommt?
Vorteil: Einfach
Nachteil: Verschwendung von Systemressourcen? Oder werden garnicht soviele Bytes vorweg reserviert wie ich im Bytecount vorgebe? Bzw. die ungenutzten Bytes wieder freigegeben falls nicht gebraucht? (Gut prinzipiell wird mich bzw. den PC die hier genutzte Anzahl weniger kratzen, ist rein informativ gefragt, bzw. man wills ja richtig machen)

Wegen der Systemresourcen solltest Du Dir vorab mal nicht zuviel Sorgen machen. Du wirst ja wohl nicht 2000000 Bytes oder mehr anfordern und ob LabVIEW einen Buffer von 10 oder 1000 Bytes alloziert macht in der Laufzeit keinerlei Unterschied.

Zitat:3. VISA einmal öffnen und schließen

Nummer 1 =Variante A: VISA wiederholt öffnen und schließen
Nummer 2 = Variante B: VISA einmal öffnen und schließen
Variante B so richtig mit dem einmal öffnen und schließen? Hier ist für mich zunächst ungewöhnlich, dass die VISA-Resource des Writes für den Frequenzspannenfall nicht zum Close geführt wird, sondern einfach "in der Luft" endet.

Variante A oder 1????? Jedenfalls sind B/2 richtig. Das mit dem offenem VISA Resource am zweiten Strang ist kein Problem. Aber eigentlich würde ich das Write ebenfalls im selben Strang einschlaufen. So wie Du das jetzt hast kann das in komplexeren Fällen dann diesem auf einem Multicore System theoretisch ein Problem provozieren Da beide Funktionen von LabVIEW effektiv parallel ausgeführt werden können.

Zitat:4. GPIB Doppelpunkt
Letzte Frage für heute:
Wozu wird einem GPIB Befehl ein Doppelpunkt vorangestellt, obwohl dem Instrument kein weiterer Befehl übergeben wurde.
Also z.B.
- zwei Befehle von FREQUENCY kombiniert einem Write übergeben: "FREQUENCY:CENTER 100MHz;SPAN 20MHz"
- zwei Befehle einem Write übergeben, eines von FREQUENCY und eines von FORM: "FREQUENCY:CENTER 100MHz;:FORM ASC"
- und jetzt kommts, nur ein Befehl: ":FORM ASC"
wozu ist im letzten Beispiel das ":" bzw. der Zusatznutzen zu "FORM ASC"? (Heißt ausgeschrieben Format ASCII)
warum wird ":" vor den LabVIEW befehl gesetzt?

Nun das jeweilige Kommandoset eines Instrumentes ist im Manual zu dem Instrument definiert und erklärt. Diese Kommandos scheinen sich am SCPI Standard zu orientieren aber das ist kein strikter Standard im eigentlichen Sinn sondern einfach ein Empfehlung wie ein Instrumentenbefehlssatz aufgebaut sein kann. Manche Instrumentenbauer halten sich in keiner Weise daran, andere mehr oder weniger aber die Idee dass man ein DMM von Hersteller X mit den gleichen Befehlen ansteuern kann dann ein DMM vom Hersteller Y ist auch mit SCPI nur ein frommer Wunsch. Das funktioniert oft nicht mal mit ähnlichen Instrumenten vom gleichen Hersteller.

Rolf Kalbermatter

Anzeige