SubVi performance bei großen Datenstrukturen

Hallo zusammen,

in meiner Problemstellung habe ich mit großen arrays zu tun, möchte den Code aber einigermaßen sinnvoll strukturieren, sprich: SubVis verwenden. Damit LabVIEW nicht jeweils beim Betreten und Verlassen des SubVis eine Kopie der Daten erstellt, dadurch bei jedem Aufruf mehrere MB kopiert und so die Performance bzw. den verfügbaren Arbeitsspeicher "tötet", verwende ich den Ausführungsmodus Unterprogramm (Eigenschaften für Vi->Ausführung->Priorität->Unterprogramm).

Mein Problem ist nun, dass bei diesem Ausführungsmodus kein Debugging verfügbar ist und asynchrone Knoten verboten sind (z.B. Queues, teilweise Events). Gibt es eine andere Möglichkeit, effizient Arrays mittels SubVis zu verarbeiten und dennoch asynchrone Knoten verwenden zu können?
In LabVIEW 9 dürfte dieses Problem mit Datenreferenzen lösbar sein, leider arbeiten wir noch mit LV 8.6.

Schöne Grüße,
soranito

Anzeige

Was für Events sollen nicht funktionieren? Und wieso kannst Du keine Queue in einer Subroutine (Englischer Begriff Deiner Ausführungsart) erstellen? Ich habe versucht eine Queue zu erstellen und das hat funktioniert.
Ansonsten sind Subroutines gar keine so schlechte Sache, zwar nicht so schnell, wie Primitives, aber wesentlich schneller, als ein normales SubVI (je nachdem, was damit gemacht werden soll). Auf dem Performance-Guide gab's einen netten Benchmark mit Subroutines und einem normalen SubVI.
Kannst Du mal Dein Bsp. hochladen und sagen, um was für Größenordnungen es bei Deinem Array geht?

Gruß Markus

PS: Bitte . Da steht noch LabVIEW 8.2 drin und Du hast ja jetzt anscheinend schon LabVIEW 8.6.

Hallo Markus.
Du hast recht: Queue erstellen funktioniert, aber in Queue schreiben und Queue lesen funktionieren nicht. Bei Ereignissen war ich auch etwas ungenau: Es funktionieren "Benutzerereignis erzeugen", "Benutzerereignis erstellen", aber Ereignisstrukturen sind verboten. Ein weiteres Problem ist, dass in einem Unterprogramm nur VIs verwendet werden dürfen, die ebenfalls den Typ Unterprogramm haben. Schließlich kommt noch dazu, dass in Unterprogrammen der Debugger nicht funktioniert.

Im Augenblick geht es mir nicht direkt um die Lösung einer konkreten Problemstellung, sondern eher um die generelle Möglichkeit, Code mit Hilfe von SubVIs zu strukturieren wobei ich einerseits Performanceeinbrüche bei großen Datenmengen vermeiden möchte und andererseits alle Möglichkeiten zur Verfügung haben, die ich hätte, wenn ich komplett auf SubVis verzichte.

Das mit dem konkreten Beispiel könnte auch etwas kompliziert werden, da das array in einem ziemlich umfangreichen Projekt die Rolle des zentralen Puffers übernimmt. Ich habe den Post vor allem deshalb erstellt, da es mir schon öfters passiert ist, dass ich sehr große Datenstrukturen habe (z.B. Filme), in denen z.B. nur ein Frame manipuliert werden soll, das aber oft hintereinander und jedesmal wird der komplette Puffer kopiert. In jeder anderen ernsthaften Programmiersprache gibt es neben dem in LabVIEW typischen Call-By-Value (also kopieren der Daten) Call-By-Reference (lediglich übergabe eines Zeigers) - ich dachte mir einfach, diese Möglichkeit MUSS es bei einer über 20 Jahre alten Programmiersprache auch geben.


Du hattest primitives erwähnt. Sehe ich das richtig, dass damit eingebaute Funktionen wie z.B. "Teil-Array ersetzen" bezeichnet werden? Gibt es etwa eine Möglichkeit, solche primitves auch selbst zu erstellen?

Schöne Grüße,
Matthias

P.S.: Danke für den Hinweis (8.2->8.6)

' schrieb:In jeder anderen ernsthaften Programmiersprache gibt es neben dem in LabVIEW typischen Call-By-Value (also kopieren der Daten) Call-By-Reference (lediglich übergabe eines Zeigers) - ich dachte mir einfach, diese Möglichkeit MUSS es bei einer über 20 Jahre alten Programmiersprache auch geben.

Die Frage ist, ob es Intension von LabVIEW ist, auch Call-By-Reference auf oberster Ebene zuzulassen. Streng genommen widerspricht das nämlich dem Datenflußprinzip (RaceConditions!).

Du hast aber jederzeit die Möglichkeit einer eigenen (c++ etc.) DLL, um z.B. performance-sensible Berechnungen zu machen.

' schrieb:In LabVIEW 9 dürfte dieses Problem mit Datenreferenzen lösbar sein,

Wenn das das ist was du willst und ich meine: Wie kommt du darauf, dass das in LV9 geht?

Kann das einer bestätigen? Dass da ein Unterschied ist zwischen 90 und 86? Ich selbst hab's jetzt noch nicht probiert.

' schrieb:Wenn das das ist was du willst und ich meine: Wie kommt du darauf, dass das in LV9 geht?

Kann das einer bestätigen? Dass da ein Unterschied ist zwischen 90 und 86? Ich selbst hab's jetzt noch nicht probiert.

Ich habe es auf http://www.ni.com/LabVIEW/whatsnew/d/features.htm gelesen: "Seit LabVIEW 7.1"->Datenreferenzen. Unter dem dort angegebenen Link (der bei mir heute leider einen Server-Error gibt), war noch vor kurzem ein Tutorial erreichbar, in dem die Verwendung von Datenrefenzen unter LV9 genauer beschrieben wurde.

' schrieb:(der bei mir heute leider einen Server-Error gibt),

So-nebenbei-Bemerkung der Hotline(die ich heute morgen um 9°° in einer anderen Angelegenheit befragt habe) zu dem Serverausfall in USA: "Ach, in einer Stunde geht das wieder". War wohl ein Kaufmann.