Variable ohne Element -einfach unsichtbar machen?

Zitat:Wenn aber wie hier, die Schleifen nur genau 1 Mal durchlaufen, sollte das kein Thema sein oder verstehe ich dich falsch? Du redest von parallel laufenden Schleifen, oder?

Es kommt auf Menge der Prozesse innerhalb der While Schleife an. Könnte passieren, dass der Wert der Variable sich ändert bevor sie ausgelesen wird.

Gruß
Freddy

Hallo catbull,

GerdW schrieb:

Zitat:Prinzipiell sieht das BD schon sehr geordnet aus!
Was ich machen würde: alle Schieberegister durch ein einziges ersetzen und alle Einzelwerte in einem Cluster zusammenfassen! (Dann bist du schon ganz knapp vor einer echten OOP-Implementierung.)

So verschieden sind die Auffassungen: Ich würde ja sagen, viel zu viele Drähte, also Wirrwarr - nimm einen Cluster.

Zitat:Redet man da schon von FGVs? Ich hätte gedacht, da gehöre noch etwas mehr dazu...

Was gar nicht geht (als FGV), ist, nur einen einzigen Wert zu speichern und sonst gar nichts in der FGV zu haben, also keine Methoden.

Es ist nicht Sinn und Zweck einer FGV, einen(1) Wert zu speichern. Sinn und Zweck ist, ein Objekt zu bearbeiten. Werte sind nur notwendiges Übel zu einem Objekt. Du denkst ja schließlich in Objekten: Prüfstand, Eingabemaske, Messwerte sampeln, Protokollausgabe, graphische Anzeige etc.

Eine Eingabemaske z.B. impliziert das Lesen und Schreiben der Parameterwerte, die in der Eingabemaske zu sehen sind, auf Platte. Werte können gegenseitig verriegelt sein. Aus Eingabewerten kann man Anzeigewerte berechnen (z.B. Dauer eines Ablaufes). Alles das sind Algorithmen, die man in der FGV sammeln kann. Und für die Anzeige, die man dummerweise braucht, übergibt man der FGV eine Referenz auf einen Cluster an einem beliebigen Frontpanel.

Was mir sehr gut an FGVs gefällt, ist die Tatsache, dass die Werte, die in der FGV vorhanden sind, von jedem Anzeige- bzw. Bedienelement unabhängig sind - womit wir wieder bei deiner ursprünglichen Frage wären ...

Hallo ichselbst,

so verschieden sind unsere Vorstellungen doch überhaupt nicht: den Cluster habe ich auch als meine Vorgehensweise genannt.
Aber das gezeigte BD selbst ist formal sauber: ordentlich angeordnete subVIs, ordentlich sortierte Schieberegister.
(Man muss Fortschritte ja auch mal loben! )

(22.08.2018 14:16 )GerdW schrieb:  Was ich machen würde: alle Schieberegister durch ein einziges ersetzen und alle Einzelwerte in einem Cluster zusammenfassen!

Meint ihr, die Werte in einem Cluster zusammenfassen, das Cluster in einem Schieberegister speichern und dann lokale Variablen des Clusters verteilen und die an der jeweiligen Stelle benötigten Werte auslesen bzw. schreiben? Meint ihr ein Cluster als Anzeige-/Bedienelement oder nur bündeln? Ich komme gerade noch nicht darauf, wie ihr das meinen könntet, so dass da dann auch tatsächlich mehr Übersicht entsteht mit der Clusterei...

Hallo catbull,

Zitat:Meint ihr, die Werte in einem Cluster zusammenfassen, das Cluster in einem Schieberegister speichern

Ja, Und ja.

Zitat:und dann lokale Variablen des Clusters verteilen und die an der jeweiligen Stelle benötigten Werte auslesen bzw. schreiben?

Nein!
Zu früh gelobt!

Zitat:Meint ihr ein Cluster als Anzeige-/Bedienelement oder nur bündeln? Ich komme gerade noch nicht darauf, wie ihr das meinen könntet, so dass da dann auch tatsächlich mehr Übersicht entsteht mit der Clusterei...

- Der Cluster muss KEIN FP-Element sein - das hatten wir doch in diesem Thread von Anfang an schon gesagt!
- Nimm (Un)BundleByName statt des einfachen (Un)Bundle - der Übersicht wegen…
- Schau dir doch mal mein "Snake"-Bild oben an: da verwende ich einen Cluster, der im Schieberegister gespeichert wird. Der enthält alle Spiel-relevanten Daten! Und man sieht ein UnbundleByName, aus dem der aktuelle Spielstand gelesen wird. Die subVIs verwenden diesen Cluster als FP-Elemente und bearbeiten ihn intern - deren FP sieht der User aber nie.

(23.08.2018 06:51 )GerdW schrieb:  - Schau dir doch mal mein "Snake"-Bild oben an: da verwende ich einen Cluster, der im Schieberegister gespeichert wird. Der enthält alle Spiel-relevanten Daten! Und man sieht ein UnbundleByName, aus dem der aktuelle Spielstand gelesen wird. Die subVIs verwenden diesen Cluster als FP-Elemente und bearbeiten ihn intern - deren FP sieht der User aber nie.

Hmmm... ich versuchs nochmal. Was ich meine für mein VI aus dem Snake-Beispiel herauszulesen:

1. Jede SubVI bekommt das komplette Cluster übergeben.
2. Zurückgegeben (an das nächste SubVI weitergegeben) wird von einem SubVI das komplette Cluster in überarbeiteter Form.
3. Erstellt wird das besagte Cluster in einer extra SubVI außerhalb der Schleife (Init), in der auch die Startwerte zugewiesen werden.
4. Man stört sich nicht daran, dass den SubVIs mehr Daten (alle) übergeben werden, als nötig. Wenn ich darüber nachdenke, finde ich das schlüssig. Methoden und Funktionen einer Klasse können ja für gewöhnlich auf alle Attribute dieser Klasse zugreifen.
5. Was mich daran nur bisher irritiert hat: Eine Funktion kennt ja die Parameter einer anderen Funktion nicht. Und dieses Cluster ist ja quasi ein Parameter-Cluster. Liege ich aber richtig damit, dass ihr dieses Cluster eher als Attribute-Cluster als als Parameter-Cluster bezeichnen würdet?
6. Um näher an eine OOP-Lösung zu gelangen sollte ich anstelle dieser 4 Boolean-Parameter für die Tastatureingabe (Leertaste, Links, Hoch, Rechts) ein(1) Enum-Element verwenden.
   

...Könnt ihr mir bitte sagen, welche Punkte richtig und welche falsch sind? Danke!

(22.08.2018 14:16 )GerdW schrieb:  [...] (Dann bist du schon ganz knapp vor einer echten OOP-Implementierung.)

Ich muss sagen, dass ich es geradezu aufregend finde, mit LV so langsam auf OOP-Pfade zu gelangen!

Anzeige

Hallo catbull,

Zitat:Jede SubVI bekommt das komplette Cluster übergeben.

Ja.

Zitat:Zurückgegeben (an das nächste SubVI weitergegeben) wird von einem SubVI das komplette Cluster in überarbeiteter Form.

Ja.

Zitat:Erstellt wird das besagte Cluster in einer extra SubVI außerhalb der Schleife (Init), in der auch die Startwerte zugewiesen werden.

Ja. Der Cluster ist auch noch typdefiniert, damit spätere Änderungen daran problemlos in allen Instanzen übernommen werden.
Im Init-subVI wird dann wiederum eine entsprechende Cluster-Konstante im BD verwendet.

Zitat:Man stört sich nicht daran, dass den SubVIs mehr Daten (alle) übergeben werden, als nötig. Wenn ich darüber nachdenke, finde ich das schlüssig. Methoden und Funktionen einer Klasse können ja für gewöhnlich auf alle Attribute dieser Klasse zugreifen.

Das ist den subVIs doch egal: sie lesen und schreiben nur die sie betreffenden Daten.

Zitat:Was mich daran nur bisher irritiert hat: Eine Funktion kennt ja die Parameter einer anderen Funktion nicht. Und dieses Cluster ist ja quasi ein Parameter-Cluster. Liege ich aber richtig damit, dass ihr dieses Cluster eher als Attribute-Cluster als als Parameter-Cluster bezeichnen würdet?

Für mich ist das ein Cluster, der Daten enthält.
Wie definierst du "Attribute" und "Parameter"?

Zitat:Um näher an eine OOP-Lösung zu gelangen sollte ich anstelle dieser 4 Boolean-Parameter für die Tastatureingabe (Leertaste, Links, Hoch, Rechts) ein(1) Enum-Element verwenden.

Kann man, muss man aber nicht.
Da aber ein Tastendruck-Event sowieso ein Enum mit der gedrückten Taste liefert, wäre das vielleicht ein sinnvolle Entscheidung…

(23.08.2018 13:09 )catbull schrieb:  Erstellt wird das besagte Cluster in einer extra SubVI außerhalb der Schleife (Init), in der auch die Startwerte zugewiesen werden.

"Erstellen" ist doppeldeutig. Daher folgendes:
Das Erstellen des Clusters geschieht zur Entwicklungszeit, nicht zur Laufzeit. Wo dieser Cluster erstellt wird, in der FGV oder in einem Extra-VI, ist egal. Nach der Erstellung liegt der Cluster als Typdefinition (.cls-Element) auf Platte vor. Den Erstellungsort gibt es zur Laufzeit nicht mehr.

Zur Laufzeit wird eine Instanz von der Typdefinition erstellt und auch mit Werten vorbesetzt (die Vorbesetzung kann implizit oder explizit erfolgen). Diese Erstellung würde ich auf jeden Fall in der FGV machen. Nämlich im Case Create ...

Zitat:Was mich daran nur bisher irritiert hat: Eine Funktion kennt ja die Parameter einer anderen Funktion nicht.

Das ist auf jeden Fall richtig

Zitat:Und dieses Cluster ist ja quasi ein Parameter-Cluster.

"Parameter-Cluster" würde ich nicht sagen. "Parameter" alleine ist ausreichend. Der Cluster als solcher ist der Parameter (wie eben auch ein struct in anderen Sprachen).

Zitat:Liege ich aber richtig damit, dass ihr dieses Cluster eher als Attribute-Cluster als als Parameter-Cluster bezeichnen würdet?

Das führt jetzt aber zu weit: Ein Parameter ist eher ein "Übergabe-Parameter", also das, was im Funktionskopf steht, bzw. das, was der Eingang des VIs ist. (Beachte: es heißt: was der Eingang ist, nicht was am Eingang hängt: Am Eingang hängen tut der Parameterwert). Ein Attribut ist eine Eigenschaft, also eher eine logische Beschreibung des Objektes.
Weiterhin muss unterschieden werden zwischen Parameter/Attribut und Parameter/Attribut-Wert: Der Parameter ist eher der Draht als solcher, der Parameterwert ist der Inhalt, der sich durch den Draht bewegt.

Zitat:Um näher an eine OOP-Lösung zu gelangen sollte ich anstelle dieser 4 Boolean-Parameter für die Tastatureingabe (Leertaste, Links, Hoch, Rechts) ein(1) Enum-Element verwenden.

OOP zu machen und Enum zu verwenden sind aber zweierlei Dinge. Da bedingt sich nichts gegenseitig. Du kann ein Enumerator auch ohne jedwede OOP verwenden (und umgekehrt). Enumeratoren sind grundsätzlich sehr gut: Die sind nämlich typspezifisch und selbst-sprechend.

(23.08.2018 13:18 )GerdW schrieb:  

Zitat:Was mich daran nur bisher irritiert hat: Eine Funktion kennt ja die Parameter einer anderen Funktion nicht. Und dieses Cluster ist ja quasi ein Parameter-Cluster. Liege ich aber richtig damit, dass ihr dieses Cluster eher als Attribute-Cluster als als Parameter-Cluster bezeichnen würdet?

Für mich ist das ein Cluster, der Daten enthält.
Wie definierst du "Attribute" und "Parameter"?

Ich meine "Attribute" im OOP-technischen Sinne. Eine Klasse besteht ja aus Attributen und Methoden/Funktionen. Wenn das VI, das ich gepostet habe, eine Klasse darstellen soll wenn man OOP-mäßig in LV programmiert (oder liege ich da falsch?), stellt dann das besagte Cluster in einem Schieberegister die Attribute dar?

Die SubVIs wären dann die Funktionen (einzeln betrachtet eher private Fkt., alle zusammen eher öffentliche). Mit Parameter meine ich die Werte, die einer Funktion, also den SubVIs übergeben werden -was ja auch das Cluster ist.

Das Cluster ist also beides: Attribute und Parameter. Nur an Parametern werden ja normalerweise nur die benötigten übergeben und nicht einfach alle. Daher die Frage, ob ich richtig verstanden habe, dass dieses Cluster eher die Attribute als die Parameter darstellt -im OOP-technischen Sinne.

Aber anstatt solche Fragen zu stellen sollte ich wahrscheinlich eher mich von Grund auf mit LVOOP beschäftigen...

(23.08.2018 13:47 )IchSelbst schrieb:  "Erstellen" ist doppeldeutig. Daher folgendes:
Das Erstellen des Clusters geschieht zur Entwicklungszeit, nicht zur Laufzeit. Wo dieser Cluster erstellt wird, in der FGV oder in einem Extra-VI, ist egal. Nach der Erstellung liegt der Cluster als Typdefinition (.cls-Element) auf Platte vor. Den Erstellungsort gibt es zur Laufzeit nicht mehr.

Zur Laufzeit wird eine Instanz von der Typdefinition erstellt und auch mit Werten vorbesetzt (die Vorbesetzung kann implizit oder explizit erfolgen). Diese Erstellung würde ich auf jeden Fall in der FGV machen. Nämlich im Case Create ...

...quasi einen Konstruktor anlegen? Sollte diese Case-Struktur mit einem Create-Case von einem Enum-Anschluss (mit unter anderem einem Create-Element) bestimmt werden?

Zitat:

Zitat:Was mich daran nur bisher irritiert hat: Eine Funktion kennt ja die Parameter einer anderen Funktion nicht.

Das ist auf jeden Fall richtig

Richtig? -Wenn ich GerdW richtig verstehe, dann kennen die Funktionen (SubVIs?) doch die Parameter der anderen Funktionen, weil sie ja alle das komplette Cluster mit allen Parametern übergeben bekommen...

Zitat:

Zitat:Liege ich aber richtig damit, dass ihr dieses Cluster eher als Attribute-Cluster als als Parameter-Cluster bezeichnen würdet?

Das führt jetzt aber zu weit: Ein Parameter ist eher ein "Übergabe-Parameter", also das, was im Funktionskopf steht, bzw. das, was der Eingang des VIs ist.

Das wäre dann in meinem VI die Tastatureingaben, also diese 4 Boolean-Elemente, nicht die Schieberegister die ich in einem Cluster zusammenfassen soll, so wie ich es momentan verstehe.

Zitat:Ein Attribut ist eine Eigenschaft, also eher eine logische Beschreibung des Objektes.

Attribute beschreiben den Zustand des Objektes denke ich. Und das träfe auf das Datencluster ja zu...


Aber gleich wie auf die Antwort auf GerdWs Post muss ich wohl sagen, dass anstatt solche Fragen zu stellen sollte ich wahrscheinlich eher mich von Grund auf mit LVOOP beschäftigen... Ihr könnt mir schwer ALLES in einem Thread beibringen. Aber vielen Dank für den Versuch! Ich will euch aber nicht überbeanspruchen...



Ich werde das Teil erstmal überarbeiten und dann wieder posten, alles andere führt an der Stelle zu weit im Moment....

Eine kurze Zwischenfrage bitte:

Ich habe jetzt mal nur bis Antriebe gemacht,...

       

...die andere SubVIs sind noch nicht überarbeitet, weshalb der Draht jeweils zwischen den anderen noch fehlt.


Was ich euch fragen wollte, brauche ich in jedem SubVI jeweils ein Anzeigeelement und ein Bedienelement der Typdefinition des Datenclusters für die Anschlüsse? Oder geht das irgendwie anders? Falls ja, ich habs nicht herausgefunden wie...

Ich frage wegen...

(23.08.2018 06:51 )GerdW schrieb:  - Der Cluster muss KEIN FP-Element sein - das hatten wir doch in diesem Thread von Anfang an schon gesagt!

Meintest du damit auch die SubVIs?