Variable ohne Element -einfach unsichtbar machen?

Hallo ihr,

eine ziemlich allgemeine Frage hätte ich an euch.

Wenn eine Variable benötigt wird, aber weder ein Bedien- noch ein Anzeigeelement gewünscht ist, wie geht man dann vor in LV? Wird einfach ein Bedienelement erstellt und unsichtbar gemacht und entsprechend lokale Variablen dieses Elementes erzeugt? Oder lassen sich Variablen unabhängig von Elementen erzeugen und verwenden?

Wie ist die gängige Vorgehensweise?

Danke!

Anzeige

Hallo catbull,

die "gängige" Lösung ist, einen Draht zu verwenden. Der Draht ist die Variable!

Ansonsten gibt es globale Variablen, notifier, queues, FGVs, neuerdings Channels, ...

(17.08.2018 21:46 )GerdW schrieb:  Hallo catbull,

die "gängige" Lösung ist, einen Draht zu verwenden. Der Draht ist die Variable!

Ansonsten gibt es globale Variablen, notifier, queues, FGVs, neuerdings Channels, ...

Drähte quer über Strukturgrenzen hinweg oder globale Variablen widersprechen allem an was ich programmiertechnisch glaube. Macht das Prinzip der Datenkapselung in LV etwa keinen Sinn? Aber ich bin mir auch sicher, dass du weißt wovon du redest...

Es fällt mir nur schwer vorzustellen, dass durch große Projekte meterlange Drähte verlegt werden. Wahrscheinlich kommen da die von dir genannten " notifier, queues, FGVs, neuerdings Channels," ins Spiel. Werde ich mir anschauen. Danke!

Oder ist Übersichlichkeit in größeren Projekten vielleicht nicht gerade eine Stärke von LabView?


Aber trotzdem wollte ich nochmal anders fragen: Ist es ein Anfängerfehler oder sogar ein No-Go, Elemente als reine Variablen zu missbrauchen indem sie unsichtbar gemacht werden oder sieht man es vielleicht durchaus wenigstens hin und wieder?

Hallo catbull,

ja!

In LabVIEW ist der Draht die Variable!
FP-Elemente dienen als Ein-/Ausgabe...

- Drähte müssen auch über Strukturgrenzen gehen: wie sollen sonst Daten in Schleifen rein/raus?
- wenn du meterlange Drähte benötigst, hast du dich zuvor nicht an den Styleguide gehalten...
- Datenkapselung ist durchaus sinnvoll, aber was hat das mit versteckten Anzeigeelementen zu tun?
- seit etlichen Versionen kannst du auch Drähten ein Label geben: dann bekommt die "Variable" auch einen Namen...

(17.08.2018 23:08 )catbull schrieb:  Drähte quer über Strukturgrenzen hinweg oder globale Variablen widersprechen allem an was ich programmiertechnisch glaube.

Erstens: So global kann man das nicht sagen - spricht: man kann das schon so machen.
Zweitens: Glauben ist in SW-Technik ganz schlecht. Glauben gilt mehr für Kirche ...

Zitat:Macht das Prinzip der Datenkapselung in LV etwa keinen Sinn?

Selbstverständlich !!
Datenkapselung, und wie sie alle heißen, die Programmiertechniken/Paradigmen, sind zuerst einmal unabhängig von der Programmiersprache. Sie sind in der einen oder anderen Sprache lediglich einfacher oder schwieriger umzusetzen.

Zitat:Es fällt mir nur schwer vorzustellen, dass durch große Projekte meterlange Drähte verlegt werden. Wahrscheinlich kommen da die von dir genannten " notifier, queues, FGVs, neuerdings Channels," ins Spiel. Werde ich mir anschauen.

Deine Vorstellung ist richtig.
Selbstverständlich kann man auch in große Projekte meterlange Drähte ziehen - das ist aber schlechter Programmierstil. LV würde das können ...

Zitat:Oder ist Übersichlichkeit in größeren Projekten vielleicht nicht gerade eine Stärke von LabView?

Keinesfalls !!
Die Übersichtlichkeit entsteht durch den Programmierstil. Bei LabVIEW gehört da auch ein ansprechendes äußeres Erscheinungsbild dazu. Ich sage nur "graphische Entwicklungsumgebung" ...

Zitat:Aber trotzdem wollte ich nochmal anders fragen: Ist es ein Anfängerfehler oder sogar ein No-Go, Elemente als reine Variablen zu missbrauchen indem sie unsichtbar gemacht werden oder sieht man es vielleicht durchaus wenigstens hin und wieder?

Erstens: Ich finde es ein No-Go, und zwar ein absolutes No-Go, wenn man das so sagen kann, Anzeigen/Bedienelemente unsichtbar zu machen. Es gibt einen Grund, sie sichtbar zu lassen: Debugging ...
Zweitens: Selbstverständlich sieht man auch ausgeblendete Elemente - allerdings mehr bei Anfängern und Hobby-Programmieren. Ein Professional wird das kaum machen: Der nimmt die von Gerd aufgelisteten Methoden.

Ich gebe zu, dass ich, um den Verdrahtungssalat gering zu halten, gern globale Veriable verwende. Die hier manchmal beschworene geringere Gesschwindigkeit ist eine Mär, das habe ich ausführlich getestet. Man braucht lediglich ein zusätzliches VI, genannt z.B. "global.vi", in dem man alle Variablen, die man verwendeten will, definiert. Da besondere Vorteil ist, dass nicht nur Draht im Haupt-VI wegfällt, sondern auch Anschlüsse an den Sub-VIs. Man kann in jedem beliebig tief verschachtelten SubVI direkt auf die GBs zugreifen.
Normalerweise werden hier auf so eine Frage mit an erster Stelle Schieberegister genannt. Weiß nicht warum diesmal nicht. Man braucht auch nicht für jede Variable ein eigenes SR (- was wieder auf viel Draht hinausliefe -) , sondern das SR kann ein entsprechend großes Cluster sein, in dem alle benötigten Variablen als Elemente enthalten sind.
Übrigens: Man spart auch dann schon viel Draht und das VI gewinnt an Übersicht, wenn man alle Elemente, die zusammengehören, als Cluster zusammenfasst. Die Clusterumrandung kann man auf dem FP unsichbtbar machen, ja, man kann soger Elemente, die gar nicht zum Cluster gehören, in den Clusterbereich reinschieben. Will sagen: Die Verclusterung zusammengehöriger Elemente muß auf dem FP nicht unbedingt zu einem anderen Aussehen führen, man hat trotzdem noch große Freiheiten im Design.

Anzeige

(18.08.2018 10:42 )Lucki schrieb:  Normalerweise werden hier auf so eine Frage mit an erster Stelle Schieberegister genannt. Weiß nicht warum diesmal nicht.

Genau das war mein allererste Gedanke. Ich habe mir dann aber gedacht, wartest mal ab, auf was er überhaupt hinaus will.

Schieberegister ist die ideale Wahl für Datenkapselung: kommt keiner mehr an die Daten ran ...

Nicht dass catbull hier auf globale Variablen verfällt: So schön sie sind und so einfach sie zu handhaben sind, so lehne ich sie doch aus prinzipiellen Gründen ab: Zum Einen nämlich genau wegen der nicht vorhandenen Datenkapselung und weil sie jeder modularen Programmierung im Wege stehen, zum Anderen aber auch, weil sie anfällig für RaceConditions sind, wenn man sie nicht zu handhaben weiß.

Noch eins für catbull: Man kann globale Variablen leicht umgehen - nämlich mit funktionalen globalen Variablen.

(18.08.2018 08:42 )GerdW schrieb:  Hallo catbull,

ja!

In LabVIEW ist der Draht die Variable!
FP-Elemente dienen als Ein-/Ausgabe...

- Drähte müssen auch über Strukturgrenzen gehen: wie sollen sonst Daten in Schleifen rein/raus?

...mit lokalen Variablen funktioniert das ja auch. Aber klar, dann kann es sein, dass deren Elemente im Weg sind.

Zitat:- Datenkapselung ist durchaus sinnvoll, aber was hat das mit versteckten Anzeigeelementen zu tun?

Wenn ein Element versteckt wird bleibt ja nur der Anschluss im Blockdiagramm übrig und beliebig viele lokale Variablen des Elements. Der Anschluss ist selber dann nichts anderes mehr, als eine lokale Variable. Lokale Variablen bzw. Elemente gelten ja nur innerhalb des Moduls/VIs. Deren Daten sind somit im jeweiligen VI gekapselt.

Zitat:- seit etlichen Versionen kannst du auch Drähten ein Label geben: dann bekommt die "Variable" auch einen Namen...

Das wusste ich noch nicht. Danke. Trotzdem ist es noch nicht das, was ich meine unbedingt zu brauchen. In meinem aktuellen Projekt, ein Spiel in dem ein Luftkissenfahrzeug aus der Vogelperspektive gesteuert wird, gibt es Daten wie Geschwindigkeiten, Kräfte (beides Vektoren in Fornm von komplexen Zahlen) und vieles mehr... Die müssen nirgendwo angezeigt werden, benötigen also kein Element, aber alleine in einem Draht können sie nicht gespeichert werden. Ich brauche ganz normale lokale Variablen -meine ich zumindest.

(18.08.2018 10:42 )Lucki schrieb:  Ich gebe zu, dass ich, um den Verdrahtungssalat gering zu halten, gern globale Veriable verwende. Die hier manchmal beschworene geringere Gesschwindigkeit ist eine Mär, das habe ich ausführlich getestet. Man braucht lediglich ein zusätzliches VI, genannt z.B. "global.vi", in dem man alle Variablen, die man verwendeten will, definiert. Da besondere Vorteil ist, dass nicht nur Draht im Haupt-VI wegfällt, sondern auch Anschlüsse an den Sub-VIs. Man kann in jedem beliebig tief verschachtelten SubVI direkt auf die GBs zugreifen.

Das wäre allerdings eine Möglichkeit, die, wenn ich mir mein Projekt anschaue, noch die passendste wäre neben oder nach unsichtbaren Elementen. Du formulierst aber selber schon "Ich gebe zu...". Der Königsweg scheint das nicht zu sein und weil ich eben seit jeher gelernt habe, dass globale Variablen zu vermeiden sind und ich den Gründen dafür auch zustimme, verstehe ich einfach nicht, weshalb es globale Variablen gibt, lokale Variablen aber nur ein Feature von Anzeige-/Bedienelementen sein sollen.

Zitat:Normalerweise werden hier auf so eine Frage mit an erster Stelle Schieberegister genannt. Weiß nicht warum diesmal nicht. Man braucht auch nicht für jede Variable ein eigenes SR (- was wieder auf viel Draht hinausliefe -) , sondern das SR kann ein entsprechend großes Cluster sein, in dem alle benötigten Variablen als Elemente enthalten sind.

Nachdem ich widerwillig mir gerade einige Minuten Gedanken darüber gemacht habe, wie ich das mit Schieberegistern machen könnte ist mir sogar eine Möglichkeit gekommen, die an einigen Stellen funktionieren müsste. Von GerdW weiß ich jetzt auch, dass ich den Drähten zum/vom SR Namen geben könnte. Schmecken will es mir noch nicht, ich werds aber mal versuchen. Danke.

Zitat:Übrigens: Man spart auch dann schon viel Draht und das VI gewinnt an Übersicht, wenn man alle Elemente, die zusammengehören, als Cluster zusammenfasst. Die Clusterumrandung kann man auf dem FP unsichbtbar machen, ja, man kann soger Elemente, die gar nicht zum Cluster gehören, in den Clusterbereich reinschieben. Will sagen: Die Verclusterung zusammengehöriger Elemente muß auf dem FP nicht unbedingt zu einem anderen Aussehen führen, man hat trotzdem noch große Freiheiten im Design.

Jep. Darauf bin ich neulich auch gekommen und habe schon angefangen das so zu machen -notgedrungen wegen begrenzter Anzahl Ein-/Ausgängen der SubVIs. Trotzdem ist ein Cluster ja genauso ein Anzeige- oder Bedienelement das unsichtbar gemacht werden muss, wenn man lediglich die Daten braucht...

(18.08.2018 09:09 )IchSelbst schrieb:  Erstens: Ich finde es ein No-Go, und zwar ein absolutes No-Go, wenn man das so sagen kann, Anzeigen/Bedienelemente unsichtbar zu machen. Es gibt einen Grund, sie sichtbar zu lassen: Debugging ...
Zweitens: Selbstverständlich sieht man auch ausgeblendete Elemente - allerdings mehr bei Anfängern und Hobby-Programmieren. Ein Professional wird das kaum machen: Der nimmt die von Gerd aufgelisteten Methoden.

Ich werds versuchen. Da mein Projekt aber keine Scrollbalken haben wird, habe ich mir auch gedacht, vielleicht schiebe ich die Elemente, die nicht angezeit werden müssen, deren Werte ich aber brauche, einfach außerhalb des sichtbaren Bereichs. Dann bleiben sie in der Entwicklungsumgebung sichtbar (zwecks Debugging wie du ja sagst), weil dort die Scrollbalken ja immer angezeigt werden, zur Laufzeit wären sie dann quasi unsichtbar, weil sie außerhalb des angezeigten Bereichs liegen. Wäre das eine Lösung, die noch eher in Frage käme deiner/eurer Meinung nach?



Vielen Dank euch für eure Mühen mit mir. Ich hoffe ich wirke nicht irgendwie stur oder uneinsichtig. Es ist aber wirklich so, dass ich nicht verstehen kann, weshalb es keine lokale Variablen geben soll, so wie es auch globale gibt -also unabhängig von GUI-Elementen. Geht es allen so, die von nicht-grafischen Programmiersprachen zu LV kommen? Wie ich es auch drehe und wende, ich meine, dass lokale Variablen in meinem Projekt am Geeignetsten oder sogar nötig sind. Wie in meinem anderen Thread bezüglich Performanceproblemen angekündigt, werde ich das Projekt an dem ich sitze herzeigen, sobald ich eine "herzeigbare" Version habe. Wenn sich dann der ein oder andere die Mühe machen könnte, mal drüberzuschauen, welche der Alternativen für versteckte Elemente hier die passendste sein muss, wäre ich sehr sehr dankbar dafür...

Ich werde mich aber anstrengen, es selber hinzubekommen. Schieberegister werde ich als erstes versuchen.

Zitat:Wenn ein Element versteckt wird bleibt ja nur der Anschluss im Blockdiagramm übrig

Das ist so falsch wie es falscher gar nicht geht !!

Auch wenn ein Element nicht sichtbar ist, ist es doch noch immer vorhanden - es ist also auch noch "übrig". Genau aus dem Grunde - man sieht es nicht - bin ich nämlich gegen unsichtbar machen: Nach einem halben Jahr weißt du nämlich nicht mehr, dass da eine Variable ist: Den Anschluss im BD zu finden kann nämlich ganz schön schwierig sein ...

Zitat:beliebig viele lokale Variablen des Elements.

Beliebig viele lokale Variablen eines Elementes zu machen ist streng genommen der falsche Weg.

In LabVIEW muss du gemäß Datenfluss-Prinzip denken: Werte befinden sich in Drähten und werden durch diese Drähte geleitet. Und was heißt es jetzt, wenn du zwei lokale Variablen im Lesemodus und zwei ebensolche im Schreibmodus hast und dazwischen jeweils einen Draht? Richtig: Zwei Datenflüsse - das aber heißt (streng genommen) zwei Instanzen des Elementes, die nicht den selben, nur den gleichen Wert haben.

Das nächste, das du unbedingt verinnerlichen musst, wenn du LV programmierst, ist, dass alles das, was nicht sequenziert ist, grundsätzlich parallel abgearbeitet wird. Und wenn ich parallel sage, so meine ich im Falle von LV tatsächlich parallel. Wenn du das verinnerlicht hat und jetzt den vorhergehenden Absatz nochmals ließt, siehst du, dass ein Problem auftritt: Welcher Wert steht letztendlich im Anzeige/Bedien-Element, nachdem zwei Datenflüsse parallel auf dessen lokale Variablen geschrieben haben? Dieser Effekt heißt RaceCondition und kann fatal schlimm sein ...

Selbstverständlich aber kannst du lokale Variablen verwenden - du musst dir aber im Klaren sein über die sämtlichen Nachteile.

Wenn du kein Anzeigeelement in deinem VI haben will, so nimm eine FGV. Die kann man aufbauen wie ein Klasse im "klassischen Sinne": mit gekapselten Daten und Methoden. Meine FGVs haben einen einzigen Ausgang nämlich den Datencluster. Eingänge gibt es zwei Stück: einen Variant, der Daten hineinleitet und einen Enumerator, der eine Methode aufruft. (Anmerkung: bei beiden Anschlüsse Error-Cluster In und Out sind integraler Bestandteil eines VIs und müssen nicht weiter erwähnt werden.)

FGVs... tolle Konstruktion. Ich bin begeistert. Vielen Dank euch! Nie im Leben wäre ich da drüber gestolpert. Bin gerade dabei das zu erproben, das scheint die perfekte Lösung für mich zu sein.

Wisst ihr etwas darüber, wie FGVs performancemäßig so dastehen?