LabVIEWForum.de

' schrieb:Ich habe noch den Eindruck, dass das sehr viel Funktionalität an einem Ort vereint, was auch meiner Programmiererfahrung (ok, nicht LabVIEW) meistens eher von Nachteil ist.

Mit "einem Ort" meinst du jetzt z.B. ein einziges SubVI. So gesehen hast du Recht. Viel in einem SubVI/Function ist schlecht. In wie weit man aber die vielen Sachen in SubVIs auslagert, steht auf einem anderen Blatt. Meine Intension ging eher dort hin, zu sagen: Für das Viele unterhalb einer bestimmten Ebene gibt es nur einen einzigen Einsprungpunkt - nämlich z.B. die Instanz.

Zitat:Allerdings würde ich eher nicht dazu tendieren, das eine "Klasse" zu nennen, denn (zumindest, wie ich das bisher verstehe) es fehlen hier elementare Dinge, die für mich eine Klasse ausmachen, wie Vererbung, Polymorphie, late binding, etc. Für mich ist das eher ein Modul, ein bisschen wie das, was man in C in einer Datei kapselt ohne dass man dafür OOP verwenden würde. Aber letztlich kommt das wahrscheinlich auf die Definition an.

Ich gebe dir hier prinzipiell Recht: Warum sollte ich aber eine Klasse im Sinne von OOP/LVOOP machen, wenn ich die vorerst nie wieder so verwenden werde.

Zitat:Könnte man ein solches permanent laufendes VI jetzt eigentlich auch reentrant machen und damit z.B. gleichzeitig auf verschiedenen COM-Ports operieren lassen? Ich bin mir noch nicht sicher, ob ich das brauchen würde, aber es klingt verlockend.

siehe eg.

Zitat:Das Beispiel, dass Du gepostet hast führt ja - wenn ich das richtig verstehe - immer nur eine Funktion aus und wartet dann wieder, bis ein neuer Befehl reinkommt, bevor es wieder was tut. Mein Programm müsste ja permanent samplen.

Das Beispiel sampled kontunuierlich (soll's zumindest) - und zwar im Raster von 50ms. Alle 50ms werden also die Queue überprüft und die in der vergangenen Zeit aufgelaufenen Samples gelesen und weiterverarbeitet. Ob von diesen 50ms-Raster nun z.B. mal 10 Stück wes wegen auch immer ausfallen, spielt für das Samples keine Rolle. Die Daten werden - ob Daq oder VISA - im Hintergrund gespeichert.

Zitat:Trotzdem müsste das Sampling auf die Daten zugreifen, die auch von den anderen Methoden manipuliert würden. Ich könnte jetzt natürlich immer, wenn kein Befehl anliegt in den Sample-State gehen, aber das hätte den Nachteil, dass das Sampling unterbrochen würde wenn eine andere Funktion länger bräuchte, was auch nicht schön wäre. Kann man das irgendwie geschickt parallelisieren?

Bei der Unterbrechung kommt es darauf an. Kommen die Daten z.B. vom Daq, sampelt eigentlich nicht das SubVI, sondern der Daq. Der macht das im Hintergrund, also parallel. Das SubVI holt sich lediglich die bereitgestellen Daten. Daher ist das Zeitverhalten im SubVI eigentlich unkritisch.

Zitat:- Wo würde man die Parameter- und Result-Queues halten? Wenn ich Deinen Code richtig verstehe, holst Du sie Dir nach Namen, oder?

Eigentlich muss man die nirgens halten. Eine Queue bekommt einen "logischen Namen". Alleine die Tatsache, dass du ein "Queue anfordern" mit diesem Namen an Eingang verwendest, reichst bereits, dass alle, die das so machen, die selbe Queue verwenden. Oberflächlich betrachtet sieht es also aus, als ob die Queue(Referenz) nirgens gehalten würde. Tatsächlich gehalten wird sie im Hintergrund in LV.
Ich hab das mit dem SubVI, das die Queue erstellt und für alle Verwender die gleiche Referenz zurück gibt, ja nur deswegen gemacht, damit ich nicht 100mal in den SourceCode den String "MeineQueue" schreiben muss. Außerdem kann ich jetzt Suchen lassen, wer denn nun genau diese eine Queue verwendet.

Zitat:Gibt es zu der Sprache eigentlich schon irgendwelche akademischen Abhandlungen, die die Paradigmen mal im Lichte der Informatik betrachten? Mir waren aus dem Studium funktionale Sprachen bekannt (wenn auch mehr theoretisch als praktisch), aber mit Datenflusssprachen bin ich vor LabVIEW noch nie in Berührung bekommen.

Keine Ahnung.


Nochwas zu OOP/LVOOP:
Das ist ja alles schön und gut. Einen richtigen OOP-Ansatz zu machen für z.B. eine Sample-Klasse kommt für mich aber nicht in Frage. Selbst in der anderen Programmiersprache, also in Delphi, hab ich das in 10 Jahren nicht in dieser Art gebraucht. Dort hab ich natürlich auch Klassen erstellt mit Propertys, Events etc. etc. Aber warum Aufwand machen, für ein Sodoku-Einzelfeld eine Klasse schreiben und die wieder in die Sodoku-Klasse einbinden, wenn die Sodoku-Klasse die Einzelfelder auch in einen Array selbst verwalten kann.

Und zu Instanzen:
Instanziert wird in LV, indem ein SubVI auf das Blockdiagramm plaziert wird.

' schrieb:Nachtrag: Es fehlt auch Instanziierung, oder? Es sei denn man würde das VI reentrant machen (würde das gehen?)

Ach hier hab ich das gelesen. Kein Wunder, dass ich das oben nicht mehr gefunden habe. ^_^

Instanzierung in LV: SubVI auf Blockdiagramm positionieren. Mehrere Instanzen: Reentrant.

Das geht natürlich mit allem, z.B. CanOpen-gesteuerten Netzteilen. Mach dir ein SubVI (Klasse), das ein Netzteil komplett steuern kann. Diesem SubVI gibt du dann einen Parameter (Nummer des Netzteiles, aus der dann z.B. die Busadresse berechnet wird) und machst das SubVI reentrant. Jetzt setzt du das reentrante VI zweimal hin - und schon hast du zwei Netzteile.

' schrieb:Warum sollte ich aber eine Klasse im Sinne von OOP/LVOOP machen, wenn ich die vorerst nie wieder so verwenden werde.

Naja, ich habe die Erfahrung gemacht, dass sich das dann später oft doch auszahlt, besonders wenn man konsequent objektorientiert entwirft. Aber ich gebe zu, dass es nicht für alle Anwendungen optimal ist und es sicher auch für vieles besser und/oder effizienter ist, einen anderen Ansatz zu wählen. So gesehen wollte ich auch nicht Deinen Ansatz kritisieren, sondern nur sagen, dass für mich da der Name "Klasse" erstmal verwirrend war.

Zu Instanziierung:

' schrieb:siehe eg.

Das klingt ja gut. Allerdings sollte man in diesem Fall die Queues wohl nicht mehr einfach über Namen verwalten, oder? Dann würde man wahrscheinlich doch eher die Queues beim Start dem VI übergeben, damit jede Instanz seine eigene Queue hat. Das mit den Namen ist mir auch noch etwas unheimlich, da ich ja da nie sicherstellen kann, wer da drauf schreibt...

' schrieb:Das Beispiel sampled kontunuierlich (soll's zumindest) - und zwar im Raster von 50ms. Alle 50ms werden also die Queue überprüft und die in der vergangenen Zeit aufgelaufenen Samples gelesen und weiterverarbeitet. Ob von diesen 50ms-Raster nun z.B. mal 10 Stück wes wegen auch immer ausfallen, spielt für das Samples keine Rolle. Die Daten werden - ob Daq oder VISA - im Hintergrund gespeichert.

Ah, ok, jetzt sehe ich es auch. Ja, solange es nicht wirklich länger ausfällt, würde es durch den VISA-Puffer wohl abgefangen. Allerdings ist das bei mir schon ziemlich zeitkritisch. Ich bekomme pro ms 10 Bytes rein und ich darf da auch eigentlich nichts verlieren.

' schrieb:Und zu Instanzen:
Instanziert wird in LV, indem ein SubVI auf das Blockdiagramm plaziert wird.

Ok... das funktioniert aber dann nur, wenn das VI reentrant ist und kontinuierlich ausgeführt wird, oder? Wenn es nicht kontinuierlich ausgeführt würde, und seine Daten nur in einem uninitialisierten Schieberegister speichern würde, dann würde man doch bei jedem Aufruf wieder dieselbe Instanz bekommen...

Nochmal danke für Deine ausführlichen Antworten und die rege Diskussion. Ich habe durch diesen Thread schon eine Menge gelernt!

Gruß,

Tobias

' schrieb:Das klingt ja gut. Allerdings sollte man in diesem Fall die Queues wohl nicht mehr einfach über Namen verwalten, oder? Dann würde man wahrscheinlich doch eher die Queues beim Start dem VI übergeben, damit jede Instanz seine eigene Queue hat. Das mit den Namen ist mir auch noch etwas unheimlich, da ich ja da nie sicherstellen kann, wer da drauf schreibt...

In dem Fall gebe ich jeder Instanz einen Namen. Wenn die Instanz etwas über ne Queue schickt, dient dieser Name als Header. Dann kann man ja beim Parsen des Pakets erkennen wo das herkam.

' schrieb:Ich bekomme pro ms 10 Bytes rein und ich darf da auch eigentlich nichts verlieren.

10 Byte/ms ist schon viel bzw. schnell. Bei Millisekunden-Raster hat ein Programm (bedenke: da ist auch noch ein FP und User-Events) schon zu kämpfen. Aber: 10byte/ms geht.

Zitat:Ok... das funktioniert aber dann nur, wenn das VI reentrant ist und kontinuierlich ausgeführt wird, oder?

[*grübel*]
Nein, nicht unbedingt. Ein reentrantes SubVI muss nicht zwangsläufig kontinuierlich ausgeführt werden. Es gibt aber den größeren Sinn, es kontinuierlich laufen zu lassen.

Zitat:Wenn es nicht kontinuierlich ausgeführt würde, und seine Daten nur in einem uninitialisierten Schieberegister speichern würde, dann würde man doch bei jedem Aufruf wieder dieselbe Instanz bekommen...

Jawohl. Das kann ja auch genau so gewollt sein.
Die selbe Instanz mit den Daten vom letzten Aufruf. Aber nur unter der Voraussetzung, dass genau das selbe SubVI aufgerufen wird. Das selbe bedeutet hier z.B.: Positioniert in einer For-Schleife (also an einer eineindeutig definierten Stelle im BD)