Verwenden der LabVIEW-Umgebungsvariable

Zum Erstellen einer Umgebungsvariable muss ein LabVIEW-Projekt geöffnet sein. 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, um zum Dialogfeld „Eigenschaften für Umgebungsvariable“ zu gelangen. Wählen Sie aus den Konfigurationsoptionen der Umgebungsvariable aus und klicken Sie auf die OK-Schaltfläche.

Wenn Sie ein System oder einen Ordner außerhalb einer Projektbibliothek anklicken und Neu»Variable aus dem Kontextmenü auswählen, fügt LabVIEW die Umgebungsvariable in eine neue Projektbibliothek ein. Weitere Informationen zu Variablen und Bibliotheken finden Sie im Abschnitt Lebensdauer von 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. Obwohl in diesem Beispiel sowohl das LabVIEW Real-Time Module als auch das LabVIEW DSC Module installiert sind, können die vom LabVIEW DSC Module hinzugefügten Funktionen nur für Netzwerk-Umgebungsvariablen verwendet werden.

Abbildung 1: Eigenschaften für Einzelprozess-Umgebungsvariable

 

Datentyp

Sie können eine große Anzahl von Standarddatentypen für eine neue Umgebungsvariable auswählen. Zusätzlich zu diesen Standarddatentypen können Sie einen benutzerdefinierten Datentyp angeben, indem Sie aus der Pulldown-Liste Datentyp die Option Benutzerdefiniert auswählen und zu einem benutzerdefinierten Element navigieren. Manche Funktionen wie Skalierung und Echtzeit-FIFOs funktionieren jedoch nicht mit einigen benutzerdefinierten Datentypen.  Wenn Sie das LabVIEW DSC Module installiert haben, sind Alarme bei Verwendung benutzerdefinierter Datentypen auf ungültige Statusbenachrichtigungen beschränkt.

Nach dem Konfigurieren der Eigenschaften der Umgebungsvariablen und Anklicken der Schaltfläche OK wird die Umgebungsvariable im Projekt-Explorer unter der ausgewählten Bibliothek oder dem ausgewählten Zielsystem angezeigt (siehe Abbildung 2).

Abbildung 2: Umgebungsvariable im Projekt

Das Zielsystem, zu dem die Umgebungsvariable gehört, ist das Zielsystem, von dem aus die Umgebungsvariable übertragen und gehostet wird. Weitere Informationen zum Bereitstellen und Hosten von gemeinsam genutzten Variablen finden Sie im Abschnitt Bereitstellung und Hosting.

 

Variablenreferenzen

Nach dem Hinzufügen einer Umgebungsvariablen zu einem LabVIEW-Projekt können Sie diese in das Blockdiagramm eines VIs ziehen, um die Umgebungsvariable zu lesen oder zu schreiben (siehe Abbildung 3). Die Lese- und Schreibknoten im Diagramm werden Umgebungsvariablenknoten genannt.

Abbildung 3: Lesen und Schreiben von Umgebungsvariablen mit Hilfe eines Umgebungsvariablenknotens

Je nachdem, wie der Knoten eine Verbindung mit der Variablen herstellen soll, können Sie einen Umgebungsvariablenknoten als absolut oder relativ zum Zielsystem festlegen. Bei der Einstellung „Absolut“ stellt der Knoten eine Verbindung mit der Umgebungsvariablen her, deren System beim Erstellen der Variablen angegeben wurde. Ein zielbezogener Umgebungsvariablenknoten stellt eine Verbindung zu der Umgebungsvariablen auf dem Zielsystem her, auf dem Sie das VI ausführen, das den Knoten enthält.

Wenn Sie ein VI mit einem relativen Zielsystem-Umgebungsvariablenknoten auf ein neues Zielsystem verschieben, müssen Sie auch die Umgebungsvariable auf das neue Zielsystem verschieben. Verwenden Sie systemvariable Umgebungsvariablenknoten, wenn VIs und Variablen auf anderen Systemen genutzt werden sollen.

Per Voreinstellung sind alle Umgebungsvariablenknoten absolut. Klicken Sie mit der rechten Maustaste auf einen Knoten und wählen Sie Referenzmodus»Relativ zum Zielsystem oder Referenzmodus»Absolut, um die Verbindung zwischen dem Umgebungsvariablenknoten und der Umgebungsvariablen zu ändern. 

Sie können jederzeit im Projekt-Explorer mit der rechten Maustaste auf eine Umgebungsvariable klicken und die Eigenschaften der Umgebungsvariablen bearbeiten. Das LabVIEW-Projekt überträgt die neuen Einstellungen an alle Umgebungsvariablenreferenzen im Speicher. Beim Speichern der Variablenbibliothek werden diese Änderungen auch auf die Variablendefinition übernommen, die auf dem Datenträger gespeichert ist.

Mit Hilfe von Einzelprozessvariablen können Daten zwischen zwei verschiedenen Stellen im selben VI ausgetauscht werden, die nicht über Verbindungen miteinander verbunden werden können, z. B. parallele Schleifen im selben VI, oder zwischen zwei verschiedenen VIs in derselben Anwendungsinstanz. Die zugrunde liegende Implementierung der Einzelprozess-Umgebungsvariablen ähnelt der der globalen LabVIEW-Variablen. Der Hauptvorteil von Einzelprozess-Umgebungsvariablen gegenüber herkömmlichen globalen Variablen besteht darin, dass eine Einzelprozess-Umgebungsvariable in eine Netzwerk-Umgebungsvariable umgewandelt werden kann, auf die jeder Knoten in einem Netzwerk zugreifen kann.

Einzelprozess-Umgebungsvariablen und LabVIEW Real-Time

Um den Determinismus beizubehalten, erfordert eine Real-Time-Anwendung einen nicht blockierenden deterministischen Mechanismus, um Daten von deterministischen Programmabschnitten wie zeitgesteuerten Schleifen mit höherer Priorität und VIs mit zeitkritischer Priorität an nicht deterministische Programmabschnitte zu übertragen. Wenn Sie das LabVIEW Real-Time Module installieren, können Sie eine Umgebungsvariable für die Verwendung von Echtzeit-FIFOs konfigurieren, indem Sie die Echtzeit-FIFO-Funktion im Dialogfeld „Eigenschaften für Umgebungsvariable“ aktivieren. NI empfiehlt die Verwendung von Echtzeit-FIFOs für den Datenaustausch zwischen einer zeitkritischen und einer Schleife niedrigerer Priorität. Sie können die Low-Level-Echtzeit-FIFO-VIs vermeiden, indem Sie den Echtzeit-FIFO an einer Einzelprozess-Umgebungsvariablen aktivieren.

LabVIEW erstellt einen Echtzeit-FIFO, wenn das VI für die Ausführung reserviert ist (wenn das Haupt-VI in der Anwendung in den meisten Fällen mit der Ausführung beginnt), so dass die erste Ausführung des Umgebungsvariablenknotens nicht speziell berücksichtigt werden muss. 

Hinweis: In älteren LabVIEW-Versionen (Versionen vor 8.6) erstellt LabVIEW einen Echtzeit-FIFO, wenn ein Umgebungsvariablenknoten zum ersten Mal versucht, eine Umgebungsvariable zu schreiben oder aus einer Umgebungsvariablen zu lesen. Dadurch verlängert sich die Ausführungsdauer bei der ersten Verwendung jeder Umgebungsvariablen im Vergleich zu nachfolgenden Verwendungen. Wenn eine Anwendung ein extrem präzises Timing erfordert, fügen Sie entweder anfängliche Warmlaufiterationen in die zeitkritische Schleife ein, um diese Schwankungen in Zugriffszeiten zu berücksichtigen, oder lesen Sie die Variable mindestens einmal außerhalb der zeitkritischen Schleife.

Abbildung 4: FIFO-fähige Echtzeit-Umgebungsvariablen

LabVIEW erzeugt für jede Einzelprozess-Umgebungsvariable einen Echtzeit-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, mehrere Sender oder Empfänger von Einzelprozess-Umgebungsvariablen in zeitkritischen Schleifen zu vermeiden.

Abbildung 5: Mehrere Sender und Empfänger, die sich einen einzigen FIFO teilen

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 von einem leeren Puffer Daten 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. Dieses Verhalten ist nachfolgend dargestellt.

Abbildung 6: Funktionsweise des letzten Lesevorgangs und die Multielement-Echtzeit-FIFO-Umgebungsvariable

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.

Mit Hilfe der Netzwerk-Umgebungsvariablen können Sie Daten mit Umgebungsvariablen über ein Ethernet-Netzwerk austauschen. Die Netzwerk-Implementierung wird vollständig von der Netzwerkvariablen übernommen.

Neben der Bereitstellung Ihrer Daten über das Netzwerk fügt die Netzwerk-Umgebungsvariable viele Funktionen hinzu, die bei der Einzelprozess-Umgebungsvariablen nicht zur Verfügung stehen. Um diesen zusätzlichen Funktionsumfang bereitzustellen, ist die interne Implementierung der Netzwerk-Umgebungsvariablen wesentlich komplexer als die der Einzelprozess-Umgebungsvariablen. In den nächsten Abschnitten werden Aspekte dieser Implementierung erläutert und Empfehlungen zum Erzielen der bestmöglichen Leistung von Netzwerk-Umgebungsvariablen gegeben.

NI-PSP

Das NI Publish and Subscribe Protocol (NI-PSP) ist ein Netzwerkprotokoll, das für den Transport von Netzwerk-Umgebungsvariablen optimiert ist.  Das Protokoll der niedrigsten Ebene unter dem NI-PSP ist TCP/IP und wurde gründlich mit Blick auf die Leistung sowohl auf Desktop-Systemen als auch auf Real-Time-Zielsystemen von NI abgestimmt (siehe unten vergleichende Benchmarks).  

Funktionsweise von LogosXT

In Abbildung 7 ist der Software-Stack der Netzwerk-Umgebungsvariablen dargestellt.  Es ist wichtig, dies zu verstehen, da die hier verwendete Betriebstheorie spezifisch auf die Ebene des Stacks, der als LogosXT bezeichnet wird.  LogosXT ist die Stapel-Ebene, die für die Optimierung des Durchsatzes für die Umgebungsvariable verantwortlich ist.

Abbildung 7: Netzwerkstapel für Umgebungsvariablen

In Abbildung 8 sehen Sie die Hauptkomponenten des LogosXT-Übertragungsalgorithmus.  Er ist im Wesentlichen sehr einfach.  Es gibt zwei wichtige Akteure:

1. 1. einen 8-Kilobyte-Übertragungspuffer und
   2. einen Timer-Thread von 10 ms

Abbildung 8: LogosXT-Akteure.  Der Puffer wird gesendet, wenn er voll ist oder nach Ablauf von 10 ms

Diese Zahlen wurden durch gründliches Profilieren verschiedener Paketgrößen und -zeiten ermittelt, um den Datendurchsatz zu optimieren.  Der Algorithmus lautet wie folgt:

• • WENN der Sendepuffer bis zur Kapazität (8 KB) gefüllt ist, bevor der 10-ms-Timer ausgelöst wird, werden die Daten in diesem Puffer sofort an den TCP-Thread gesendet, der den Schreibvorgang initiiert hat.  Im Fall der Umgebungsvariable ist der Thread der Engine-Thread der Umgebungsvariable.
  • Wenn 10 ms vergehen, ohne dass der Puffer voll ist, werden die Daten über den Thread des Timers gesendet.

Wichtiger Hinweis: Für alle Verbindungen zwischen zwei unterschiedlichen Endpunkten ist ein Sendepuffer vorhanden.  Das heißt, alle Variablen, die Verbindungen zwischen zwei verschiedenen Computern darstellen, haben einen gemeinsamen Puffer.  Verwechseln Sie diesen Übertragungspuffer nicht mit der Eigenschaft Pufferung von Umgebungsvariablen.  Dieser Sendepuffer ist ein sehr Low-Level-Puffer, der Variablen zu einer TCP-Verbindung multiplexiert und den Netzwerkdurchsatz optimiert.

Es ist wichtig, den Funktionsumfang dieser Netzwerkschicht zu verstehen, da sie Nebeneffekte auf den Programmcode in Ihrem LabVIEW-Diagramm hat.  Der Algorithmus wartet 10 ms, da es immer effizienter ist, so viel wie möglich in einem Sendevorgang zu senden.  Jede Netzwerkoperation hat einen festen Overhead sowohl in der Zeit als auch in der Paketgröße.  Wenn wir viele kleine Pakete senden (N Pakete genannt), die insgesamt B Bytes enthalten, zahlen wir den Netzwerk-Overhead N Mal.  Wenn wir stattdessen ein großes Paket mit B Bytes senden, zahlen wir den festen Overhead nur einmal und der Gesamtdurchsatz ist wesentlich höher.

Dieser Algorithmus funktioniert besonders gut, wenn Sie Daten mit der höchstmöglichen Durchsatzrate von einem oder an ein Zielsystem streamen möchten.  Wenn Sie hingegen kleine Pakete selten senden möchten, z. B. Befehle an ein Zielsystem senden, um eine Operation wie das Öffnen eines Relais (1 Byte boolescher Daten) auszuführen, aber es so schnell wie möglich erreicht werden soll, müssen Sie die Latenz optimieren.  

Wenn es in Ihrer Anwendung wichtiger ist, die Latenz zu optimieren, benötigen Sie das VI Flush Shared Variable Data.vi.  Dieses VI erzwingt, dass die Übertragungspuffer in LogosXT durch die Engine für Umgebungsvariablen und über das Netzwerk geleert werden.  Dadurch verringert sich die Latenz erheblich.  

Hinweis: In LabVIEW 8.5 gab es keinen Haken, um LogosXT zu zwingen, seinen Puffer zu leeren, und das VI Flush Shared Variable Data.vi existiert nicht.  Stattdessen war praktisch garantiert, dass das System mindestens 10 ms mit einer Latenz verbunden ist, da das Programm auf die Füllung des Sendepuffers wartet, bevor es schließlich alle 10 ms ein Timing durchführt und die Daten sendet.  

Da jedoch, wie bereits erwähnt, alle Umgebungsvariablen, die einen Computer mit einem anderen verbinden, denselben Übertragungspuffer verwenden, durch Aufruf von Daten der Umgebungsvariablen leeren werden viele der Umgebungsvariablen auf Ihrem System beeinflusst.  Wenn Sie andere Variablen haben, die von hohem Durchsatz abhängen, beeinflussen Sie sie durch Aufruf des VIs „Daten der Umgebungsvariablen entfernen.vi“ (Abbildung 9).

 

Abbildung 9: Daten der Umgebungsvariable entfernen.vi

 

Bereitstellung und Hosting

Netzwerk-Umgebungsvariablen müssen auf einer Umgebungsvariablen-Engine (SVE) bereitgestellt werden, die die Werte der Umgebungsvariablen im Netzwerk hostet. Wenn Sie an einen Umgebungsvariablenknoten schreiben, sendet LabVIEW den neuen Wert an die SVE, die die Variable übertragen und gehostet hat. Die SVE-Verarbeitungsschleife veröffentlicht dann den Wert, so dass Empfänger den aktualisierten Wert erhalten. In Abbildung 10 wird dieser Prozess veranschaulicht. Wenn wir die Terminologie „Client/Server“ verwenden, dann ist die SVE der Server für eine Umgebungsvariable und alle Referenzen sind die Clients, unabhängig davon, ob sie mit der Variablen schreiben oder auslesen. Der SVE-Client ist Teil der Implementierung jedes Umgebungsvariablenknotens. In diesem Dokument sind die Begriffe Client und Empfänger austauschbar.

Abbildung 10: Wertänderungen der Engine für Umgebungsvariablen und der Netzwerk-Umgebungsvariable

Netzwerkvariablen und LabVIEW Real-Time

Echtzeit-FIFOs können mit einer Netzwerk-Umgebungsvariablen aktiviert werden. FIFO-fähige Netzwerk-Umgebungsvariablen haben jedoch einen wichtigen Funktionsunterschied gegenüber FIFO-fähigen Einzelprozess-Umgebungsvariablen. Denken Sie daran, dass bei der Einzelprozess-Umgebungsvariablen alle Sender und Empfänger einen einzelnen Echtzeit-FIFO gemeinsam nutzen, was bei der Netzwerk-Umgebungsvariablen nicht der Fall ist. Jeder Empfänger einer Netzwerk-Umgebungsvariablen erhält sowohl im Einzelelement- als auch im Multielement-Case seinen eigenen Echtzeit-FIFO (siehe folgende Abbildung).

Abbildung 11: Echtzeit-FIFO-fähige Netzwerkvariable

Netzwerkpufferung

Daten können nur bei Netzwerk-Umgebungsvariablen gepuffert werden. Sie können die Pufferung im Dialogfeld „Eigenschaften für Umgebungsvariable“ konfigurieren (siehe Abbildung 12).

Abbildung 12: Aktivieren der Pufferung an Netzwerk-Umgebungsvariablen

Bei aktivierter Pufferung können Sie die Puffergröße in Einheiten des Datentyps (in diesem Fall verdoppelt) angeben.

Mit der Pufferung können temporäre Schwankungen zwischen den Lese- und Schreibraten einer Variablen berücksichtigt werden. Empfänger, die eine Variable gelegentlich langsamer auslesen als der Sender auslesen, können einige Updates verpasst werden. Wenn die Anwendung gelegentlich fehlende Datenpunkte tolerieren kann, hat die langsamere Lesegeschwindigkeit keinen Einfluss auf die Anwendung und Sie müssen die Pufferung nicht aktivieren. Wenn der Empfänger jedoch jedes Update empfangen muss, aktivieren Sie die Pufferung. Sie können die Puffergröße auf der Seite Variable des Dialogfelds „Eigenschaften für Umgebungsvariable“ festlegen, so dass Sie bestimmen können, wie viele Updates die Anwendung beibehalten soll, bevor sie alte Daten überschreibt.

Wenn Sie im Dialogfeld oben einen Netzwerkpuffer konfigurieren, konfigurieren Sie die Größe zweier unterschiedlicher Puffer.  Der serverseitige Puffer, der in Abbildung 13 unten als Puffer im Feld mit der Bezeichnung Engine für Umgebungsvariablen (SVE) dargestellt ist, wird automatisch erstellt und so konfiguriert, dass er die gleiche Größe wie der clientseitige Puffer hat. Mehr zu diesem Puffer gleich.  Der clientseitige Puffer ist eher derjenige, an den Sie logischerweise denken, wenn Sie Ihre Umgebungsvariable so konfigurieren, dass die Pufferung aktiviert ist.  Der clientseitige Puffer (auf der rechten Seite von Abbildung 13 dargestellt) ist der Puffer, der für das Aufrechterhalten der Queue vorheriger Werte verantwortlich ist.  Dieser Puffer isoliert Ihre Umgebungsvariablen vor Schwankungen in der Schleifengeschwindigkeit oder im Netzwerkverkehr.

Im Gegensatz zur FIFO-fähigen Einzelprozessvariablen, bei denen alle Sender und Empfänger denselben Echtzeit-FIFO verwenden, erhält jeder Empfänger einer Netzwerk-Umgebungsvariablen seinen eigenen Puffer, so dass die Empfänger nicht miteinander interagieren.

Abbildung 13: Pufferung

Die Pufferung ist nur hilfreich, wenn die Lese-/Schreibrate vorübergehende Schwankungen aufweisen. Wenn die Anwendung für einen unbestimmten Zeitraum ausgeführt wird, gehen Empfängern, die immer langsamer als ein Sender lesen, letztendlich Daten verloren, unabhängig von der Größe des angegebenen Puffers. Da die Pufferung jedem Empfänger einen Puffer zuweist, sollten Sie zur Vermeidung unnötiger Speicherverbrauch nur bei Bedarf verwenden.

Pufferung über Netzwerk und Echtzeit

Wenn Sie sowohl die Netzwerkpufferung als auch den Echtzeit-FIFO aktivieren, enthält die Implementierung der Umgebungsvariablen sowohl einen Netzwerkpuffer als auch einen Echtzeit-FIFO. Beachten Sie, dass bei aktiviertem Echtzeit-FIFO für jeden Sender und Empfänger ein neuer Echtzeit-FIFO erstellt wird. Das bedeutet, dass mehrere Sender und Empfänger sich nicht gegenseitig blockieren.

Abbildung 14: Netzwerkpufferung und Echtzeit-FIFOs

Obwohl Sie die Größe dieser beiden Puffer unabhängig festlegen können, empfiehlt NI in den meisten Fällen, die gleiche Größe zu behalten. Wenn Sie den Echtzeit-FIFO aktivieren, erstellt LabVIEW für jeden Sender und Empfänger einen neuen Echtzeit-FIFO. Daher blockieren sich mehrere Sender und Empfänger nicht gegenseitig.

Lebensdauer des Puffers

Abhängig vom Speicherort der Puffer erstellt LabVIEW beim ersten Schreib- oder Lesevorgang Netzwerk- und Echtzeit-FIFO-Puffer.

• Serverseitige Puffer werden erstellt, wenn ein Sender zum ersten Mal in eine Umgebungsvariable schreibt.
• Puffer auf dem Client werden beim Einrichten eines Abonnements erstellt. 

Diese tritt auf, wenn das VI mit dem Umgebungsvariablenknoten gestartet wird.  Wenn ein Sender Daten an eine Umgebungsvariable überträgt, bevor ein Empfänger diese Variable abonniert hat, stehen die anfänglichen Datenwerte dem Empfänger nicht zur Verfügung.

Hinweis: Vor LabVIEW 8.6 wurden Puffer erstellt, wenn ein Knoten zum Lesen oder Schreiben einer Umgebungsvariablen zum ersten Mal ausgeführt wurde.  

Abbildung 15: Lebensdauer des Puffers

Pufferüberlauf/-unterlauf

Die Netzwerk-Umgebungsvariable meldet Über- und Unterlaufzustände des Netzwerkpuffers. Der Echtzeit-FIFO in allen Versionen zeigt durch Ausgabe von Fehlern einen FIFO-Überlauf oder -Unterlauf an.

Hinweis: In älteren LabVIEW-Versionen werden keine Über-/Unterlaufzustände im Netzwerkpuffer gemeldet. Eine Anwendung in LabVIEW 8.0 oder 8.0.1 kann auf zwei Arten nach Netzwerkpuffer-Unterläufen überprüft werden. Da die Zeitstempelauflösung der Umgebungsvariablen 1 ms beträgt, können Sie den Zeitstempel einer Umgebungsvariablen mit dem nachfolgenden Lesezeitstempel vergleichen, um Pufferunterläufe zu erkennen, wenn Sie die Variable mit einer Rate von weniger als 1 kHz aktualisieren. Oder der Empfänger kann eine mit den Daten gebündelte Sequenznummer verwenden, um Pufferüberläufe/-unterläufe zu beobachten. Sie können den zweiten Ansatz nicht mit Umgebungsvariablen verwenden, die in einer zeitkritischen Schleife verwendet werden, wenn der Datentyp ein Array ist, da die Echtzeit-FIFO-fähigen Umgebungsvariablen den Datentyp „Benutzerdef. Element (Cluster)“ nicht unterstützen, wenn eines der Cluster-Elemente ein Array ist.

Lebensdauer der Umgebungsvariablen

Wie bereits erwähnt, gehören alle Umgebungsvariablen zu einer Projektbibliothek. Die SVE registriert Projektbibliotheken und die in diesen Bibliotheken enthaltenen Umgebungsvariablen, wenn LabVIEW eine dieser Variablen benötigt. Per Voreinstellung wird eine Bibliothek von Umgebungsvariablen übertragen und veröffentlicht, sobald ein VI ausgeführt wird, das auf eine der enthaltenen Variablen verweist. Da die Umgebungsvariable die gesamte Bibliothek überträgt, zu der eine Umgebungsvariable gehört, veröffentlicht sie alle Umgebungsvariablen in der Bibliothek, unabhängig davon, ob sie von einem laufenden VI auf sie verweist oder nicht. Sie können jede Projektbibliothek jederzeit manuell bereitstellen, indem Sie die Bibliothek im Projekt-Explorer mit der rechten Maustaste anklicken.

Durch das Stoppen des VIs oder einen Neustart des Computers, auf dem die Umgebungsvariable gehostet wird, wird die Variable für das Netzwerk nicht länger verfügbar. Wenn Sie die Umgebungsvariable aus dem Netzwerk entfernen möchten, müssen Sie die Bibliothek, zu der die Variable gehört, im Fenster Projekt-Explorer ausdrücklich aufheben. Sie können auchWerkzeuge»DSM auswählen, um Umgebungsvariablen oder komplette Projektbibliotheken von Variablen aufzuheben.

Hinweis: In älteren LabVIEW-Versionen wird die Übertragung von Umgebungsvariablen mit dem Variablenmanager (Werkzeuge»Umgebungsvariable»Variablenmanager) anstelle des Distributed System Manager gesteuert. 

Frontpanel-Datenbindung

Eine weitere Funktion, die nur für Netzwerk-Umgebungsvariablen zur Verfügung steht, ist die Frontpanel-Datenbindung. Ziehen Sie eine Umgebungsvariable vom Projekt-Explorer auf das Frontpanel eines VIs, um ein Element zu erstellen, das mit der Umgebungsvariablen verknüpft ist. Wenn Sie die Datenbindung für ein Steuerelement aktivieren, ändert das Ändern des Werts des Steuerelements den Wert der Umgebungsvariable, an die das Steuerelement gebunden ist. Wenn die Verbindung mit der SVE erfolgreich ist, wenn das VI ausgeführt wird, wird neben dem Frontpanel-Element ein kleines grünes Anzeigeelement angezeigt, wie in Abbildung 16 dargestellt.

Abbildung 16: Verknüpfen eines Frontpanel-Elements mit einer Umgebungsvariable

Auf der Seite „Datenbindung“ des Dialogfelds „Eigenschaften“ können Sie auf die Bindung für jedes Bedien- oder Anzeigeelement zugreifen und diese ändern. Wenn Sie mit dem LabVIEW Real-Time Module oder dem LabVIEW DSC Module arbeiten, können Sie Werkzeuge»Umgebungsvariable»Frontpanelbindung – Massenkonfiguration auswählen, um zum Dialogfeld Frontpanelbindung – Massenkonfiguration zu gelangen und eine Bedienoberfläche zu erstellen, mit der viele Bedien- und Anzeigeelemente mit Umgebungsvariablen verknüpft werden.

NI empfiehlt die Verwendung der Frontpanel-Datenbindung für Anwendungen, die auf LabVIEW Real-Time ausgeführt werden, nicht, da das Frontpanel möglicherweise nicht vorhanden ist.

Programmatischer Zugriff

Wie oben beschrieben, können Sie Umgebungsvariablen mit Hilfe des LabVIEW-Projekts interaktiv erstellen, konfigurieren und verteilen und mit Hilfe des Umgebungsvariablenknotens im Blockdiagramm oder über die Datenbindung auf dem Frontpanel lesen und schreiben. In LabVIEW 2009 und neueren LabVIEW-Versionen haben Sie außerdem programmatischen Zugriff auf diese Funktionen.

Mit dem VI-Server können Sie Projektbibliotheken und Umgebungsvariablen programmatisch in Anwendungen erstellen, in denen eine große Anzahl von Umgebungsvariablen erstellt werden muss. Darüber hinaus bietet das LabVIEW DSC Module einen umfassenden Satz von VIs zum programmatischen Erstellen und Bearbeiten von Umgebungsvariablen und Projektbibliotheken sowie zur Verwaltung der SVE. Bibliotheken von Umgebungsvariablen können programmatisch nur auf Windows-Systemen erstellt werden. Die neuen Bibliotheken können jedoch programmatisch auf Windows- oder LabVIEW-Real-Time-Systemen übertragen werden.

Verwenden Sie die programmatische Umgebungsvariablen-API in Anwendungen, in denen Sie die Umgebungsvariable, die von einem VI gelesen und geschrieben werden soll, dynamisch ändern oder eine große Anzahl von Variablen lesen und schreiben müssen. Sie können eine Umgebungsvariable dynamisch ändern, indem Sie die URL programmatisch erstellen. 

Abbildung 17: Verwenden der programmatischen Umgebungsvariablen-API zum Lesen und Schreiben von Umgebungsvariablen

Darüber hinaus können Sie mit der in NI LabWindows/CVI 8.1 und NI Measurement Studio 8.1 eingeführten Network Variable Library in ANSI C, Visual Basic .NET oder Visual C# lesen und schreiben.

Die SVE ist ein Software-Framework, mit dem eine Netzwerk-Umgebungsvariable Werte über das Netzwerk senden kann. Unter Windows konfiguriert LabVIEW die SVE als Dienst und startet sie beim Systemstart. Auf einem Echtzeit-Zielsystem ist die SVE eine installierbare Startkomponente, die beim Systemstart geladen wird.

Um Netzwerk-Umgebungsvariablen verwenden zu können, muss eine SVE auf mindestens einem Knoten im verteilten System ausgeführt werden. Jeder Knoten im Netzwerk kann Umgebungsvariablen lesen oder schreiben, die von der SVE veröffentlicht werden. Wie in Tabelle 1 gezeigt, können Knoten auf eine Variable verweisen, ohne dass die SVE installiert ist. Wenn Sie Umgebungsvariablen je nach Anwendungsanforderungen an unterschiedlichen Stellen bereitstellen möchten, können Sie auch mehrere SVEs gleichzeitig auf mehreren Systemen installieren.

Empfehlungen für den Host-Speicherort von Umgebungsvariablen

Bei der Entscheidung, von welchem Rechengerät Netzwerk-Umgebungsvariablen in einem verteilten System übertragen und hosten sollen, müssen Sie eine Reihe von Faktoren berücksichtigen.

Ist das Rechengerät mit der SVE kompatibel?

In der folgenden Tabelle werden die Plattformen zusammengefasst, für die die SVE verfügbar ist, und die Plattformen aufgelistet, die über Referenzknoten oder die DataSocket-API Netzwerk-Umgebungsvariablen verwenden können. NI benötigt 32 MB RAM und empfiehlt 64 MB für die SVE auf allen zutreffenden Plattformen.

Beachten Sie, dass das Hosten von Umgebungsvariablen unter Linux oder Macintosh noch nicht unterstützt wird.

Erfordert die Anwendung Datenaufzeichnungs- und Überwachungsfunktionen?

Wenn Sie die Funktionen des LabVIEW DSC Modules verwenden möchten, müssen Sie die Umgebungsvariablen unter Windows hosten. Mit dem LabVIEW DSC Module werden Netzwerk-Umgebungsvariablen folgende Funktionen hinzugefügt:
· Historische Protokollierung in der Citadel-Datenbank von NI.
· Netzwerk-Alarme und Alarmprotokollierung
· Skalierung
· Benutzerbasierte Sicherheit
· Anfangswert
· Fähigkeit, benutzerdefinierte I/O-Server zu erstellen.
· Integration der LabVIEW-Ereignisstruktur in die Umgebungsvariable
· LabVIEW-VIs zur programmatischen Steuerung aller Aspekte von Umgebungsvariablen und der Engine für Umgebungsvariablen. Diese VIs sind besonders nützlich für die Verwaltung einer großen Anzahl von Umgebungsvariablen.

Verfügt das Rechengerät über ausreichende Prozessor- und Speicherressourcen?

Die SVE ist ein zusätzlicher Prozess, der sowohl Verarbeitungs- als auch Speicherressourcen erfordert. Um die beste Leistung in einem verteilten System zu erzielen, installieren Sie die SVE auf Computern mit den meisten Speicher- und Verarbeitungsfunktionen.

 

Welches System ist immer online?

Wenn Sie eine verteilte Anwendung erstellen, in der einige der Systeme regelmäßig offline werden können, hosten Sie die SVE auf einem System, das immer online ist.

Weitere Funktionen der Engine für Umgebungsvariablen

In Abbildung 18 sind die vielen Aufgaben der SVE veranschaulicht. Zusätzlich zur Verwaltung von Netzwerk-Umgebungsvariablen übernimmt die SVE folgende Aufgaben:
· Erfassen von Daten, die von I/O-Servern empfangen werden.
· Bereitstellen von Daten über die OPC- und PSP-Server an Abonnenten
· Bereitstellen von Skalierungs-, Alarm- und Protokollierungsdiensten für alle Umgebungsvariablen mit diesen konfigurierten Diensten Diese Dienste stehen nur im LabVIEW DSC Module zur Verfügung.
· Überwachen von Alarmbedingungen und Reaktion auf Alarme

I/O Server

I/O-Server sind Plugins zur Umgebungsvariablen, mit denen Programme die Umgebungsvariable zum Veröffentlichen von Daten verwenden können. NI FieldPoint enthält einen I/O-Server, der Daten direkt von FieldPoint-Banken an die SVE sendet. Da die SVE ein OPC-Server ist, dient die Kombination aus SVE und dem FieldPoint-I/O-Server als FP-OPC-Server. Das FieldPoint-Installationsprogramm enthält keine SVE. Sie müsste von einer anderen Softwarekomponente wie LabVIEW installiert werden.

NI-DAQmx enthält außerdem einen I/O-Server, der globale virtuelle NI-DAQmx-Kanäle automatisch an die SVE senden kann. Dieser I/O-Server ersetzt den traditionellen DAQ-OPC-Server und den RDA. NI-DAQmx enthält die SVE und kann installiert werden, wenn LabVIEW nicht installiert ist.

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

Abbildung 18: Engine für Umgebungsvariablen (SVE)

OPC

Die SVE ist 3.0-kompatibel und kann auf Windows-Computern als OPC-Server fungieren. Jeder OPC-Client kann mit einer Umgebungsvariablen auf einem Windows-Rechner schreiben oder auslesen. Wenn Sie das LabVIEW DSC Module auf einem Windows-Computer installieren, kann die SVE auch als OPC-Client fungieren. Umgebungsvariablen, die auf einem Windows-Computer gehostet werden, können mittels DSC und durch Schreiben oder Auslesen an OPC-Datenobjekte gebunden werden.

Da OPC eine auf COM basierende Technologie ist, bei der es sich um eine Windows-API handelt, funktionieren Real-Time-Zielsysteme nicht direkt mit OPC. Wie in Abbildung 19 gezeigt, können Sie immer noch auf OPC-Datenobjekte von einem Real-Time-Zielsystem aus zugreifen, indem Sie die Umgebungsvariablen auf einem Windows-Computer hosten.

Abbildung 19: Bindung mit OPC-Datenobjekt

In diesem Abschnitt finden Sie allgemeine Hinweise zum Erstellen leistungsstarker Anwendungen mit Umgebungsvariablen.

Da die Einzelprozess-Umgebungsvariable eine Implementierung aufweist, die ähnlich wie die globalen Variablen und Echtzeit-FIFOs in LabVIEW hat, gibt NI keine speziellen Empfehlungen zum Erzielen einer guten Leistung für Einzelprozess-Umgebungsvariablen. In den folgenden Abschnitten wird die Netzwerk-Umgebungsvariable behandelt.

Gemeinsame Nutzung des Prozesses

Die Netzwerk-Umgebungsvariable vereinfacht LabVIEW-Blockdiagramme, indem viele der Implementierungsdetails der Netzwerkprogrammierung ausgeblendet werden. Anwendungen bestehen aus LabVIEW-VIs sowie dem SVE- und dem SVE-Client-Code. Um die bestmögliche Leistung der Umgebungsvariablen zu erzielen, entwickeln Sie die Anwendung so, dass sie regelmäßig den Prozessor aufgibt, damit die SVE-Threads ausgeführt werden können. Dazu können Sie Warteschleifen in die Verarbeitungsschleifen einfügen und sicherstellen, dass die Anwendung keine ungesteuerten Schleifen verwendet. Die genaue Wartezeit hängt von der Anwendung, dem Prozessor und dem Netzwerk ab. Jede Anwendung erfordert ein gewisses Maß an empirischer Optimierung, um die beste Leistung zu erzielen.

Überlegen des Speicherorts der SVE

Im Abschnitt Empfehlungen für das Hosting von Umgebungsvariablen wurde eine Reihe von Faktoren beschrieben, die Sie bei der Entscheidung, wo die SVE installiert werden soll. In Abbildung 20 sehen Sie einen weiteren Faktor, der die Leistung der Umgebungsvariablen erheblich beeinflussen kann. Dieses Beispiel bezieht sich auf ein Real-Time-Zielsystem, aber die Grundprinzipien gelten auch für Nicht-Real-Time-Systeme. Abbildung 20 zeigt eine ineffiziente Verwendung von Netzwerk-Umgebungsvariablen: Sie erzeugen Daten auf einem Real-Time-Zielsystem und müssen die lokal verarbeiteten Daten protokollieren und von einem Netzwerkcomputer überwachen. Da Variablenempfänger Daten von der SVE empfangen müssen, ist die Latenz zwischen dem Schreiben in der Schleife mit hoher Priorität und dem Lesen in der Schleife mit normaler Priorität groß und erfordert zwei Durchläufe über das Netzwerk.

Abbildung 20: Ineffiziente Verwendung von Netzwerkvariablen in Echtzeit

In Abbildung 21 sehen Sie eine bessere Architektur für diese Anwendung. Die Anwendung verwendet eine Einzelprozess-Umgebungsvariable, um Daten zwischen der Schleife mit hoher und niedriger Priorität zu übertragen, wodurch die Latenz erheblich reduziert wird. Die Schleife mit niedriger Priorität protokolliert die Daten und überträgt das Update an eine Netzwerk-Umgebungsvariable für den Empfänger auf dem Host.

Abbildung 21: Effiziente Verwendung von Netzwerkvariablen in Echtzeit

In diesem Abschnitt wird die Leistung der Umgebungsvariablen mit anderen LabVIEW-Methoden verglichen, z. B. der globalen LabVIEW-Variablen, Echtzeit-FIFOs und TCP/IP. In der folgenden Tabelle werden die besprochenen Tests in den folgenden Abschnitten zusammengefasst.

Test	Beschreibung	SVE-Standort	Notizen
T1	Einzelprozess-Umgebungsvariable und globale Variable	k. A.	Festlegen der maximalen Lese-/Schreibraten
T2	Einzelprozess-Umgebungsvariable mit Echtzeit-FIFO und Echtzeit-FIFO-VIs	k. A.	Festlegen der maximalen Lese-/Schreibraten bei Verwendung von Echtzeit-FIFOs Bestimmen Sie die höchste nachhaltige Rate, mit der Sie in eine Umgebungsvariable oder einen Echtzeit-FIFO in einer zeitgesteuerten Schleife schreiben und die Daten gleichzeitig von einer Schleife mit normaler Priorität auslesen können.
T3	Netzwerk-Umgebungsvariable mit Echtzeit-FIFO gegenüber Echtzeit-FIFO mit 2 Schleifen mit TCP	PXI mit LV RT	Legt die maximale Rate fest, die Einzelwertdaten über das Netzwerk gestreamt werden können. Umgebungsvariable: Empfangs-VI befindet sich immer auf dem Host. RT-FIFO + TCP: Ähnlich wie T2 mit TCP-Kommunikation/IP-Netzwerk
T4	Footprint der Netzwerk-Umgebungsvariable	RT-Serien-Zielsystem	Festlegen der Speicherauslastung von Umgebungsvariablen nach der Bereitstellung
T5	Vergleich zwischen 8.2-Netzwerkvariablen und 8.5-Variablen – Streaming	RT-Serien-Zielsystem	Vergleich der neuen 8.5-Implementierung von NI-PSP mit der 8.20 und älteren Implementierung. Mit diesem Benchmark wird der Durchsatz einer Anwendung gemessen, die Signalverlaufsdaten von einem cRIO-Gerät an einen Desktop-Host streamen.
T6	Vergleich zwischen 8.2-Netzwerkvariablen und 8.5-Variablen – hohe Kanalanzahl	RT-Serien-Zielsystem	Vergleich der neuen 8.5-Implementierung von NI-PSP mit der 8.20 und älteren Implementierung. Mit diesem Benchmark wird der Durchsatz einer Anwendung mit hoher Kanalanzahl auf einem cRIO-Gerät gemessen.

Tabelle 2: Benchmark-Überblick

In den folgenden Abschnitten wird der von NI für jedes der Benchmarks erstellte Programmcode beschrieben, gefolgt von den tatsächlichen Benchmark-Ergebnissen. Im Abschnitt Methodologie und Konfiguration wird die für jedes Benchmark gewählte Methodik und die detaillierte Konfiguration für die Hardware und Software, auf der das Benchmark ausgeführt wurde, näher erläutert.

Einzelprozess-Umgebungsvariablen im Vergleich zu Globale Variablen in LabVIEW

Die Einzelprozess-Umgebungsvariable ähnelt der globalen LabVIEW-Variablen. Die Implementierung der Einzelprozess-Umgebungsvariablen ist eine globale LabVIEW-Umgebungsvariable mit zusätzlichen Zeitstempelfunktionen.

Um die Ausführungsgeschwindigkeit der Einzelprozess-Umgebungsvariablen mit der globalen LabVIEW-Variablen zu vergleichen, hat NI Benchmark-VIs erstellt, mit denen gemessen wird, wie oft das VI eine globale oder Einzelprozess-Umgebungsvariable pro Sekunde lesen und schreiben kann. In Abbildung 22 sehen Sie den Benchmark zum Lesen von Einzelprozess-Umgebungsvariablen. Die Einzelprozess-Umgebungsvariablen-Benchmarks und die globalen Lese-/Schreib-Benchmarks von LabVIEW folgen dem gleichen Muster.

Abbildung 22: Benchmarking-VI „Lesen von Einzelprozess-Umgebungsvariablen“

Der Kombinationstest für Lese-/Schreibvorgänge enthält außerdem Programmcode, mit dem geprüft wird, dass jeder geschriebene Punkt auch in derselben Iteration der Schleife ohne Datenbeschädigung gelesen werden kann.

T1-Testergebnisse

In Abbildung 23 sehen Sie die Ergebnisse von Test T1. Die Ergebnisse zeigen, dass die Leseleistung für eine Einzelprozess-Umgebungsvariable niedriger ist als die für eine globale LabVIEW-Variable. Die Schreibgeschwindigkeit und somit die Lese-/Schreibgeschwindigkeit der Einzelprozess-Umgebungsvariablen ist etwas niedriger als die der globalen LabVIEW-Variablen. Die Ausführungsgeschwindigkeit von Einzelprozess-Umgebungsvariablen wird durch das Aktivieren und Deaktivieren der Zeitstempel-Funktion beeinträchtigt. Daher wird empfohlen, den Zeitstempel zu deaktivieren, wenn er nicht nützlich ist.

Im Abschnitt Methodologie und Konfiguration werden die spezifischen Benchmarking-Methoden und Konfigurationsdetails für diese Testreihe erläutert.

 

Abbildung 23: Leistung der Einzelprozess-Umgebungsvariable im Vergleich zur Leistung der globalen Variable

Einzelprozess-Umgebungsvariablen im Vergleich zu Echtzeit-FIFOs

NI hat einen nachhaltigen Durchsatz verglichen, um die Leistung der FIFO-fähigen Einzelprozess-Umgebungsvariablen mit herkömmlichen Echtzeit-FIFO-VIs zu vergleichen. Mit dem Benchmark wird außerdem die Auswirkung der Größe der übertragenen Daten oder der Nutzdaten für jede der beiden Echtzeit-FIFO-Implementierungen untersucht.

Die Tests bestehen aus einer zeitkritischen Schleife (TCL), die Daten erzeugt, und einer Schleife mit normaler Priorität (NPL), die die Daten verarbeitet. NI hat die Auswirkung der Nutzdatengröße durch Skalar- und Array-Datentypen mit doppelter Genauigkeit ermittelt. Der skalare Typ bestimmt den Durchsatz, wenn die Nutzlast ein Double ist, und die Array-Typen bestimmen den Durchsatz für die restlichen Nutzlasten. Mit dem Test wird der maximale dauerhafte Durchsatz ermittelt, indem die maximale dauerhafte Geschwindigkeit bestimmt wird, mit der beide Schleifen ohne Datenverlust ausgeführt werden können.

In Abbildung 24 sehen Sie ein vereinfachtes Diagramm des Echtzeit-FIFO-Benchmark, in dem ein Großteil des zum Erstellen und Entfernen der FIFOs benötigten Programmcodes fehlt. Beachten Sie, dass ab LabVIEW 8.20 eine neue FIFO-Funktion eingeführt wurde, um die hier gezeigten FIFO-SubVIs zu ersetzen. Die FIFO-Funktionen wurden für die in diesem Artikel dargestellten Daten verwendet und bieten eine bessere Leistung als die Vorgängerversionen des 8.0.x-SubVIs.

Abbildung 24: Vereinfachtes Echtzeit-FIFO-Benchmarking-VI

Eine äquivalente Version des Tests verwendet die Einzelprozess-Umgebungsvariable. In Abbildung 25 sehen Sie eine vereinfachte Darstellung dieses Diagramms.

Abbildung 25: Vereinfachtes FIFO-fähiges Einzelprozess-Umgebungsvariablen-Benchmarking-VI

T2-Testergebnisse

In den Abbildungen 26 und 27 sehen Sie die Ergebnisse des T2-Tests, bei denen die Leistung der FIFO-fähigen Einzelprozess-Umgebungsvariablen mit Echtzeit-FIFO-Funktionen verglichen wird. Die Ergebnisse zeigen, dass die Verwendung der Einzelprozess-Umgebungsvariablen etwas langsamer ist als die Verwendung von Echtzeit-FIFOs.

Abbildung 26: Leistung der Einzelprozess-Umgebungsvariable im Vergleich zur Leistung von Echtzeit-FIFO-VIs (PXI)

Abbildung 27: Leistung der Einzelprozess-Umgebungsvariable im Vergleich zur Leistung von Echtzeit-FIFO-VIs (cRIO 9012)

Netzwerk-Umgebungsvariablen im Vergleich zu Echtzeit-FIFOs und TCP/IP

Mit der Flexibilität der Umgebungsvariablen können Sie eine Einzelprozess-Umgebungsvariable mit nur wenigen Konfigurationsänderungen schnell über das Netzwerk veröffentlichen. Insbesondere bei Echtzeitanwendungen erfordert die Durchführung der gleichen Transformation in älteren LabVIEW-Versionen eine große Menge an Programmcode, um die Echtzeit-FIFOs auf dem Controller der RT-Serie zu lesen und die Daten anschließend mit Hilfe eines der vielen verfügbaren Netzwerkprotokolle über das Netzwerk zu senden. Um die Leistung dieser beiden verschiedenen Ansätze zu vergleichen, hat NI noch einmal Benchmark-VIs erstellt, um den nachhaltigen Durchsatz jeder einzelnen Ansätze ohne Datenverlust über einen Bereich von Nutzdaten zu messen.

Für den vorvariablen Ansatz verwendet das Benchmark-VI Echtzeit-FIFOs und TCP/IP. Ein TCL erzeugt Daten und fügt sie in einen Echtzeit-FIFO ein; ein NPL liest die Daten aus dem FIFO aus und sendet sie über TCP/IP über das Netzwerk. Ein Host-PC empfängt die Daten und prüft, ob kein Datenverlust auftritt.

In Abbildung 28 sehen Sie ein vereinfachtes Diagramm des Echtzeit-FIFOs und des TCP/IP-Benchmarks. Auch dieses Diagramm vereinfacht das eigentliche Benchmark-VI erheblich.

Abbildung 28: Vereinfachtes Echtzeit-FIFO und TCP/IP-Benchmarking-VI

NI hat mit Hilfe der Netzwerk-Umgebungsvariablen eine äquivalente Version des Tests erstellt. Abbildung 29 zeigt ein vereinfachtes Diagramm.

Abbildung 29: Vereinfachtes Echtzeit-FIFO-fähiges Netzwerk-Umgebungsvariablen-Benchmarking-VI

T3-Testergebnisse

Dieser Abschnitt enthält die Ergebnisse des T3-Tests und vergleicht die Leistung der Echtzeit-FIFO-fähigen Netzwerk-Umgebungsvariablen mit der Leistung von äquivalenten Programmcode, der auf Echtzeit-FIFO-VIs und LabVIEW-TCP/IP-Funktionen basiert. In Abbildung 30 sehen Sie die Ergebnisse, wenn das LabVIEW-Real-Time-Zielsystem ein Embedded-PXI-Controller der RT-Serie ist.

Abbildung 30: Leistung der Netzwerk-Umgebungsvariable im Vergleich zu Echtzeit-FIFOs und TCP-VIs (PXI)

 Die T3-Ergebnisse zeigen, dass der Durchsatz von Netzwerk-Umgebungsvariablen dem von TCP entspricht und dass beide bei mittleren bis großen Nutzdaten konsistent sind.  Die Umgebungsvariable erleichtert Ihre Programmierarbeit, aber das ist nicht ohne Kosten.  Beachten Sie jedoch, dass bei Verwendung einer nativen TCP-Implementierung leicht Umgebungsvariablen unterschieden werden können, insbesondere bei der neuen 8.5-Implementierung von NI-PSP.

 

T4-Testergebnisse

Arbeitsspeicher-Footprint der Netzwerk-Umgebungsvariable

Beachten Sie, dass in LabVIEW 8.5 keine wesentlichen Änderungen am variablen Footprint vorgenommen wurden.  Daher wurde der Benchmark nicht erneut ausgeführt.

Das Bestimmen des Arbeitsspeicher-Footprints der Umgebungsvariablen ist schwierig, da der von der Variablen genutzte Speicher von der Konfiguration abhängt. Bei Netzwerk-Umgebungsvariablen mit Pufferung wird der Speicher dynamisch nach Bedarf des Programms zugewiesen. Durch die Konfiguration einer Umgebungsvariablen für die Verwendung von Echtzeit-FIFOs erhöht sich auch die Speicherauslastung, da LabVIEW zusätzlich zu Netzwerkpuffern Puffer für den FIFO erstellt. Daher stellen die Benchmarking-Ergebnisse in diesem Artikel nur eine Basismessung des Speichers bereit.

In Abbildung 31 sehen Sie den Arbeitsspeicher, den die Umgebungsvariable beansprucht, nachdem LabVIEW 500 und 1000 Umgebungsvariablen der angegebenen Typen übertragen hat. Der Graph zeigt, dass der Variablentyp die Speicherauslastung der verteilten Umgebungsvariablen nicht signifikant beeinflusst. Beachten Sie, dass es sich um ungepufferte Variablen handelt.

Abbildung 31: Speicherauslastung von Netzwerk-Umgebungsvariablen mit unterschiedlichen Datentypen

In Abbildung 32 ist die Speicherauslastung als Funktion der Anzahl der verteilten Umgebungsvariablen dargestellt. Dieser Test verwendet nur einen Variablentyp, ein leeres boolesches Array. Die Speicherauslastung steigt mit der Variablenanzahl linear an.

Abbildung 32: Speicherauslastung von Umgebungsvariablen unterschiedlicher Größe

 

T5-Testergebnisse

Vergleich zwischen 8.2-Netzwerkvariablen und 8.5-Variablen – Streaming

In LabVIEW 8.5 haben wir die untere Lage des Netzwerkprotokolls zur Übertragung von Daten der Umgebungsvariablen neu implementiert.  Das bietet erheblich bessere Leistung.

In diesem Fall haben wir eine einzelne Variable des Typs „Signalverlauf von Werten mit doppelter Genauigkeit“ auf einem cRIO 9012 gehostet.  Wir haben alle Daten erzeugt und dann in einer engen Schleife an den Host übertragen, der sie so schnell wie möglich aus einem anderen Signalverlauf-Umgebungsvariablenknoten ausliest.

In Abbildung 30 sehen Sie, dass sich die Leistung in LabVIEW 8.5 in diesem Anwendungsfall um mehr als 600 % verbessert hat.

 

Abbildung 33: Vergleich des Signalverlaufsdurchsatzes zwischen LabVIEW 8.5 und LabVIEW 8.20 (und älter)

T6-Testergebnisse

Vergleich zwischen 8.2-Netzwerkvariablen und 8.5-Variablen – Streaming

In diesem Test haben wir dieselben zwei Zielsysteme wie im Test T5 verwendet, aber anstatt eine einzelne Variable zu übertragen, haben wir den Datentyp in einen Doppelpunkt geändert und die Anzahl der Umgebungsvariablen von 1 bis 1000 geändert, wodurch der Durchsatz während der Zeit gemessen wird.  Auch hier wurden alle Variablen auf dem cRIO 9012 gehostet. Inkrementelle Daten wurden dort generiert und an den Host gesendet, wo sie gelesen wurden.

Abbildung 34 zeigt erneut eine erhebliche Leistungssteigerung zwischen LabVIEW 8.20 und LabVIEW 8.5.  Bei vielen kleineren Variablen ist der Durchsatz jedoch wesentlich geringer als bei einer einzelnen großen Variablen wie bei T5.  Der Grund dafür ist, dass jeder Variable eine feste Menge an Overhead zugeordnet ist.  Wenn viele Variablen verwendet werden, wird dieser Overhead mit der Anzahl der Variablen multipliziert und wird ziemlich bemerkbar.

Abbildung 34: Vergleich des Durchsatzes bei hoher Kanalanzahl zwischen LabVIEW 8.5 und LabVIEW 8.20 (und älter)

Methodik und Konfiguration

Dieser Abschnitt enthält detaillierte Informationen zum Benchmarking-Prozess für alle oben genannten Testsets.

Methoden und Hinweise zum T1-Test

Der Test T1 verwendet eine einfache Benchmarking-Vorlage, um die Lese- und Schreibraten durch einfache Mittelwertbildung über eine große Anzahl von Iterationen zu bestimmen. Bei jedem Test wurden insgesamt 500 Millionen Iterationen für eine Gesamtausführungsdauer von einer Minute und mit einer Millisekundenauflösung ausgeführt.

T1-Hardware-/Softwarekonfiguration

Host-Hardware

• Dell Precision 450
• Dual Intel Xeon 2,4 GHz Prozessoren der Pentium-Klasse
• 1 GB DRAM

Host-Software

• Windows XP SP2
• LabVIEW 8.20

Methodik und Überlegungen zum T2

Mit dem T2-Test wird der Durchsatz gemessen, indem die maximale dauerhafte Kommunikationsrate zwischen Tasks ermittelt wird, die mit unterschiedlichen Prioritäten ausgeführt werden. Die Daten erzeugt eine zeitgesteuerte Schleife mit Mikrosekundenauflösung. Der Verbraucher der Daten ist eine freilaufende Schleife mit normaler Priorität, die aus dem Echtzeit-FIFO oder der gemeinsam genutzten Einzelprozessvariable liest, bis sie leer ist, und diesen Prozess wiederholt, bis eine bestimmte Zeitspanne ohne Fehler verstrichen ist. Das Testergebnis ist nur gültig, wenn alle folgenden Aussagen zutreffen:

• Es treten keine Pufferüberläufe auf
• Datenintegrität wird beibehalten: Es tritt kein Datenverlust auf und der Verbraucher erhält die Daten in der Reihenfolge, in der sie gesendet wurden.
• Die zeitgesteuerte Schleife kann nach einer festgelegten Aufwärmzeit von 1 s mithalten

Die Einzelprozess-Empfängerschleife für Einzelprozess-Umgebungsvariablen führt einfache Datenintegritätsprüfungen durch, wie z. B. sicherzustellen, dass die erwartete Anzahl von Datenpunkten empfangen wurde und dass dem empfangenen Nachrichtenmuster keine Zwischenwerte fehlen.

NI hat die Puffergrößen für die Echtzeit-FIFO- und Umgebungsvariablen-FIFO-Puffer 100 Elemente tief für alle Testvarianten und Datentypen konfiguriert.
 

T2-Hardware-/Softwarekonfiguration

PXI-Hardware

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

PXI-Software

• LabVIEW 8.20 Real-Time Module
• Netzwerkvariablen-Engine 1.2.0
• Variablen-Client-Unterstützung 1.2.0
• Broadcom 57xx Gigabit-Ethernet-Treiber 2.1, im Polling-Modus konfiguriert

CompactRIO-Hardware

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

CompactRIO-Software

• LabVIEW 8.20 Real-Time Module
• Netzwerkvariablen-Engine 1.2.0
• Variablen-Client-Unterstützung 1.2.0  

 

Methodik und Überlegungen zum T3

Mit dem T3-Test wird der Durchsatz direkt gemessen, indem die über das Netzwerk übertragenen Datenmenge und die Gesamtdauer des Tests aufgezeichnet wird. Eine zeitgesteuerte Schleife mit Mikrosekundenauflösung enthält den Datenerzeuger, der ein bestimmtes Datenmuster an die Netzwerk-Umgebungsvariable oder die Echtzeit-FIFO-VIs überträgt.

Für den Case „Netzwerk-Umgebungsvariablen“ wird eine NPL auf dem Host-System ausgeführt und in einer frei laufenden While-Schleife ausgelesen. Für den Test der Echtzeit-FIFO-VIs wird die NPL auf dem Real-Time-System ausgeführt, prüft den Zustand des FIFOs mit einer gegebenen Rate, liest alle verfügbaren Daten aus und sendet sie über TCP über das Netzwerk. Die Benchmark-Ergebnisse zeigen den Effekt, wenn dieser Polling-Zeitraum entweder auf 1 oder 10 ms eingestellt ist.

Das Testergebnis ist nur gültig, wenn alle folgenden Aussagen zutreffen:

• Keine Pufferüberläufe, weder FIFO noch Netzwerk
• Datenintegrität wird beibehalten: Es tritt kein Datenverlust auf und der Verbraucher erhält die Daten in der Reihenfolge, in der sie gesendet wurden.
• Die zeitgesteuerte Schleife im TCL VI kann nach einer festgelegten Aufwärmzeit von 1 s mithalten

Nach dem Lesen jedes Datenpunkts prüft die NPL für den Test der Netzwerkvariablen das Datenmuster auf Richtigkeit. Für den Echtzeit-FIFO-Test ist der TCL für die Validierung verantwortlich, je nachdem, ob ein Echtzeit-FIFO-Überlauf aufgetreten ist.

Um Datenverluste zu vermeiden, hat NI die Puffergrößen so konfiguriert, dass sie nicht kleiner als das Verhältnis zwischen NPL- und TCL-Schleifenperioden sind, wobei die Mindestgröße für die Echtzeit-FIFO-Puffer auf 100 Elemente begrenzt ist.

T3-Hardware-/Softwarekonfiguration

Host-Hardware

• Intel Core 2 Duo 1,8 GHz
• 2 GB DRAM
• Intel PRO/1000 (Ethernet-Adapter mit 1 Gb/s)

Host-Software

• Windows Vista 64 Bit 
• LabVIEW 8

Netzwerkkonfiguration

• Switched-Netzwerk mit 1 Gb/s

PXI-Hardware

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

PXI-Software

• LabVIEW 8.5 Real-Time Module
• Netzwerkvariablen-Engine 1.2.0
• Variablen-Client-Unterstützung 1.2.0
• Treiber 2.1 für Broadcom 57xx Gigabit Ethernet

Methodik und Überlegungen zum T4

Beim T4-Test hat NI ungepufferte Netzwerk-Umgebungsvariablen mit den folgenden Datentypen verwendet: Doppelt, Einfach, Boolesch, Doppel-Array, Einzel-Array und Boolesches Array.

T4-Hardware-/Softwarekonfiguration

PXI-Hardware

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

PXI-Software

• LabVIEW Real-Time-Module 8.0
• Netzwerkvariablen-Engine 1.0.0
• Variablen-Client-Unterstützung 1.0.0
• Treiber 1.0.1.3.0 für Broadcom 57xx Gigabit Ethernet

 

Methodik und Überlegungen zu T5 und T6

In den T5- und T6-Tests hat NI ungepufferte Netzwerk-Umgebungsvariablen des Datentyps Doppel-Signalverlauf verwendet.

T5-und T6-Hardware-/Softwarekonfiguration

Host-Hardware

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

Host-Software

• Windows Vista 64 Bit
• 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)
• Variablen-Client-Unterstützung 1.0 (mit LabVIEW 8.20) und 1.4 (mit LabVIEW 8.5)