Verwenden der Umgebungsvariablen in LabVIEW

Überblick

LabVIEW bietet Zugang auf eine Vielzahl von Technologien für das Erstellen von verteilten Anwendungen. Mit der Umgebungsvariable lässt sich die Programmierung für solche Anwendungen erheblich vereinfachen. In diesem Artikel erhalten Sie eine Einführung in Umgebungsvariablen einschließlich Beschreibung ihrer Komponenten/Eigenschaften und Funktionsweise in LabVIEW ab Version 8.20.

Inhalt

Erstellen von Umgebungsvariablen

Mit Hilfe der Umgebungsvariablen können Sie Daten zwischen Schleifen in einem Diagramm oder zwischen VIs im Netzwerk austauschen. Im Gegensatz zu vielen anderen Methoden der Datenübertragung in LabVIEW, wie z. B. UDP/TCP, LabVIEW-Queues und Real-Time-FIFOs, werden Umgebungsvariablen in der Regel mit Hilfe von Eigenschaftsdialogfeldern während der Bearbeitung konfiguriert. Bei Verwendung von Umgebungsvariablen muss auch kein Konfigurationscode in die Anwendung eingebunden werden.

Sie können drei verschiedene Arten von Umgebungsvariablen erstellen: Einzelprozess-Umgebungsvariablen, Netzwerk-Umgebungsvariablen und zeit-getriggerte Umgebungsvariablen. In diesem Artikel werden Einzelprozess-Umgebungsvariablen und Netzwerk-Umgebungsvariablen detailliert beschrieben. Weitere Informationen zu zeit-getriggerten Umgebungsvariablen finden Sie im Dokument Using Time-Triggered Networks to Communicate Deterministically Over Ethernet with the LabVIEW Real-Time Module. Zum Erstellen einer Umgebungsvariablen klicken Sie in einem LabVIEW-Projekt mit der rechten Maustaste auf ein Datenverarbeitungsgerät wie "Mein Computer" oder ein Real-Time-Zielsystem und wählen Sie Neu»Variable aus. Daraufhin wird das Dialogfeld "Eigenschaften für Umgebungsvariable" angezeigt. In diesem Dialogfeld können Sie die neue Variable konfigurieren.

Zum Erstellen einer Umgebungsvariablen muss ein Projekt geöffnet sein. Zum Hinzufügen einer Umgebungsvariablen zu einem Projekt klicken Sie im Projekt-Explorer mit der rechten Maustaste auf ein Zielsystem, eine Projektbibliothek oder einen Ordner in einer Projektbibliothek und wählen Sie Neu»Variable aus dem Kontextmenü aus. Daraufhin wird das Dialogfeld Eigenschaften für Umgebungsvariable angezeigt. Wählen Sie eine der Konfigurationsoptionen aus und klicken Sie anschließend auf die Schaltfläche OK.

Wenn Sie ein Zielsystem oder einen Ordner außerhalb einer Projektbibliothek anklicken und Neu»Variable aus dem Kontextmenü auswählen, wird eine neue Projektbibliothek erstellt und die Umgebungsvariable in diese neue Projektbibliothek eingefügt. Weitere Informationen zu Variablen und Bibliotheken finden Sie im Abschnitt Lebensdauer einer Umgebungsvariablen.

In Abbildung 1 sehen Sie das Dialogfeld Eigenschaften für Umgebungsvariable für eine Einzelprozess-Umgebungsvariable. Das LabVIEW Real-Time Module und das LabVIEW Datalogging and Supervisory Control (DSC) Module bieten zusätzliche Funktionen und konfigurierbare Eigenschaften für Umgebungsvariablen. In diesem Beispiel sind zwar das LabVIEW Real-Time Module und das LabVIEW DSC Module installiert, die Funktionen des LabVIEW DSC Modules können jedoch nur für Netzwerk-Umgebungsvariablen verwendet werden.

Abbildung 1: Eigenschaften für Einzelprozess-Umgebungsvariable


Datentyp

Sie können aus einer Reihe von Standarddatentypen für die neue Umgebungsvariable auswählen. Zusätzlich zu diesen Standarddatentypen können Sie einen benutzerspezifischen Datentyp angeben. Wählen Sie dazu aus dem Pulldown-Menü Datentyp den Punkt Von benutzerdefiniertem Element... aus und wählen Sie anschließend ein benutzerdefiniertes Element aus. Manche Funktionen wie z. B. Skalierung und Real-Time-FIFOs funktionieren nicht mit allen benutzerdefinierten Datentypen.  Wenn Sie das LabVIEW DSC Module installiert haben, sind Alarme bei Verwendung von benutzerdefinierten Datentypen auf Meldungen des Typs "Ungültiger Status" beschränkt.

Nachdem Sie die Eigenschaften der Umgebungsvariablen konfiguriert und auf OK geklickt haben, wird die Umgebungsvariable im Projekt-Explorer unter der ausgewählten Bibliothek oder dem ausgewählten Zielsystem angezeigt (vgl. Abbildung 2).

Abbildung 2: Umgebungsvariable im Projekt


Das Zielsystem, zu welchem die Umgebungsvariable gehört, ist das Zielsystem, von dem die Variable auf andere Systeme verteilt wird. Weitere Informationen zum Verteilen und Hosten von Umgebungsvariablen finden Sie im Abschnitt Verteilen und Hosten.

 

Variablenreferenzen

Nachdem Sie eine Umgebungsvariable zu einem LabVIEW-Projekt hinzugefügt haben, können Sie diese Variable in das Blockdiagramm eines VIs ziehen, wo die Variable Daten senden und empfangen kann (vgl. Abbildung 3). Die Knoten zum Lesen und Schreiben im Blockdiagramm werden als Umgebungsvariablenknoten bezeichnet.

Abbildung 3: Senden und Empfangen von Daten mit Hilfe eines Umgebungsvariablenknotens

Sie können einen Umgebungsvariablenknoten als absolut oder relativ zu einem Zielsystem konfigurieren, je nachdem wie der Knoten mit der Variablen verbunden sein soll. Bei der Einstellung "Absolut" stellt der Knoten eine Verbindung mit der Umgebungsvariablen her, deren Zielsystem beim Erstellen der Variablen angegeben wurde. Wenn der Knoten auf "Relativ zum Zielsystem" eingestellt ist, stellt er eine Verbindung mit dem Zielsystem her, auf dem das VI ausgeführt wird, das den Knoten enthält.

Wenn Sie ein VI, das einen Umgebungsvariablenknoten mit der Einstellung "Relativ zum Zielsystem" enthält, auf ein neues Zielsystem verschieben, muss auch die Umgebungsvariable auf das neue Zielsystem verschoben werden. Verwenden Sie solche systemvariablen Umgebungsvariablenknoten, wenn VIs und Variablen auf anderen Systemen genutzt werden sollen.

Per Voreinstellung sind alle Umgebungsvariablenknoten absolut. Zum Ändern, wie ein Umgebungsvariablenknoten mit der Umgebungsvariablen verbunden sein soll, klicken Sie mit der rechten Maustaste auf einen Knoten und wählen Sie Referenzmodus»Relativ zum Ziel oder Referenzmodus»Absolut aus.

Sie können eine Umgebungsvariable im Projekt-Explorer zu jeder beliebigen Zeit mit der rechten Maustaste anklicken und die Eigenschaften bearbeiten. Das LabVIEW-Projekt speichert die neuen Einstellungen für alle Umgebungsvariablen-Referenzen im Speicher. Beim Speichern der Variablenbibliothek werden diese Änderungen auch auf die Variablendefinition auf der Festplatte übernommen.

Einzelprozess-Umgebungsvariable


Mit Hilfe von Einzelprozess-Umgebungsvariablen lassen sich Daten zwischen zwei verschiedenen Stellen in einem VI austauschen, die nicht direkt miteinander verbunden sind, wie z. B. parallele Schleifen im gleichen VI oder zwei verschiedene VIs in der gleichen Anwendungsinstanz. Die Implementierung einer Einzelprozess-Umgebungsvariablen ist vergleichbar mit der von globalen Variablen in LabVIEW. Der Hauptvorteil bei der Verwendung von Einzelprozess-Umgebungsvariablen gegenüber den traditionellen globalen Variablen besteht darin, dass eine Einzelprozess-Umgebungsvariable in eine Netzwerk-Umgebungsvariable konvertiert werden kann, auf die jeder Knoten in einem Netzwerk zugreifen kann.

Einzelprozess-Umgebungsvariable und LabVIEW Real-Time

Um den Determinismus in Real-Time-Anwendungen zu bewahren, ist es notwendig, dass Daten von einem deterministischen Codeabschnitt (z. B. zeitgesteuerte Schleifen mit hoher Priorität und zeitkritische VIs mit Priorität) an einen nicht deterministischen Codeabschnitt mit Hilfe eines nicht blockierenden, deterministischen Datenübertragungsmodus ausgetauscht werden. Wenn Sie das LabVIEW Real-Time Module installieren, können Sie eine Umgebungsvariablen zur Verwendung eines Real-Time-FIFOs konfigurieren, indem Sie den Real-Time-FIFO im Dialogfeld Eigenschaften für Umgebungsvariable aktivieren. Es wird empfohlen, Real-Time-FIFOs für den Austausch von Daten zwischen einer zeitkritischen Schleife und einer Schleife geringerer Priorität zu verwenden. Sie können die Low-Level-Real-Time-FIFO-VIs vermeiden, wenn Sie den Real-Time-FIFO in einer Einzelprozess-Umgebungsvariablen aktivieren.

In LabVIEW-Versionen vor 8.6 wird ein Real-Time-FIFO erstellt, wenn ein Umgebungsvariablenknoten das erste Mal versucht, Daten mit einer Umgebungsvariablen auszutauschen. Diese Funktionsweise führt dazu, dass die erste Verwendung einer Umgebungsvariablen im Vergleich zu nachfolgenden Ausführungen etwas mehr Zeit in Anspruch nimmt. Wenn eine Anwendung ein extrem präzises Timing erfordert, sollten Sie entweder Warmlaufiterationen in die zeitkritische Schleife einbauen, um die Fluktuationen mit Hilfe zusätzlicher Iterationen auszugleichen, oder die Variable mindestens einmal außerhalb der zeitkritischen Schleife auslesen.  In LabVIEW ab Version 8.6 wird ein Real-Time-FIFO erstellt, wenn das VI für die Ausführung reserviert ist (in den meisten Fällen, wenn das Haupt-VI in der Anwendung gestartet wird). Für die erste Ausführung des Umgebungsvariablenknotens muss also nichts besonderes beachtet werden.  

Abbildung 4: Umgebungsvariablen mit aktiviertem Real-Time-FIFO


LabVIEW erzeugt für jede Einzelprozess-Umgebungsvariable einen einzelnen Real-Time-FIFO, selbst wenn die Umgebungsvariable mehrere Sender oder Empfänger hat. Zur Wahrung der Datenintegrität blockieren mehrere Sender oder Empfänger einander. Sender blockieren jedoch keine Empfänger und umgekehrt. Es wird empfohlen, die Verwendung von mehreren Sendern oder mehreren Empfängern von Einzelprozess-Umgebungsvariablen in zeitkritischen Schleifen zu vermeiden.

Abbildung 5: Mehrere Sender und Empfänger verwenden einen FIFO gemeinsam


Bei Aktivierung des Echtzeit-FIFOs können Sie zwischen zwei ähnlichen Typen von Variablen mit aktiviertem FIFO wählen: dem Einzelelement- und dem Multielementpuffer. Einer der Unterschiede zwischen diesen beiden Puffertypen ist, dass der Einzelelement-FIFO bei Über- oder Unterlauf keine Warnung ausgibt. Ein weiterer Unterschied besteht in dem Wert, den LabVIEW ausgibt, wenn mehrere Empfänger Daten von einem leeren Puffer abfragen. Mehrere Empfänger des Einzelelement-FIFOs erhalten denselben Wert, und der FIFO gibt denselben Wert so lange aus, bis ein Sender einen neuen Wert an die Variable übermittelt. Mehrere Empfänger eines leeren Multielement-FIFOs erhalten jeweils den letzten Wert, den sie aus dem Puffer lesen, oder – wenn sie von der Variablen noch nie einen Wert erhalten haben – den Standardwert für den Datentyp der Variablen. In der folgenden Abbildung ist diese Funktionsweise dargestellt.

Abbildung 6: Funktionsweise des letzten Lesevorgangs und die Real-Time-FIFO-Umgebungsvariablen mit mehreren Elementen


Wenn es eine Anwendung erfordert, dass jeder Empfänger jeden Datenwert erhält, der an eine Multielement-FIFO-Umgebungsvariable gesendet wurde, verwenden Sie für jeden Empfänger eine eigene Umgebungsvariable.

Netzwerk-Umgebungsvariable


Mit Hilfe von Netzwerk-Umgebungsvariablen können Sie Daten mit Umgebungsvariablen über ein Ethernet-Netzwerk austauschen. Die Netzwerkimplementierung erfolgt voll und ganz über die Netzwerk-Umgebungsvariable.

Mit Hilfe der Netzwerk-Umgebungsvariablen werden Ihre Daten über das Netzwerk verfügbar. Darüber hinaus werden viele Funktionen hinzugefügt, die bei Einzelprozess-Umgebungsvariablen nicht zur Verfügung stehen. Um diesen zusätzlichen Funktionsumfang zur Verfügung stellen zu können, ist die interne Implementierung der Netzwerk-Umgebungsvariablen komplexer als die einer Einzelprozess-Variablen. In den folgenden Abschnitten werden Aspekte dieser Implementierung besprochen und Empfehlungen für das Erzielen der besten Geschwindigkeit mit Hilfe von Netzwerk-Umgebungsvariablen ausgesprochen.

NI-PSP

Das NI-Protokoll zum Senden und Empfangen (NI-PSP) ist ein Netzwerkprotokoll, das für den Transport von Netzwerk-Umgebungsvariablen optimiert ist.  Das Low-Level-Protokoll unter dem NI-PSP ist TCP/IP. TCP/IP wurde gründlich im Hinblick auf Geschwindigkeit für Desktop-Systeme und Real-Time-Zielsystem von National Instruments abgestimmt (siehe unten für Vergleiche).  

Theorie der Funktionsweise von LogosXT

In Abbildung 7 ist der Softwarestapel von Netzwerk-Umgebungsvariablen dargestellt.  Es ist wichtig, die Funktionsweise zu verstehen, da sie eine Besonderheit der LogosXT-Ebene im Softwarestapel darstellt.  LogosXT ist die Schicht des Stapels, die für die Optimierung des Datendurchsatzes der Umgebungsvariablen verantwortlich ist.

 

Abbildung 7: Netzwerkstapel der Umgebungsvariablen

In Abbildung 8 sind die Hauptkomponenten des LogosXT-Übertragungsalgorithmus dargestellt.  Im Wesentlichen ist der Algorithmus sehr einfach.  Er besteht aus zwei wichtigen Teilen:

    1. ein 8-Kilobyte-Übertragungspuffer
    2. ein 10-Millisekunden-Timer-Thread

Abbildung 8: LogosXT-Teile  Der Puffer wird übertragen, wenn er voll ist oder nachdem 10 ms verstrichen sind.

Diese Zahlen kommen durch Vergleichen von verschiedenen Paketgrößen und Zeiten für die Optimierung des Datendurchsatzes zu Stande.  Der Algorithmus lautet folgendermaßen:

    • WENN der Übertragungspuffer bis zu seiner Kapazität (8 KB) gefüllt ist, bevor der 10-ms-Timer ausgelöst wird, werden die Daten in diesem Puffer sofort an TCP im gleichen Thread gesendet, der den Schreibvorgang ausgelöst hat.  Im Fall der Umgebungsvariablen ist der Thread der Thread der Umgebungsvariablen-Engine.
    • WENN 10 ms verstreichen, ohne dass der Puffer bis zu seiner Kapazität gefüllt ist, werden die Daten im Timer-Thread gesendet.

Wichtiger Hinweis: Es gibt nur einen Übertragungspuffer für alle Verbindungen zwischen zwei Endpunkten.  Alle Variablen, die Verbindungen zwischen zwei verschiedenen Rechnern darstellen, verwenden also einen gemeinsamen Puffer.  Verwechseln Sie diesen Übertragungspuffer nicht mit den Puffereigenschaften von Umgebungsvariablen.  Der Übertragungspuffer ist ein Low-Level-Puffer, der Variablen in eine TCP-Verbindung multiplext und den Datendurchsatz im Netzwerk optimiert.

Sie müssen die Funktionsweise dieser Schicht des Netzwerkstapels verstehen, da sie Auswirkungen auf den Programmcode in Ihrem LabVIEW-Blockdiagramm hat.  Der Algorithmus wartet 10 ms, da es immer effizienter für den Datendurchsatz ist, so viele Daten wie möglich in einem einzigen Sendevorgang zu senden.  Jeder Vorgang im Netzwerk hat einen festgelegten Overhead (für die Dauer der Übertragung und die Paketgröße).  Beim Senden von vielen kleinen Paketen (N Pakete), die insgesamt B Byte enthalten, wird dann im Netzwerk N-mal Overhead verursacht.  Wenn dagegen ein großes Paket mit B Byte gesendet wird, wird im Netzwerk nur einmal ein festgelegter Overhead erzeugt und der gesamte Datendurchsatz ist viel größer.

Dieser Algorithmus funktioniert sehr gut, wenn Sie Daten mit der höchstmöglichen Datendurchsatzrate von oder zu einem Zielsystem streamen möchten.  Wenn Sie dagegen kleinere Pakete in unregelmäßigen Abständen senden möchten, müssen Sie Ihr System für Latenz (oder: Wartezeit) optimieren. Ein Beispiel für solche kleinen Pakete ist das Senden von Befehlen an ein Zielsystem, mit denen eine Operation ausgeführt wird. z. B. Öffnen eines Relais (1 Byte boolesche Daten). Diese Operation soll so schnell wie möglich ausgeführt werden.  In LabVIEW 8.5 gab es keine Möglichkeit, in LogosXT das Leeren des Puffers zu Erzwingen.  Stattdessen war garantiert, dass eine Wartezeit von mindestens 10 ms in das System eingebaut ist, während das Programm darauf wartet, dass sich der Übertragungspuffer füllt, bevor alle vorhandenen Daten alle 10 ms gesendet werden.  

Wenn es für Ihre Anwendung wichtiger ist, dass die Wartezeit optimiert ist, als das in LabVIEW ab Version 8.5.1 der Fall ist, finden Sie das neue VI "Daten der Umgebungsvariablen entfernen" auf der Palette "Umgebungsvariable". Mit diesem VI können Sie das Leeren der Übertragungspuffer in LogosXT über die Engine für Umgebungsvariablen und über das Netzwerk erzwingen.  Dadurch wird die Wartezeit drastisch reduziert.  

Da, wie bereits zuvor erwähnt, alle Umgebungsvariablen, die einen Rechner mit einem anderen Rechner verbinden, gemeinsam einen Übertragungspuffer verwenden, hat das Aufrufen des VIs "Daten der Umgebungsvariablen entfernen" Auswirkungen auf alle Umgebungsvariablen in Ihrem System.  Wenn Sie andere Variablen haben, die von einem hohen Datendurchsatz abhängen, werden diese durch Aufrufen des VIs "Daten der Umgebungsvariablen entfernen" nachteilig beeinflusst (vgl. Abbildung 9).

 

Abbildung 9: VI "Daten der Umgebungsvariable entfernen"

 

Verteilen und Hosten

Sie müssen die Netzwerk-Umgebungsvariable an eine Engine für Umgebungsvariablen übertragen, die Umgebungsvariablenwerte im Netzwerk hostet. Wenn Sie Werte an einen Umgebungsvariablenknoten übertragen, sendet LabVIEW den neuen Wert an die Engine für Umgebungsvariablen, welche die Variable verteilt und gehostet hat. Die Verarbeitungsschleife der Engine für Umgebungsvariablen veröffentlicht den Wert, so dass Empfänger den aktualisierten Wert abrufen können. In Abbildung 10 wird dieser Vorgang illustriert. Wenn mit der Client/Server-Terminologie gearbeitet wird, gilt die Engine für die Umgebungsvariablen als Server für eine Umgebungsvariable und alle Referenzen gelten als Clients, unabhängig davon, ob sie Daten senden oder empfangen. Der Client ist Teil der Implementierung des Umgebungsvariablenknotens. In diesem Artikel sind die Bezeichnungen Client und Empfänger beliebig austauschbar.

Abbildung 10: Ändern von Werten in der Engine für Umgebungsvariablen und Netzwerk-Umgebungsvariablen



Netzwerk-Umgebungsvariablen und LabVIEW Real-Time

Sie können Real-Time-FIFOs mit einer Netzwerk-Umgebungsvariablen aktivieren. Die FIFO-aktivierten Netzwerk-Umgebungsvariablen unterscheiden sich jedoch in ihrer Funktionsweise von Real-Time-FIFO-aktivierten Einzelprozess-Umgebungsvariablen. Bei Einzelprozess-Umgebungsvariablen verwenden alle Sender und Empfänger einen Real-Time-FIFO gemeinsam. Bei Netzwerk-Umgebungsvariablen ist das nicht der Fall. Jeder Empfänger einer Netzwerk-Umgebungsvariablen erhält einen Real-Time-FIFO für einzelne Elemente und für mehrere Elemente (vgl. Abbildung unten).

Abbildung 14: Netzwerk-Umgebungsvariable mit aktiviertem Real-Time-FIFO



Netzwerkpuffer

Daten können bei Verwendung von Netzwerk-Umgebungsvariablen gepuffert werden. Die Einstellungen zur Pufferung können im Dialogfeld Eigenschaften für Umgebungsvariable vorgenommen werden (vgl. Abbildung 12).

Abbildung 12: Aktivieren der Pufferung für eine Netzwerk-Umgebungsvariable


Wenn die Pufferung aktiviert ist, können Sie die Größe des Puffers in Einheiten des Datentyps festlegen, in diesem Fall lautet der Datentyp "Double".

Mit der Pufferung können Sie temporäre Fluktuationen zwischen den Raten für Lesen und Schreiben einer Variablen ausgleichen. Empfänger, die eine Variable gelegentlich langsamer auslesen als Daten gesendet werden, können manche Werteänderungen verpassen. Wenn Ihre Anwendung problemlos gelegentlich Datenpunkte verpassen kann, hat die langsamere Lesen-Rate keine Auswirkung auf die Anwendung und die Pufferung muss nicht aktiviert werden. Wenn der Empfänger jedoch jeden aktualisierten Wert empfangen muss, sollte die Pufferung aktiviert werden. Sie können die Größe des Puffers im Dialogfeld Eigenschaften für Umgebungsvariable auf der Seite Netzwerk festlegen. Sie können somit entscheiden, wie viele aktualisierte Werte in der Anwendung gespeichert werden, bevor alte Daten überschrieben werden.

Wenn Sie einen Netzwerkpuffer im oben gezeigten Dialogfeld konfigurieren, legen Sie tatsächlich die Einstellungen von zwei verschiedenen Puffern fest. Der Puffer des Servers (abgebildet als Puffer in dem Kästchen mit der Bezeichnung "SVG" (Shared Variable Engine - Engine für Umgebungsvariablen) in Abbildung 13 unten wird automatisch erstellt und hat die gleiche Größe wie der Puffer des Clients. Der Puffer des Clients ist wahrscheinlich der Puffer, der Ihnen in den Sinn kommt, wenn Sie die Pufferung einer Umgebungsvariablen aktivieren. Der Puffer des Client (abgebildet auf der rechten Seite in Abbildung 13) ist der Puffer, der die Queue mit vorherigen Werten handhabt. Dieser Puffer sorgt dafür, dass Ihre Umgebungsvariablen vor Fluktuationen in Schleifengeschwindigkeit oder Netzwerkauslastung geschützt werden.

Bei Real-Time-FIFO-aktivierten Einzelprozess-Umgebungsvariablen verwenden alle Sender und Empfänger den gleichen Real-Time-FIFO. Im Gegensatz dazu hat jeder Empfänger einer Netzwerk-Umgebungsvariable seinen eigenen Puffer, so dass die Empfänger nicht miteinander interagieren müssen.

Abbildung 13: Pufferung


Puffer sind nur in Situationen hilfreich, in denen die Raten für Lese- und Schreibvorgänge temporäre Schwankungen aufweisen. Wenn die Anwendung eine unbestimmte Zeit lang ausgeführt wird, verlieren Empfänger, die immer langsamer sind als der Sender, irgendwann Daten, unabhängig von der angegebenen Puffergröße. Puffer sollten nur dann verwendet werden, wenn unbedingt notwendig, um eine unnötige Speicherauslastung zu verhindern, da für jeden Empfänger/Client ein Puffer zugewiesen wird.

Netzwerkpuffer und Real-Time-Puffer

Wenn Sie den Netzwerkpuffer und den Real-Time-FIFO aktivieren, müssen an der Umgebungsvariablen ein Netzwerkpuffer und ein Real-Time-FIFO implementiert werden. Wenn der Real-Time-FIFO aktiviert ist, wird für jeden Sender und Empfänger ein neuer Real-Time-FIFO erstellt, das bedeutet, dass mehrere Sender und Empfänger sich nicht gegenseitig blockieren.

Abbildung 14: Netzwerkpuffer und Real-Time-FIFOs



Obwohl Sie die Größen der beiden Puffer unabhängig voneinander festlegen können, wird in den meisten Fällen empfohlen, dass beide Puffer die gleiche Größe haben. Wenn Sie den Real-Time-FIFO aktivieren, erstellt LabVIEW einen neuen Real-Time-FIFO für jeden Sender und Empfänger. Daher behindern sich mehrere Sender und Empfänger nicht gegenseitig.

Lebensdauer des Puffers

LabVIEW erstellt Netzwerkpuffer und Real-Time-FIFOs beim ersten Schreiben oder Lesen, je nach Position des Puffers. Puffer des Servers werden erstellt, wenn eine Umgebungsvariable das erste Mal gesendet wird. Puffer des Clients werden erstellt, wenn ein Empfänger die Variable ausliest.  In LabVIEW bis Version 8.6 trat dies auf, wenn eine Umgebungsvariablenknoten zum Lesen oder Schreiben das erste Mal ausgeführt wurde.  In LabVIEW ab Version 8.6 tritt dies auf, wenn das VI ausgeführt wird, das die Umgebungsvariable enthält.  Wenn ein Sender Daten an eine Umgebungsvariable überträgt, bevor ein Empfänger eine Verbindung mit der Variablen hergestellt hat, stehen dem Empfänger die ersten gesendeten Werte nicht zur Verfügung.

Abbildung 15: Lebensdauer des Puffers



Pufferüberlauf/Pufferunterlauf

In LabVIEW ab Version 8.2 meldet die Netzwerk-Umgebungsvariable Überlauf und Unterlauf am Netzwerkpuffer. Die Real-Time-FIFOs geben bei Überlauf und Unterlauf in allen LabVIEW-Versionen einen Fehler aus. Eine Anwendung in LabVIEW 8.0 oder 8.0.1 kann auf zwei verschiedene Arten auf Unterlauf am Netzwerkpuffer prüfen. Da die Auflösung des Zeitstempels der Umgebungsvariablen 1 ms ist, kann der Zeitstempel einer Umgebungsvariablen mit dem nachfolgenden Zeitstempel des Lesevorgangs verglichen werden, um Pufferunterläufe zu erkennen, wenn die Variablen mit einer Frequenz kleiner als 1 kHz aktualisiert wird. Oder der Empfänger kann mit Hilfe einer Nummer, die mit den Daten gebündelt wird, Überläufe/Unterläufe feststellen. Die zweite Vorgehensweise kann nicht bei Umgebungsvariablen in einer zeitkritischen Schleife verwendet werden, wenn der Datentyp "Array" lautet. Die Ursache dafür liegt darin, dass die Real-Time-FIFO-aktivierten Umgebungsvariablen den benutzerdefinierten Datentyp (Cluster) nicht unterstützen, wenn eines der Elemente des Clusters sich in einem Array befindet.

Lebensdauer der Umgebungsvariablen

Wie bereits zuvor erwähnt, sind alle Umgebungsvariablen Teil einer Projektbibliothek. Die Engine für Umgebungsvariablen registriert Projektbibliotheken und die Umgebungsvariablen in diesen Projektbibliotheken, wann immer LabVIEW eine dieser Variablen benötigt. Per Standardeinstellung wird eine Bibliothek aus Umgebungsvariablen übertragen und veröffentlicht, sobald ein VI ausgeführt wird, dass eine Referenz auf eine in der Bibliothek enthaltenen Variable hat. Da die Engine für Umgebungsvariablen die gesamte Bibliothek überträgt, welcher die Umgebungsvariable angehört, veröffentlicht die Engine für Umgebungsvariablen alle Umgebungsvariablen in der Bibliothek, unabhängig davon, ob ein ausgeführtes VI eine Referenz auf alle VIs hat. Sie können eine Projektbibliothek manuell verteilen, indem Sie im Projekt-Explorer mit der rechten Maustaste auf die Bibliothek klicken.

Auch nach dem Anhalten des VIs oder Neustarten des Rechners, auf dem sich die Umgebungsvariable befindet, ist die Umgebungsvariable weiterhin im Netzwerk verfügbar. Wenn Sie die Umgebungsvariable aus dem Netzwerk entfernen möchten, müssen Sie die Verteilung der Bibliothek rückgängig machen, zu der die Variable im Projekt-Explorer zugeordnet ist. Sie können auch die Option Werkzeuge»Umgebungsvariable»Variablenmanager auswählen, um die Umgebungsvariable oder alle Projektbibliotheken mit Variablen zu entfernen. In Labview 8.6 wurde der Variablenmanager durch den DSM (Distributed System Manager) ersetzt, der über Werkzeuge»DSM aufgerufen wird.

Frontpanel-Datenbindung

Eine weitere Funktion, die nur den Netzwerk-Umgebungsvariablen zur Verfügung steht, ist die Frontpanel-Datenbindung. Zum Erstellen eines Elements, das an eine Umgebungsvariable gebunden ist, ziehen Sie eine Umgebungsvariable aus dem Projekt-Explorer auf das Frontpanel eines VIs. Wenn Sie die Datenbindung für ein Element aktivieren, ändert sich der Wert der Umgebungsvariablen, an welches das Element gebunden ist, wenn sich der Wert des Elements ändert. Wenn die Verbindung mit der Engine für Umgebungsvariablen erfolgreich ist, wenn das VI ausgeführt wird, wird neben dem Frontpanel-Element eine kleine grüne LED angezeigt.

Abbildung 16: Binden eines Frontpanel-Elements an eine Umgebungsvariable


Sie können die Datenbindung eines Anzeige- oder Bedienelements auf der Registerkarte Datenbindung des Dialogfelds Eigenschaften anzeigen und ändern. Wenn Sie mit dem LabVIEW Real-Time Module oder dem LabVIEW DSC Module arbeiten, können Sie über Auswahl von Werkzeuge»Umgebungsvariable»Frontpanelbindung - Massenkonfiguration das Dialogfeld Frontpanelbindung - Massenkonfiguration öffnen und eine Schnittstelle erstellen, mit der mehrere Anzeige- und Bedienelemente an Umgebungsvariablen gebunden werden.

Es wird nicht empfohlen, die Frontpanel-Datenbindung in Anwendungen zu verwenden, die auf LabVIEW-Real-Time-Zielsystemen ausgeführt werden, da möglicherweise kein Frontpanel vorhanden ist.

Programmatischer Zugriff

Wie bereits besprochen, können Sie Umgebungsvariablen interaktiv mit Hilfe eines LabVIEW-Projekts erstellen, konfigurieren und verteilen. Sie können mit Hilfe eines Umgebungsvariablenknotens Daten mit einer Umgebungsvariablen im Blockdiagramm oder über die Frontpanel-Datenbindung austauschen. Ab LabVIEW 2009 haben Sie programmatischen Zugriff auf diesen Funktionsumfang.

Erstellen Sie Projektbibliotheken und Umgebungsvariablen programmatisch mit Hilfe des VI-Servers in Anwendungen, in denen Sie eine große Anzahl von Umgebungsvariablen benötigen. Darüber hinaus bietet das LabVIEW DSC Module eine umfangreiche Auswahl von VIs zum programmatischen Erstellen und Bearbeiten von Umgebungsvariablen und Projektbibliotheken sowie zum Verwalten der Engine für Umgebungsvariablen. Sie können Bibliotheken von Umgebungsvariablen nur auf Windows-Systemen programmatisch erstellen. Sie können diese neuen Bibliotheken jedoch programmatisch auf Windows- oder LabVIEW-Real-Time-Zielsysteme verteilen.

Verwenden Sie die programmatische API für Umgebungsvariablen in Anwendungen, in denen die Umgebungsvariable, mit der ein VI Daten austauscht, dynamisch geändert werden muss, oder in denen Daten mit einer großen Anzahl von Variablen ausgetauscht werden müssen. Sie können eine Umgebungsvariable dynamisch ändern, indem Sie die URL programmatisch erstellen. 

Abbildung 17: Verwendung der API für Umgebungsvariablen zum Lesen und Schreiben von Umgebungsvariablen



Die Bibliothek für Netzwerkvariablen wurde in NI LabWindows/CVI 8.1 und NI Measurement Studio 8.1 eingeführt. Umgebungsvariablen können jedoch auch mit ANSI C, Visual Basic .NET und Visual C# gesendet und empfangen werden.

Engine für Umgebungsvariablen


Die Engine für Umgebungsvariablen ist ein Rahmenwerk, das es Netzwerk-Umgebungsvariablen ermöglicht, Werte über das Netzwerk zu senden. Unter Windows wird die Engine für Umgebungsvariablen als ein Dienst konfiguriert und beim Starten des Systems gestartet. Auf Real-Time-Zielsystemen ist die Engine für Umgebungsvariablen eine installierbare Startkomponente, die beim Systemstart geladen wird.

Um Netzwerk-Umgebungsvariablen verwenden zu können, muss die Engine für Umgebungsvariablen auf mindestens einem Knoten im verteilten System ausgeführt werden. Jeder Knoten im Netzwerk kann Daten mit Umgebungsvariablen austauschen, die von der Engine für Umgebungsvariablen veröffentlicht werden. Wie in Tabelle 1 dargestellt, können Knoten eine Referenz auf eine Variable haben, ohne dass die Engine für Umgebungsvariablen installiert ist. Es ist auch möglich, dass Sie mehrere Engines für Umgebungsvariablen auf mehreren Systemen gleichzeitig installiert haben, wenn Sie Umgebungsvariablen basierend auf den Anforderungen Ihrer Anwendung an verschiedenen Stellen verteilen müssen.

Empfehlungen für den Speicherort von Umgebungsvariablen

Bei der Entscheidung, von welchem Rechner aus Netzwerk-Umgebungsvariablen verteilt werden sollen und auf welchem Rechner Netzwerk-Umgebungsvariablen gehostet werden sollen, müssen eine Vielzahl von Faktoren beachtet werden.

Ist der Computer mit der Engine für Umgebungsvariablen kompatibel?

In der folgenden Tabelle finden Sie eine Zusammenfassung der Plattformen, auf denen die Engine für Umgebungsvariablen verfügbar ist und auf denen Netzwerk-Umgebungsvariablen mit Hilfe von Referenzknoten oder der DataSocket-API verwendet werden können. Für die Verwendung der Engine für Umgebungsvariablen sind auf allen Plattformen mindestens 32 MB RAM Speicher erforderlich (empfohlen: 64 MB).

Das Verwenden von Umgebungsvariablen wird auf Linux oder Macintosh immer noch nicht unterstützt.

Windows-PCs
Mac OS
Linux
PXI
Real-Time
Compact FieldPoint
CompactRIO
Compact Vision System
Rechner mit
LabVIEW Real-Time ETS
Engine für Umgebungsvariablen
X
X
Referenzknoten
X
X
DataSocket-API mit PSP
Tabelle 1: Überblick zur Kompatibilität von Netzwerk-Umgebungsvariablen

Erfordert die Anwendung Funktionsumfang für Datenprotokollierung und -überwachung?

Wenn Sie die Funktionen des LabVIEW DSC Modules verwenden möchten, müssen die Umgebungsvariablen auf einem Windows-Rechner gehostet werden. Mit dem LabVIEW DSC Module wird folgender Funktionsumgang zu Netzwerk-Umgebungsvariablen hinzugefügt:
· Protokollierung von historischen Daten in die NI-Citadel-Datenbank
· Netzwerkalarme und Protokollierung von Alarmen
· Skalierung
· benutzerdefinierte Einstellungen für Sicherheit
· Startwert
· Möglichkeit zum Erstellen von benutzerdefinierten I/O-Servern
· Integration der LabVIEW-Ereignisstruktur in Umgebungsvariablen
· LabVIEW-VIs zum programmatischen Steuern aller Aspekte von Umgebungsvariablen und Engine für Umgebungsvariablen. Diese VIs sind besonders nützlich für das Verwalten einer großen Anzahl von Umgebungsvariablen.

Hat der Computer ausreichend Prozessor- und Speicherressourcen?

Die Engine für Umgebungsvariablen ist ein zusätzlicher Prozess, der sowohl Prozessor- als auch Speicherressourcen erfordert. Um die beste Geschwindigkeit in einem verteilten System zu erreichen, installieren Sie die Engine für Umgebungsvariablen auf den Rechnern mit den besten Prozessor- und Speicherressourcen.

 

Welches System ist immer online?

Wenn Sie eine verteilte Anwendung erstellen, bei der einige Systeme in periodischen Abständen offline sind, hosten Sie die Umgebungsvariable auf einem System, das immer online ist.

Zusätzliche Funktionen der Engine für Umgebungsvariablen

In Abbildung 18 sind die verschiedenen Aufgaben der Engine für Umgebungsvariablen dargestellt. Mit der Engine für Umgebungsvariablen werden Netzwerk-Umgebungsvariablen verwaltet und darüber hinaus folgende Aufgaben erfüllt:
· Sammeln von Daten, die von I/O-Servern empfangen werden
· Bereitstellen von Daten über die OPC- und PSP-Server für Empfänger
· Bereitstellen von Diensten für Skalierungen, Alarme und Protokollierung für Umgebungsvariablen, für welche diese Dienste konfiguriert sind; diese Dienste sind nur mit dem LabVIEW DSC Module verfügbar
· Überwachung von Alarmbedingungen und Reaktion auf Alarme

I/O-Server

I/O-Server sind Plugins für die Engine für Umgebungsvariablen, mit deren Hilfe Programme Daten mit Hilfe der Engine für Umgebungsvariablen veröffentlichen können. NI FieldPoint enthält einen I/O-Server, der Daten direkt von der FieldPoint-Bank an die Engine für Umgebungsvariablen veröffentlicht. Da die Engine für Umgebungsvariablen ein OPC-Server ist, dient die Kombination aus Engine für Umgebungsvariablen und FieldPoint-I/O-Server als FieldPoint-OPC-Server. Die Engine für Umgebungsvariablen ist nicht im FieldPoint-Installationsprogramm enthalten. Die Engine muss von einer anderen Softwarekomponente, wie z. B. LabVIEW, installiert werden.

NI-DAQmx enthält ebenfalls einen I/O-Server, mit dem globale virtuelle NI-DAQmx-Kanäle automatisch an die Engine für Umgebungsvariablen veröffentlicht werden können. Dieser I/O-Server ersetzt den OPC-Server und die Remote-Device-Access-Funktion (RDA) des traditionellen DAQ-Treibers. Die Engine für Umgebungsvariablen ist in NI-DAQmx enthalten und kann von NI-DAQmx installiert werden, wenn sie noch nicht über LabVIEW installiert wurde.

Mit dem LabVIEW DSC Module können Benutzer neue I/O-Server erstellen.

Abbildung 18: Engine für Umgebungsvariablen



OPC

Die Engine für Umgebungsvariablen ist kompatibel mit 3.0 und kann als OPC-Server auf Windows-Rechnern eingesetzt werden. Jeder OPC-Client kann Daten mit einer Umgebungsvariablen austauschen, die auf einem Windows-Rechner gehostet wird. Wenn Sie das LabVIEW DSC Module auf einem Windows-Rechner installieren, kann die Engine für Umgebungsvariablen ein OPC-Client sein. Sie können Umgebungsvariablen auf einem Windows-Rechner an OPC-Datenobjekte mit DSC binden und Daten mit dem OPC-Datenobjekt austauschen.

Da OPC eine Technologie ist, die auf COM basiert, funktionieren die Windows-API und Real-Time-Zielsysteme nicht direkt mit OPC. Wie in Abbildung 19 dargestellt, können Sie immer noch von einem Real-Time-Zielsystem auf OPC-Datenobjekte zugreifen, indem Sie eine Umgebungsvariable auf einem Windows-Rechner hosten.

Abbildung 19: Bindung an ein OPC-Datenobjekt

Leistung


In diesem Abschnitt finden Sie allgemeine Richtlinien für das Erstellen von leistungsstarken Anwendungen mit Hilfe von Umgebungsvariablen.

Da Einzelprozess-Umgebungsvariablen ähnlich den globalen variablen in LabVIEW und Real-Time-FIFOs implementiert werden, hat National Instruments keine besonderen Empfehlungen für das Erreichen von hoher Geschwindigkeit bei Verwendung von Einzelprozess-Umgebungsvariablen. In den folgenden Abschnitten liegt das Hauptaugenmerk auf Netzwerk-Umgebungsvariablen.

Gemeinsame Verwendung des Prozessors

Mit Netzwerk-Umgebungsvariablen werden LabVIEW-Blockdiagramme vereinfacht, indem viele Implementierungsdetails für die Netzwerkprogrammierung versteckt werden. Anwendungen bestehen aus LabVIEW-VIs, der Engine für Umgebungsvariablen und Client-Code der Engine für Umgebungsvariablen. Um die bestmögliche Geschwindigkeit der Umgebungsvariablen zu erreichen, entwickeln Sie Ihre Anwendung so, dass der Prozessor in regelmäßigen Abständen freigegeben wird, damit die Threads der Engine für Umgebungsvariablen ausgeführt werden können. Eine Möglichkeit, dies zu erreichen, ist das Einfügen von Warteperioden in die Verarbeitungsschleifen und das Sicherzustellen, dass in der Anwendung keine ungetakteten Schleifen verwendet werden. Wie lang die Warteperiode ist, hängt von der Anwendung, vom Prozessor und vom Netzwerk ab. Die Parameter jeder Anwendung müssen im Laufe der Zeit angepasst werden, um die beste Geschwindigkeit zu erreichen.

Speicherort der Engine für Umgebungsvariablen

Im Abschnitt Empfehlungen für den Speicherort von Umgebungsvariablen wurden Faktoren besprochen, die beachtet werden müssen, wenn Sie sich dazu entscheiden, die Engine für Umgebungsvariablen zu installieren. In Abbildung 20 sehen Sie einen weiteren Faktor, der einen großen Einfluss auf die Geschwindigkeit der Umgebungsvariablen hat. In diesem Beispiel ist ein Real-Time-Zielsystem dargestellt. Die Grundkonzepte gelten jedoch auch für Nicht-Real-Time-Zielsysteme. In Abbildung 20 wird die ineffiziente Verwendung von Netzwerk-Umgebungsvariablen veranschaulicht: Sie erzeugen Daten auf einem Real-Time-Zielsystem und müssen die verarbeiteten Daten auf der Festplatte des Rechners protokollieren, aber von einem Rechner im Netzwerk aus überwachen. Da Variablen-Empfänger Daten von der Engine für Umgebungsvariablen empfangen müssen, ist die Wartezeit zwischen dem Senden von Daten an die Schleife mit hoher Priorität und dem Empfangen in der Schleife mit normaler Priorität sehr groß. Das liegt daran, dass die Daten zweimal über das Netzwerk gesendet werden.

Abbildung 20: Ineffiziente Verwendung von Netzwerk-Umgebungsvariablen auf einem Real-Time-System


In Abbildung 21 ist eine bessere Architektur für diese Anwendung dargestellt. In der Anwendung wird eine Einzelprozess-Umgebungsvariable zum Austauschen von Daten zwischen der Schleife mit hoher Priorität und der Schleife mit geringerer Priorität verwendet, wodurch die Wartezeit dramatisch verringert wird. Die Schleife mit geringerer Priorität protokolliert die Daten und veröffentlich die aktualisierten Daten an eine Netzwerk-Umgebungsvariable für den Empfänger auf dem Host-Rechner.

Abbildung 21: Effiziente Verwendung von Netzwerk-Umgebungsvariablen auf einem Real-Time-System

Benchmark-Tests

In diesem Abschnitt wird die Geschwindigkeit von Umgebungsvariablen mit anderen möglichen Datenübertragungsmethoden in LabVIEW verglichen, wie z. B. der globalen Variablen in LabVIEW, Real-Time-FIFOs und TCP/IP. In der folgenden Tabelle finden Sie eine Zusammenfassung der Tests, die in den folgenden Abschnitten genauer besprochen werden.

 

Test
Beschreibung
Speicherort der Engine für Umgebungsvariablen
Anmerkungen
T1
Einzelprozess-Umgebungsvariable und globale Variable
N/A
Ermitteln der maximalen Geschwindigkeit beim Lesen/Schreiben
T2
Einzelprozess-Umgebungsvariable mit Real-Time-FIFO
und Real-Time-FIFO-VIs
N/A

Ermitteln der maximalen Geschwindigkeit beim Lesen/Schreiben bei Verwendung des Real-Time-FIFOs

Bestimmen der höchsten Rate, mit der Daten an eine Umgebungsvariable oder ein Real-Time-FIFO in einer zeitgesteuerten Schleife gesendet werden und gleichzeitig von einer Schleife mit normaler Priorität ausgelesen werden können

T3
Netzwerk-Umgebungsvariable mit Real-Time-FIFO und Real-Time-FIFO mit zwei Schleifen mit TCP
PXI und LV RT

Ermitteln der maximalen Geschwindigkeit, mit der Einzelwerte über das Netzwerk gestreamt werden können

Umgebungsvariable: Empfänger-VI ist immer auf dem Host. RT-FIFO + TCP: ähnlich wie T2 mit zusätzlicher TCP-Kommunikation. IP-Netzwerk

T4
Speicherbedarf der Netzwerk-Umgebungsvariablen
Real-Time-Zielsystem
Ermitteln der Speicherauslastung von Umgebungsvariablen nach der Verteilung

T5

Vergleich zwischen Netzwerk-Umgebungsvariablen (LabVIEW 8.2) und Variablen (LabVIEW 8.5) - Streaming

Real-Time-Zielsystem

Vergleich zwischen der Implementierung von NI-PSP (LabVIEW 8.5) mit der Implementierungen in LabVIEW-Versionen bis 8.20

Messen des Datendurchsatzes einer Anwendung, mit der Signalverlaufsdaten von einem cRIO-Gerät an einen Desktop-Host gestreamt werden

T6

Vergleich zwischen Netzwerk-Umgebungsvariablen (LabVIEW 8.2) und Variablen (LabVIEW 8.5) - hohe Kanalanzahl

Real-Time-Zielsystem

Vergleich zwischen der Implementierung von NI-PSP (LabVIEW 8.5) mit der Implementierungen in LabVIEW-Versionen bis 8.20

Messen des Datendurchsatzes einer Anwendung mit hoher Kanalanzahl auf einem cRIO-Gerät

Tabelle 2: Überblick über Benchmark-Tests


In den folgenden Abschnitten wird der Programmcode von National Instruments beschrieben, der für die einzelnen Tests erstellt wurde. Anschließend werden die Ergebnisse der Benchmark-Tests präsentiert. Im Abschnitt Methodologie und Konfiguration wird detailliert besprochen, welche Methodologie für jeden Test ausgewählt wurde und die exakte Hardware- und Softwarekonfiguration, welche für den Test verwendet wurde.

Einzelprozess-Umgebungsvariable und globale Variable in LabVIEW

Die Einzelprozess-Umgebungsvariable ist vergleichbar mit der globalen Variable in LabVIEW. Die Umsetzung einer Einzelprozess-Umgebungsvariable ist eine globale Variable in LabVIEW mit zusätzlichem Funktionsumfang für einen Zeitstempel.

Zum Vergleichen der Geschwindigkeit einer Einzelprozess-Umgebungsvariablen mit einer globalen Variablen in LabVIEW hat National Instruments Benchmark-VIs erstellt, mit deren Hilfe gemessen werden kann, wie oft das VI Daten mit einer globalen Variablen oder einer Einzelprozess-Umgebungsvariablen austauschen kann. In Abbildung 22 ist der Benchmark-Test zum Lesen der Einzelprozess-Umgebungsvariablen dargestellt. Der Benchmark-Test zum Schreiben von Daten an eine Einzelprozess-Umgebungsvariable und die Tests für das Austauschen von Daten mit der globalen Variablen in LabVIEW sind auch nach diesem Muster aufgebaut.

Abbildung 22: Benchmark-VI zum Senden von Daten an eine Einzelprozess-Umgebungsvariable


Die Kombination von Tests zum Senden und Empfangen von Daten enthält auch Programmcode, mit dem geprüft werden kann, ob jeder gesendete Datenpunkt auch in der gleichen Iteration der Schleife empfangen werden, ohne dass Daten beschädigt werden.

Testergebnisse für T1

In Abbildung 23 sind die Ergebnisse von Test T1 zu sehen. Die Ergebnisse zeigen, dass die Lesegeschwindigkeit einer Einzelprozess-Umgebungsvariablen geringer ist als die Lesegeschwindigkeit einer globalen Variablen in LabVIEW. Die Schreibgeschwindigkeit und somit die kombinierte Lese-/Schreibgeschwindigkeit einer Einzelprozess-Umgebungsvariablen ist geringfügig langsamer als die einer globalen Variablen in LabVIEW. Die Geschwindigkeit der Einzelprozess-Umgebungsvariablen wird durch Aktivieren/Deaktivieren des Zeitstempels beeinflusst. Es wird daher empfohlen, den Zeitstempel zu deaktivieren, wenn er nicht benötigt wird.


Im Abschnitt Methodologie und Konfiguration werden die spezifischen Details der Benchmark-Methodologie und der Konfiguration dieser Tests näher erläutert.

 


Abbildung 23: Geschwindigkeit von Einzelprozess-Umgebungsvariable und globaler Variable



Einzelprozess-Umgebungsvariable und Real-Time-FIFOs

National Instruments hat Benchmark-Tests für Datendurchsatzraten entwickelt, um die Geschwindigkeit der FIFO-aktivierten Einzelprozess-Umgebungsvariablen mit den traditionellen Real-Time-FIFO-VIs zu vergleichen. Mit den Tests wird auch die Auswirkung der Größe auf die übertragenen Daten (Nutzdaten) für die beiden Real-Time-FIFO-Implementierungen überprüft.

Die Test-VIs bestehen aus einer zeitkritischen Schleife, die Daten erzeugt und einer Schleife mit normaler Priorität, die Daten empfängt. National Instruments hat die Auswirkung der Größe der Nutzdaten festgestellt, indem eine große Palette von Skalaren und Arrays doppelter Genauigkeit ausgewertet wurde. Mit dem Datentyp "Skalar" wird der Datendurchsatz bestimmt, wenn die Nutzdaten "Double" sind und mit dem Datentyp "Array" wird der Datendurchsatz für den Rest der Nutzdaten bestimmt. Der Test zeichnet den maximalen Datendurchsatz auf, indem die maximale Geschwindigkeit bestimmt wird, mit der beide Schleifen ohne Datenverlust ausgeführt werden können.

In Abbildung 24 sehen Sie ein vereinfachtes Blockdiagramm des Real-Time-FIFO-Benchmark-Tests, bei dem notwendiger Programmcode ausgelassen wurde, der für das Erstellen und Löschen des FIFOs notwendig ist. In LabVIEW 8.20 wurde eine neue FIFO-Funktion eingeführt, welche das hier gezeigte FIFO-SubVI ersetzt. Die FIFO-Funktionen wurden für Daten verwendet, die in diesem Artikel dargestellt werden und sind leistungsfähiger als ihre SubVI-Vorgänger in LabVIEW 8.0.x.

Abbildung 24: Vereinfachtes Benchmark-Test-VI für Real-Time-FIFO


Eine äquivalente Version des Tests verwendet die Einzelprozess-Umgebungsvariable. In Abbildung 25 ist das vereinfachte Blockdiagramm zu sehen.

Abbildung 25: Vereinfachtes Benchmark-Test-VI mit FIFO-aktivierter Einzelprozess-Umgebungsvariable



Testergebnisse für T2

In den Abbildungen 26 und 27 sehen Sie die Testergebnisse von Test T2. In den Graphen werden die Geschwindigkeiten der FIFO-aktivierten Einzelprozess-Umgebungsvariablen und der Real-Time-Funktionen gegenübergestellt. Aus den Ergebnissen wird deutlich, dass die Einzelprozess-Umgebungsvariable geringfügig langsamer ist als die Real-Time-FIFOs.

Abbildung 26: Geschwindigkeit von Einzelprozess-Umgebungsvariable und Real-Time-FIFO-VI (PXI)

Abbildung 27: Geschwindigkeit von Einzelprozess-Umgebungsvariable und Real-Time-FIFO-VI (cRIO 9012)



Netzwerk-Umgebungsvariablen und Real-Time-FIFOs und TCP/IP

Mit der Flexibilität der Umgebungsvariablen können Sie Einzelprozess-Umgebungsvariablen schnell über das Netzwerk mit nur wenigen Änderungen der Einstellungen veröffentlichen. Besonders bei Real-Time-Anwendungen erfordert die Durchführung der gleichen Transformation in früheren LabVIEW-Versionen die Einführung einer großen Menge Programmcode zum Lesen des Real-Time-FIFOs auf dem Real-Time-Controller und zum Senden der Daten über das Netzwerk mit Hilfe eines der verfügbaren Netzwerkprotokolle. Zum Vergleichen der Geschwindigkeit dieser beiden unterschiedlichen Vorgehensweisen hat National Instruments Benchmark-VIs erstellt, mit denen jeweils der Datendurchsatz für verschiedene Nutzdaten gemessen wird, bei dem kein Datenverlust auftritt.

Für die Vorgehensweise ohne Variable verwendet das Benchmark-VI Real-Time-FIFOs und TCP/IP. Eine zeitkritische Schleife erzeugt Daten und sendet diese an den Real-Time-FIFO; eine Schleife mit normaler Priorität liest die Daten aus dem FIFO aus und sendet diese mit Hilfe von TCP/IP über das Netzwerk. Ein Host-Rechner ruft die Daten ab und validiert, ob Datenverlust aufgetreten ist.

In Abbildung 28 sehen Sie ein vereinfachtes Blockdiagramm des Benchmark-VIs des Real-Time-FIFOs und von TCP/IP. Dieses VI stellt eine starke Vereinfachung des tatsächlichen Benchmark-Test-VIs dar.

Abbildung 28: Vereinfachtes Benchmark-Test-VI für Real-Time-FIFO und TCP/IP


National Instruments hat eine äquivalente Version des Tests mit der Netzwerk-Umgebungsvariablen erstellt. In Abbildung 29 ist ein vereinfachtes Blockdiagramm dargestellt.

Abbildung 29: Vereinfachtes Benchmark-VI für Real-Time-FIFO-aktivierte Netzwerk-Umgebungsvariable



Testergebnisse für T3

Dieser Abschnitt enthält die Ergebnisse von Test T3, in dem die Geschwindigkeit der Real-Time-FIFO-aktivierten Netzwerk-Umgebungsvariablen mit dem entsprechenden Programmcode mit den Real-Time--FIFO-VIs und LabVIEW-TCP/IP-Funktionen verglichen wird. In Abbildung 30 sind die Ergebnisse für den Test zu sehen, bei dem das LabVIEW-Real-Time-Zielsystem ein PXI-Real-Time-Controller ist.

Abbildung 30: Geschwindigkeit von Netzwerkumgebungs-Umgebungsvariable und Real-Time-FIFO-VI mit TCP-VI (PXI)


 Die Ergebnisse von T3 zeigen, dass der Datendurchsatz der Netzwerk-Umgebungsvariablen vergleichbar ist mit dem Datendurchsatz von TCP und dass beide Vorgehensweisen konsistent sind für moderate bis große Nutzdatenmengen.  Die Umgebungsvariable vereinfacht die Programmierung, was jedoch mit Nachteilen einhergeht. Bei Verwendung einer einfachen TCP-Implementierung, ist es möglich, dass die Vorteile von Umgebungsvariablen nicht ausreichend genutzt werden, besonders bei der Arbeit mit NI-PSP in LabVIEW ab Version 8.5.

 
Testergebnisse für T4

Speicherbedarf der Netzwerk-Umgebungsvariablen

Es gab keine bedeutenden Änderungen am Speicherbedarf der Variablen in LabVIEW 8.5.  Daher wurde dieser Benchmark-Test nicht erneut durchgeführt.

Es ist nicht einfach, den Speicherbedarf der Umgebungsvariablen zu bestimmen, da sich der Speicher, der von der Variablen verwendet wird, nach der Konfiguration richtet. Netzwerk-Umgebungsvariablen mit Puffer z. B. weisen den Speicher nach Bedarf dynamisch zu. Wenn eine Umgebungsvariable Real-Time-FIFOs verwendet, erhöht sich die Speicherauslastung, da zusätzlich zur Verwendung von Netzwerkpuffern Puffer für den FIFO erstellt werden. Daher bieten die Ergebnisse der Benchmark-Tests nur eine Messbasis für den Speicher.

In Abbildung 31 sehen Sie den Speicher, der von der Engine für Umgebungsvariablen verwendet wird, nachdem 500 und 1000 Umgebungsvariablen des angegeben Typs übertragen wurden. Der Graph zeigt, dass der Typ der Variablen keine große Auswirkung auf die Speicherauslastung der verteilten Umgebungsvariablen hat. Es handelt sich hierbei um Variablen ohne Puffer.

Abbildung 31: Speicherauslastung von Netzwerk-Umgebungsvariablen mit unterschiedlichen Datentypen

In Abbildung 32 wird die Speicherauslastung als eine Funktion der Anzahl der verteilten Umgebungsvariablen dargestellt. In diesem Test wird nur ein Typ von Variablen, ein leeres boolesches Array verwendet. Die Speicherauslastung erhöht sich linear mit der Anzahl der Variablen.

Abbildung 32: Speicherauslastung von Umgebungsvariablen unterschiedlicher Größe

 

Testergebnisse für Test T5

Vergleich zwischen Netzwerk-Umgebungsvariablen (LabVIEW 8.2) und Variablen (LabVIEW 8.5) - Streaming
 
In LabVIEW 8.5 wurde die untere Schicht des Netzwerkprotokolls neu implementiert, mit dem Umgebungsvariablen übertragen werden. Die neue Version ist bedeutend schneller.
 
In diesem Fall wurde eine Variable des Typs Signalverlauf aus DBL-Werten auf einem cRIO 9012 gehostet.  Es wurden alle Daten erzeugt, in einer engen Schleife an den Host übertragen, der die Daten anschließend so schnell wie möglich aus einem anderen Umgebungsvariablenknoten für den Signalverlauf ausgelesen hat.
 
In Abbildung wird deutlich, dass sich die Geschwindigkeit in LabVIEW 8.5 um über 600% für diesen Anwendungsfall verbessert hat.
 

Abbildung 33: Vergleich des Datendurchsatzes eines Signalverlaufs zwischen LabVIEW 8.5 und LabVIEW 8.20 (und früher)

Testergebnisse für T6

Vergleich zwischen Netzwerk-Umgebungsvariablen (LabVIEW 8.2) und Variablen (LabVIEW 8.5) - Streaming

In diesem Test wurden die gleichen beiden Zielsysteme wie in Test T5 verwendet. Aber statt eine SGL-Variable zu übertragen, wurde der Datentyp in DBL geändert und die Anzahl der Umgebungsvariablen zur Messung des Datendurchsatzes variiert von 1 bis 1000.  Alle Variablen werden auf dem cRIO 9012 gehostet, auf dem auch die Daten erzeugt und an den Host übertragen wurden, wo sie abgerufen werden.

In Abbildung 34 sehen Sie eine deutliche Verbesserung der Geschwindigkeit in LabVIEW 8.5 gegenüber LabVIEW 8.20.  Der Datendurchsatz ist jedoch bedeutend kleiner im Fall von vielen kleineren Variablen als bei einer großen Variablen wie in Test T5.  Die Ursache dafür liegt darin, dass jede Variable mit einer festgelegten Menge an Overhead verknüpft ist.  Bei Verwendung von vielen Variablen, wird dieser Overhead mit der Anzahl der Variablen multipliziert und wird spürbar.

Abbildung 34: Vergleich des Datendurchsatzes einer Anwendung mit hoher Kanalanzahl zwischen LabVIEW 8.5 und LabVIEW 8.20 (und früher)


Methodologie und Konfiguration

In diesem Abschnitt erhalten Sie detaillierte Informationen zum Benchmark-Prozess für alle zuvor erwähnten Tests.

Methodologie und Hinweise für Test T1

In Test T1 wird eine einfache Benchmark-Test-Vorlage verwendet, mit der die Rate von Lese- und Schreibvorgängen ermittelt wird, indem der Mittelwert von einer großen Anzahl von Durchläufen berechnet wird. Jeder Test wurde insgesamt 500 Millionen Iterationen lang ausgeführt. Die gesamte Ausführungsdauer liegt bei einer Minute (Millisekunden-Taktperiode).

Hardware-/Softwarekonfiguration für Test T1

 

Hardware des Host-Rechners
  • Dell Precision 450
  • Dual Intel Xeon Pentium-Prozessoren mit 2,4 GHz
  • DRAM-Speicher mit 1 GB

Software des Host-Rechners
  • Windows XP SP2
  • LabVIEW 8.20

Methodologie und Hinweise für Test T2

In Test T2 wird der Datendurchsatz gemessen, indem die maximale Kommunikationsrate zwischen Tasks ermittelt wird, die mit verschiedenen Prioritäten ausgeführt werden. Eine zeitgesteuerte Schleife, die mit einer Millisekunden-Taktperiode ausgeführt wird, enthält einen Datenproduzenten. Der Verbraucher dieser Daten ist eine frei laufende Schleife mit normaler Priorität, die Daten aus dem Real-Time-FIFO oder einer Einzelprozess-Umgebungsvariablen ausliest, bis diese leer ist. Dieser Vorgang wird so lange wiederholt, bis eine bestimmte Zeitdauer ohne Auftreten von Fehlern überschritten wird. Das Testergebnis ist nur gültig, wenn alle der folgenden Bedingungen erfüllt sind:

  • es tritt kein Pufferüberlauf auf
  • Daten werden nicht beschädigt: es tritt kein Datenverlust auf und der Empfänger erhält die Daten in der Reihenfolge, in der sie gesendet wurden
  • die zeitgesteuerte Schleife kann nach einer Warmlaufperiode von 1 s Schritt halten


Die Empfängerschleife der Einzelprozess-Umgebungsvariable führt einfache Tests zur Datenintegrität aus, z. B. wird geprüft, ob die erwartete Anzahl von Datenpunkten empfangen wurden und dass im Muster der empfangenen Daten keine Zwischenwerte fehlen.

National Instruments hat die Puffergrößen für die Real-Time-FIFOs und die FIFO-Puffer der Umgebungsvariablen so konfiguriert, dass sie für alle Testvariationen und Datentypen Platz für 100 Elemente haben.

Hardware-/Softwarekonfiguration für Test T2

 

PXI-Hardware
  • NI PXI-8196 (RT-Controller)
  • 2,0 GHz Pentium-Prozessor
  • DRAM-Speicher mit 256 MB
  • Broadcom 57xx (1 GB/s integrierter Ethernet-Adapter)

PXI-Software
  • LabVIEW 8.20 Real-Time Module
  • Netzwerkvariablen-Engine 1.2.0
  • Variable Client Support 1.2.0
  • Broadcom 57xx Gigabit Ethernettreiber 2.1 konfiguiert im Modus "Polling"

CompactRIO-Hardware

  • NI-cRIO-9012-Controller
  • Prozessor mit 400 MHz
  • DRAM-Speicher mit 64 MB

CompactRIO-Software

  • LabVIEW 8.20 Real-Time Module
  • Netzwerkvariablen-Engine 1.2.0
  • Variable Client Support 1.2.0  

 

Methodologie und Hinweise für Test T3

In Test T3 wird der Datendurchsatz direkt gemessen, indem die Menge der über das Netzwerk übertragenen Daten sowie die Gesamtdauer des Tests aufgezeichnet werden. Eine zeitgesteuerte Schleife mit einer Millisekunden-Taktperiode enthält einen Datenproduzenten, mit dem ein spezifisches Datenmuster an die Netzwerk-Umgebungsvariable oder die Real-Time-FIFO-VIs gesendet werden.

Im Fall der Netzwerk-Umgebungsvariablen wird eine Schleife mit normaler Priorität auf dem Host-System ausgeführt und liest die Variablen in einer regulären, frei laufenden While-Schleife aus. Beim Test mit den Real-Time-FIFO-VIs wird die Schleife mit normaler Priorität auf dem Real-Time-System ausgeführt, mit der der Zustand des FIFOs bei einer beliebigen Rate geprüft, alle verfügbaren Daten ausgelesen und mit Hilfe von TCP über das Netzwerk gesendet werden. Die Benchmark-Ergebnisse zeigen die Auswirkung, wenn diese Polling-Periode auf 1 oder 10 ms gesetzt ist.

Das Testergebnis ist nur gültig, wenn alle der folgenden Bedingungen erfüllt sind:

  • es tritt kein Pufferüberlauf auf (weder am FIFO noch im Netzwerk)
  • Daten werden nicht beschädigt: es tritt kein Datenverlust auf und der Empfänger erhält die Daten in der Reihenfolge, in der sie gesendet wurden
  • die zeitgesteuerte Schleife im VI mit der zeitkritischen Schleife kann nach einer Warmlaufperiode von 1 s Schritt halten


Nach dem Auslesen aller Datenpunkte wird mit dem Test für die Schleife mit normaler Priorität für Netzwerkvariablen, geprüft ob die Datenmuster stimmen. Beim Real-Time-FIFO-Test ist die zeitkritische Schleife verantwortlich für die Validierung in Abhängigkeit davon, ob ein Überlauf am Real-Time-FIFO aufgetreten ist.

Zum Vermeiden von Datenverlust hat National Instruments die Puffergrößen so konfiguriert, dass sie nicht kleiner sind als das Verhältnis der Schleifenperioden zwischen zeitkritischer Schleife und Schleife mit normaler Priorität. Die Mindestgröße für die Real-Time-FIFO-Puffer beträgt dabei mindestens 100 Elemente.

Hardware-/Softwarekonfiguration für Test T3

 

Hardware des Host-Rechners
  • Intel Core 2 Duo 1,8 GHz
  • DRAM-Speicher mit 2 GB
  • Intel PRO/1000 (1 GB/s Ethernet-Adapter)

Software des Host-Rechners
  • Windows Vista 64 
  • LabVIEW 8

Netzwerkkonfiguration
  • 1GB/s Netzwerk mit Schaltmodulen

PXI-Hardware
  • NI PXI-8196 (RT-Controller)
  • 2,0 GHz Pentium-Prozessor
  • DRAM-Speicher mit 256 MB
  • BROADCOM57XX 57xx (1 GB/s integrierter Ethernet-Adapter)

PXI-Software
  • LabVIEW 8.5 Real-Time Module
  • Netzwerkvariablen-Engine 1.2.0
  • Variable Client Support 1.2.0
  • BROADCOM57XX 57xx Gigabit Ethernet Treiber 2.1

 

 


Methodologie und Hinweise für Test T4

In Test T4 wurden Netzwerk-Umgebungsvariablen ohne Pufferung mit den Datentypen "Double", "Single", "Boolesch", "DBL-Array", "SGL-Array" und "boolesches Array" verwendet.

Hardware-/Softwarekonfiguration für Test T4



PXI-Hardware
  • NI PXI-8196 (RT-Controller)
  • 2,0 GHz Pentium-Prozessor
  • DRAM-Speicher mit 256 MB
  • BROADCOM57XX 57xx (1 GB/s integrierter Ethernet-Adapter)

PXI-Software
  • LabVIEW Real-Time Module 8.0
  • Netzwerkvariablen-Engine 1.0.0
  • Variable Client Support 1.0.0
  • BROADCOM57XX 57xx Gigabit Ethernettreiber 1.0.1.3.0

Methodologie und Hinweise für Tests T5 und T6

In den Tests T5 und T6 wurden Netzwerk-Umgebungsvariablen ohne Pufferung mit dem Datentyp "Double-Signalverlauf" verwendet.

Hardware-/Softwarekonfiguration für Tests T5 und T6

Hardware des Host-Rechners

  • 64 Bit Intel Core 2 Duo 1,8 GHz
  • 2 GB RAM
  • Gigabit Ethernet

Software des Host-Rechners

  • Windows Vista 64
  • LabVIEW 8.20 und LabVIEW 8.5

CompactRIO-Hardware

  • cRIO 9012
  • 64 MB RAM

CompactRIO-Software

  • LabVIEW RT 8.20 und LabVIEW RT 8.5
  • Netzwerkvariablen-Engine 1.2 (mit LabVIEW 8.20) und 1.4 (mit LabVIEW 8.5)
  • Variable Client Support 1.0 (mit LabVIEW 8.20) und 1.4 (mit LabVIEW 8.5)