Clusterkonstante in einer dll füllen

Ich habe eine DLL, welche Hardwareinfos sammelt und an LabVIEW zurückgibt. Kann ich da sinnvollerweise (aus designsicht) eine Clusterkonstante erzeugen und diese an die dll übergeben. Oder muß das ein normales Cluster sein.

Hat eine LV-Konstante auch performance-Vorteile?

Danke

Anzeige

' schrieb:Ich habe eine DLL, welche Hardwareinfos sammelt und an LabVIEW zurückgibt. Kann ich da sinnvollerweise (aus designsicht) eine Clusterkonstante erzeugen und diese an die dll übergeben. Oder muß das ein normales Cluster sein.

Als Eingang bei "Call by Value" an eine DLL-Funktion müsste das möglich sein, bei Rückgabewerten macht das natürlich keine Sinn.

' schrieb:Hat eine LV-Konstante auch performance-Vorteile?

Ehrlich gesagt, keine Ahnung. Aber dein FP ist etwas aufgeräumter.

MfG, Jens

' schrieb:... bei Rückgabewerten macht das natürlich keine Sinn.

Keinen Sinn würde ich nicht sagen. Wenn die dll die Werte sammelt um das Cluster zu füllen und dieses innerhalb LabVIEW nicht verändert werden soll/darf, wäre so eine Konstante schon sinnvoll.

' schrieb:Wenn die dll die Werte sammelt um das Cluster zu füllen und dieses innerhalb LabVIEW nicht verändert werden soll/darf, wäre so eine Konstante schon sinnvoll.

Per se wäre der Datenspeicher, den du konstant haben möchtest, in dem Moment schon nicht mehr konstant, in dem er durch die DLL respektive des DLL-Knoten beschrieben wird. Dieses Beschreiben, besonders das durch den Knoten selbst (der kopiert nämlich die Daten in den Ausgangs-Wire), kannst du so wie so nicht verhindern. Eine spezielle Eigenschaft von Datenelementen, die es ermöglichen würde, dieses Datenelement als "nur lesbar" zu definieren, ist mir nicht bekannt. Theoretisch wäre das aber auch mit einer Datenflußsteuerung möglich. Praktischerweise kannst du eine "konstante Variable" aber ganz leicht programmieren: Einfach nicht beschreiben. z.B. dadurch, dass du ein funktionales SubVI machst. Darin befindet sich ein Schieberegister, das nur von der DLL beschrieben werden kann. Ansonsten kann dieses Schieberegister nur gelesen werden.

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.

' schrieb: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.

Du siehst das richtig.

Das Wort respektive den "Datenspeicher" "Variable" so wie du (respektive ich) es z.B. aus C++ kennst, gibt es in LV nicht. Dass der Wert einer "Variablen" irgendwo in einem Speicher abgelegt ist, ist für eine Datenflußsteuerung nicht relevant. Hier entspricht ein Wire dem Wert einer Variablen. Und ein Wire ist ein Strich am Bildschirm. Da die "Striche" an einem DLL-Knoten - das sieht man ja schon optisch - für Eingang und Ausgang zwei unterscheidliche sind, sind es quasi auch zwei unterschiedliche Variablen (sprich Datenspeicher).

Dass Eingang und Ausgang den selben Typ haben, ist elementspezifisch. Ein DLL-Knoten ist eben so definiert, dass dem so ist. Es gibt auch noch folgenden interessanten Fall beim DLL-Knoten: Für den Fall, dass ein Ausgang ein Array ist, kann man am korrespondierenden Eingang die Größe des Ausgangsarrays festlegen. Wenn z.B. eine DLL in den Speicher von LV schreiben soll, dann muss vor dem Aufruf der DLL bereits ein ausreichend großer Speicher vorhanden sein. Diese Größe kann eben durch den Eingangswert (hier reicht dann eine entsprechend konfigurierte Konstante) festgelegt werden. Am Ausgang steht dann praktisch ein gleich großes Array an.

' 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