Objekt in globaler Variable

Hallo zusammen

Fange nach LabView 7 gerade mit LabView 2011 an.
Genauer gesagt geht es gerade um OOP.
Habe mit Klassen von C++ her schon etwas Erfahrung.

Wenn ich ein Objekt erzeuge kann ich dann den Ausgang in eine globale Variable legen und dann von überall auf das Objekt zugreifen?
Funktionieren sollte es doch, allerdings handel ich mir damit irgendwelche Probleme ein?

Vielen Dank im Voraus.
MfG Stephan

Zugreifen kannst du schon von überall aus, nur wird bei jedem Lesen eine Kopie deines Objekts angelegt. Beim Schreiben kannst du dir eine Race Condition einfangen.
Die globale Variable ist zwar eine statische Referenz, du kommst aber nur by-Value an den Inhalt.

Ich vermute du suchst eine Objekt by-Reference. Dazu kannst du einmal auf dein Datenobjekt eine DVR erstellen und diese DVR-Reference mittels globaler Variable anderen Programmteilen zugänglich machen (FGV wäre aber wohl noch "schöner".)

Vielen dank erst mal.
Vielleicht kurz beschrieben was mein Ziel ist, eventuell gibt es eine noch bessere Umsetzung.
Ich habe, sagen wir mal ein großes über die Jahre gewachsenes Programm.
Um am Prüfstand (nur exe installiert) sporadisch auftretende Fehler besser untersuchen zu können, will ich eine Klasse die mir einfach eine Log-Datei schreibt.

Ich habe mir das wie folgt vorgestellt:
Klasse log welche als Eigenschaft den Dateinamen der LogDatei hat, eine Init Funktion und viele verschiedene Schreibmethoden für String, Integer, Double, verschiedenen Arrays, ...
Damit ich das Klassen Objekt nicht durch die ganzen Vis von oben nach unten verdrahten muß, kam mir die Idee mit der globalen Variablen vom Objekt selbst, was wohl nicht ganz so gut ist.
Wenn ich jetzt DVR verwende und es richtig verstanden habe, würde ich mir in der Init Funktion eine Refrenz vom Objekt erstellen und diese in einer globalen Variablen ablegen und alle Member Funktionen der Klasse würden dann intern nur mit dieser Referenz arbeiten anstatt dem Objekt selbst.
Ist dies so richtig, bzw verständlich was ich meine?

FGV sagt mir leider gar nichts.
Nach kurzem googlen kann ich mir darunter etwas vorstellen jedoch ist mir nicht ganz klar wie ich dies hier einsetzen soll?
War gemeint das Objekt in dem FGV VI zu erstellen und für jeder Memberfunktion ein Case in der FGV zu erstellen?
Wenn dies der Fall ist kann ich mir das OOP doch gleich sparen, oder nicht?

Mein Reden.
Ich habe bisher noch keine Aufgabenstellung gefunden, bei der es notwendig gewesen wäre, LVOOP zu verwenden, bzw. die man auch sonst ohne Probleme lösen könnte.
"Gefühlsmäßig" verwenden das auch keine 5 % der LabVIEW-User, daher kennen sich hier wohl auch die wenigsten damit aus.

Gruß Markus

(20.06.2012 06:22 )Stephan schrieb:  Wenn dies der Fall ist kann ich mir das OOP doch gleich sparen, oder nicht?

(20.06.2012 06:34 )Y-P schrieb:  Mein Reden.
Ich habe bisher noch keine Aufgabenstellung gefunden, bei der es notwendig gewesen wäre, LVOOP zu verwenden, bzw. die man auch sonst ohne Probleme lösen könnte.
"Gefühlsmäßig" verwenden das auch keine 5 % der LabVIEW-User, daher kennen sich hier wohl auch die wenigsten damit aus.

Na ja, das dachte ich früher bei C/C++ auch.
Allerdings gibt es schon Vorteile wie beispielsweise Vererbung, Daten sind im Objekt (private) geschützt, Übersichtlichkeit, ...

Wir haben hier schon etwas größere Projekte (eine komplette GUI + Testschritte) und da erhoffe ich mir von LVOOP bessere Übersicht (alles was in einer Klasse ist gehört zusammen) und vorallem bessere Wiederverwendbarkeit.

Das alles auch ohne LVOOP gelöst werden kann ist klar, allerdings wir könnten heute auch noch alles in Assembler programmieren.
Machbar ist vieles, dies Frage ist ob es übersichtlich, gut und schön gelöst ist.

Wenn hier kaum einer in LVOOP arbeite, gibt es dann noch ein gutes deutsches LVOOP Forum?

MfG Stephan

Ich habe hier auch große Projekte und mit der Übersicht habe ich auch keine Probleme. Der Vergleich mit Assembler passt meiner Meinung nach nicht. Eher z.B. der Vergleich ob man MySQL oder PostgreSQL nimmt.
Das ist meiner Meinung nach eher eine Frage des Geschmacks.
Ein LVOOP-Forum kenne ich leider nicht.
Aber vielleicht interessiert Dich das:
http://sine.ni.com/tacs/app/overview/p/a...8/id/1587/

Gruß Markus

(20.06.2012 07:32 )Stephan schrieb:  Wir haben hier schon etwas größere Projekte (eine komplette GUI + Testschritte) und da erhoffe ich mir von LVOOP bessere Übersicht (alles was in einer Klasse ist gehört zusammen) und vorallem bessere Wiederverwendbarkeit.

Das alles auch ohne LVOOP gelöst werden kann ist klar, allerdings wir könnten heute auch noch alles in Assembler programmieren.
Machbar ist vieles, dies Frage ist ob es übersichtlich, gut und schön gelöst ist.

Wenn hier kaum einer in LVOOP arbeite, gibt es dann noch ein gutes deutsches LVOOP Forum?

MfG Stephan

Anzeige

Hi Stephan
Wenn ich Deine Angaben richtig verstanden habe, handelt es sich bei den Instanzen Deiner Log-Klasse geplant um eine passives Datenobjekte, die von sich aus nicht tun, sondern von der Applikation zum Leben erweckt werden.

Es spricht also im Prinzip nicht dagegen es in einer Globalen Variablen zu speichern (Nur dass man aus Prinzip keine globlane Variablen benutzen soll.) , wenn man einige Kleinigekeiten berücksichtigt:

Ich vermute, das Objekt öffnet die Datei nur einmal und speichert die Datei-Referenz. Dass sollte nur einmal zu Beginn des Programms geschehen. Dieses Objekt speicherst Du in der Globalen Variablen. Am Ende des Pogramms benutzt der letzte aktive Thread das Objekt, um die Datei ordentlich zu schliesen. Solltest Du die Datei zwischen durch schliessen und eine andere Datei öffnen wollen, sollte dass immer aus demselben Thread heraus geschehen. Alle anderen Lesen nur. An dieser Stelle musst Du mit Race-Conditions rechnen, mit denen man aber umgehen kann, wenn das nicht zu oft geschieht.

Aller anderen Threads benutzen nur die VIs zum Lesen von der und Schreiben in die Log-Datei. Das ist dann unproblematisch.

Du solltest aber immer im Sinn haben, dass es in LabVIEW keine Variablen gibt, sondern nur Datenquellen und Datensenken. Datenfluß heisst das Programmierparadigma von LabVIEW. LVOOP-Objekte werden, genau wie allen anderen Datentypen auch, an Drahtabzweigen geklont!

Gruß Holger

@BNT / Holger
So im großen und ganzen soll mein Logger aussehen wie Du beschrieben hast.
Allerdings wird bei jedem Schreibzugriff die Datei geöffnet und wieder geschlossen.

Threads werden doch in Labview durch parallele Schleifen implementiert, oder liege ich da flasch?
Wenn dem so ist, habe ich nur einen Thread und somit doch eigentlich auch kein Problem mit Race Conditions.

Das mit den globalen Variablen ist mir bekannt, allerdings gibt es Dinge wo globale Variablen das Leben/Programmieren sehr vereinfachen.

Das es keine Variablen gibt sondern nur Quelle und Senke, war mir so jetzt momentan nicht mehr bewußt.
Danke.

MfG Stephan

(20.06.2012 09:55 )Stephan schrieb:  Threads werden doch in Labview durch parallele Schleifen implementiert, oder liege ich da flasch?
Wenn dem so ist, habe ich nur einen Thread und somit doch eigentlich auch kein Problem mit Race Conditions.

Ja und Nein... LabVIEW führt ggf. Code auch dann nebenläufig aus, wenn keine Abhängigkeit zwischen den Teilen bestehen. D.h. liegen Nodes ohne Datenflußabhängigkeit auf einem Blockdiagramm (mit oder ohne Schleife/n) werden sie auch parallel ausgeführt (wobei es da auch noch Details in den VI Executioneinstellungen gibt).

Wenn du schon objekt orientiert programmieren kannst, dann empfehle ich GOOP. Das kommt der OOP IMHO am nächsten, da mit Objekten gearbeitet wird (by Reference). GOOP4 kapselt die Objekte in DVRs, was das ganze auch um einiges performanter macht als mit GOOP3 Klassen.

(20.06.2012 06:34 )Y-P schrieb:  Mein Reden.
Ich habe bisher noch keine Aufgabenstellung gefunden, bei der es notwendig gewesen wäre, LVOOP zu verwenden, bzw. die man auch sonst ohne Probleme lösen könnte.

Kleines Beispiel:
um unsere DUTs vor den Tests zu konfigurieren gibt es verschiedene Treiber. Alle Treiber besitzten eine gleiche Anzahl Methoden (lesen, schreiben, reset, uvm), besitzen aber unterschiedliche Implementierungen/benötigen unterschiedliche APIs (C++ API, .NET Treiber v3.5, .NET Treiber v4.0 u.a.). Ich könnte jetzt (so wie wir es zu Beginn hatten) so viele VIs generieren wie es Treiber-Methoden gibt und innerhalb meine dedizierten Treiber-VIs aufrufen (über Fallunterscheidung). Nur muss ich dann jedes mal wenn ein neuer Treiber hinzukommt jedes dieser VIs öffnen und eine Fallunterscheidung hinzufügen, so dass der neue Treiber benutzt wird. Das ist alles natürlich kein Problem und funktioniert auch. Die Wartbarkeit leidet zwar, aber es geht.
Oder aber ich setzte das ganze OO um:
Man schreibe sich eine Basis-Klasse, die nur die leeren Methoden zur DUT Kommunikation enthält plus ein paar zusätzliche, generische Methoden.
Die vererbt man an dedizierte Treiber Kind-Klassen und dort drin implementiert man die explizite Kommunikation. Zur Laufzeit wird dann die Kind-Klasse instanziert, für die gerade ein Test läuft.
So weit so gut. Bis hier hin hat man sich ohne Frage mehr Arbeit aufgehalst.
Kommt jetzt aber ein weiterer Treiber hinzu, müssen die Methoden zur Kommunikation geschrieben werden (was auch im klassischen Ansatz gemacht werden muss). Nur muss ich jetzt an nur genau einer Stelle im bestehenden Code eine Anpassung vornehmen, um den neuen Treiber einzubinden!

(20.06.2012 08:23 )Y-P schrieb:  Eher z.B. der Vergleich ob man MySQL oder PostgreSQL nimmt.

Dieser Vergleich passt so auch nicht ganz: MySQL oder PostgreSQL (was ich nicht kenne) sind beides Datenbanken und beide werden über irgendwelche Queries abgefragt, nur die Syntax wird verschieden sein.

Der Vergleich OOP <-> Assembler passt vielleicht auch nicht ganz, da ein Programmierkonzept mit einem Abstaktionsgrad verglichen wird.