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!
das einzige, was ich dazu weiß ist, daß man die Verwendung von lokalen Variablen vermeiden sollte und statt dessen die Ausgänge von Sub-VIs wieder mit den Eingängen der nachfolgenden verbindet, bzw. im gleichen Atemzug auch die Verwendung von Sequenzen vermeidet (wo man dann im nachfolgenden Fenster wieder eine lokale Variable vom gleichen Objekt wie in einem vorhergehenden verwenden würde).
Ziel des ganzen ist, daß der Daten- bzw. Signalfluß erhalten und übersichtlicher bleibt.
Ob das ganze auch noch irgendwelche programmtechnische Hintergründe hat, wie z.B. Speicherbedarf etc., kann ich leider nicht sagen.
Also ich kenn mich ja mit LabVIEW noch nicht besonders aus, aber sonst kenne ich es das eine globale mehr Speicherplatz frisst als eine lokale, da die lokale erst initialisiert wird beim starten der Funktion etc.
Und was du meinst s200rs versteh ich nicht. lokale Variablen gelten doch gerade nur für ein VI, wieso sollte man die an ein weiteres VI abtreten anstatt eine globale zu verwenden? oder versteh ich da was komplett falsch?
Lokale Variablen benötigen Speicherplatz pro zu lesender Variablen. Wenn du also 27 Lokale Variablen hast, die gelesen werden sollen, so muss bei jedem Schreiben auf eine Lokale Variable - und beim Schreiben auf das Element - alles 28 mal gemacht werden. Ist die Variable ein aufwändiger Cluster oder gar ein Array, ist der Platzverbrauch entsprechend. Neben dem Speicherbedarf ist da natürlich auch noch die Prozessorzeit, die - meistens unnötigerweise - verbraucht wird. Wahrscheinlich (Wahrscheinlich deswegen, weil ich mir um solche Sachen eigentlich keine größeren Gedanken mache) ist das Beschreiben dieser Lokalen Variablen noch komplizierter, da sie auch noch in unterschiedlichen Prozessorthreads liegen können, was ein thread-übergreifendes Speicherzugriffs-Handling benötigt. Und das ist nicht ohne.
Für viel wichtiger halte ich aber das Argument der Datenflußsteuerung. LV ist datenflußgesteuert. Und das heißt nun mal: Wire, Wire, Wire (Datenleitung, Datenleitung, Datenleitung). Alles mit Sequenzierung (Datenfluß ist nichts anderes) zu machen erleichtert außerdem die Lesbarkeit - erheblich.
Das (übermäßige) Benutzen von Lokalen Variablen hat außerdem den Nachteil: Wer lokale Variablen benutzt, benutzt auch alle anderen "Features" und Programmier-Konstrukte, die eigenlich nicht in eine Datenflußsteuerung gehören.
Jeder, der zur wahren Erkenntnis hindurchdringen will, muss den Berg Schwierigkeit alleine erklimmen (Helen Keller).
' schrieb:Und was du meinst s200rs versteh ich nicht. lokale Variablen gelten doch gerade nur für ein VI, wieso sollte man die an ein weiteres VI abtreten anstatt eine globale zu verwenden? oder versteh ich da was komplett falsch?
Nein, komplett falsch nicht.
Er meint ja (wahrscheinlich): Anstelle vom VI heraus in eine Lokale Variable schreiben, die dann selbst wieder als Eingang auf ein anderes VI geht, kann man gleich die beiden VIs verbinden, sodass mal die Lokale Variable (und demzufolge auch das Element, was hierfür notwendig ist) gar nicht braucht.
Im übrigen bin ich der Meinung, dass globale Variablen noch schlimmer sind als lokale.
Jeder, der zur wahren Erkenntnis hindurchdringen will, muss den Berg Schwierigkeit alleine erklimmen (Helen Keller).
Bei LabVIEW habe ich bisher beide auch gar keine gebrauchen können, wo das bei Programmiersprachen absolut unumgänglich war.
Poste doch mal dein VI, vielleicht lassen die Variablen sich einfach vermeiden und das Thema ist gegessen ^^
das Hauptproblem aus meiner Sicht besteht bei der Verwendung von Globalen- und Lokalen Variable in der Kopplung.
Diese gibt an, wie stark Funktionen miteinander Verknüpft sind. Aus SoftwareQS-Sicht ist eine Lose Kopplung anzustreben.
Lokale- und ganz besonders Globale Variablen verleiten nun aber einmal dazu die Lose Kopplung aufzubrechen. Gerade, wenn nachträglich Änderungen in ein bestehendes Konzept einfließen und diese nicht nochmals die Plannungsstufen durchlaufen.
' schrieb:Anstelle vom VI heraus in eine Lokale Variable schreiben, die dann selbst wieder als Eingang auf ein anderes VI geht, kann man gleich die beiden VIs verbinden, sodass mal die Lokale Variable (und demzufolge auch das Element, was hierfür notwendig ist) gar nicht braucht.
Im übrigen bin ich der Meinung, dass globale Variablen noch schlimmer sind als lokale.
@ weesnich, IchSelbst,
genau:
Habe mich da bißl schwer verständlich ausgedrückt , aber ich meine genau das, was IchSelbst geschrieben hat.
Als LV-Anfänger habe ich fast nur mit lokalen Variablen gearbeitet, macht sich aber u.a. schwierig bei der Fehlersuche, oder beim Verstehen von schlecht dokumentierten VIs.
und nochmal "genau:" :
Ich denke auch, daß globale Variablen schlimmer sind als lokale, ich verwende mittlerweile keine mehr.
' schrieb:Aus SoftwareQS-Sicht ist eine Lose Kopplung anzustreben.
Oliver Frank hat das sehr schön und kurz und knapp ausgedrückt.
Da will ich doch gleich noch was zu schreiben:
Die Funktionsfähigkeit eines Softwareprogrammes (SP) ist nicht zwangsläufig das wichtigste Kriterium, wie ein SP zu schreiben ist. Von Standpunkt der Funktionsfähigkeit aus gesehen, habe ich gar kein Problem mit lokalen und auch nicht mit globalen Variablen (LV kann das und soll das auch machen). Viel wichtiger ist heutezutage aber die Wiederverwendbarkeit sowie die Debugfähigkeit eines SP. Wiederverwendbarkeit bedeutet: Ich nehme ein Modul aus einem SP heraus und baue es in ein anderes SP ein. Wenn der Auswand der Intergration des Modules gegen Null geht oder nur sehr klein ist, ist das Modul gut und auch das (andere) SP. Hat das Modul aber nun globale (aber auch mit lokalen würde das so sein) Variablen, so muss in dem anderen SP auch die Variable (Anzeige- oder Bedienelement) ergänzt werden. Das kann einfach aber auch bis hin zu unmöglich sein: Was tun, wenn es in den neuen SP bereits ein Element gleichen Names gibt? Kommt es in dem neuen SP zu RaceConditions bei Verwendung der Variablen? etc.
Um noch mal die Worte von Oliver Frank zu bemühen: Je loser die Kopplung, desto besser. Je mehr lokale/globale Variablen, desto fester die Kopplung.
Im übrigen gilt das mit der Kopplung nicht nur für datenfluß-orientierte Programmiersprachen sondern auch für strukturierte und objektorientierte.
Zitat:Lokale- und ganz besonders Globale Variablen verleiten nun aber einmal dazu die Lose Kopplung aufzubrechen.
Wenn das mit dem Verleiten halt nicht immer so schön wäre ... (Überlegt euch mal es gäbe in LV noch einen goto. Ja, selbst der wird noch bei objektorientiert benutzt.)
Jeder, der zur wahren Erkenntnis hindurchdringen will, muss den Berg Schwierigkeit alleine erklimmen (Helen Keller).
, aber ich meine genau das, was IchSelbst geschrieben hat.
: