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!
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.
<!--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).
' 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
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
15.07.2010, 11:21 (Dieser Beitrag wurde zuletzt bearbeitet: 15.07.2010 11:22 von IchSelbst.)
<!--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.
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).
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 ).
In theory, there is no difference between theory and practice; In practice, there is.
<!--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 ).[/quote]
Stichwort Reference-Pattern Lohnt sich manchmal über den Tellerrand hinaus zu schauen.
<!--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).
' 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 mich
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
15.07.2010, 13:00 (Dieser Beitrag wurde zuletzt bearbeitet: 15.07.2010 13:38 von abrissbirne.)
<!--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 mich
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 muss
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.
).
Lohnt sich manchmal über den Tellerrand hinaus zu schauen.