LabVIEWForum.de

Hi,
möchte mal ganz prinzipiell fragen wie Ihr es mit den lokalen Variablen habt. Wenn Ihr ein relativ großen bzw. komplexes Programm habt, benützt Ihr dann zur besseren Übersicht viele lokale Variablen oder verbindet Ihr alles was irgendwie geht auf konventionelle Art und Weise?

Ich habe bis jetzt eben wegen der besseren Übersicht recht viele lokale Variablen benützt, nun hat mir jemand gesagt (auch noch Student und grün hinter den Ohren ) dass das nicht so gut ist, er meint dass aufgrund der Variablen die Übersicht erst recht leidet da man nicht immer sieht wo die Quelle sitzt, ausserdem meinte er dass die ganzen Variablen LAbView recht schnell ausbremsen.
Ich wiederum denke dass durch das wegfallen von vielen Leitung man schon sehr viel mehr Übersicht erreicht, weis nun aber auch nicht so recht was ich tuen soll - deswegen wollt ich mal wissen wie das bei Euch aussieht!

Gruß Chriz

Hallo Chriz,

ich persönlich benutze sehr wenige lokale und gar keine globalen Variable. Zwar hatte ich noch nie Probleme mit Race-Conditions (oder ich habe es noch nicht gemerkt), trotzdem benutze ich Drähte, Shiftregisters und was mich (im Bezug auf die Übersichtlichkeit und besondere Vorteile) sehr begeistert hat - Synchronisationspalette fast im vollen Umfang.
Ich habe mal ein Programm von Inder korrigiert und habe eine Woche gebraucht nur um die Übersicht zu bekommen, wobei das Programm eigentlich nichts besonderes machte. Das Problem lag daran, dass die in einem Team aus 15 Mann arbeiteten und getrennte Module für das Projekt programmierten. Komischerweise sah ich im HauptVI ca. 20 19" Bildschirme, die ich auf 5 reduziert habe. Die haben mehrere Eventstructures benutzt(die man vereinigen konnte) und eine Unmenge von lokalen Variablen, die die ganze Übersichtlichkeit töteten. Soviel dazu.

i2dx weiss vielmehr zum Thema, frage ihn. Ich hatte sogar einen Thread dazu gestartet, den du mit Suchfunktion finden kannst.

Also meine Meinung: negativ bei grossen Projekten, neutral bei kleinen.

Gruss, Eugen

Also ich benutze LabVIEW seit fast 10 Jahren, und ich habe in Bezug auf die Verwendung lokaler Variablen drei Phasen hinter mir, wobei Du dich gegenwärtig in Phase 2 befindest:
Phase 1: Lokale Variablen verwenden
Phase 2: Verunsicherung und seltenere Verwendung lokaler Variablen. Grund der Verunsicherung sind nicht Reinfälle bei der Programmierung, sondern weil immer und überall vor der Verwendnung lokaler Variablen gewarnt wird.
Phase 3: Augen und Ohren zuhalten, wenn vor der Verwendung gewarnt wird, und lokale Veriable weiter verwenden.

Natürlich gebe ich einem Shift-Register den Vorzug, wenn es beide Alternativen gibt. Was ich meine ist, daß ich lokale Variable auch "unnötigerweise" verwende, und zwar zu dem einzigen Zweck, mir einen unübersichtlichen "Drahtverhau" im Blockbild zu ersparen.
Argumente:

Zitat:dass die ganzen Variablen LAbView recht schnell ausbremsen.

Mag sein oder auch nicht, mir ist jedenfall noch kein Programm untergekommen, bei dem das relevant sein könnte. Mich jedenfalls betrifft das nicht.

Zitat:dass aufgrund der Variablen die Übersicht erst recht leidet da man nicht immer sieht wo die Quelle sitzt

Das Gegenteil ist der Fall: Kein Mensch studiert ein LV-Programm auf dem Papier, sondern immer vor dem PC. Umständlich ist es, eine Leitung in einem Gewirr von Leitungen bis zur Quelle zurückzuverflogen. Ein rechter Mausklick auf die Lokale Variable führt hingegen sofort zur Quelle. Außerdem steht der Name der Quelle in der lokalen Variablen, an der Leitung steht nichts. Die Funktion dieses offensichtlich unsachliches Argument besteht lediglich darin, ansonsten schwache Argumente durch Aufzählung eines weiteren Argumentes zu stützen.

Nun aber zur Hauptsache: Was soll man LabVIEW-Anfängern zur Verwendung Lokaler Veriablen raten?
Contra: Finger weg! Es passieren ganz unvorhergesehene Dinge.
Pro: Die unvorhergesehenen Dinge werden sich zwar nicht vermeiden lassen, aber die Analyse dieser Fehler und das Ziehen der entsprechenden Lehren daraus ist in jedem einzelnen Fall ein gewaltiger Sprung für des wahre Verständnis des datengesteuerten Programmablaufes von LabVIEW. Um diese Struktur richtig beherrschen zu lernen, gibt es fast kein besseres Mittel als die "experimentierfreudige" Verwendung lokaler Variablen. Sie sind eine Herausfordrung, es ist eine Art Wette, die da lautet: Habe ich LabVIEW so gut im Griff, daß, wenn ich an dieser Stelle diese loklale Variable verwende, genau das passiert, was ich erwarte? Ja oder Nein? Schon weil das Spiel spannend ist, kann man der Versuchung erliegen, es immer wieder mal wieder zu spielen.



Gruß Chriz[/quote]

Ich habe zwar erst vor drei Monaten mit LabVIEW angefangen, denke aber dass man - nach allem was ich bisher in diversen Foren dazu gelesen habe - lokale Variablen in LabVIEW ähnlich behandeln sollte wie die allseits verteufelten gotos in C und anderen textbasierten Programmiersprachen:
Es gibt durchaus Situationen, wo sie Sinn machen und dem eigentlichen Programmablauf dienlich sind; übertreibt man es aber, kommt ein unübersichtlicher Quark dabei raus.

Um diesen Standpunkt zu stützen, verweise ich mal auf die "Spielwiese der Großen", auf das LAVA-Forum; hier können einige Diskussionen zu dem Thema nachgelesen werden.

Gruß, Niko

Also ich verwende "Lokale Variablen" nur um Werte von Bedienelementen programmatisch zu veraendern.
Allerdings finde ich auch, dass es dadurch teilweise unuebersichtlich wird.
Um die Unuebersichtlichkeit zu vermeiden verwende ich dann "Funktionale Globale Variablen".

Seht Euch mal die angehaengten Texte von NI dazu an.

Gruss,
Marko

Hi chris,

der Harken an den lokalen und globalen Variablen ist einfach die Übersichtlichkeit.

Das ganze Thema kommt aus dem Bereich der Softwarequalitätssicherung.
Ich habe damals im Studium eine Vorlesung dazu gehabt, und komme nun seit über fünf Jahren ohne aus.
Variablen erhöhen die Kopplung der einzelnden Module untereinander.

Sicher mag das bei kleinen Applicationen noch alles übersichtlich sein, aber spätestens, wenn du (war in unserer Firma der Fall) zu einer Anlage ein LV Programm geliefert bekommst, an dem du noch Ergänzungen machen sollst.
Aber erstmal zwei Wochen brauchst, um die Stelle zu finden, wie eine Anzeige ihre Werte erhält, dann möchtest du dem Programmierer halt nunmal den Hals umdrehen. (Der Wert kam halt über eine Globale und die dadurch enstandene Kopplung war nicht zu ersehen... :evil: )

Und wenn Lucki schreibt, die Übersicht geht ihm bei dem Drahtwirrwar verloren, dann schlage ich vor Funktionalität in Sub-VIs auszugliedern.
Man kann bei LabVIEW ohne Probleme viele Regeln von SD (Structured Design) anwenden.

Gruß
Oliver

ich schließ mich da der Meinung von Oliver, marker und Azmodan an.

man sollte locals und globals nicht verteufeln, sie können einem das Leben stark erleichtern. Ansonsten zieht's mir bei der Aussage, dass Locals die Übersicht erhöhen die Schuhe aus.

Prinzipiell gilt: das Paradigma von LabVIEW ist die Datenflussorientierung. Locals & Globals umgehen dieses Prinzip und sollten desshalb sparsam eingesetzt werden. Wer gerne und viele Locals & Globals einsetzt sollte IMHO besser zu C oder C++ wechseln.

Fazit: Im Sinne der Lesbarkeit, Reproduzierbarkeit und Sicherheit sollte man wenn möglich den Draht verwenden, logische Strukturen von Drähten in Cluster packen und SubVIs bauen.

Ich kotz jedesmal ab, wenn ich Code sehe (und im schlechtesten Fall bearbeiten muss) in dem 5 mal Stacked Sequences ineinandergeschachtelt sind, controls als "Datenspeicher" verwendet werden, die dann in den einzelnen States per Local gelese/geschrieben werden, wo man doch so schön ne state-machine bauen könnte mit ausreichend Shift registern ... den Mist sollte man den Entwicklern 5 Projekte später nochmal vorsetzen und was von nem sporadisch reproduzierbaren Bug berichten, sich dann genüsslich zurücklehnen und zuschaun, wie er an seinem eigenen Spaghetticode verzweifelt <eg>

diese Art von Programmierung funktioniert nur so lange, wie man "sein" Projekt im Kopf hat. Wenn man mal vergessen hat, welche local man wann & wo und warum schreibt, dann hat man (auch selber) keine Chanze mehr. Ich weiss wovon ich rede, ich meine D-Arbeit war in der Form programmiert

Grüße
CB