Schätze ich sehe den Wald vor lauter Bäumen nicht:
wenn ich in verschiedenen VIs gemeinsame Konstanden brauche ... ja da fällt mir nichts anderes ein als ein VI zu schreiben mit einem Ausgang.
Das kommt mir aber sehr ... gekünstelt vor.
Wie macht Ihr das?
Gottfried
Also für alle "Quasi-Konstanten" verwende ich globale Variable. Man kann sogar sagen, dass ich gobale Variable ausschließlich dafür verwende, aber niemals zum Datenaustausch.
Beispiel: Ein Targetabstand, der konstruktionsbedingt ist, bei dem aber nicht ganz auszuschließen ist, dass er sich mal ändern kann.
Abspeicherung in INI-Textfile, zu Programmbeginn Einlesen in Globale Variable, die dann in allen SubVIs zur Verfügung steht. Ein Schreibzugriff auf die Ini-File ist für diesen Parameter nicht erforderlich. Falls sich der Parameter ändert, wird das mit einen Texteditor gändert.
Man kann aber auch eine echte Konstante bei der Initialisierung des Programms in eine GB schreiben. Bei Änderung des Werte muss man dann nicht an mehreren Stellen (fehlerträchtig) den Wert ändern.
Tip: Der "Flächenverbrauch" einer GB im BD ist proportional der Namenslänge --> möglichst kurze Namen verwenden.
Edit: Bei der genauen "Textanalyse" deines Beitrages komme ich zu dem Schluss, dass Du der Manie verfallen bist, GBs zu vermeiden und grundsätzlich FGVs zu verwendeen. Diese Krankheit kommt davon, dass Du zu viel hier im Forum gelesen hast, wo diese Auffassung gepflegt wird. Lass Dich davon nicht anstecken!
Hallo,
Zitat:Bei der genauen "Textanalyse" deines Beitrages komme ich zu dem Schluss, dass Du der Manie verfallen bist, GBs zu vermeiden und grundsätzlich FGVs zu verwenden. Diese Krankheit kommt davon, dass Du zu viel hier im Forum gelesen hast, wo diese Auffassung gepflegt wird. Lass Dich davon nicht anstecken!
Da muss ich doch glatt einsteigen!
Im Ernst:
Ich befürworte FGVs für solche Anwendungen, weil:
- ich zusammengehörende Einstellungen/"Konstanten" bündeln kann
- ich in der FGV gleich noch die passende (!) Lade-/Speicherroutine unterbringen kann, ohne dafür andere VIs pflegen zu müssen
- ich die FGV in mehreren Projekten verwenden kann, ohne mir Gedanken über die enthaltenen Größen zu machen
Beispiel:
Wir haben mehrere Prüfstände, die recht ähnliche Software nutzen: Hardware-Treiber unterscheiden sich, aber Anzeige/Logging/Setup/usw. sind identisch. Alle allgemeinen Einstellungen (Prüfstandskennung, Pfade zum Laden und Speichern von Dateien, etc.) landen in einer FGV. Ein Aufruf der FGV mit dem Parameter "load settings" lädt die zuletzt genutzten Einstellungen aus einer INI-Datei, ein entsprechender Aufruf der FGV am Programmende speichert die Settings. Vor dem Start der Messung darf der User nochmal die Settings überprüfen und ggfs. abändern, danach können alle Programmteile die (dann statischen) Settings nutzen. Die FGV wurde einmal entwickelt/getestet und nun auf allen unseren Prüfständen genutzt...
Diese Kapselung und Wiederverwendbarkeit ist es, die mich immer wieder dazu treibt, FGVs zu empfehlen...
D.h. nicht, dass ich keine globalen Variablen nutze - aber fast nur in dem recht klein abgesteckten Rahmen der "einmaligen" Nutzung ("nur ein Projekt"/"nur ein spezieller HW-Treiber mit verteilten VI-Aufrufen"). Und bei anderen Anforderungen mag man auch daran denken, LVOOP zu nutzen, um noch mehr oder viele unterschiedliche Daten in einem Objekt (mit entsprechenden Eigenschaften/Methoden) zu bündeln...
Danke - super .... aber was ist ein GB?
Gottfried
(26.01.2013 19:55 )gottfried schrieb: [ -> ]Danke - super .... aber was ist ein GB?
Nachdem ich drei Mal die Bezeichnung "Globale Variable" ausgeschrieben habe, hatte ich die Faxen dicke und habe einfach GB gechrieben. Aber Du hast Recht, eine gängige Abkürzung, die keiner Erklärung bedarf, ist das nicht.
Und wo wir schon dabei sind. Was sind "FGVs"?
@Gerd
Ich lehne ja FGVs nicht ab und in den Szenarien Du Du beschreibst ( - die aber nicht richtig zu Gottfrieds Frage passen -) sind FGVs absolut sinnvoll. Es geht mir nur darum, dass hier im Forum manchmal globale Veriable rundweg abgelehnt werden und FGV grundsätzlich als die bessere Alternative beschrieben werden - so, als ob NI dämlich gewesen wäre, dass es GVs überhaupt einführte. Das führt dann dazu, dass Gottfried als fleißiger Forumsleser hier vielleicht seine persönliche Gehirnwäsche erfahren hat und er demzufolge gar nicht mehr auf die Idee kommen kann, dass für sein kleines Problem eine globale Variable die einfachste Lösung sein könnte.
@Ludwig:
- Die INI-Dateien hast du selbst ins Spiel gebracht.
Zitat:Man kann aber auch eine echte Konstante bei der Initialisierung des Programms in eine GB schreiben. Bei Änderung des Werte muss man dann nicht an mehreren Stellen (fehlerträchtig) den Wert ändern.
Bei einer FGV hat man einen INIT-Case. Um den zu erreichen, muss man nicht erst im MainVI (oder in einem Init-VI) nachschauen, wie dort der Wert vorgegeben wurde, sondern man öffnet einfach die FGV, mit der man ja sowieso gerade arbeitet. Mit Ctrl-Doppelklick landet man direkt im BD - und findet dort den einen Ort, wo eine Konstante definiert wird...
Zitat:Tip: Der "Flächenverbrauch" einer GB im BD ist proportional der Namenslänge --> möglichst kurze Namen verwenden.
Die "kleinste" meiner FGVs hat ein Icon mit 8*32 Pixel Größe. Da der Standard-Aufruf auf "READ" gesetzt ist, wird kein weiterer Platz benötigt. Nur beim INIT (u.a.) wird etwas mehr Platz für das begleitende Enum benötigt...
Du siehst, man kann diese Argumente sowohl für globale Variablen als auch FGVs anwenden.
Ich weiß nicht mal mehr, wie man globale Variablen anlegt.
Da müsste ich erst mal in meinen Unterlagen schauen, oder hier im Forum, da habe ich glaub' mal eine Anleitung gemacht.
Für den Fall nehme ich jedenfalls immer FGV's, aber wie Lucki schon sagt, spricht nichts gegen eine globale Variable. Wenn Du aus dem Stehgreif weißt, wie man die anlegt, dann kannst Du sie ja verwenden. Bevor Du aber lange nachlesen musst, wie es geht, dann mach's mit FGV's. Das ist meiner Meinung nach wesentlich einfacher....
@Lucki: Da passt übrigens auch wieder die Geschichte mit dem Fuchs und den Trauben.
Gruß Markus
EDIT:
Hier ist übrigens meine Anleitung (6 1/2 Jahre alt). Weiß aber nicht, ob das heute auch noch so geht.