LabVIEWForum.de - Lokale Variablen oder Property Node

LabVIEWForum.de

Normale Version: Lokale Variablen oder Property Node
Du siehst gerade eine vereinfachte Darstellung unserer Inhalte. Normale Ansicht mit richtiger Formatierung.
Hallo zusammen.
Ich bin gerade dabei ein VI zu entwickeln. Früher habe ich auf massiven Einsatz von lokalen Variablen gesetzt was inzwischen stark zurück gegangen ist. Jetzt habe ich eine State-Machine die mir innerhalb eines States mehrmals Werte in eine Tabelle schreiben soll. Ich möchte bei jedem Durchlauf den neuen Wert in die Tabelle schreiben und auch anzeigen lassen. Das Funktioniert auch einwandfrei. Die Tabelle selbst wird aber auch von einem anderen möglichen State beschrieben. Nun stellt sich mir die Frage ob an dieser Stelle die Verwendung einer lokalen Variable der Tabelle sinnvoller ist oder ein Property Node der Tabelle mitsamt dessen Reference wobei bei dem Property Node jeweils der aktuelle Wert in die Tabelle geschrieben wird.

Im Prinzip wurde die lokale Variable durch eine Reference + einen Property node ersetzt.

Welche Vor- oder Nachteile kann solch ein Konstrukt haben gegenüber lokalen Variablen? Denn diese Property Nodes können ja genauso wie lokale variablen auch im kompletten VI verstreut sein. Und gerade diese "unverkabelte" Verteilung ist ja eigentlich der größte Kritikpunkt der lokalen Variablen.

Grüße
flattervieh
Ganz klare Aussage:
Solange es nur um das Setzen eines Wertes geht: lokale Variable!
Setzen per PropertyNode ist nämlich noch langsamer und erzwingt auch immer ein Frontpanel-Update.

Innerhalb einer Statemachine ist das auch erlaubt, denn hier kann ja immer nur ein State aktiv sein. Somit keine Race-Condition.

Anders sieht es aus, wenn du sowieso noch irgendeine Eigenschaft änderst, dann PropertyNode aufziehen und gleich alles machen.

Gruß, Jens
Was man unbedingt wissen muß ist, daß eine lokale Variable kaum langsamer ist als das direkte Schreiben/Lesen, ein Property-Node aber ist 100-200 mal langsamer. Allerdings ist davon auszugehen, daß das Langsame daran der Aufruf des Eigenschaftknotesn an sich ist und daß es keine Rolle spielt, wie viele Eigenschaften dieser dann hat. Deshalb ist überhaup nichts dagegen einzuwenden, dass, wenn der Eigenschaftsknoten wegen anderer Eigenschaften sowieo aufgerufen werden muß, dann auch die Eigenschaft "Wert" anstelle eine lokalen Variablen mit verwendet wird.

Der Eigenschaftsknoten ist weniger in Verruf als die Lokale Variable, aber nur deshalb, weil er Fehleranschlüsse hat und somit etwas einfacher (ohne zusätzliche Struktur) eine Datenabhängigkeit hergestellt werden kann. Bei eine State-Machine wird aber immer nur ein State ausgeführt. Wenn nicht gerade mehrere lokale Variable in einem State verwendet werden, dann dürfte das Problem von Wettlaufeffekten beherrschbar sein.

Ich gestehe, daß ich den Eigenschaftsknoten "Wert" gern in Verbindung mit SubVIs verwende. Wenn im SubVI z.B. ein Variable editiert werden soll, braucht man normalerweise zwei Anschlüsse (Ein- und Ausgang) - oder aber nur einen Referenzanschuß.

Bei Dir würde ich sagen, es kommt alles darauf an, wie zeitkritisch Dein Programm ist. Die Verwendung vom Referenzen in den States bietet die Möglichkeit, ganz leicht Sub-VIs zu erstellen. Das würde ich dann auch machen. Das Programm wird übersichtlicher, weil besser modularisiert.

Die entscheidende Frage, die man hätte am Anfang stellen sollen, ist aber die: Warum nicht Shift-Register verwenden, um damit Lese- und Schreibzugriff auf eine Variable in allen States zu haben? Normalerweise ist das - und nichts anderes - die optimale, allgemein akzeptierte Lösung.
Referenz-URLs