Objektorientiertes Programmieren mit LV

' schrieb:Guten morgen,

um meinen Standpunkt genauer zu erklären:

Ich komme eigentlich aus der Welt der OO. Sequentielle Programmierung wie sie normalerweise in C oder LabVIEW ohne SubVI gemacht wird war bei uns immer verboten.

nicht desto trotz werden die einzelnen Zeilen eine Programmstücks nacheinander verarbeitet.

' schrieb:Aus diesem Grund habe ich auch einige Schwierigkeiten mit der LabVIEW Programmierung. Mein Problem besteht derzeit darin,
dass ich ein riesen Array ([100]x[100.000] Einträge) verarbeiten muss. Ich muss die Array Werte verarbeiten um so am Ende ein neues Array mit veränderten Werten zu erhalten.

Was mir halt bei dieser sequentiellen Programmierung dann ständig passiert ist, dass ich die verränderten Arrays, es sind mehrere Zwischenschritte nötig um ans End-Resultat-Array zu kommen, zwischenspeichere als Anzeigeelement, da der nächste Schritt erst 3-5 Sequenzen weiter ist. Ich möchte dann nicht den Datenfluss vom Array über mehrere Sequenzen weitergeben, weil ich dann sowieso nicht mehr weiß, wozu gehörte der Datenfluss. Ich erstelle mir also dann eine lokale Variable vom neuen Anzeigeelement und verarbeite diese weiter in den weiter hinten liegenden Sequenzen. Manchmal benötige ich aber dann doch noch das UrsprungsArray mit den nicht verränderten Daten und muss dann quasi das wieder heranholen mittels Lokaler Variable.

Aber so etwas machst Du in textbasierten Programmiersprachen auch nicht: Das Array bearbeiten und das Ergebnis in einer neuen Variable speichern. Dann ein paar Zeilen weiter das neue Array nehmen wieder bearbeiten und das Ergebnis in einer dritten Variable speichern. Eine neue Variable ist nur nötig, wenn die alten Daten noch mal gebraucht werden. Und in LabVIEW ist die Variable eine Leitung, die vom Ausgang von VI A zum Eingang von VI B geht. Wenn Du den Wert Deines Array von vor x Arbeitsschritten noch mal brauchst, dann ziehe eine Leitung von diesen Punkt (Leitung oder VI Ausgang) zu den Eingang wo es gebraucht wird. Du brauchst dazu keine Variable definieren wie in textbasierten Programmiersprachen noch ein Anzeigeelement in LV anlegen.

Beachte immer, dass ein SubVI erst dann ausgeführt wird wenn an allen Eingängen ein gültiger Wert anliegt. Die Reihenfolge der Ausführung von SubVIs kann durch die Verkettung mit dem Error-Cluster erfolgen aber auch alleine durch das Weiterreichen von Daten.

' schrieb:Man kann sich vorstellen, dass dabei die Übersicht verloren geht, grad wenn man noch Anfänger ist und massiv von FlatSequenz etc gebrauch macht.

Aufjedenfall hatte ich gedacht, dass ich mit der LVOOP wie folgt hätte lösen können:

Eine Klasse "MeineMessdaten" die das Ursprungsarray als private "Member" hat.
Eine Methode, die mir das Ursprungsarray zurückgibt.
Eine Methode, die mir das gefilterte Array zurückgibt.
Jetzt wollte ich mir eine Instanz vom Objekt machen und dieses Objekt immer wieder verwenden. Wenn ich also mal mein Ursprungsarray benötige rufe ich:
MeineMessadaten.Usrpungsarray
auf und wenn ich mal das gefilterte Array brauche:
MeineMessdate.gefiltertesArray

Es hätte auch den Vorteil, das das gefilterte Array erst berechnet wird und nicht ganze Zeit im Speicher liegt.

Das ist Überhaupt kein Problem. Das LV Klassen Control enthält ein Daten-Array. Auf das können nur die Methoden der Klasse zugreifen. (durch unbundle by name).

Natürlich musst Du die VI der Klasse miteinander verbinden in dem jedes ein Klassen Control als Eingang und Ausgang hat. Das ist so, wie Du auch immer einen Namen des Objektes angeben musst, wenn Du eine Methode einer Klasse aufrufst. Da LabVIEW Datenfluss orientiert ist muss das Objekt der Begierde im rein und wieder raus, sonst stehen Änderungen an dem Objekt den nachfolgenden VI nicht zur Verfügung.

Mit Goop ist das anders. Hier wird mit Referenzen gearbeitet und man braucht die Referenz nur in die VIs reinstecken. Sie kommen der Übersichtkeit der Blockdiagramme halber aber auch wieder raus.

' schrieb:Dies ist stark an der OOP von Java/.NET/und Co angelegt. Funktioniert aber (noch) nicht wirklich, da ich derzeit keine Ahnung habe wie mein instanziertes Objekt, in anderen FlatSequences verwenden kann. Sobald man den Cluster von der Klasse ja nicht weiterleteitet, kann man ja gar nicht mehr drauf zurückgreifen. Man muss ja scheinbar wirklich den Datenfluss immer weiterleiten und kann nicht einfach ein Objekt erstellen in Sequenz1 und dann in Sequenz999 wieder aufrufen. Was meiner Meinung nach eigentlich von der OO ja ein Muss ist.
Man stelle sich ein normales Java Programm vor. Ganz oben irgendwo definiert man "Point EinPunkt =new Point(x,y,) ". Diesen EinPunkt kann ich dann jederzeit überall in der Klasse verwenden, indem ich den Namen verwende.
Wie das ist in LVOOP gehen soll...weiß ich noch nicht? Ihr?

Die Aussage hier, dass es eigentlich nichts anders ist als SubVIs würde ich eigentlich auch schon so sehen. Der einzige Vorteil/Nachteil von Methoden gegenüber SubVIs wäre, dass diese an ihre Klasse gebunden sind und dieses nochmal ein bisschen mehr Übersicht fördert.

Ich hoffe ich habe euch nicht allzu verwirrt. Ich bin es nämlich selbst noch mit LV :-D

VIs (Methoden) einer LV-Klasse können auch überladen werden. Dazu muss die Vererbung gesetzt werden (Welche LV-Klasse erbt von welcher) und zusätzlich bei allen VIs die Ein- und Ausgänge des Klassen-Control als "dynamic dispatch" gesetzt werden. Oder einfach bei der Klasse New > VI from Dynamic Dispatch Template wählen.

Also alles was Du brauchst geht; leider habe ich im Moment nicht viel Zeit alles im Detail zu erklären, oder Beispiele zu posten.

Anzeige

' schrieb:..
Seht ihr, und genau das will ich auch wissen. ^_^
..

Genau so wie Du in LV Variablen benutzt: Leitung ziehen.

Also im Blockdiagramm das Klassen-Ctl ablegen und Leitung zur ersten Klassenmethode ziehen.
In textbasierten Programmiersprachen muss man Objekte auch erst erzeugen, bevor man sie verwenden kann.

' schrieb:Genau so wie Du in LV Variablen benutzt: Leitung ziehen.

Für komplexte Variablen ziehe ich nicht unbedingt Leitungen. Meistens verwende ich FGVs.

Kann ich die Instanz, die ja durch die Leitung repräsentiert wird, in eine FGV legen? Ist dann der Ausgang der FGV immer genau diese eine Instanz? Ich will nämlich in parallelen Prozessen auf ein und die selbe Instanz zugreifen. Und da liegt dann eben das Problem darin, dass es hier keine Leitungsverbindung gibt.

Zitat:In textbasierten Programmiersprachen muss man Objekte auch erst erzeugen, bevor man sie verwenden kann.

Das ist richtig, aber nicht meine Frage.

In textbasierten Programmiersprachen schreibe ich in jedem parallelen Prozess den Namen der Instanz hin und schon kann ich darauf zugreifen.

' schrieb:Für komplexte Variablen ziehe ich nicht unbedingt Leitungen. Meistens verwende ich FGVs.

Kann ich die Instanz, die ja durch die Leitung repräsentiert wird, in eine FGV legen? Ist dann der Ausgang der FGV immer genau diese eine Instanz? Ich will nämlich in parallelen Prozessen auf ein und die selbe Instanz zugreifen. Und da liegt dann eben das Problem darin, dass es hier keine Leitungsverbindung gibt.

Ja.

Es wird mit FGVs vielmehr schwierig/aufwändig mehrere Instanzen zu haben.

' schrieb:Das ist richtig, aber nicht meine Frage.
..

Der Satz davor liefert auch keine Antwort? Dann verstehe ich die Frage nicht richtig.

' schrieb:Es wird mit FGVs vielmehr schwierig/aufwändig mehrere Instanzen zu haben.

Aus diesem Grund nutze ich sie nicht. Ich versuche so zu programmieren, wie es vom Jeff Kodosky ursprünglich gedacht war. Also keine unsichtbaren Leitungen und uninitialisierten Schieberegister.

Krass, wie man sich die an sich recht einfache und intuitive LabVIEW-Programmierung künstlich erschweren kann......
Da bin ich froh, dass ich LVOOP nicht verwende.

Gruß Markus

Anzeige

' schrieb:Es wird mit FGVs vielmehr schwierig/aufwändig mehrere Instanzen zu haben.

In bestimmten Fällen will ich nicht mehrere Instanzen, sondern genau eine. Die dann aber überall. Also auch dort, wo keine Leitung hinverlegbar ist.
Die Antwort "Ja" reicht mir aber vorerst aus.

Zitat:Der Satz davor liefert auch keine Antwort? Dann verstehe ich die Frage nicht richtig.

Du verstehst mich schon richtig. Und ich dich auch.

' schrieb:Ich versuche so zu programmieren, wie es vom Jeff Kodosky ursprünglich gedacht war. Also keine unsichtbaren Leitungen und uninitialisierten Schieberegister.

Queues/Melder sind aber nichts weiter als unsichtbare Leitungen.
Wäre mein parelleles SubVI eine Klasse, müsste ich die Daten nicht per Queue verschicken, sondern könnte sie per Property holen.

' schrieb:Aus diesem Grund nutze ich sie nicht. Ich versuche so zu programmieren, wie es vom Jeff Kodosky ursprünglich gedacht war. Also keine unsichtbaren Leitungen und uninitialisierten Schieberegister.

' schrieb:
Krass, wie man sich die an sich recht einfache und intuitive LabVIEW-Programmierung künstlich erschweren kann......
Da bin ich froh, dass ich LVOOP nicht verwende.

Gruß Markus

SO meinen Lieben,

wie würdet Ihr denn vorgehen, wenn Ihr eine Bildreihe mit 600 Bilder à 658 x 496 Bildpunkten (SGL) verarbeiten wollt? Und zwar nicht nach fester Vorschrift sondern sequentiell nach Benutzerwunsch. Es gibt also so Funktionen wie Projektdatei öffnen, Neue Projektdatei anlegen, Bilder hinzufügen, Bilder drehen, Bilder glätten, Regionen auswählen und Mittelwerte der Pixel bestimmen, und etc. pp.

Also man hat eine umfangreiche Event-Struktur in einer Schleife und ziemlich viele verschiedene unterschiedlich komplexe Bildverarbeitungsfunktionen, die in SubVIs stecken, damit das Blockdiagramm nicht 3000 x 3000 Bildpunkte groß wird.

Würdet Ihr das alles mit sichtbaren Leitungen machen wollen?

' schrieb:..
Du verstehst mich schon richtig. ..

Sorry, leider nicht.

Ich würde wohl einen (oder mehrere) Cluster nehmen, weil ich LVOOP auf jeden Fall vermeiden möchte.

Gruß Markus

' schrieb:SO meinen Lieben,

wie würdet Ihr denn vorgehen, wenn Ihr eine Bildreihe mit 600 Bilder à 658 x 496 Bildpunkten (SGL) verarbeiten wollt? Und zwar nicht nach fester Vorschrift sondern sequentiell nach Benutzerwunsch. Es gibt also so Funktionen wie Projektdatei öffnen, Neue Projektdatei anlegen, Bilder hinzufügen, Bilder drehen, Bilder glätten, Regionen auswählen und Mittelwerte der Pixel bestimmen, und etc. pp.

Also man hat eine umfangreiche Event-Struktur in einer Schleife und ziemlich viele verschiedene unterschiedlich komplexe Bildverarbeitungsfunktionen, die in SubVIs stecken, damit das Blockdiagramm nicht 3000 x 3000 Bildpunkte groß wird.

Würdet Ihr das alles mit sichtbaren Leitungen machen wollen?