Datenerfassung mittels GPIB

Hallo LabVIEW Forum

an einem Versuchsstand steuere ich eine Stromquelle mit SCPI Befehlen über den GPIB an. Dazu nutze ich die NI GPIB - Karte Der eingestellte Strom erzeugt ein Magnetfeld, welches ich über ein Teslameter ebenfalls über GBIP auslese. Ich benötige Ausgabe- bzw. Abtastraten von min. 1000 Samples/s.

Bis zum jetzigen Zeitpunkt bin ich noch nicht groß mit GPIB in Berührung gekommen. Vielleicht kann daher jemand meine Ansichten zum Thema kommentieren. Ich denke:
- Datenerfassung für höhere Abtastraten ist mit GPIB gar nicht möglich. Ich kann mit GPIB zwar Übertragungsraten von 7,7 MB/s (HS488) erreichen, aber dies gilt eben nur große Datenpakete. Möchte ich nur ein paar Byte hin und her schieben (meine Messwerte), fällt die Übertagungsrate sehr viel niedriger aus (Figur 1/2).
- Es ist daher sinnvoller die Analog Ein/Ausgänge der Geräte zu verwenden, auch wenn dieser stärker rauschen, um Abtastraten > 1000/s zu erzielen.
und noch einige allgemeinere Aussagen zur Implementierung von GPIB. Ich habe gelesen:
- Man sollte die VISA-VIs verwenden. Diese sind bequemer und haben keinen Nachteil gegenüber den GPIB-VIs, richtig?
- Für VISA Read muss nur eine ausreichend große Byte Anzahl vorgeben, Es werden ohnehin nur soviele gelesen wie am Bus vorhanden sind. In meiner Test VI zum lesen des Feldes ist es aber unbedingt notwendig die genaue Byte-Anzahl des erwartenden Wertes zu definieren, andererseits werden (bei zuvielen Bytes) der nächste Wert an den alten angeheftet (Scrennshots kann ich gerne morgen nachreichen).
- Es ist nicht notwendig eine Wartezeit zwischen VISA-Read und Write einzubauen. Mein Test - VI stürzt allerdings bei Wartezeiten unter 20 ms ab.

Wenn jemand dazu was sagen könnte wäre das super.

Grüße

Anzeige

Hallo lumaxo,

Zitat:- Datenerfassung für höhere Abtastraten ist mit GPIB gar nicht möglich. Ich kann mit GPIB zwar Übertragungsraten von 7,7 MB/s (HS488) erreichen, aber dies gilt eben nur große Datenpakete. Möchte ich nur ein paar Byte hin und her schieben (meine Messwerte), fällt die Übertagungsrate sehr viel niedriger aus (Figur 1/2).

Du machst hier den Fehler, das Schnittstellenprotokoll GPIB mit den Fäghigkeiten von Messgeräten in einen Topf zu werfen. Die (mögliche) Geschwindigkeit der Schnittstelle sagt nichts, aber auch rein gar nichts, über die Fähigkeiten der daran angeschlossenenen Messgeräte aus!

- Es ist daher sinnvoller die Analog Ein/Ausgänge der Geräte zu verwenden, auch wenn dieser stärker rauschen, um Abtastraten > 1000/s zu erzielen.
und noch einige allgemeinere Aussagen zur Implementierung von GPIB. Ich habe gelesen:

Zitat:- Man sollte die VISA-VIs verwenden. Diese sind bequemer und haben keinen Nachteil gegenüber den GPIB-VIs, richtig?

Es gibt ein, zwei Sachen, die sich mit den LowLevel-GPIB-Funktionen besser machen lassen. Die wirst du aber nicht benötigen, deshalb solltest du bei VISA bleiben. Sobald statt der NI-GPIB-Schnittstelle eine eines anderen Herstellers genommen wird, bist du quasi auf VISA angewiesen…

Zitat:Ich benötige Ausgabe- bzw. Abtastraten von min. 1000 Samples/s.

Da hilft wohl ein Blick ins Manual deiner Messgeräte, ob diese das überhaupt unterstützen. Solange du diese nicht benennst, musst du selbst lesen. Wenn du uns da genauere Angaben machst, könnten wir selbst nachschauen…

Zitat:- Für VISA Read muss nur eine ausreichend große Byte Anzahl vorgeben, Es werden ohnehin nur soviele gelesen wie am Bus vorhanden sind. In meiner Test VI zum lesen des Feldes ist es aber unbedingt notwendig die genaue Byte-Anzahl des erwartenden Wertes zu definieren, andererseits werden (bei zuvielen Bytes) der nächste Wert an den alten angeheftet (Scrennshots kann ich gerne morgen nachreichen).

VISA liest nach drei Bedingungen:
- die gewünschte Anzahl Zeichen ist im Lesepuffer vorhanden/angekommen
- es wird ein TermChar erkannt
- es wird der TimeOut erreicht

Zitat:- Es ist nicht notwendig eine Wartezeit zwischen VISA-Read und Write einzubauen. Mein Test - VI stürzt allerdings bei Wartezeiten unter 20 ms ab.

Das hat nichts mit VISA selbst zu tun, sondern mit den Geräten, die am verwendeten Bus hängen. Das VISAWrite schreibt den String nur in einen Ausgangsbuffer, wo ihn dan der Treiber nach Bedarf abholt und ausgibt - wofür er seine Zeit braucht. Dann muss das Gerät den Befehl empfangen, auswerten und umsetzen: das dauert! Und dann muss noch die Antwort generiert und versendet werden: auch das dauert (ein Multimeter in der höchsten Auflösung braucht dann schon mal ~0.5s für die Messung selbst))! Und dann musst du den Befehl aus dem Lesepuffer abholen - mittels VISARead. Deshalb kann eine Wartezeit sinnvoll sein - ABER: da du ja eh auf eine bestimmte Anzahl Zeichen im Puffer wartest, ist es einfacher, hier einen vernünftigen TimeOut-Wert zu setzen…

Warum dein VI "abstürzt" kann ich nicht sagen. Kannst du das VI mal für LV2011 anhängen?

Zitat:Du machst hier den Fehler, das Schnittstellenprotokoll GPIB mit den Fähigkeiten von Messgeräten in einen Topf zu werfen.

Stimmt, vielen Dank das habe ich nicht bedacht und ist beim lesen beider Manuals an mir vorbeigegangen.

Zitat:Da hilft wohl ein Blick ins Manual deiner Messgeräte, ob diese das überhaupt unterstützen. Solange du diese nicht benennst, musst du selbst lesen. Wenn du uns da genauere Angaben machst, könnten wir selbst nachschauen…

Ich benutze ein Netzgerät von KEPCO Serie BOP. Im Manual (Tabelle 1-2) steht auch: "Digital Readback resolution: 400 Updates/s" bzw. "Digital Readback Characteristics: 5 ms measurement rate". Auch wenn mir der Unterschied nicht ganz klar ist, ist beides zu langsam für mich. Das Teslameter (S. 2-2) besitzt sogar nur eine Abtastrate von 10 Messungen pro Sekunde.

Die VI in 2011 und Sreenshots reiche ich später nach.

Da ich eigentlich den Strom in Abhängigkeit des Feldes regeln möchte, bleibt mir nur die analoge Stromsteuerung und Felderfassung, richtig? Ich nutze dazu das NI 9263 und NI 9239 Modul im cDAQ. Ich weiß das für deterministische Regelungen mit 1 ms Windows ungeignet ist, bzw. man LabVIEW RT /FPGA nutzen sollte. Habe ich dennoch Chancen diese mit einer Taktfrequenz von 10 - 1ms zu regeln? (Fall ich diese Frage in einem neuen Beitrag stellen soll, bitte Bescheid geben).

Hallo lumaxo,

Zitat:Habe ich dennoch Chancen diese mit einer Taktfrequenz von 10 - 1ms zu regeln?

Die Chance hast du. Irgendwas in der Größenordnung 2-5ms Schleifenrate ist erreichbar. Aber: du musst dir im klaren sein, dass du unter Windows auch gern mal sekundenlange Aussetzer haben kannst, wenn Windows den Virenscanner oder irgendeinen anderen Service gerade für wichtiger als dein VI hält…

Falls du das PID-Toolkit hast, dann kannst du dir das Beispiel-VI "PID Control Single Channel" anschauen…

Zitat:Für VISA Read muss nur eine ausreichend große Byte Anzahl vorgeben, Es werden ohnehin nur soviele gelesen wie am Bus vorhanden sind. In meiner Test VI zum lesen des Feldes ist es aber unbedingt notwendig die genaue Byte-Anzahl des erwartenden Wertes zu definieren, andererseits werden (bei zuvielen Bytes) der nächste Wert an den alten angeheftet

Zitat:VISA liest nach drei Bedingungen:
- die gewünschte Anzahl Zeichen ist im Lesepuffer vorhanden/angekommen
- es wird ein TermChar erkannt
- es wird der TimeOut erreicht

Habe nochmal an der VI rumgespielt und es nun verstanden denke ich. Ich musste den TermChar aktivieren und auf /r setzen. Damit ist das Problem des anheftens weg. Kann es sein das dies normalerweise vom Treiber gemacht wird, denn beim Netzteil ist dies nicht notwendig (Es wird im Gegensatz zum Teslameter auch im NI MAX erkannt, das Teslameter wird nur als Instrument angezeigt).

Allerdings stürzt das Programm nach wie vor bei Wartezeiten unter 10-20 ms früher oder später ab (d.h. es friert komplett ein und LabVIEW kann nur über den Task Manager beendet werden) oder es kommt zum Timeout. Auch wenn das Gerät nur alle 100 ms einen neuen Wert bereitstellt, spricht doch theoretisch nichts dagen diesen mehrfach auszlesen, oder?

Hallo lumaxo,

Zitat:Auch wenn das Gerät nur alle 100 ms einen neuen Wert bereitstellt, spricht doch theoretisch nichts dagen diesen mehrfach auszlesen, oder?

Jein, das hängt vom Gerät ab…
Die meisten Geräte, mit denen ich zu tun hatte, bestimmen erst einen neuen Messwert, bevor sie diesen nach einer Read-Anfrage ausgeben. Und dann ist es nicht sinnvoll, das Gerät alle 10ms anzutriggern, wenn es doch seine 100ms (oder mehr) für die Messung benötigt…

Nochmal:

Zitat:Da hilft wohl ein Blick ins Manual deiner Messgeräte, ob diese das überhaupt unterstützen.

Dies gilt nicht nur für die Samplerate an sich, sondern auch für die Art und Weise der Messwert-Abfrage. Meine Erfahrung beziehen sich dabei auf Keithley-DMMs: diese benötigen bei Einzelwertabfrage auch je nach Modus bis zu 500ms für einen Wert, können aber auch mit ~1kHz Werte samplen. Der schnelle Modus funktioniert aber nur über einen DMM-internen Buffer und spezielle Parameter bei der Werteabfrage! Deshalb: Manual lesen und an die dort beschriebenen Verfahren/Timings/etc. halten!

Zum VI:
Was spricht dagegen, den Error-Cluster zu nutzen?
   
(Natürlich auch mit Schieberegister und Auswertung in der Schleife…)

Anzeige