Objektorientiertes Programmieren mit LV

Das Problem der Abstrahierung betrifft aber nicht nur LVOOP, oder OOP, sondern ist allgemeines Problem. Auch wenn man ohne OOP programmiert, besteht dieses Problem der Wiederverwendung. Nur bei OOP gibt es solche Tools wie Ableitung, Überladung und ähnliches, die zur Lösung genau dieses Problems gerichtet sind. Ansonsten klar, bleibt fast nur das Kopieren und Einfügen + Bibliotheken und Templates.

P.S. muss/soll - feiner Unterschied, sorry Deutsch ist nicht meine Muttersprache.

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.

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.

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.

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

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

Also mich auf jeden Fall
Ich denke du solltest irgendwie von der textbasierten Denkweise weg.

Vielleicht helfen dir meine Tipps&Tricks ein wenig:
http://LabVIEWportal.eu/de/tipps-und-tricks

Ja das ist echt ein Problem.
Ich arbeite Parallel dazu noch im .NET Framework.
So einfach immer hin und her zu switchen ist gar nicht so einfach.

Die Tipps habe ich mir durchgelesen. Generell versuche ich auch so zu programmieren. Ich werde trotzdem mal etwas weiter testen mit LVOOP. Und vielleicht kann der ein oder andere mit ja doch noch eine Frage, von oben, beantworten. (Speziell so ein Objekt zu erstellen und überall zuzugreifen wäre gut (siehe java point beispiel).

' schrieb: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.

Und was machst du innerhalb einer Methode? Doch wohl die einzelnen Befehle, also Schritte, sequenziell abarbeiten.

Zitat: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.

Zitat:Man kann sich vorstellen, dass dabei die Übersicht verloren geht,

Ich bin der Meinung, dass man da nicht unbedingt den Überblick verliert.

Zitat:grad wenn man noch Anfänger ist und massiv von FlatSequenz etc gebrauch macht.

Eine FlatSequenz (die du ja nicht verwenden sollst) kannst du immer durch SubVIs mit Error-Cluster ersetzen: Jeden Case-Inhalt in ein SubVI (ist 32x32 Pixel groß) und die alle mit ErrorCluser verbinden. Und schon ist die Übersichtlichkeit wieder da. z.B. kann man ganz oben das Original-Array durchschleifen und darunter die Zwischenschritte.
Du kannst auch eine Statemachine nehmen: Hier gibt es pro Schritt (z.B. BenutzerEvent!) ein Case einer CaseSequenz.

Zitat: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

Auch das geht eigenlich ohne OOP: Nimm eine "funktionale Globale Variable". Das ist ein SubVI, das Daten enthält. Über einen Enumeratoreingang kann man verscheidene Funktionen aufrufen und sich (mit anderen Enumeratorwerten) Daten geben lassen.

Zitat:kann nicht einfach ein Objekt erstellen in Sequenz1 und dann in Sequenz999 wieder aufrufen.

Genau dieses kannst du nämlich mit einer FGV machen. Hinweis: eine FGV ist nicht nur ein Datenspeicher. Da ein FGV ein SubVI ist, kann man auch Code ausführen.

Zitat: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?

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

Zitat:Die Aussage hier, dass es eigentlich nichts anders ist als SubVIs würde ich eigentlich auch schon so sehen.

Na, da bin ich ja beruhigt.

Hallo,

Zitat:Du kannst auch eine Statemachine nehmen: Hier gibt es pro Schritt (z.B. BenutzerEvent!) ein Case einer CaseSequenz.

Das hab ich jetzt schon öfter gelesen. Das man in LabVIEW Zustandsautomaten verwenden sollte. Ich werde das aufjedenfall damit mal versuchen.

Auch diese Sache mit den "funktionalen Globalen Variablen". Bisher habe ich immer gelesen, selbst auf NI.COM, dass man eigentlich die Finger weg lassen sollte von lokalen/globalen Variablen. Ich werde mir das aber mal angucken.

Vielleicht wird das mit LVOOP ja noch interessanter, wenn es mal weiterentwickelt wurde und es sich wie in einer echten OO-Sprache anfühlt. Bisher scheinen die Vorteile ja =0 zu sein. Vorstellbare Vorteile sehe ich bisher nur in großen Projekten aufgrund geschützter Member-Variablen (Protected) und Vererbungen der Klassen.

Gruß

Anzeige

' schrieb:Auch diese Sache mit den "funktionalen Globalen Variablen". Bisher habe ich immer gelesen, selbst auf NI.COM, dass man eigentlich die Finger weg lassen sollte von lokalen/globalen Variablen. Ich werde mir das aber mal angucken.

Vorsicht. Eine Funktionale-Globale-Variable hat nichst mit der Globalen Variable von NI-LV zu tun. Es ist viel mehr ein SubVI indem Daten abgelegt werden (wie IchSelbst schon erklärte). Man muss sich seine FGV also selbst programmieren. Von "normalen" globale Variablen ist auch abzuraten, da dies einen Sprungbefehle zur Folge hat. Das ist in einer Programmiersprache welche Datenflussorientiert ist natürlich suboptimal. Mit einer FGV kann man den Datenfluss erhalten.

Ich habe bislang auch noch keine zufriendenstellende OOP mit LV hinbekommen. Von daher greife ich bei meiner Datenaufnahme noch auf C++ Skripte zurück.

Gruß, abrissbirne

' schrieb:Auch diese Sache mit den "funktionalen Globalen Variablen". Bisher habe ich immer gelesen, selbst auf NI.COM, dass man eigentlich die Finger weg lassen sollte von lokalen/globalen Variablen. Ich werde mir das aber mal angucken.

FGVs sind keine lokalen/globalen Variablen. Du hast recht, diese sollte man, falls nötig und wenn möglich, vermeiden, da sie immer Kopien der Daten erzeugen und Race-Condition nach sich ziehen können.

Funktionale globale Variable dagegen ist ein Begriff in der LV-Welt, der eher ein Konzept bedeutet.
Ganz rudimentär könnte das so aussehen:

  FGV.vi (Größe: 6,19 KB / Downloads: 423)


Gruß, Jens

' schrieb:...In LVOOP funktioniert es ByValue (nicht By Reference), somit hast du die Klasse kopiert.

Wenn du es nocheinmal mit OOP versuchen willst, rate ich zur
GOOP
Dev Suite. Die gibt es auch in einer Community Edition! Dort funktioniert das dann by Reference.
Ich will die ganze Diskussion OOP/nicht OOP nicht nocheinmal anheizen, lediglich auf einen guten Verwendungszweck des OOP Ansatzes hinweisen.
Sollte jemand einen Treiber für irgendwelche devices der gleichen Art schreiben, kann ich OOP nur empfehlen. Somit fällt das lästige verzweigen innerhalb eines Programmablaufs auf das richtige device weg. Ich instantiere zu Beginn die richtige Klasse und schon läuft der Laden. Selbst dann, wenn später ein neuer Treiber für ein zusätzliches device hinzukommt gibt es keine neuen Verzweigungen innerhalb des Hauptprogrammes, sondern lediglich eine neue von der Basis abgeleitete Klasse, die dann wieder zu beginn instanziert werden kann...

Hoffe das war jetzt nicht zu verworren ,-)

Hallo,

dann ist die FVG sowas wie eine statische public methode. Das könnte wirklich nützlich sein.


Goop werd ich mal privat testen.