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!
13.12.2010, 09:19 (Dieser Beitrag wurde zuletzt bearbeitet: 13.12.2010 09:21 von Matze.)
gibt es eine Möglichkeit, die Pufferzuweisung bei "Nach Namen aufschlüsseln" / "Unbundle by Name" zu verhindern? Also so, dass ich direkt mit den Werten arbeite?
Ich habe viele Messwerte in einem Cluster und möchte nicht, dass laufend beim Auslesen die Messwerte im Speicher kopiert werden.
Eine Inplace-Elementstruktur bringt hier nichts, da ich die Werte nur lesen möchte. Und ob das mit Datenreferenzen geht, weiß ich nicht. Wenn ja, wäre ein kleines Beispiel nett.
' schrieb:Ist das eine konkrete Frage weil du an einer Stelle Performance/Speicher Probleme hast?
Ja, ist es. Ich erfasse Messwerte, die ich in einem Cluster ablege (da sind auch noch einige andere Daten enthalten und ohne Cluster sinkt die Übersicht aufgrund vieler Drähte).
Mein Speicher läuft z.T. voll bei vielen Messwerten, da ich in verschiedenen SubVIs "Unbundle By Name" nutze. Über das Pufferzuweisungs-Tool sieht man, dass Speicher zugewiesen wird.
Das tritt bei Klassen-Daten und bei normalen CLustern auf:
Edit: Ich verwende mittlerweile einige Konstrukte wie dieses, in der Hoffnung, beim fortlaufenden Aufruf (Schleife, die das immer zyklisch aufruft) wird kein neuer Speicher zugewiesen:
"Data Value References" wirken Wunder!
Ich hab meinen RingPuffer damit geschrieben und seit dem Läuft alles zum Einen rund und zum Anderen mit viel weniger CPU Last (zum Vergleich: RingPuffer mit GOOP3-Klassen CPU-Last bei 95% -> SW-crash, RingPuffer mit GOOP4-Klassen CPU-Last bei 10%, Code wurde 1<->1 von GOOP3 auf GOOP4 portiert)
Pack deinen Cluster in eine "Data Value Reference" und wende darauf das "in place element read" an. So kannst du skalare Grössen ohne "CPU-Verlust" lesen.
Im Bild:
Die Variable "Buffer" besteht zum Teil aus 2D-dbl mit mehreren 10000 Einträgen, meinen Pufferstatus lese ich dann so aus. GOOP3 hat meine System an den Anschlag gebracht mit GOOP4 läuft es nun...
Gruess,
Christian
In theory, there is no difference between theory and practice; In practice, there is.
danke. Dass die Inplace-Struktur auch in der Art etwas bringt, wusste ich noch nicht. Ich dachte, man müsse lesen und Änderungen schreiben.
Was ich nicht verstehe: Wieso soll die Struktur keine CPU-Last benötigen? Du liest die Werte aus und genau dann wird ebenfalls Speicher zugrwiesen, würde ich sagen. Spätestens dort, wo du sie aus der Inplace-Struktur heraus führst.
"Keine" war vielleicht etwas übertrieben.
Auf jeden Fall wird weniger CPU-Last benötigt, da ich nur skalare Grössen lese. Das was viel Aufwand kostet ist das Lesen der Buffer-Variablen und die wird nicht nach "draussen" geführt und somit kein Speicher dafür alloziert.
In theory, there is no difference between theory and practice; In practice, there is.
Und wo genau befindet sich nun das Messwert-Array?
Oder wärst du so nett, mir die Stelle zu zeigen, wo du die Werte zuweist und ausliest, so als ganz kleine Demo?
Diese Daten-Referenzen sind mir noch nicht eingeleuchtet.
Das Messwert Array schreibe ich zyklisch auf Festplatte, da wirst du um einen direkten Zugriff nicht drumrum kommen. Wie geschrieben, bei mir war es einen Ausschnitt aus meinem generischen Ringpuffer.
Wahrscheinlich reden (schreiben?!) wir aneinander vorbei und/oder ich hab dich falsch verstanden. Da ich deinen Code und den gesamten Aufbau nicht kenne, habe ich mich darauf bezogen, dass du immer wieder auf deine "Statisch.xxxx", "Dynamisch.yyy" Parameter zugreifen möchtest die mehr oder minder skalare Grössen sind (ein Array mit wenigen Einträgen bezeichne ich hier mal als Skalar, so wie HF-Entwickler Signale mit mehrere MHz als nervösen Gleichstrom bezeichen). Liest du bei jedem Aufruf von denen deine Messwerte mit auf, hast du grossen Kopieraufwand.
Du hast geschrieben, dass du in mehreren SubVIs den Cluster zerlegst und da bin ich davon ausgegangen, dass du auch in diesen deine Messwerte auch immer mit "unbundel"st. Rufst du in deinen SubVIs aber die Daten-Referenz auf und kopierst du nur die skalaren Grössen, dann sparst du dir den Aufwand für die Messwerte.
Hast du jedoch ein allgemeines Problem mit deinen Messwerten, dann würde ich dir einen Ringpuffer empfehlen, der dann die Messwerte auf HDD speichert, wenn dein Code gerade Zeit hat....
In theory, there is no difference between theory and practice; In practice, there is.
Chuck Reid
13.12.2010, 22:28 (Dieser Beitrag wurde zuletzt bearbeitet: 13.12.2010 22:30 von Matze.)
also es sind ca. 12.000 Messwerte. Das ist nicht sonderlich viel, aber wenn man das öfters "unbundled", summiert sich das schon auch und geht auf die Performance. Auf HDD speichern geht nicht (ist ein Real-Time-System).
Ich lese da die Werte vom FPGA ein (als FXP), und skaliere diese in DBL (soweit zum Hintergrund, aber das tut nichts zur Sache). Dann lege ich sie in einem Cluster ab und möchte in mehreren SubVIs die Messwerte durchlaufen können (nur lesend).
Und beim "Unbundle" wird eben alles kopiert, was ich vermeiden wollte. Daher wäre eine Lösung, direkt mit dem Cluster zu arbeiten, schön. Also dass ich direkt auf die Speicheradressen zugreife (ähnlich einem Pointer in C/C++), nur eben komfortabler/sicherer.
Vielleicht würde ich auch keinen großen Unterschied merken, aber einen Versuch wäre es Wert.
D.h. du möchtest ein post-processing machen, oder?
Wenn ja, dann würde ich mal versuchen die Rechenoperation in der "In place" Struktur durchführen zu lassen....
In theory, there is no difference between theory and practice; In practice, there is.
