+- LabVIEWForum.de (https://www.labviewforum.de)
+-- Forum: LabVIEW (/Forum-LabVIEW)
+--- Forum: LabVIEW Allgemein (/Forum-LabVIEW-Allgemein)
+---- Forum: LVOOP (/Forum-LVOOP)
+---- Thema: Objektorientiertes Programmieren mit LV (/Thread-Objektorientiertes-Programmieren-mit-LV)
Objektorientiertes Programmieren mit LV - Y-P - 10.08.2009 14:39
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?
Objektorientiertes Programmieren mit LV - abrissbirne - 10.08.2009 14:39
' 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.Wer sagt denn das die Schieberegister in FGV's uninitialisiert sind? Es gibt das Zustandsautomaten und ein Zustand ist "Initialisiere"
Diese Art der Programmierung wird einem im Intermediate Kurs sogar beigebracht.
Objektorientiertes Programmieren mit LV - eg - 10.08.2009 14:48
@ Y-P, das ist es genau. LVOOP-Klasse ist nichts anderes als Cluster, nur ist es ein wenig bequemer zu benutzen.
@ abrissbirne, ich sage ja nicht, dass man es nicht initialisieren kann, ich sage nur dass FGVs mit Reintrance und Instanziirung Probleme haben. Es kann also schnell passieren, dass wenn man nicht alles im Griff hat, können unerwartete Probleme auftreten.
Bleiben wir bei dem Beispiel mit Bilder. Im Prinzip ist es ein 2D-Array. Jetzt will man zum Beispiel das eine Bild schwarz und das andere weiß machen. Mit FGVs macht man entweder pro Bild ein FGV oder man nimmt ein Array aus Bilder oder auch man macht zwei Schieberegister in einer FGV.
Mit LVOOP (oder sagen wir mal einfach ohne FGVs) hat man eine Klasse und zwei Objekte. Das entsprechende VI zum Füllen mit der Farbe hat man nur ein Mal implementiert. Man kann ja dieses VI für das eine und für das andere Bild aufrufen. Dabei bleibt der Code übersichtlich und man hat nicht eine Funktion zwei mal zu implementieren.
Objektorientiertes Programmieren mit LV - unicorn - 10.08.2009 15:12
LV-Klassen erwecken den Eindruck eigentlich nichts anderes als eine Sammlung von SubVI zu sein. Eigentlich könnte man alles zu Fuß ohne Klasse erledigen. Dem ist nicht ganz so: es gibt halt die Vererbung und die Kapselung.
Genauso könnte man in textbasierten Sprachen objektorientiert Programmieren indem nur mit bestimmten Funktionen auf bestimmte Daten zurückgreift und niemals die 'Daten direkt benutzt. Alles eine Frage der Disziplin!?
Objektorientierte Programmierung ist aber nicht nur eine Frage des Stils, wobei die Klassen-Objekte bestimmte Programmierweisen erfordern (in LV als auch in Text) und gleichzeitig die Arbeitsweise erleichtern. Auch die Philosophie die hinter der Bedeutung der Objektorientierung steckt ist unterschiedlich. Diese ist aber auch bei den textbasierten Sprachen nicht ganz einheitlich. LVOOP ist da sicherlich etwas besonderes, weil es auch noch den Datenfluss umsetzt. Dennoch ist es auch mit LVOOP möglich, Klassen erst zur Laufzeit zu laden. Oder klassenspezifische Funktionen aufzurufen, wobei in dem Blockdiagramm dann nur das VI der Basisklasse steht und zur Laufzeit das jeweils spezifische VI aufgrund des Klasse des übergebenen Objektes aufgerufen wird. Die Klasse des übergebenen Objektes muss natürlich von der Basisklasse abgeleitet sein.
Objektorientiertes Programmieren mit LV - IchSelbst - 10.08.2009 15:25
' schrieb:LV-Klassen erwecken den Eindruck eigentlich nichts anderes als eine Sammlung von SubVI zu sein. Eigentlich könnte man alles zu Fuß ohne Klasse erledigen. Dem ist nicht ganz so: es gibt halt die Vererbung und die Kapselung.
Und weil ich Vererbung und zwangsweise Kapselung bisher nicht brauche, sehe ich keinen Grund vieles nicht zu Fuß zu machen.
Zitat:Genauso könnte man in textbasierten Sprachen objektorientiert Programmieren indem nur mit bestimmten Funktionen auf bestimmte Daten zurückgreift und niemals die 'Daten direkt benutzt.
Zitat:Alles eine Frage der Disziplin!?Das war es schon vor 25 Jahren, das wird es auch noch in 25 Jahren sein.
Zitat:Objektorientierte Programmierung ist aber nicht nur eine Frage des Stils, wobei die Klassen-Objekte bestimmte Programmierweisen erfordern (in LV als auch in Text) und gleichzeitig die Arbeitsweise erleichtern.Letzteres ist auf jeden Fall ein Grund, LVOOP doch zu machen.
Objektorientiertes Programmieren mit LV - unicorn - 10.08.2009 15:49
Eine einfache Multiplikation für mein Bildbeispiel zeigt, dass wir es mit 747 MB zu tun haben.
Die möchte bestimmt niemand als Datenfluss von VI zu VI schicken. Und es wird auch klar, dass man davon in der Regel nur ein Objekt gleichzeitig im Speicher hat. Ich gehe mal von einer üblichen PC-Konfiguration aus.
Wenn es als Datenfluss nicht geht, scheidet eine Klasse zunächst aus.
Objektorientiertes Programmieren mit LV - eg - 10.08.2009 15:52
Wenn es nun so ist, dann würde ich es aus dem RAM in eine oder mehrere Dateien auslagern.
Objektorientiertes Programmieren mit LV - Y-P - 10.08.2009 15:54
Bin mal gespannt, wann der LabVIEW-Advanced II - Lehrgang endlich mal kommt. Dort soll es nämlich genau um LVOOP gehen. Vielleicht kann ich dann auch von LVOOP überzeugt werden (wenn ich verstehe, was das Ganze soll und wie es funktioniert).
Gruß Markus
Objektorientiertes Programmieren mit LV - unicorn - 10.08.2009 16:08
Stell Dir vor Du hast einen komplexen Messstand und Du kannst oder möchtest nicht immer davor sitzen, um an dem Programm für den Messstand zu arbeiten. Also baust Du ein virtuelles Instrument statt der realen Datenerfassung und an jeder stelle, wo der Messstand konfiguriert, Daten erfasst werden, Daten gespeichert werden kann ein Case hin, der je nach einem Wert in der Konfigurationsdatei das eine oder das andere Instrument benutzt. Etwas aufwändig.
Nun wird eine Variante des Messstandes gesbaut (andere Geräte gleich Funktionalität) und es kommen neue Anforderung an das was getan werden muss hinzu. Jetzt wird es schon ziemlich aufwändig die Ganzen Cases zu aktualisieren.
Nimm ein Klasse für jeden Messstand und das virtuelle Gerät, die von einer Basisklasse abgeleitet werden. Dann gibt nur noch eine Case-Struktur in der die Klasse nach Lesen der Konfiguration eingestellt wird. Das ganze Programm enthält keine Cases mehr sondern nur noch die VIs (Methoden) der Basisklasse. LV übernimmt die Entscheidung, welches VI jeweils benutzt wird.
Natürlich musst Du immer die VI (Methoden) aller Klassen programmieren. Das kann Dir niemand abnehmen egal ob Du nun Cases oder Klassen verwendest. Mit Klassen behälst Du in jedem Falle den Überblick was noch fehlt.
Objektorientiertes Programmieren mit LV - IchSelbst - 10.08.2009 16:15
' schrieb:Eine einfache Multiplikation für mein Bildbeispiel zeigt, dass wir es mit 747 MB zu tun haben.
Die möchte bestimmt niemand als Datenfluss von VI zu VI schicken. Und es wird auch klar, dass man davon in der Regel nur ein Objekt gleichzeitig im Speicher hat. Ich gehe mal von einer üblichen PC-Konfiguration aus.
Wenn es als Datenfluss nicht geht, scheidet eine Klasse zunächst aus.
Kann ich auch von folgendem ausgehen: Daten, die in einer Klasse liegen - ob als private oder public - werden nicht mehr (so oft) kopiert?
Wenn ich also ein größerer 2D-Array habe, das bearbeitet werden muss, dann wird das ja mit normalem DF ständig (naja sagen wir sehr oft) kopiert. Was viel Arbeit macht. Ich könnte mir durchaus vorstellen, dass, liege dieses Array als private in einer Instanz, erheblich Kopierarbeit gespart werden könnte.