DLL in LabVIEW Erstellen, String als Rückgabewert?

Liebe LabVIEW Gemeinde

Ich möchte mit dem Appliation Builder eine DLL erstellen, die in einer bestehenden Software eingebunden werden soll. Die Prototypendefinition ist da bereits vorgegeben.
Der Rückgabewert soll nun ein STRING sein (z.b. PC Name etc).

So wie es aussieht, ist es nur möglich, eine numerische Zahl als Rückgabewert auszuwählen. Terminals andere Datentypen stehen nicht zur Auswahl, obwohl ich sie ebenfalls am Connector Pane verdrahtet habe.

Den String als Pointer in einem weiteren Argument zu übergeben wäre ein Workaround, aber wie Eingangs schon erwähnt, ist die Prototypendefinitionn bereits vorgegeben. Das ist also für mich keine Lösung.

Weiss da jemand Abhilfe?

Ich verwende LabVIEW 2013 (32 bit)

Vielen Dank im Voraus.

Anzeige

Haettest du in deinem GetSystemName.vi den indicator mit der connector pane verlinkt, wuerde dein Dialog so aussehen:
   
Den "return value" sollte man verwenden, um Fehler, die waehrend der Abarbeitung der Funktion aufgetreten sind, zurueck zu liefern. Den string (oder pointer darauf) musst du als parameter uebergeben.

Hallo teegee

Danke für deine Antwort. Dieser Weg ist bekannt, und leider ist das nicht die Lösung. Das aufrufende Programm (nicht von mir, nicht änderbar) erwartet leider den String als RETURN VALUE, und genau hier lässt LabVIEW leider nur die Zuweisung eines NUMERIC Indicators zu. Scheint eine echte Limitierung von LabVIEW zu sein. Nicht einmal ein BOOL Wert lässt sich zuweisen - hab das schon versucht. Bei BOOL ist das aber nicht so tragisch, ein UINT8 mit dem Wert 0 oder 1 würde "von der Gegenseite" korrekt als BOOL WERT verstanden werden.
Das brachte mich auch auf einen möglichen Lösungsansatz: Ein STRING POINTER ist doch im Grunde genommen auch nichts anderes als ein Zahlenwert, der einer Speicherstelle anzeigt. Vielleicht gibt es ja einen Trick, einen LabVIEW STRING Wert in eine numerische Speicheradresse zu verwandeln, und diesen dann als Wert zu übergeben. Ich weiß, das ist schon etwas "bizarr" - aber vielleicht der einzig gehbare Ausweg.

Hier gibt's eine gute Erklärung dazu:
http://zone.ni.com/reference/en-XX/help/...g_options/

Bei Stackoverflow ist auch noch was:
http://stackoverflow.com/questions/26906...ction-node
Stefan

(16.02.2015 08:35 )andiauskaindorf schrieb:  Das brachte mich auch auf einen möglichen Lösungsansatz: Ein STRING POINTER ist doch im Grunde genommen auch nichts anderes als ein Zahlenwert, der einer Speicherstelle anzeigt. Vielleicht gibt es ja einen Trick, einen LabVIEW STRING Wert in eine numerische Speicheradresse zu verwandeln, und diesen dann als Wert zu übergeben. Ich weiß, das ist schon etwas "bizarr" - aber vielleicht der einzig gehbare Ausweg.

Damit kommst du nicht weit.
1. Der return type ist uint8, pointer sind 32 oder 64 bit lang
2. Das Programm, was dll aufruft, sollte den Platz fuer die Variable im Speicher bereitstellen. Ansonsten laeufst du in Speicher management Probleme rein. Mit einer Ausnahme: die dll hat eine Funktion, die den Speicherplatz wieder freigibt.

Danke Dali4u

Unter https://decibel.ni.com/content/docs/DOC-9091 habe ich Hinweise gefunden, die mir weitergeholfen haben.
Wie ursprünglich vermutet, ist es möglich, den String Indicator in LabVIEW in einen Pointer zu verwandeln und diesen Wert als NUMERIC RETURN VALUE auszuwählen. Die aufrufende Funktion kann dann einfach den Rückgabewert als CStr* interpretieren.

Anzeige

Rückmeldung mit einer Lösung inkl. Anleitung als Bild

(17.02.2015 09:00 )andiauskaindorf schrieb:  Danke Dali4u

Unter https://decibel.ni.com/content/docs/DOC-9091 habe ich Hinweise gefunden, die mir weitergeholfen haben.
Wie ursprünglich vermutet, ist es möglich, den String Indicator in LabVIEW in einen Pointer zu verwandeln und diesen Wert als NUMERIC RETURN VALUE auszuwählen. Die aufrufende Funktion kann dann einfach den Rückgabewert als CStr* interpretieren.

Das hat aber einen "kleinen" Schönheitsfehler. Jedesmal wird mit DSNewPtr() ein Speicher alloziert. Diesen Speicher muss der Aufrufer dann explizit mit DSDisposePtr() wieder deallozieren oder Du produzierst bei jedem Aufruf ein Memoryleak. Da die Aufrufende Applikation bereist besteht ist aber die Chance dass diese so angepasst werden kann genau so gross, wie den Funktionsaufruf zu veränderen und den String als Parameter zu übergeben, also wohl nicht.

Danke Rolf für deinen Hinweis, das ist ein tatsächlich etwas, was ich noch nicht bedacht habe.
Ich könnte den Pointer zwar noch in der selben Funktion deallokieren, aber damit ist eine sichere Datenübergabe wohl nicht mehr gewährleistet...
Ich werde also doch den Weg gehen müssen, mir meine Funktionen von einem C Programmierer "umverpacken" zu lassen.

(19.02.2015 08:34 )andiauskaindorf schrieb:  Danke Rolf für deinen Hinweis, das ist ein tatsächlich etwas, was ich noch nicht bedacht habe.
Ich könnte den Pointer zwar noch in der selben Funktion deallokieren, aber damit ist eine sichere Datenübergabe wohl nicht mehr gewährleistet...
Ich werde also doch den Weg gehen müssen, mir meine Funktionen von einem C Programmierer "umverpacken" zu lassen.

Ja! Deallozieren um dann zu hoffen dass der Speicher noch gültig ist wenn Dein aufrufendes Programm ihn liest ist minimal russisch Roulette spielen. Es kann 10 mal gut gehen aber das 11te Mal knallts!