INFO: Dieses Forum nutzt Cookies...
Cookies sind für den Betrieb des Forums unverzichtbar. Mit der Nutzung des Forums erklärst Du dich damit einverstanden, dass wir Cookies verwenden.

Es wird in jedem Fall ein Cookie gesetzt um diesen Hinweis nicht mehr zu erhalten. Desweiteren setzen wir Google Adsense und Google Analytics ein.


Antwort schreiben 

GOOP <-> Klassisch



Wenn dein Problem oder deine Frage geklärt worden ist, markiere den Beitrag als "Lösung",
indem du auf den "Lösung" Button rechts unter dem entsprechenden Beitrag klickst. Vielen Dank!

15.07.2010, 09:53
Beitrag #1

oenk Offline
LVF-Stammgast
***


Beiträge: 361
Registriert seit: May 2005

>= 7.1
2004
EN

3018
Schweiz
GOOP <-> Klassisch
Hallo LabVIEW Enthusiasten

folgende Situation:
Ich habe ein PXI-System mit mehreren Einschubkarten. Manche davon kommen mehrmals vor.
Für jede Karte gibt es ein Treiber.vi (als ActionEngine implementiert, der nach dem initialisieren den DaqMx-Task in einen ShiftRegister speichert), ein ParallelerTask.vi (der das Treiber.vi aufruft und die Daten der Karte liest, basierend auf dem DaqMx-Task der jeweiligen Karte) und ein RingPuffer.vi (das die Daten vom ParallelerTask.vi zwischenspeichert). Das RingPuffer.vi wird in einem weiteren parallelen Task LeereRingPuffer.vi ausgelesen, um die Daten auf der HDD abzuspeichern. Das ParallelerTask.vi wird vom Hauptprogramm dynamisch, über VI-Server aufgerufen.
Momentan sind gleiche Karten zusammengefasst und die Daten sind gekoppelt. Jetzt möchte ich aber das gerne entkoppeln und das Treiber/RingPuffer Paar für jede Karte einzeln erstellen. Zum einen, um reduzierte Messgeräte (weniger Einschubkarten) schneller erstellen zu können und zum anderen nur die Karten anzusprechen, die für den momentanen Test benutzt werden.

Mit GOOP würde ich mir jetzt eine PXI-Class erstellen, die den parallelen Task und den RingPuffer als Methode implementiert. Von dieser Klasse könnte ich mir dann die n-Instanzen meiner gleichen Karte erstellen und hab mir einen Haufen Programmier- und vor allem Wartungsaufwand gespart. (das dynamische Aufrufen über VI-Server würde dann nicht mehr gehen, aber das steht auf einem anderen Blatt)

Wie würdet ihr das klassisch lösen, so dass es nur ein "RingPuffer.vi" und ein "ParallelerTask.vi" gibt, welches ich aber dynamisch, je nach Anzahl der vorhandenen Karten, laden und erstellen könnte. Das RingPuffer.vi muss dabei wie gesagt im ParallelerTask.vi und im LeereRingPuffer.vi aufgerufen werden können.
Beim OOP Ansatz kann ich mir die Klassen einfach mehrmals instanzieren und schon hab ich sie doppelt, dreifach, x-fach. Wie mach ich das aber klassisch?

Besten Dank für eure Ideen
Christian

In theory, there is no difference between theory and practice; In practice, there is.

Chuck Reid
Alle Beiträge dieses Benutzers finden
Diese Nachricht in einer Antwort zitieren to top
Anzeige
15.07.2010, 10:39
Beitrag #2

IchSelbst Online
LVF-Guru
*****


Beiträge: 3.687
Registriert seit: Feb 2005

11, 14, 15, 17, 18
-
DE

97437
Deutschland
GOOP <-> Klassisch
<!--quoteo(post=101913:date=15.07.2010 , 10:53:30:name=<<oenk>>)--><div class='quotetop'>ZITAT(<<oenk>> @ 15.07.2010 , 10:53:30) [url=index.php?act=findpost&pid=101913][/url]</div><div class='quotemain'><!--quotec-->Beim OOP Ansatz kann ich mir die Klassen einfach mehrmals instanzieren und schon hab ich sie doppelt, dreifach, x-fach. Wie mach ich das aber klassisch?[/quote]Genauso: Einfach mehrfach auf das BD legen. Voraussetzung ist natürlich, dass die VIs reentrant sind.

Warum willst du es denn klassisch machen, wenn es auch mit OOP geht?

Jeder, der zur wahren Erkenntnis hindurchdringen will, muss den Berg Schwierigkeit alleine erklimmen (Helen Keller).
Alle Beiträge dieses Benutzers finden
Diese Nachricht in einer Antwort zitieren to top
15.07.2010, 10:44
Beitrag #3

oenk Offline
LVF-Stammgast
***


Beiträge: 361
Registriert seit: May 2005

>= 7.1
2004
EN

3018
Schweiz
GOOP <-> Klassisch
' schrieb:Genauso: Einfach mehrfach auf das BD legen. Voraussetzung ist natürlich, dass die VIs reentrant sind.
OK, wie mach ich es dann aber dynamisch. Dh ohne den Code anzufassen? OOP wäre ja in einer FOR-Schleife n-fach die Create.vi Methode aufrufen und dann die Instanzen weiterverwenden.

' schrieb:Warum willst du es denn klassisch machen, wenn es auch mit OOP geht?
Würde ich ja schon, aber das zieht halt so einiges nach sich. GOOP müsste beschafft werden, mein Chef müsste überzeugt werden, dass GOOP sinnvoll ist und wir es brauchen etc pp Big Grin
Wie es halt so läuft...
Wenn mir nichts schlaueres einfällt, läuft es wohl aber darauf hinaus....

In theory, there is no difference between theory and practice; In practice, there is.

Chuck Reid
Alle Beiträge dieses Benutzers finden
Diese Nachricht in einer Antwort zitieren to top
15.07.2010, 11:21 (Dieser Beitrag wurde zuletzt bearbeitet: 15.07.2010 11:22 von IchSelbst.)
Beitrag #4

IchSelbst Online
LVF-Guru
*****


Beiträge: 3.687
Registriert seit: Feb 2005

11, 14, 15, 17, 18
-
DE

97437
Deutschland
GOOP <-> Klassisch
<!--quoteo(post=101924:date=15.07.2010 , 11:44:09:name=<<oenk>>)--><div class='quotetop'>ZITAT(<<oenk>> @ 15.07.2010 , 11:44:09) [url=index.php?act=findpost&pid=101924][/url]</div><div class='quotemain'><!--quotec-->OK, wie mach ich es dann aber dynamisch. Dh ohne den Code anzufassen? OOP wäre ja in einer FOR-Schleife n-fach die Create.vi Methode aufrufen und dann die Instanzen weiterverwenden.[/quote]Dacht ich mir's doch. Tongue

Analog: Aufruf in der FOR-Schleife per VI-Server. Was du bei OOP als Instanz bezeichnest, wäre hier die VI-Referenz. Du musst dem VI-Server nur mitteilen, dass das VI als reentrant auszuführen ist.

Wie es bei OOP genau geht, weiß ich nicht. Schön wäre, wenn man die Instanz-Referenz (also den Wire) überall im Programm unabhängig vom Datenfluss zur Verfügung hätte. Dann kann man quasi per Methodenaufruf die Klasse was machen lassen, sich Daten holen etc. Bei diesem Verfahren, also eingebunden in den Datenfluss, würde die Klasse nicht kontinuierlich, also quasi wie als Standalone-Task, laufen.

Ich verwende immer folgendes Verfahren. Das "Klassen-VI" läuft als eigenständige Task im Hintergrund. Gesteuert wird sie per Queue. Daten liefern tut sie per Melder, aber auch per Queue und per FGV ist möglich. Dieses "Klassen-VI" kann per se reentrant verwendet werden. Meine "Klassen-VIs" sind keine OOP-Klassen, sondern sind klassisch realisiert.

Ich sehe bei OOP z.Z. lediglich den Vorteil, dass Instanz-spezifische Daten per se richtig gehandhabt werden (d.h., dass das Handling automatisch richtig geht). Willst du es klassisch machen, musst du dich selbst darum kümmern, dass deine Daten konsistent und Instanz-spezifisch gehandhabt werden. Das ist aber auf jeden Fall möglich.

Jeder, der zur wahren Erkenntnis hindurchdringen will, muss den Berg Schwierigkeit alleine erklimmen (Helen Keller).
Alle Beiträge dieses Benutzers finden
Diese Nachricht in einer Antwort zitieren to top
15.07.2010, 11:48
Beitrag #5

abrissbirne Offline
LVF-Stammgast
***


Beiträge: 480
Registriert seit: Aug 2007

LV2009, LV2010
2007
EN

66123
Deutschland
GOOP <-> Klassisch
Das kann man alles mit LVOOP machen. Dazu musst du ein paar Designpatterns kombinieren. Hier mal zwei Links:
http://decibel.ni.com/content/docs/DOC-2875
http://jabberwocky.outriangle.org/LabVOOP_...gn_Patterns.pdf

Oder du kannst die HGF_Base_Classes von BNT nutzen. Diese sind unter GPL veröffentlicht. Ein Link zur Präsentation:
http://www.docstoc.com/docs/23931273/Objec...ng-with-LabVIEW
Alle Beiträge dieses Benutzers finden
Diese Nachricht in einer Antwort zitieren to top
15.07.2010, 12:00
Beitrag #6

oenk Offline
LVF-Stammgast
***


Beiträge: 361
Registriert seit: May 2005

>= 7.1
2004
EN

3018
Schweiz
GOOP <-> Klassisch
' schrieb:Dacht ich mir's doch. Tongue

Analog: Aufruf in der FOR-Schleife per VI-Server. Was du bei OOP als Instanz bezeichnest, wäre hier die VI-Referenz. Du musst dem VI-Server nur mitteilen, dass das VI als reentrant auszuführen ist.
OK, an das hab ich auch schon gedacht. Was mach ich aber mit den RingPuffer.vis? Wie komme ich da an die Richtige Instanz im LeereRingPuffer.vi?

@abrissbirne: danke für die Links, muss ich mir mal anschauen. Wenn sie aber LVOOP behandeln, dann möchte ich das eher nicht machen. Ich persönlich finde "by reference" als OOP Ansatz besser als der "by value" Ansatz (wie in verschiedensten Threads schon erwähnt Cool).

In theory, there is no difference between theory and practice; In practice, there is.

Chuck Reid
Alle Beiträge dieses Benutzers finden
Diese Nachricht in einer Antwort zitieren to top
15.07.2010, 12:17
Beitrag #7

abrissbirne Offline
LVF-Stammgast
***


Beiträge: 480
Registriert seit: Aug 2007

LV2009, LV2010
2007
EN

66123
Deutschland
GOOP <-> Klassisch
<!--quoteo(post=101942:date=15.07.2010 , 13:00:18:name=<<oenk>>)--><div class='quotetop'>ZITAT(<<oenk>> @ 15.07.2010 , 13:00:18) [url=index.php?act=findpost&pid=101942][/url]</div><div class='quotemain'><!--quotec-->@abrissbirne: danke für die Links, muss ich mir mal anschauen. Wenn sie aber LVOOP behandeln, dann möchte ich das eher nicht machen. Ich persönlich finde "by reference" als OOP Ansatz besser als der "by value" Ansatz (wie in verschiedensten Threads schon erwähnt Cool).[/quote]
Stichwort Reference-Pattern Wink Lohnt sich manchmal über den Tellerrand hinaus zu schauen.
Alle Beiträge dieses Benutzers finden
Diese Nachricht in einer Antwort zitieren to top
15.07.2010, 12:50
Beitrag #8

IchSelbst Online
LVF-Guru
*****


Beiträge: 3.687
Registriert seit: Feb 2005

11, 14, 15, 17, 18
-
DE

97437
Deutschland
GOOP <-> Klassisch
<!--quoteo(post=101942:date=15.07.2010 , 13:00:18:name=<<oenk>>)--><div class='quotetop'>ZITAT(<<oenk>> @ 15.07.2010 , 13:00:18) [url=index.php?act=findpost&pid=101942][/url]</div><div class='quotemain'><!--quotec-->OK, an das hab ich auch schon gedacht. Was mach ich aber mit den RingPuffer.vis? Wie komme ich da an die Richtige Instanz im LeereRingPuffer.vi?[/quote]Im schlimmsten Falle über einen Enumerator.

Das ginge z.B. wie folgt:
Ein einem (1) VI liegen die Daten aller Instanzen. Das VI bekommt zusätzlich zu den funktionalen Parametern einen weiteren Parameter "Auswahl Instanz", den man als Enumerator o.ä. ausführen kann. ...

Selbstverständlich kann man auch SubVIs zu den "Klassen" als reentrant ausführen. Klassisch hast du dann also 2 Referenzen, die zusammengehören.

Nicht aus den Augen verlieren solltest du allerdings die Möglichkeit , es doch mit OOP zu machen.

Jeder, der zur wahren Erkenntnis hindurchdringen will, muss den Berg Schwierigkeit alleine erklimmen (Helen Keller).
Alle Beiträge dieses Benutzers finden
Diese Nachricht in einer Antwort zitieren to top
15.07.2010, 12:56
Beitrag #9

oenk Offline
LVF-Stammgast
***


Beiträge: 361
Registriert seit: May 2005

>= 7.1
2004
EN

3018
Schweiz
GOOP <-> Klassisch
' schrieb:Nicht aus den Augen verlieren solltest du allerdings die Möglichkeit , es doch mit OOP zu machen.

Danke IchSelbst und Abrissbirne für euren wertvollen (!) Kommentare.
Hab es mir nochmals durch den Kopf gehen lassen, mir eine Strategie überlegt und meinen Chef überzeugt. So wie es aussieht gibt es GOOP für michBig Grin

Es lässt sich sicher klassisch und auch sicher mit LVOOP bewerkstelligen. LVOOP lässt sich sicher "by value" und "by reference" realisieren. Wie mit so vielem gibt es immer eine persönliche Präferenz (die einen lieben Windows, die andere Linux und für einen dritten gibt es nur OS X). Ich persönlich habe mich sehr mit GOOP angefreundet.

vielen Dank nochmals
Christian

In theory, there is no difference between theory and practice; In practice, there is.

Chuck Reid
Alle Beiträge dieses Benutzers finden
Diese Nachricht in einer Antwort zitieren to top
15.07.2010, 13:00 (Dieser Beitrag wurde zuletzt bearbeitet: 15.07.2010 13:38 von abrissbirne.)
Beitrag #10

abrissbirne Offline
LVF-Stammgast
***


Beiträge: 480
Registriert seit: Aug 2007

LV2009, LV2010
2007
EN

66123
Deutschland
GOOP <-> Klassisch
<!--quoteo(post=101951:date=15.07.2010 , 13:56:37:name=<<oenk>>)--><div class='quotetop'>ZITAT(<<oenk>> @ 15.07.2010 , 13:56:37) [url=index.php?act=findpost&pid=101951][/url]</div><div class='quotemain'><!--quotec-->Danke IchSelbst und Abrissbirne für euren wertvollen (!) Kommentare.
Hab es mir nochmals durch den Kopf gehen lassen, mir eine Strategie überlegt und meinen Chef überzeugt. So wie es aussieht gibt es GOOP für michBig Grin

Es lässt sich sicher klassisch und auch sicher mit LVOOP bewerkstelligen. LVOOP lässt sich sicher "by value" und "by reference" realisieren. Wie mit so vielem gibt es immer eine persönliche Präferenz (die einen lieben Windows, die andere Linux und für einen dritten gibt es nur OS X). Ich persönlich habe mich sehr mit GOOP angefreundet.

vielen Dank nochmals
Christian[/quote]
Ich wollte lediglich die Diskussion mit deinem Chef vermeiden, da LVOOP nicht dazugekauft werden mussBig Grin

Was ich eigentlich auch noch sagen wollte. Es gibt gute Gründe, warum LVOOP byValue implementiert wurde. Schließlich bedient sich LabVIEW dem Datenfluss-Paradigma. Ein lesenswertes Dokument findest du hier:
http://zone.ni.com/devzone/cda/tut/p/id/3574
In den zuvor geposteten Links findest du Entwurfsmuster mit denen du auch auf LabVIEW Objekte referenzieren kannst, ohne den Datenfluss zu verletzen und somit Raceconditions zu vermeiden. Außerdem wird LVOOP immer weiterentwickelt, immer mächtiger und von NI. Für mich genügend Gründe nicht zu einem Fremdhersteller Toolkit, für das ich auch noch zahlen muss, zu wechseln.
Alle Beiträge dieses Benutzers finden
Diese Nachricht in einer Antwort zitieren to top
Antwort schreiben 


Möglicherweise verwandte Themen...
Themen Verfasser Antworten Views Letzter Beitrag
  Problem bei häufigem Aufruf von Open Goop Klasse Stargrove1 2 10.411 20.01.2010 12:44
Letzter Beitrag: Stargrove1
  GOOP eg 1 9.090 02.02.2007 23:02
Letzter Beitrag: eg
  GOOP Hilfe Apu 4 9.986 21.07.2006 14:55
Letzter Beitrag: eg

Gehe zu: