' schrieb:Oliver Frank hat das sehr schön und kurz und knapp ausgedrückt.
Abgesehen von diesem Aspekt haben lokale Variablen und Globale noch in grösserem Masse, zwei grundlegende technische Probleme. Da LabVIEW inherent multithreading ist muss jeder Zugriff auf eine lokale/globale Variable geschützt sein. Das könnte durch komplettes Locking geschehen während der Lebensdauer eines Drahtes der von einer solchen Variablen kommt, aber würde dadurch die parallele Ausführung des Programms schwer einschränken bis ganz unmöglich machen. Deshalb hat LabVIEW dafür entschieden um bei jedem Zugriff auf so eine Variable eine komplette Kopie davon anzulegen. Das ist für Skalarwerte keine Katastrophe aber sobald man da ein multi-Megabyte Array hineinstellt ist es eine garantierte Methode um das Programm dahinkriechen zu lassen. Alles was ich dazu sagen kann ist: selber schuld wenn jemand das so macht.
Das gravierendere Problem ist meines Erachtens aber die Möglichkeit um Raceconditions zu verursachen die schwer zu debuggen sein können. Sobald auf eine globale oder lokale Variable an mehr als einem Ort geschrieben werden kann, sind solche Race-Conditions immer gleich um die Ecke potentiel anwesend. Und das Gemeinste ist dass es durch die quasi-parallele Ausführung von LabVIEW Nodes und die Unvorhersagbarkeit davon in welcher Reihenfolge diese ausgeführt werden, manchmal funktionieren kann und durch minimalste A"nderungen am VI, die eine Recompilation des VIs verursachen plötzlich nicht mehr.
Zitat: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.)
Goto in C ist nicht grundsätzlich falsch. Aber wenn es für etwas anderes als frühzeitige Beendung eines Codeabschnittes gebraucht wird, dann ist es immer eine Indikation dafür, dass der Programmierer von saubererem Programmieren keinen Schimmer hat.
try/catch als Exception handling ist ja eigentlich auch nicht so viel anders, nur etwas mehr formalisiert.
Rolf Kalbermatter
Hallo,
ich kann da auch etwas aus eigener Erfahrung berichten. Ich habe vor ca. 1/2 Jahr angefangen mit LabVIEW zu programmieren. Am Anfang habe ich auch ständig lokale Variablen benutzt. Habe aber jetzt beim überarbeiten der Software festgestellt, dass sich viele davon durch normale Verbindungen ersetzen lasse. Dadurch konnte man sich gleich noch einige Sequenzen sparen:-)
Jetzt verwende ich sie in meinem Programm nur noch an 2 Stellen: Zum übergeben von Daten zwischen parallel ablaufenden Schleifen und anstatt Schieberegistern in der Hauptwhile-Schleife, das könnte man eigentlich auch weglassen, aber die ewiglangen quervebindungen in der Hauptschleife sorgen nicht gerade für mehr Übersichtlichkeit.
MfG Jeffrey
Zu 1) Man kann die Tools aus der Synchronisationspalette benutzen, sonst hast du Race Conditions
Zu 2) Alle Schieberegister zu einem Cluster zusammenfassen, dann hast du nur eine einzige Verbindung
' schrieb:Zu 1) Man kann die Tools aus der Synchronisationspalette benutzen, sonst hast du Race Conditions
Zu 2) Alle Schieberegister zu einem Cluster zusammenfassen, dann hast du nur eine einzige Verbindung
zu 1.) habe ich gemacht, aber trotzdem danke für den tipp
zu 2.) gute idee, muss ich mir nachher mal anschauen, problem ist dann aber nur, dass ich die fp-elemente in dieses cluster pcken muss, oder doppelte anlegen muss
mfg jeffrey
Wie sieht es mit der Verwendung der Sequence Local aus? Diese kann man bei den Sequenzen benutzen. Mir ist aufgefallen, dass wenn ich diese zur Übergabe verwende die Sequenzen schneller abgearbeitet werden. Oder täusche ich mich da?
Edit: Sorry hatte hier etwas gepostet was für einen anderen Thread gedacht war.
' schrieb:Wie sieht es mit der Verwendung der Sequence Local aus? Diese kann man bei den Sequenzen benutzen. Mir ist aufgefallen, dass wenn ich diese zur Übergabe verwende die Sequenzen schneller abgearbeitet werden. Oder täusche ich mich da?
Also multiframe Sequenzen sind eigentlich auch etwas das man nicht tun sollte. Die sind nur nötig wenn man keine sauber programmierten SubVIs benützt, die durch entsprenchende Datanabhängigkeit etwa durch den Error Cluster automatisch in der richtigen Reihenfolge ausgeführt werden. Die Locals in einer Sequence sind wahrscheinlich wirklich effizienter dann eine gewöhnliche Lokal aber fördern die Übersichtlichkeit des Programmes nicht. Ein weiterer Nachteil ist dass die Sequence Locals nur einmal beschrieben werden können, so dass man bei einer grösseren Multiframesequenz schon bald mal zig Locals hat. Sicher wenn Error Clusters auf diese Weise geschlauft werden hat die Sequence eh absolut keinen Sinn, da eine korrekte Bedrahtung des Error Clusters automatisch auch die richtige Reihenfolge in der Ausführung erzwingt.
Zusammen mit Globals und Lokals sind Multiframesequenzen die Dinge die man in LabVIEW so viel als möglich vermeiden sollte. Die flache Sequenz ist manchmal sinnvoll und da nicht übereinander gelegt auch noch übersichtlich.
Rolf Kalbermatter