' schrieb:Hm, und ohne dass man globale Variablen oder Ähnliches verwendet? Unten redest Du auch immer von "Klassen". Ich dachte, das ist dann automatisch LVOOP?!
Eine Klasse ist, wie du ja weist, eine Ansammlung von Methoden, Events, Propertys und Feldern, also gekapselten Daten. Genau dieses kannst du auch mit einem SubVI machen - und zwar so, dass kein Außenstehender was von den Methoden und Feldern sieht. Propertys kann man durch Enumeratoren und Variant-Ein/Ausgängen realsieren. "Globale Variablen" kann man auch mit einem SubVI machen: Schieberegister in While-Schleife.
Was ich als Klasse bezeichne, ist ein SubVI mit einer Statemachine (das sind die Methoden), einem Queue-Lesen-Element (das ist das SubVI-Aufrufen) und einer While-Schleife außenherum. Die While-Schleife enthält Schieberegister, die die Felder (gekapselten Daten) enthalten. Jetzt hast du auf höchster Ebene in dem SubVI (in der Klasse) alle benötigten Daten.
Zitat:Allerdings hat das Kommunikations-VI ja jetzt keinen Zugriff auf dieses Array, da es in den privaten Daten der Klasse liegt. Entweder kann ich das als globale Variable machen (unschön wegen Datenkapselung, oder?), oder selber wieder in eine Queue legen (was dann zu einer Queue mit einem Array von Queues führt - nicht grade elegant), oder es geht irgendwie anders und ich sehe das nur nicht.
Globale Variablen sind sehr schlecht. Dieses Problem wird durch das Schieberegister gelöst.
Zitat:Warum ich das ganze als Klasse machen wollte, war, dass ich dachte, ich könnte es als Singleton implementieren. D.h., ein VI fordert die Kommunikation an und bekommt eine "Referenz" darauf und kann jetzt Queues als Listener registrieren und andere Kommunikation machen. Jetzt wird ein anderes VI gestartet, dass die Kommunikation auch anfordert. Da sie schon existiert, bekommt es nur eine Referenz auf das schon existierende Objekt zurück und kann damit ganz normal weitermachen (Ich hatte gedacht, das als Mischung zwischen den Beispielen Grundlagen->Objektorientiert->Design Pattern.lvproj und Grundlagen->Objektorientiert->ReferenceObject.lvproj zu implementieren).
Dieses Denken ist oop-gerecht. Das geht in LV, das ein Denken nach dem Datenflußprinzip erfordert, aber eigentlich nicht.
Zitat:Jetzt noch zum Starten des kontinuierlich laufenden VIs: Da ich es ja in verschiedenen VIs dynamisch verwenden wollte, kann ich es eigentlich nicht in einem VI ablegen, denn dann würde es ja beendet, wenn dieses VI beendet wird, obwohl vielleicht ein anderes VI noch darauf zugreift. Ich hatte deshalb gedacht, die Klasse bekommt eine StartCommunication-Methode, die dann über eine Referenz auf das RS232-VI dieses startet. Aber das ist auch nicht so richtig schön, finde ich.
Deswegen legt du die Klasse einfach auf das MainVI als paralleles SubVI. Dann läuft es wie ein eigener Prozess innerhalb deiner LV-Applikation.
Gesteuert wird dieses parallele SubVI durch eine einzige Queue. Eine Queue macht nichts weiter als einen Datenfluss imaginär - also im BD unsichtbar - zu realisieren. Dieser Queue bedienen sich alle die VIs, die die RS232-Kommunikation nutzen wollen. Wie der Datentyp der Queue aussieht - da bist du völlig frei.
Zitat:Wenn ihr wollt, kann ich mal ein Beispiel-Projekt hochladen, wo ich die eigentliche Kommunikation rausnehme, damit ihr mal seht, wie das momentan aussieht.
Gute Idee.
