Kommunikation zwischen SubVis im Subpanel und GUI

Hallo zusammen,

ich bin auf der Suche nach einer Lösung für den Datenaustausch zwischen verschiedenen SubVis welche im Subpanel angezeigt werden. Das SubVi soll auf Ereignisse vom GUI reagieren und muss Konfigurationsdaten von anderen SubVIs empfangen bzw. schicken können.
Hier stellt sich mir noch die Frage, wo man die Daten grundsätzlich lagert??? Meine Idee war mit Shift-Register in einer Loop und von dort aus die Daten verteilen. Ich habe jedoch gemerkt, dass das ganz schon auf die CPU-Auslastung geht und somit nicht so ideal ist.

Kann mir jemand weiterhelfen?

Vielen Dank schon mal im Voraus

LabVIEW 2017
  IR_Project.zip (Größe: 826,12 KB / Downloads: 327)

Anzeige

(27.10.2017 18:26 )Rene123 schrieb:  ich bin auf der Suche nach einer Lösung für den Datenaustausch zwischen verschiedenen SubVis welche im Subpanel angezeigt werden.

Deine bisherige Lösung ist nicht die schlechteste.
Allerdings sehe ich bisher keinen Nutzen darin, ein VI mit Frontpanel laufen zu lassen, ohne das Frontpanel anzuzeigen. Grundsätzlich lass ich VIs mit FP immer erst dann ausführen, wenn sie auch im SubPanel angezeigt werden. Nichtsdestoweniger kann man Programmteile, die zwar laufen müssen, aber nicht zwangsweise ein FP haben müssen, in ein weiteres VI auslagern, das dann grundsätzlich z.B. mit einer Schrittkette läuft.

Zitat:Das SubVi soll auf Ereignisse vom GUI reagieren und muss Konfigurationsdaten von anderen SubVIs empfangen bzw. schicken können.

Zum einen steuert die GUI die SubVIs per Mitteilungen, die man ohne weiteres per Queue verschicken kann. Zum anderen würde ich Konfigurationsdaten, also ganze Datensätze, in einer sogenannten FGV vorhalten. Ein FGV ist eine While-Schleife mit Schieberegistern und einer Case-Sequenz, die Methoden abarbeiten kann.

Zitat:Hier stellt sich mir noch die Frage, wo man die Daten grundsätzlich lagert???

z.B. in der FGV.

Zitat:Meine Idee war mit Shift-Register in einer Loop und von dort aus die Daten verteilen.

Genau: in der FGV.

Zitat:Ich habe jedoch gemerkt, dass das ganz schon auf die CPU-Auslastung geht

Das liegt daran, weil du in den While-Schleifen, die dauernd laufen, keine Wartezeit von z.b. 50ms eingefügt hast. Ob die While-Schleifen in deinem Falle tatsächlich dauernd laufen müssen, steht auf einem anderen Blatt ...

Vielen Dank für das Feedback.

Zitat:Allerdings sehe ich bisher keinen Nutzen darin, ein VI mit Frontpanel laufen zu lassen, ohne das Frontpanel anzuzeigen. Grundsätzlich lass ich VIs mit FP immer erst dann ausführen, wenn sie auch im SubPanel angezeigt werden.

Ich habe diese Variante gewählt, damit das Programm ein bisschen skalierbar ist. Das Beispiel für diese Struktur habe ich in den Beispielen (Find Examples) gefunden. Gibt es eine Möglichkeit ein Öffnen und Schließen von VIs umzusetzen ohne das es sich merkbar auf die Benutzung auswirkt?

Zitat:Nichtsdestoweniger kann man Programmteile, die zwar laufen müssen, aber nicht zwangsweise ein FP haben müssen, in ein weiteres VI auslagern, das dann grundsätzlich z.B. mit einer Schrittkette läuft.

Mache ich grundsätzlich auch so. Ist es nicht eh so, dass z.B. in der MeasurementSubVi die Consumer Loop erst läuft, wenn diese aus der Producer Loop ein Element bekommt? Dadurch laufen ja nur die Programmteile welche zu Abfrage der Variablen und Controls dienen???

Zitat:Zum einen steuert die GUI die SubVIs per Mitteilungen, die man ohne weiteres per Queue verschicken kann. Zum anderen würde ich Konfigurationsdaten, also ganze Datensätze, in einer sogenannten FGV vorhalten. Ein FGV ist eine While-Schleife mit Schieberegistern und einer Case-Sequenz, die Methoden abarbeiten kann.

FGV muss ich mir mal näher anschauen. Bisher habe ich das noch nie verwendet, aber ich habe hier irgendwo gelesen, dass man keine großen Datenarrays mit FGV speichern soll. Die Frage ist natürlich, was hier mit groß gemeint ist? Das Datenarray von mir kann im schlimmsten Fall auch über 1000 Elemente enthalten.
Was auf jeden Fall die Auslastung minimiert, ist das Entfernen der Shift-Register in er GUI zum lagern der Daten. Die Daten liegen ja sowieso in den Globals und damit sind diese Shift-Register überflüssig.
Ich hatte auch zuerst alles mit Queues gemacht, aber ich hatte das Lesen der globalen Variable mit der Schleifer des Queue-Elementes, was dazu geführt hat das die Daten beim Ausführen der Eventstruktur nicht angelegen haben.

Grundsätzlich würde mich interessieren, warum das Konzept mit den Referenzen nicht übergreifend drahtlos auf verschiedene VIs anwendbar ist? Wenn ich das Statisch mache und einen Draht anlegen, geht es... Also z.B. erstelle ich eine Referenz von einem Button aus dem Vertical Cluster. Speichere diese als Typedef Strict und kopiere diese in mein SubVI und greife mit einer Property Node drauf zu. Aber drahtlos geht es nicht (habe ich schon so ziemlich alle Varianten ausprobiert).

Zitat:Das liegt daran, weil du in den While-Schleifen, die dauernd laufen, keine Wartezeit von z.b. 50ms eingefügt hast.

Ich habe noch nie Wartezeiten in Schleifen verwendet, außer es musste ein definierter Zeitrahmen geschaffen werden. Gut zu wissen. Macht man das immer so?

(28.10.2017 17:47 )Rene123 schrieb:  Ich habe diese Variante gewählt, damit das Programm ein bisschen skalierbar ist.

Der Gedanke an sich ist sehr gut! Ich bin aber der Meinung, auch andere Verfahren sind gut genug skalierbar.

Zitat:Gibt es eine Möglichkeit ein Öffnen und Schließen von VIs umzusetzen ohne das es sich merkbar auf die Benutzung auswirkt?

Da die Benutzung eines VIs nach dem Öffnen beziehungsweise vor dem Schließen stattfindet, kann sich Öffnen oder Schließen eigentlich gar nicht so sehr auf die Benutzung auswirken. Oder was meinst du genau?

Zitat:Ist es nicht eh so, dass z.B. in der MeasurementSubVi die Consumer Loop erst läuft, wenn diese aus der Producer Loop ein Element bekommt?

Das ist richtig. Aber: Was ist mit dem Rest des VIs?
Mir sind mehrere Sachen eingefallen, was an der Kombination SubPanel und Queue-gesteuert möglicherweise schlecht ist:
* Geht denn ein solches SubVI zu debuggen? Kommt man an das BD, wenn das FP im SubPanel läuft?
* Wenn man ein solches VI standalone ausführt, also nicht in SubPanel, kann man es nur schwer steuern. Dazu bräuchte man parallel ein VI, das die Queue bedient. Ist denn das praktikabel?

Zitat:FGV muss ich mir mal näher anschauen. Bisher habe ich das noch nie verwendet, aber ich habe hier irgendwo gelesen, dass man keine großen Datenarrays mit FGV speichern soll. Die Frage ist natürlich, was hier mit groß gemeint ist? Das Datenarray von mir kann im schlimmsten Fall auch über 1000 Elemente enthalten.

* 1000 Elemente ist relativ: Array of DBL => völlig irrelevant. Array of Cluster of (...) => kompliziert.
* Arrays, die z.B. Messdaten enthalten, würde ist gegebenenfalls auch nicht in einem FGV verwalten.
* Ich verwende FGV z.B. als "Globale Variable". Da ein FGV, das per Enumerator gesteuert werden kann, auch Methoden für die Manipulation der Daten enthalten kann, kann so eine FGV als Klasse im klassischen Sinne verstanden werden.
Hinweis: Die FGV würde die globale Variable, die in den Dauer-While-Schleife gelesen bzw. geschrieben wird, ersetzen. Die FGV wird immer dann gelesen bzw. geschrieben, wenn das auch so notwendig ist. Geschreiben wird sie z.B. dann, wenn infolge eines Benutzer-Events die Lokale Variable (das FP-Element) geändert wurde.

Zitat:Was auf jeden Fall die Auslastung minimiert, ist das Entfernen der Shift-Register in er GUI zum lagern der Daten.

Das bezweifle ich sehr!
Du solltes zuerst in die While-Schleifen eine z.B. 50ms-Wartezeit (Metronom) einfügen. Ich gehe sehr davon aus, dass dein Programm dann 0% (Max.Max 5%) Auslastung hat. Danach kannst du das mit den Schieberegistern nochmals prüfen.
Hinweis: Auch wenn LV eine Datenfluss-Sprache ist, kann man doch hervorragend Event-Gesteuert arbeiten => Auslastung geht gegen Null.

Zitat:Die Daten liegen ja sowieso in den Globals und damit sind diese Shift-Register überflüssig.

Globale Variablen? Das sind "Ressourcen-Fresser"!

Zitat:Ich hatte auch zuerst alles mit Queues gemacht, aber ich hatte das Lesen der globalen Variable mit der Schleifer des Queue-Elementes, was dazu geführt hat das die Daten beim Ausführen der Eventstruktur nicht angelegen haben.

Auch wenn LV nach Datenfluss arbeitet, muss du dieses Verfahren natürlich auch dort einhalten, wo kein expliziter Datenfluss besteht: Erst Daten in FGV schreiben, dann Queue beschreiben, dann im Consumer beim Queue-Event Daten aus FGV lesen.

Zitat:Grundsätzlich würde mich interessieren, warum das Konzept mit den Referenzen nicht übergreifend drahtlos auf verschiedene VIs anwendbar ist?

Diese Frage kann ich nur ganz allgemein beantworten, weil ich nicht genau weiß, was du meinst.
Selbstverständlich kannst du Referenzen auch drahtlos applikationsweit verwenden: Die Referenz sollte auf ein strict-typisiertes Element (Cluser, VI) gehen. Diese Referenz kann man in einer FGV vorhalten ...

Zitat:Wenn ich das Statisch mache und einen Draht anlegen, geht es... Also z.B. erstelle ich eine Referenz von einem Button aus dem Vertical Cluster. Speichere diese als Typedef Strict und kopiere diese in mein SubVI und greife mit einer Property Node drauf zu. Aber drahtlos geht es nicht (habe ich schon so ziemlich alle Varianten ausprobiert).

Eine Referenz ist auch nur eine Variable (im klassichen Sinne) und enthält einen Wert. Dieser Wert allerdings kann nur zur Laufzeit(!) erzeugt werden (weil das Objekt, das referenziert werden soll, erst zur Laufzeit seinen Wert bekommt).
Das Kopieren einer Referenz (beachte: du kopiert den Wert der Referenz mit!) zur Programmerstellungszeit funktioniert nicht, da bei der nächsten Laufzeit die Referenz einen anderen Wert haben kann. Du musst also z.B. in einem Init-Case den Wert der Referenz in eine FGV (oder bäh Globale Variable schreiben) und kannst den dann wo du willst verwenden.

Zitat:Macht man das immer so?

Ja, wenn es keine andere Möglichkeit gibt ...

Ein paar Anmerkungen.

1. Daten in Queue
Daten, die per se für die Allgemeinheit zugänglich sein sollen, in einer Queue zu speichern, hat einen strategischen Nachteil: Einmal ausgelesen sind sie für andere nicht mehr zugreifbar. Wenn, dann Melder nehmen. Oder FGV.

2. Daten in Queue
Siehe HeaderSubVI, Cluster "Main Data Cluster". Schreiben nach Queue. Beim Schreiben in die Queue werden die beiden anderen Untercluster mit konstanten Werten belegt. Woher weiß der Queue-Auslesende, welcher Untercluster gültige Daten aufweist? Besser: FGV nehmen mit Enumerator SetHeaderCluster.

3. VI unsichtbar laufen lassen und in SubPanel anzeigen.
Man kann das so machen. Hat aber (mindestens) einen Nachteil. Folgendes:
Du hast VI X im SubPanel laufen und öffnest über den Projektmanager (nebenbei: mit Projektmanager, so gehört sich das) VI Y. Jetzt kannst du beide VI (X und Y) bearbeiten, was nicht unbedingt nachteilig sein muss. Wenn du jetzt aber Y beendest (kann ja vorkommen, wenn man auf Schließen klickt), dann wird die Abarbeitung beendet. Schließt du jetzt X (was kein Schließen ist, sondern nur ein FP unsichtbar machen), und machst VI Y im SubPanel sichtbar, so ist zwar VI Y sichtbar - es wird aber nicht ausgeführt.

4. Zugriff auf das FP vom FGV aus.
Ich trenne immer gerne Daten vom FP. Das hat den Vorteil, dass grundsätzlich jedes VI (das BD eines jeden VIs) Zugriff auf diese Daten hat ohne selbst ein FP-Element für die Daten haben zu müssen (globale Variablen würden den selben Zweck erfüllen). Irgendwann jedoch muss der Anwender die Daten (z.B. Konfigurationsdaten) eingeben. Das mach ich dann so: Beim Starten des VIs, das als Eingabemaske dient, wird eine Referenz auf den Eingabecluster in das FGV übergeben. Somit kann die FGV auf das Eingabeelement schreiben (oder davon Lesen). Der Anwender mache nun eine Eingabe, daraufhin wird im Cluster-Value-Change-Event der komplette Cluster an die FGV übergeben (Enumerator: neue Daten). Jetzt kommt der Vorteil: In der FGV kann man den Cluster auf Eingabefehler überprüfen (Vorteil?: Der Code steht nicht im Haupt-VI) und kann ihn wieder zurückschreiben. Weiterer Vorteil: Methode Lesen von File - und dann Schreiben nach FP. Das sind alles Maßnahmen, die das BD des Haupt-VIs möglichst klein und damit übersichtlich halten. Und außerdem ist alles das, was bezüglich eines Datensatzes zusammengehört, in "einer Klasse gekapselt".

Zitat:Ich bin aber der Meinung, auch andere Verfahren sind gut genug skalierbar.

Ok, ich bin interessiert... Wie löst du das (außer mit Actor Framework etc.) Mein wissen ist leider noch nicht so tief, dass ich jede Möglichkeit kennen würde. Ich hatte zuerst einen Tab Control verwendet, aber hier haben sich folgende Probleme ergeben: 1. Controls verschieben sich beim Skalieren 2. Graphs skalieren zu langsam wenn man es mittels Property Nodes löst (war irgendwo ein Beispiel) oder skalieren sich nicht paralle zum Tab Control mit 3. Liegt ein Cluster im Tab Control, ist skalieren nur bis zur Mindestesgröße des größten Clusters möglich

Zitat:Da die Benutzung eines VIs nach dem Öffnen beziehungsweise vor dem Schließen stattfindet, kann sich Öffnen oder Schließen eigentlich gar nicht so sehr auf die Benutzung auswirken. Oder was meinst du genau?

Ich meinte hier, dass es ggf. Verzögerungen beim UI führen könnte. Ich bin mir aber auch nicht sicher, wie das gehen soll. Wie soll ich die schließen, wenn ich mittels Event nur die Vis anzeigen lasse??? Hast du hier eine Möglichkeit schon mal umgesetzt?

Zitat:Mir sind mehrere Sachen eingefallen, was an der Kombination SubPanel und Queue-gesteuert möglicherweise schlecht ist:

Zitat:* Geht denn ein solches SubVI zu debuggen? Kommt man an das BD, wenn das FP im SubPanel läuft?

--> Nein! Wenn das Programm läuft, sind die SubVIs welche im Frontpanel aufgerufen werden nicht mehr zugänglich. Ich hatte zwar eine Möglichkeit geschaffen, aber schon wieder vergessen ^^

Zitat:* Wenn man ein solches VI standalone ausführt, also nicht in SubPanel, kann man es nur schwer steuern. Dazu bräuchte man parallel ein VI, das die Queue bedient. Ist denn das praktikabel?

--> Bisher ging es gut. Einziges Problem war bevor ich die globale Variable in eine Schleife gelegt habe, dass die Daten nicht angelegt waren.

Zitat:* 1000 Elemente ist relativ: Array of DBL => völlig irrelevant. Array of Cluster of (...) => kompliziert.

Ja, die Daten sollen in ein Cluster Array. Macht es dann Sinn für jedes Cluster (Config, Header, Messdaten etc.) eine eigene FGV anzulegen?

Zitat:Das bezweifle ich sehr!

Ich habe die 3 Shift Register und die beiden Schleifen aus der GUI gelöscht und habe 30% weniger CPU-Auslastung. Scheinbar bringt es doch was. Funktionieren Event-Strukturen ohne While-Loop?

Zitat:Globale Variablen? Das sind "Ressourcen-Fresser"!

Warum und welche Ressourcen? CPU oder RAM?
--> http://vishots.com/wp-content/uploads/20...enback.pdf
Da steht jetzt nichts, dass es auf die Ressourcen geht. Für mein Verständnis ist es so, dass die Variable nur einmal angelegt wird. Kannst du das näher erläutern?

Zitat:Selbstverständlich kannst du Referenzen auch drahtlos applikationsweit verwenden: Die Referenz sollte auf ein strict-typisiertes Element (Cluser, VI) gehen.

und

Zitat:Du musst also z.B. in einem Init-Case den Wert der Referenz in eine FGV (oder bäh Globale Variable schreiben) und kannst den dann wo du willst verwenden.

Könntest du hier mal ein Beispiel zeigen??? Bin grad nicht so sicher wie das funktionieren soll^^

Zitat:4. Zugriff auf das FP vom FGV aus.

Auch hier wäre ein Beispiel-Code mega

Vielen Dank schon mal für die echt nützlich Ratschläge. Ich denke das Konzept mit den FGVs ist sicherlich besser als normale Globals. Bin gespannt, wie sich das auf die Leistung auswirkt, da die FGV ja ein VI ist und der Code jedesmal kopiert wird. Probiere es mal aus

(29.10.2017 14:30 )Rene123 schrieb:  haben sich folgende Probleme ergeben: 1. Controls verschieben sich beim Skalieren ...

OK ich nehme alles, was ich zu Skalierung gesagt habe, zurück. Ich hab nämlich gedacht, du meinst die Skalierbarkeit der Software. FP-Skalierung, und das auch noch automatisch - so etwas verwende ich überhaupt nicht (oder: so sein Scheiß, das funktioniert hinten und vorne nicht ausreichend). Wenn du was über Skalierung von FP-Elementen wissen willst, müssen da andere was sagen.

Zitat:Ich meinte hier, dass es ggf. Verzögerungen beim UI führen könnte.

Was interessiert dich die Verzögerung beim Öffnen/Schließen eines VIs bzw. beim sichtbar/unsichtbar machen eines FP? Das geht alles schnell genug. Solltest zu Sorge haben, dass eine kontinuierliche Messwerterfassung unter dem Management eines VIs bzw. FPs leidet, kann ich dich beruhigen: Das klappt alles hervorragend - dafür benutzt du ja LabVIEW.

Zitat:Wie soll ich die schließen, wenn ich mittels Event nur die Vis anzeigen lasse???

Ich bin immer noch nicht ganz bei dir.
Du kannst das Management deiner VIs respektive FPs so machen, das wird funktionieren - halt mit den erwähnten Einschränkungen beim Debuggen.

Zitat:--> Nein! Wenn das Programm läuft, sind die SubVIs welche im Frontpanel aufgerufen werden nicht mehr zugänglich.

Hierzu muss ich sagen: Eine Programmier-Philosophie, die ein Debugging nicht ausreichendes unterstützt, muss abgelehnt werden.

Zitat:--> Bisher ging es gut.

Ein ganz schlechtes Argument. Aber dafür fragst du ja nach Verbesserungen.
Strenggenommen kann man jedes VI so gestalten, dass es standalone läuft - somit ist es ausreichend debuggbar.

Zitat:Macht es dann Sinn für jedes Cluster (Config, Header, Messdaten etc.) eine eigene FGV anzulegen?

Es ergibt schon einen Sinn, für jeden Cluster eine eigene FGV zu machen. "Datenkapselung" spricht z.B. dafür. Und Vereinfachung. Wenn natürlich die einzelnen Cluster eine gewisse enge Beziehung haben, kann man auch ein FGV nehmen.

Zitat:Ich habe die 3 Shift Register und die beiden Schleifen aus der GUI gelöscht und habe 30% weniger CPU-Auslastung. Scheinbar bringt es doch was.

Nicht, dass alleine das Löschen der Schleifen die Ersparnis bringt. Gegenbeispiel: Ich hab nur FGV, davon aber viele und selbst sonst jede Menge Schieberegister - und trotzdem eine maximale Auslastung von 7% - wegen Netzwerk-Transfer, nicht wegen Schieberegister.
Theoretisch könntest du Recht haben, dann aber musst du deinen Fall genauer beschreiben und erklären.

Zitat:Funktionieren Event-Strukturen ohne While-Loop?

Ja. Aber: dann nur ein einziges Mal - da der Datenfluss abgearbeitet ist. Sinnvollerweise liegt die Event-Struktur selbstverständlich in einer While-Schleife - dann aber alleine.

Zitat:Globale Variablen? Das sind "Ressourcen-Fresser"!

Wenn ich das noch richtig in Erinnerung habe, werden Globale Variablen wie folgt gemanagt: Jedes Element "Globale Variable lesen" bekommt ihren eigenen Speicher. Das bedeutet, dass bei "Globale Variable schreiben" jeder dieser Lese-Speicher überschrieben wird. usw. Bedenke außerdem: RaceCondition ist ein weites Feld. Globale Variablen sind extrem anfällig dafür. Mit FGV, wenn richtig angewandt, können keine RaceCondions auftreten.

Zitat:Könntest du hier mal ein Beispiel zeigen??? Bin grad nicht so sicher wie das funktionieren soll^^

Schau mer mal ...

Zitat:Bin gespannt, wie sich das auf die Leistung auswirkt, da die FGV ja ein VI ist und der Code jedesmal kopiert wird.

Wo wird da Code kopiert? Kopiert, weil Datenfluss, werden vielleicht Daten, aber kein Code. Was hast du denn für einen Rechner? Ein Smartphone? Ich schiebe Megabyte-weise Messdaten hin und her, da gibt es keine nennenswerte Prozessorauslastung. Einen Fall mit sehr viel Auslastung hab ich - mit 21 Seriellen Schnittstellen RS232.

Muster FGV, samt Referenz. LV 2017

Ich habe jetzt alle GV durch FGV (Anleitung: https://frclabviewtutorials.com/fgv/) ersetzt. Muss man hier noch was spezielles einstellen? Werde es morgen ausführlich testen und hoffen das es funktioniert^^
Eigentlich dachte ich bisher, dass ich die VI kopiere wenn ich sie an mehreren Stellen im Programm verwende. Also den Programm-Code dupliziere und somit die Daten nicht zentral gespeichert werden können, da jede Kopie einen eigenen Speicherbereich erhält.

Zitat:Ich bin immer noch nicht ganz bei dir. Du kannst das Management deiner VIs respektive FPs so machen, das wird funktionieren - halt mit den erwähnten Einschränkungen beim Debuggen.

In meinem Programm (Vorlage "Find Examples") müsste ich doch auch die Pfadreferenz mit "Close" schließen, damit das VI vollständig aus dem speicher verschwindet? Will ich das VI wieder öffenen müsste ich den Pfad wieder bekannt machen, damit das FP der VI in das Sub Panel geladen werden kann. Dies würde aber in meinem Fall nicht gehen, da ich den Pfad vorher schon geladen habe oder nicht? Mich interessiert, wie so eine Öffnen- und Schließen-Struktur aussieht?

(29.10.2017 23:26 )Rene123 schrieb:  Eigentlich dachte ich bisher, dass ich die VI kopiere wenn ich sie an mehreren Stellen im Programm verwende. Also den Programm-Code dupliziere und somit die Daten nicht zentral gespeichert werden können, da jede Kopie einen eigenen Speicherbereich erhält.

Was du gedacht hast, ist die eine der beiden Möglichkeiten.

• Denk einfach: Du kopierst keine Elemente, sondern platzierst sie.
  

• Wenn du ein VI auf das BD legst, wird auch nichts anders gemacht wie in anderen Programmiersprachen auch: Es wird ein Unterprogramm aufgerufen. Dieses eine VI - samt seinen Daten, auch die Daten in Schieberegistern - gibt es also genau einmal im Speicher. LV ist so schlau, das Unterprogramm nur dann aufzurufen, wenn alle Eingangsdaten anliegen - wie auch sonst. Außerdem: Noch schlauer - das SubVI wird nicht aufgerufen, wenn es gerade bereits läuft! Das hat zwei Folgen: Zwei unabhängige Datenflüsse, die dasselbe SubVI verwenden, können sich gegenseitig beeinflussen. Zweite Folge: automatische Vermeidung von RaceCondition.
  

• Nichtsdestoweniger gibt es auch die andere Möglichkeit, die dann ablaufinvariant heißt. Hier kann das VI tatsächlich öfter parallel ausgeführt werden. Auch besitzt jedes der parallelen VIs seine eigenen Daten. Grob gesehen liegt das VI (samt Daten) jetzt so oft als Instanz im Speicher, wie es im DB plaziert ist.