FGV-Array mit Variant-Daten

Hallo zusammen.

Nachdem ich letzt hier etwas über FGVs gelesen habe, vorallem dass dadurch der Speicherverbrauch im Gegensatz zu globalen Variablen oder Property-Nodes geringer sein soll, habe ich mir jetzt ein kleines Konzept überlegt mit dem man das ganze auf beliebig viele Variablen aufblasen kann um dieses FGV-Array als Variablenspeicher für alle anfallen Variablen zu nutzen.

Die Idee ist, ein SubVI mit 3 Eingängen und (aktuell) 3 Ausgängen. Als Eingänge 2 beliebige Datentypen, einmal der Variablenname und einmal der Variablenwert, der dritte Eingang ist ein enum. Ausgänge sind Variablenname, Variablenwert un Fehler.

Das enum kann 3 Werte einnehmen.
- read: Variablenname am Eingang ist nötig
- write: Variablenname und -wert am Eingang sind nötig
- clear: kein Eingang nötig

Die Eingänge Variablenname und -wert sind vom Typ egal, da diese Eingänge im SubVI auf ein Variant-Control gehen, damit beliebige Datentypen gespeichert werden können.

Die Ausgänge Variablenname und -wert sind bisher leider noch vom Typ Variant, müssen also nach ihrer Übergabe noch umgewandelt werden (z.B. mittels "Variant to Data").

Der Fehler-Ausgang ist aktuell eigentlich dazu nötig falls eine Variable gelesen werden soll die nicht vorhanden ist.

Zur Funktion im SubVI habe ich mir überlegt dass bei einem "write" Variablenname und -wert an ein Array angehängt werden. Sollte der Variablenname bereits vorhanden sein, so wird der bestehende Wert aktualisiert.
Bei einem "read" wird in der Spalte mit Variablenname nach dem übergebenen Namen gesucht und der dazugehörige Wert zurück geliefert.
Ein "clear" führt, wie der Name schon vermuten lässt, zu einem Löschen des gesamten Arrays.



Jetzt wollte ich fragen was Ihr von dem Konzept haltet. Evtl. hat ja aber noch jemand eine Idee für eine Funktion die ich noch unbedingt mit einbauen sollte.

Schöne Grüße und einen schönen Abend
flattervieh

Anzeige

Hallo flattervieh,

dein Konzept ist gut, aber: wenn du schon mit Variants arbeitest, warum dann nicht richtig?
Guckst du hier, wie man die Attribute von Variants für ebendiese Aufgabe nutzen kann

Dann würde ich dir empfehlen:
- immer auch einen ErrorIn-Input vorsehen (wie willst du sonst per ErrorCluster zeitliche Abläufe koordinieren?)
- den "Variablennamen"-Ein- und Ausgang als String vorzugeben
- den Dateninput an den vorgesehenen Zweck anzupassen und den Datenausgang entsprechend schon innerhalb der FGV wieder von Variant zurückzuwandeln (wobei das teilweise schon von der oben beschriebenen Methode übernommen wird!)
- natürlich das empfohlene Anschlusspattern 4-2-2-4 benutzen...

Hallo GerdW.

Erstmal vielen Dank für die Hinweise. Den Variablennamen wollte ich eh als String machen, damit der eineindeutig ist.
Ein ErrorInput ist sicherlich sinnvoll, dazu muss ich mich dann aber erstmal noch in die Thematik mit solchen Fehlermeldungen einarbeiten und schauen wie ich das am besten nutzen kann.
Das mit den Variantattributen sieht interessant aus, dadurch kann ich die Variablen dann einfacher suchen wenn ich einen Wert aus einem großen Array suchen will.

Was meinst du aber mit "Dateninput an den vorgesehenen Zweck anpassen"? Mehrere Eingänge, mal Zahlen und mal Strings?

Und warum ist das Anschlusspattern 4-2-2-4 empfohlen? Weil es das Standardpattern ist?

Grüße
flattervieh

(27.07.2011 07:23 )flattervieh schrieb:  Ein ErrorInput ist sicherlich sinnvoll, dazu muss ich mich dann aber erstmal noch in die Thematik mit solchen Fehlermeldungen einarbeiten und schauen wie ich das am besten nutzen kann.

Für eine FGV haben der Errorein- und ausgang in erster Linie die Aufgabe, die FGV nach dem Datenflussprinzip in dein Programm zu integrieren. Ohne diese Errorverdrahtung hast du die gleiche Problematik von Race Conditions wie bei normalen globalen/lokalen Variablen. Darüberhinaus kannst du mittels des Errorhandling z.B. beeinflussen, was in deiner FGV im Fehlerfall passieren soll:

   

(27.07.2011 07:23 )flattervieh schrieb:  Und warum ist das Anschlusspattern 4-2-2-4 empfohlen? Weil es das Standardpattern ist?

Zum einen ist es das Standardpattern, zum anderen sollte es vermieden werden, mehr Eingänge/Ausgänge zu verwenden. Das macht den Code wesentlich schwerer zu lesen. Werden mehr Eingänge benötigt (ich beschränke mich meistens auf 3 + Error), dann sollte man clustern statt die Eingänge auf 10+ aufzublasen


Beste Grüße,
NWO

Nur eine kleine Info. Es gibt bereits ein Konzept für generische FGV's. Allerdings muss man schonmal mit LVOOP gearbeitet haben um es zu verstehen. Das Ganze nennt sich LV2OO Style Global. Trotzdem wollte ich die Info hier lassen:

http://forums.ni.com/t5/LabVIEW/LV2OO-St...m-p/562527

Eventuell hilft es jemandem.

Hallo Abrissbirne. Vielen Dank für den Hinweis mit dem LV2OO allerdings habe ich noch keinerlei Erfahrung mit LVOOP. Daher sagt mir das zeug da gar nix. Ich hab mir mal die Blockdiagramme davon angeschaut, aber irgendwie komm ich damit mal so gar nicht klar. Werd mich da aber mal bei Gelegenheit einarbeiten.

NWOmason dir auch danke mit der Erklärung der Pattern.
Das mit dem Erroreingang muss ich mir auch mal noch anschaun. Jedoch habe ich bisher einfach noch gar nichts dass mit Fehler meldet. Es sei denn irgendwelche Hardware-Bausteine. Race-Conditions verhinder ich eigentlich dadurch, dass ich alles mit State-Machines aufbaue. Da ich aber bisher immer mehrere States habe die noch dazu z.b. in Sequenzen eingebaut sind etc. bin ich auf die Idee mit den FGV gestoßen da ich oft Variablen habe die irgendwo gesetzt werden und irgendwo anders benötigt werden. Wenn ich das alles mit Drähten und Schieberegistern direkt mache wird mir aber der Verdrahtungsaufwand zu unübersichtlich. Daher wäre so ein zentrales "Datenspeicher-VI" ideal.

Kann ein VI parallel gleichzeitig mehrmals auf ein SubVI zugreifen? Ich hatte bisher gedacht dass da nur ein einmaliger Zugriff möglich ist. Ansonsten versteh ich das mit dem Erroreingang so, als dass dieser den mehrfachen Zugriff unterbindet. Aber das könnte ich dann ja auch mit einem Flag im SubVI ebenfalls erreichen, dass einfach bei Aufruf und verlassen des SubVI gesetzt bzw wieder entfernt wird.

(26.07.2011 16:32 )flattervieh schrieb:  Nachdem ich letzt hier etwas über FGVs gelesen habe, vorallem dass dadurch der Speicherverbrauch im Gegensatz zu globalen Variablen oder Property-Nodes geringer sein soll, habe ich mir jetzt ein kleines Konzept überlegt mit dem man das ganze auf beliebig viele Variablen aufblasen kann um dieses FGV-Array als Variablenspeicher für alle anfallen Variablen zu nutzen.

FGV und weniger Speicherverbrauch stimmt nicht unbedingt. Ein FGV hat jedoch andere Vorteile.

(27.07.2011 09:53 )flattervieh schrieb:  Kann ein VI parallel gleichzeitig mehrmals auf ein SubVI zugreifen? Ich hatte bisher gedacht dass da nur ein einmaliger Zugriff möglich ist.

Da liegst du richtig. Solange ein VI nicht als Reentrant definiert ist (was bei einem FGV eher weniger sinnvoll ist), kann nur 1x darauf zugegriffen werden. Trotzdem kannst du dir noch Race-Conditions erzeugen, wenn du die Abarbeitungsreihenfolge nicht per Code festlegst. Merke: Alles, was "parallel" im BD liegt, kann von LV auch parallel abgearbeitet werden.
Die sauberste Möglichkeit ist hierbei die Verwendung des Error-Clusters. Auf Sequenzstrukturen kann man (fast) immer verzichten.

Gruß, Jens

Durch die FGV habe ich aber endlich auch Variablen die ich nicht kreuz und quer verbinden muss.

Den Errorcluster verwendet ihr dann also um Race-Conditions zu verhindern. Das erreicht man ja an sich eigentlich durch jede Art von "Verdrahtung". Die Idee dazu den Errorcluster zu verwenden ist natürlich gut.

Dann werde ich mal schaun wie ich das in meine zukünftigen VI's einbauen kann.

(27.07.2011 10:14 )flattervieh schrieb:  Den Errorcluster verwendet ihr dann also um Race-Conditions zu verhindern. Das erreicht man ja an sich eigentlich durch jede Art von "Verdrahtung". Die Idee dazu den Errorcluster zu verwenden ist natürlich gut.

Genau, eigentlich geht jede "Verdrahtung", um eine Ablaufreihenfolge zu erzwingen, wo es nötig ist.

Es ist aber ein weit verbreiteter und auch guter Programmierstil, dafür immer zusätzlich den Error-Cluster zu nehmen. Dies ermöglicht auch eine Fehlerbehandlung (s. Beitrag von NWOmason).

Gruß, Jens

Hallo zusammen.
Das mit den Variant-Attributen hat mich erstmal ein bissl irritiert, aber nun hab ich das endlich verstanden. Mein VI kann nun sowohl numeric als auch string variablen speichern und ausgeben. Genau so wie es soll.
Was mir allerdings jetzt noch fehlt ist eine Möglichkeit ein Array ebenfalls zu speichern. Einfaches anschließen eines Array sorgt nur dafür, dass die Dimensionen des Array gespeichert werden.

Ich hab mal mein bisheriges VI angehängt, für den Fall dass jemand noch Verbesserungsvorschläge hat.
Ein Erroranschluss ist noch nciht vorhanden, wird aber noch folgen. Dann werd ich vermutlich auch Ein- und Ausgänge zu Clustern zusammenfügen.