Clusterkonstante in einer dll füllen

' schrieb:Danke für die Erläuterung. Nun ist mir der Sachverhalt klar geworden. Wenn ich es richtig verstanden habe, hat die Variable am Ausgang mit der am Eingang "nichts" zu tun. d.h. ist eine eigenständige Variable, die auch im Speicher woanderst liegt und halt "nur" den gleichen Typ hat.

Das mit einem extra VI für solche Fälle ist eine gute Idee.

Im Prinzip hast Du recht und doch auch wieder nicht. Die Variable am rechten Rand der Call Library Node is zwar logisch nicht (unbedingt) identisch mit der an der linken Seite, aber im Interesse von Performance halt immer noch an der gleichen Speicherstelle. LabVIEW macht intern nicht extra eine Kopie sondern verwendet den Eingang einfach wieder um am Ausgang zurückzugeben. Wenn Du diesen Ausgang nicht verwendest (unwired lässt) dealloziert LabVIEW den Speicher einfach wieder.

Dein Problem ist wahrscheinlich dass Du denkst dass die DLL den Speicher der Konstanten selber sieht und verändern könnte aber dem ist nicht so. In dem Moment wo die Daten aus der Konstante in den Draht kommen sind sie schon nicht mehr die Konstante selber, sondern eine Kopie davon, die eben schon verändert werden kann (oder auch nicht). Alles andere wäre viel zu mühsam zum managen.

LabVIEW kennt zwar seit ein paar Versionen etwas was Konstantfolding genannt wird und hier wird tatsächlich in speziellen Fällen unter anderem auch darauf verzichtet eine Kopie der Konstante zu machen, wenn LabVIEW eindeutig feststellen kann, dass die Daten im entsprechenden Draht zu keinem einzigen Zeitpunkt überschrieben werden. Da sich LabVIEW aber die Kontrolle darüber was eine externe Library mit den Daten eines Parameters tut vollständig entzieht ist so ein Wire aber schon zum vornehinein von so einer Optimalisation ausgeschlossen.

Rolf Kalbermatter