FGV Funktionale Globale Variable

Zitat:vielleicht mache ich später mal ein Bsp, eine Variante mit FGV, eine mit globalen Variablen.

das wäre sicher lustig ...äh, ich meine "hilfreich":D

Anzeige

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

Combobox ist im Zweifel nicht besser als ein String. Hilft auf kein StrictTypedef!

' schrieb:Bei FGVs muss 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.

Die Diskussion gibt's immer wieder... z.b. Link

Hallo,

wie versprochen ein extrem einfaches Bsp., würde man in der Realität wahrscheinlich nie so machen, da ich die Race-Condition quasi absichtlich eingebaut habe, aber es zeigt: FGV funzt wie gewünscht (soll heißen-der Wert von "appended Array" ist IMMER gleich "Numeric" und "Numeric 2"), globale Variable nicht.



  VglFGVGlobal.vi (Größe: 28,24 KB / Downloads: 780)


  GlobalSpeicher.vi (Größe: 4,83 KB / Downloads: 536)


  FGVSpeicher.vi (Größe: 24,97 KB / Downloads: 643)


Gruß, Jens

' 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?

Jens hat's schon erwähnt, LabVIEW arbitriert das ganz einfach für Dich. Du brauchst da keinerlei Semaphoren, Events oder was auch immer zu verwenden wie das bei anderen Programmiersprachen üblich ist.

Zitat: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....

Wenn Du die FGV natürlich nur als dumme globale Variable verwendest hast Du recht. Aber die Idee ist halt eben, dass Du nicht nur ein "Get Value" und "Set Value" hast und dann die verschiedenen Operationen in Deinem Diagramm jeweils immer wieder selber implementierst sondern dass Du - als einfaches Beispiel - "Increment" und "Decrement" Methoden hast, die das Inkrementieren und Dekrementieren des Wertes innerhalb der FGV machen. Das hat mehrere Vorteile:

- die Operation ist atomar, da LabVIEW andere Aufrufer blockiert bis der aktuelle Aufruf beendet ist
- man implementiert die Operation jeweils nur einmal und wenn man etwas daran ändern will (oder am Datentyp innerhalb der FGV) braucht man die entsprechenden Operationen nur an einem Ort anzupassen
- man erzeugt quasi Objekte die die Daten und die Operationen darauf an einem Ort zusammenfassen (ja das kommt OOP schon sehr nahe ist aber noch nicht wirkliches OOP, da man damit noch keinerlei Vererbung, Überladen und anderes OOP Firlefanz zur Verfügung hat). Es ist quasi die "Poor mans" Implementation von OOP.

Danke Jens für das coole Beispiel. Ziemlich interessant des mal zu sehen

Danke auch rolfk, für deine Erläuterungen.

War ein Zeit lang abgetaucht und lese jetzt diesen Thread das erste Mal, und meine Frage ist: Sollte man nach 25 Beiträgen nicht langsam mal erwähnen, daß bei regelmäßig erzeugten Daten FGVs oder globale Variablem zum Datenaustausch zwischen verschiedenen VIs oder Schleifen absolut nicht die erste Wahl sind?
Das Problem ist hier doch die fehlende Synchronisation zwischen Datenerzeugung und Datenempfang. D.h. wenn ich eine FGV lese weiß ich nicht, ob das immer noch der alte, bereits schon mal gelesene Wert ist, oder ob ein neuer Wert vorliegt. Und genau so beim Schreiben: hier weiß man nicht, ob der vorher geschriebene Werte bereits abgeholt wurde oder nicht. Natürlich kann man zusätzlich eine Statusvariable für das korrekte Handshaking in die FGV einpflegen, aber wozu das, wenn es diese schönen Queues und Melder gibt?
Meines Erachtens sind FGV eher geeignet für solche Werte, die sich nicht ständig aktualisieren. Aber für alles, was nach Erzeuger-Verbraucher-Struktur schreit - und das Projekt von cabua schreit nach meinem Gehör danach - sollte man doch besser Melder oder Queues benutzen.

Hi,

mein Problem ist die FGV.. Habe alle Beiträge durchgelesen. Leider nicht mit dem Verständnis-Gewinn wie erhofft.
Bin gerade dabei eine FGV zu implementieren und muss gestehen das es nicht so einfach ist.

In der FGV möchte ich eine Datensicherung integrieren. Diese soll dann in einem bestimmten Intervall aufgerufen werden um Messdaten zu speichern. Prinzipiell kenne ich den Aufbau aber realisieren kann ich's trotzdem noch nicht.

Gebe ich jetzt die Messdaten im Init Case mit und sichere sie im Set Case? Oder nehme ich mir die Daten im Get Case und sichere sie im Set Case? Was mach ich aber dann im Init?

lg

Hallo Ria,

eine FGV ist erst einmal ein Datenpuffer wie eine normale globale Variable: man nutzt sie zur (programminternen) Datenspeicherung/-pufferung. Über das F in FGV kann man aber weitere Funktionaität drumherum programmieren...

Zur Frage:
- "INIT" sollte den Datenpuffer initialisieren. Hier kann man entweder einen Defaultwert vorgeben oder auch eine Datei auslesen, die die Werte für die Initialisierung enthält.
- "SET" sollte neue Werte in den Datenpuffer übernehmen.
- mit "GET" holt man sich üblicherweise den aktuellen Wert aus dem Datenpuffer.

Zitat:In der FGV möchte ich eine Datensicherung integrieren.

Ich nehme an, du willst in "regelmäßigen" Intervallen die Daten in eine Datei schreiben.
- Man könnte hier z.B. einen Zähler für die SET-Aufrufe integrieren und nach jedem 10ten SET die Daten in eine Datei speichern.
- Man könnte aber auch mit einem Zeitstempel arbeiten und immer, wenn ein bestimmtes Zeitintervall vergangen ist, die Daten speichern.
- Man könnte einen zusätzlichen "SAVE"-Befehl implementieren, den die aufrufende Applikation nutzt, um Daten gezielt zu speichern...

    Hab ich das jetzt so richtig verstanden?

Hallo Ria,

das sieht schon ganz gut aus.
- Im GET-Case würde ich noch irgendwelche Anzeigeelemente vorsehen - wozu sonst eine FGV, wenn du deren Werte nirgends abfragen kannst?
- Anzeige- und Bedienelemente (In/Out) würde ich immer außerhalb der Loop platzieren...