Wenn dein Problem oder deine Frage geklärt worden ist, markiere den Beitrag als "Lösung",
indem du auf den "Lösung" Button rechts unter dem entsprechenden Beitrag klickst. Vielen Dank!
Ich versuche gerade zu verstehen, wie eine funktionale globale Variable genau funktioniert. In meinem Lehrbuch "Einführung in LabView" von W. Georgi ist leider nur ein kleines Bild dazu vorhanden, auch habe ich versucht, einige Beiträge hier zu verstehen, aber es hat noch nicht so ganz geklappt.
Mein Problem liegt darin - eine FGV ist - so wie ich es verstanden habe - keine wirkliche globale Variable, sondern ein VI mit einer while-Schleife mit einem case, der zwei Befehle kennt, z.B. "Schreiben" und "Lesen". Auf dem Frontpanel hab ich ein Enum mit den beiden Befehlen als Bedienelement. Dann hab ich ein Bedienelement und ein Anezigeelement, beide vom gleichen Typ, z.B. einen String, die ich Eingang und Ausgang nenne.
Jetzt rufe ich das VI FGV einmal von einem übergeordnetem VI auf, setze eine Variable und den Enum-Befehl "Schreiben", dann wird das VI FGV wieder beendet. Rufe ich nun an einer anderen Stelle das VI FGV wieder auf mit dem Befehl "Lesen" - da verstehe ich grad etwas nicht - bleibt das VI - trotzdem es einmal beendet wurde, noch mit dem Wert im Speicher bestehen?
Bei Signalgraphen hatte ich früher manchmal das Problem, dass Anzeigeninhalte da blieben. Entweder konnte ich die Historie im Eigenschaftsknoten löschen oder bei Neustart den Haken "Bei Neustart Anzeigeninhalte löschen" setzen. Darf ich diesen Haken bei einer FGV nicht setzen?
Über eine Antwort würde ich mich sehr freuen.
Anzeige
29.04.2013, 16:27 (Dieser Beitrag wurde zuletzt bearbeitet: 29.04.2013 16:28 von jg.)
Ein nicht initialisierte Shift-Register behält den Wert seit dem letzten Aufruf des VIs - zumindest solange es im Speicher/RAM ist. Das sollte eigentlich zum Verständnis langen.
(29.04.2013 15:47 )Hasenfuss schrieb: Mein Problem liegt darin - eine FGV ist - so wie ich es verstanden habe - keine wirkliche globale Variable, sondern ein VI mit einer while-Schleife mit einem case, der zwei Befehle kennt, z.B. "Schreiben" und "Lesen". Auf dem Frontpanel hab ich ein Enum mit den beiden Befehlen als Bedienelement. Dann hab ich ein Bedienelement und ein Anezigeelement, beide vom gleichen Typ, z.B. einen String, die ich Eingang und Ausgang nenne.
Stimmt nur bedingt. Du kannst auch mehr als 2 Befehle haben, und der Ein- und Ausgang müssen auch nicht identisch sein.
(29.04.2013 15:47 )Hasenfuss schrieb: Jetzt rufe ich das VI FGV einmal von einem übergeordnetem VI auf, setze eine Variable und den Enum-Befehl "Schreiben", dann wird das VI FGV wieder beendet. Rufe ich nun an einer anderen Stelle das VI FGV wieder auf mit dem Befehl "Lesen" - da verstehe ich grad etwas nicht - bleibt das VI - trotzdem es einmal beendet wurde, noch mit dem Wert im Speicher bestehen?
s. oben.
(29.04.2013 15:47 )Hasenfuss schrieb: Bei Signalgraphen hatte ich früher manchmal das Problem, dass Anzeigeninhalte da blieben. Entweder konnte ich die Historie im Eigenschaftsknoten löschen oder bei Neustart den Haken "Bei Neustart Anzeigeninhalte löschen" setzen. Darf ich diesen Haken bei einer FGV nicht setzen?
s. oben, der Zwischenspeicher ist das Shift-Register, nicht die Controls.
Allgemein: FGVs sind der erste Zugang zu objekt-orientiertem Programmieren in LabVIEW. Vgl. dazu auch die Folien, auf die dich Gerd heute hingewiesen hat.
Gruß, Jens
Wer die erhabene Weisheit der Mathematik tadelt, nährt sich von Verwirrung. (Leonardo da Vinci)
!! BITTE !! stellt mir keine Fragen über PM, dafür ist das Forum da - andere haben vielleicht auch Interesse an der Antwort!
Wenn ich die "einfachste" Form einer FGV habe - also Lesen/Schreiben (ggf. noch Init) - werden dann die Laufzeitprobleme damit schon "behoben", oder erst dann, wenn ich noch einen "Schutz" einbaue, z.B. so eine Semaphore und wenn z.B. Lesen aufgerufen wird und parallel dazu Schreiben von einem anderen VI?
Ich würd gern irgendwie anhand eines guten Beispiels das verstehen. Der Hinweis mit den Folien ist toll, aber ich glaub für mich noch etwas zu komplex mit den Inhalten, darum halte ich mich an den einfachen Ratschlag - lieber nicht an den Prioritäten beim Aufruf rumschrauben. In dem Buch was ich hab, stehen zu der FGV nur ein paar kleine Sätze, mehr nicht und wenn ich hier in dem Forum danach suchte oder so, da bin ich noch nicht so schlau raus geworden, darum bin ich mir jetzt auch noch nicht sicher, ob mit einfachen Beispiel wie in dem Schaubild von mir, das schon behoben ist. Ich habe auch mal etwas mit einer so einer Semaphore gesehen, wo dann eine Meldung zurückkam an das übergeordnete VI, dass die Variable grade blockiert ist bzw. von einem anderen Prozess genutzt wird.
Zitat:werden dann die Laufzeitprobleme damit schon "behoben", oder erst dann, wenn ich noch einen "Schutz" einbaue
Eine FGV hat keine Laufzeitprobleme im Sinne von RaceConditions:
Das VI einer FGV ist (per Default) so eingestellt, dass es nur einmal im Speicher ist und nicht parallel aufgerufen werden kann. Wenn ein Aufruf gerade erfolgt, müssen andere Aufrufe warten, bis die FGV abgearbeitet ist. Also: keine RaceConditions!
Du hast "Laufzeitprobleme", wenn die FGV zu lange für die Abarbeitung benötigt, z.B. durch Dateizugriffe oder sonstige Operationen mit TimeOuts. Da muss man dann aufpassen, dass man sich nicht parallele Threads blockiert.
Grundaussage in den verlinkten Folien:
Setze das FGV-VI auf Aufruf-Typ "Subroutine", um möglichst viel Overhead zu vermeiden. Du verlierst dabei aber die Option des Debuggens, also erst nach Abschluß der FGV-Entwicklung dran rumspielen.
