FGV Funktionale Globale Variable

' schrieb:Ich wollte für meine FGV möglichst wenig Zusatzeingänge haben, deswegen hatte ich mal überlegt, ob ich das VI-Label dafür verwenden kann.

Aus diesem Satz geht hervor, dass du das "Label als Eingang für Daten verwenden" willst. Verstehe ich das richtig?

Als Eingang für Daten kannst du den Label nicht verwenden. Label und Eingang sind zwei völlig verschiedene Sachen. Ein Eingang ist eine Funktionalität, die zur Laufzeit durch kontrete Daten ersetzt wird. Ein Label, wenn er denn der Name des VIs ist, ist zur Laufzeit das Programm, das die Daten verarbeitet. Ist der Label gar nur die Beschriftung (Untertitel), so ist der lediglich für die IDE inderessant. Den zur Laufzeit beizubehalten, wäre unsinnig.

Möglicherweise kann man auf Label und Untertitel zugreifen. Dann aber bestimmt nur per Methode, die selbst wieder die Referenz des VIs benötigt. Wolltest du z.B. den Untertitel als Dateneingang verwenden, müsstest du die Referenz des VIs holen. Dann kucken, ob es eine Methode (oder Property) gibt, das den Untertitel referenziert. Dann schreibend und(!) lesend darauf zugreifen.

[*grübel*] Als konstanten Eingang [*grübel*]
Du willst die Daten zur Laufzeit selbst ja nicht ändern. Nur einmal vorbelegen. Dann willst du zur Laufzeit auf die vorbelegten Daten zugreifen.
Du könntest irgendein Property eines VIs (Probleme guckst du oben) verwenden, um das VI sich selbst identifizieren zu lassen. z.B. den Text in der Versionshistorie (so er denn zugreifbar ist zur Laufzeit). Allerdings ist der Aufwand hierfür nicht nur mit Kanonen, sondern mit der ganzen Imperialen Flotte auf Spatzen geschossen.

Anzeige

Hallo,

habe mein Problem jetzt etwas anders gelöst:
Neben Dateneingang und -ausgang setze ich in meinem FGV-VI nur einen einzigen String als Parameter, der sowohl Modus (Read, Write, Reset) als auch Label beinhaltet (z.B. "Umess1"). Das spart Verdrahtung und sieht auch noch elegant aus ;-)

Das VI beinhaltet ein dynamisches Array, in dem ich noch nicht vorhandene Labels eintrage (Write/Reset-Modus) oder nach einem Label suche (Read-Modus). Dann lasse ich mir den Index ausgeben und schreibe/lese mein dazugehöriges dynamisches Datenarray.

Funktioniert prima und ich kann die FGV jetzt universell verwenden! Ich weiß nur noch nicht, ob die Bearbeitungszeit für die dynamischen Arrays bei sehr großer Anzahl an FGVn darunter leidet. Bisher habe ich 50 ausprobiert hatte keine Probleme (<<1ms)

' schrieb:Neben Dateneingang und -ausgang setze ich in meinem FGV-VI nur einen einzigen String als Parameter, der sowohl Modus (Read, Write, Reset) als auch Label beinhaltet (z.B. "Umess1"). Das spart Verdrahtung und sieht auch noch elegant aus ;-)

Ja, eine sehr elegante Lösung, die auch noch gut aussieht.

Hat aber einen Nachteil, der bei mir als k.o.-Kriterium gilt: Beim Schreiben des Strings manuell per Tastatur können Schreibfehler entstehen, die man nur ganz schlecht findet. Daher verwendet man eben Enumeratoren (mit redundanten Bezeichnungen). Die haben den weiteren Vorteil, dass man alles sehen kann, was möglich ist. Das geht eben bei der String-Methode nicht.

Alternativ könnte es auch mit einer Combobox gehen. Da verschreibt man sich nicht (oder höchstens nur einmal ).


  Combo.vi (Größe: 8 KB / Downloads: 380)



Gruß Markus

Dann hätte ich allerdings wieder einen zusätzlichen Eingang bzw. der Vorteil der Label-Vergabe wäre futsch...

' schrieb:Geht doch.

Mach die reentranten VIs in ein SubVI rein. Diesem SubVI gibst du zusätzlich zu den Parametern, die in die FGV sollen (und dorthin weitergeleitet werden), einen Enumerator z.B. mit den Werten "FGVx". In diesem SubVI liegen die FGVs in unterschiedlichen Cases, die durch den zusätzlichen Enumerator ausgewählt werden. Alle Cases führen zum selben Ausgang. Das aufrufende VI weiß, welches der reentranten FVGs verwendet werden soll.

Das löse ich normal in dem ich im FGV ein Array halte und als extra Parameter einen Index mitgebe der angibt auf welches Element im Array die Methode ausgeführt werden soll. Die Methodenliste wird dann schnell etwas länger, etwa { init, add, delete, get, und was immer ich noch mit den Daten direkt im FGV tun können will}.

Rolf Kalbermatter

Anzeige

blöde Frage:
Warum nimmt man überhaupt solche FGVs und keine globalen Variablen? Racecondtions können doch bei Beiden auftreten - oder nicht?

Bei FGVs ist die Gefahr von Race-Condition ganz extrem minimiert. LabVIEW sorgt nämlich dafür, dass ein VI (solange es nicht auf reentrant steht) immer nur einmal ausgeführt werden kann, nie 2x parallel.

Bei globalen Variablen hast du folgendes Problem: Beim Lesen erzeugst du eine lokale Kopie der Werte im Speicher. Du hast also keinen direkten Bezug mehr zum Wert. Falls du 1ms nach dem Auslesen an einer anderen Stelle im Programm gerade auf die globale Variable schreibst und danach wieder die lokale Kopie zurückschreibst, dann ist dein Update verloren.

Gruß, Jens

Zitat:LabVIEW sorgt nämlich dafür, dass ein VI (solange es nicht auf reentrant steht) immer nur einmal ausgeführt werden kann, nie 2x parallel.

Achso - hm.. und was passiert, wenn in zwei parallelen Schleifen auf dieselbe FGV zugegriffen wird? Wartet Labview dann automatisch immer, bis die FGV "wieder frei ist" - also bis sie keiner mehr benutzt? Oder gibt das einen Fehler?

Zitat:Bei globalen Variablen hast du folgendes Problem: Beim Lesen erzeugst du eine lokale Kopie der Werte im Speicher. Du hast also keinen direkten Bezug mehr zum Wert. Falls du 1ms nach dem Auslesen an einer anderen Stelle im Programm gerade auf die globale Variable schreibst und danach wieder die lokale Kopie zurückschreibst

Sorry Jens, ich raffs net- Ist das bei FGVs nicht das Gleiche? Also, wenn ich den Wert aus ner FGV auslese, ist er dann nicht auch lokal irgendwo erstmal abgelegt ? Und wenn ich dann von wo anders in die FGV reinschreibe und dann den lokalen Wert von zuvor wieder zurückschreibe....

' schrieb:Achso - hm.. und was passiert, wenn in zwei parallelen Schleifen auf dieselbe FGV zugegriffen wird? Wartet Labview dann automatisch immer, bis die FGV "wieder frei ist" - also bis sie keiner mehr benutzt? Oder gibt das einen Fehler?

Genau, LAbVIEW wartet, bis die Resource - in diesem Fall das VI - wieder frei ist.

' schrieb:Sorry Jens, ich raffs net- Ist das bei FGVs nicht das Gleiche? Also, wenn ich den Wert aus ner FGV auslese, ist er dann nicht auch lokal irgendwo erstmal abgelegt ? Und wenn ich dann von wo anders in die FGV reinschreibe und dann den lokalen Wert von zuvor wieder zurückschreibe....

Natürlich kannst du auch Race Conditions mit FGVs erzeugen, gerade bei parallelen Schleifen. Vielleicht mache ich später mal ein Bsp, eine Variante mit FGV, eine mit globalen Variablen.

Gruß, Jens