Hin - und zurückschreiben von Arrays aus LV an DLL

hallo liebe LV-User... ich bin schon seit über einer Woche damit beschäftigt LV Messdaten (Array mit floats) in einer DLL Datei auszuwerten. Aber irgendwie bekomme ich das nicht hin und verliere langsam die motivation. daher bitte ich euch um hilfe... nochmal zur der Beschreibung des Problems: Ich habe Messwerte als Array [4096] gespeichert und möchte die in eine DLL Datei auswerten und als Ausgangsarray [4096] zurückschreiben. Die DLL macht eigentlich keine Probleme, mit __declspec(dllexport) lese ich die Werte ein und schreibe sie zurück. Als Beispiel habe ich den Addierer von zwei long Variablen genommen, um das zu verstehen. Auch wenn ich die Messdaten in die DLL schreibe und z.b. mir ein Wert daraus auslesen möchte klappt das auch. Aber wenn ich die Messdaten in die DLL schreibe und das Ausgangsarray als Ausgangsparameter deklariere, gibt LV eine Fehlermeldung (Fehler im Speicher) aus. Aus NI-zone habe ich versucht das ganze zu verstehen, da stand was davon, dass es Probleme gibt wenn die Arrays von der Größe her unterschiedlich sind. Bei mir ist das aber nicht der Fall, trotzdem Fehlermeldung. Ich denke das Problem liegt bei LV und nicht bei der DLL. Kennt da jemand vielleicht ne Lösung. Ich habe auch schon Versucht mit der MoveBlock Funktion aus LV... ging aber auch nicht, weil nicht verstanden.
MfG Dennis

' schrieb:Ich habe Messwerte als Array [4096] gespeichert und möchte die in eine DLL Datei auswerten und als Ausgangsarray [4096] zurückschreiben. (...) Aber wenn ich die Messdaten in die DLL schreibe und das Ausgangsarray als Ausgangsparameter deklariere, gibt LV eine Fehlermeldung (Fehler im Speicher) aus.

So wie du das machen willst - Daten an DLL übergeben, dort verarbeiten und sofort, also noch im selben DLL-Knoten, wieder zurück geben - muss funktionieren.

Dazu müsstest du in deiner DLL einen Eingang definieren: Typ single, Wert Zeiger in Wert. Dann ist das zwar ein Pointer, aber den kannst du in der DLL inkrementieren und als quasi-Array-Index benutzen. Anschließen am DLL-Knoten tust du dann das Array[4096]. Dann musst du einen Ausgang definieren. Und zwar genau so wie den Eingang. Dann bekommst du auch wieder einen Pointer. Den nimmst du dazu das Ergebnis der Berechnung abzuspeichern. In LV hängst du dann an den Ausgang ein Array der Länge 4096. Bei LV8.2 geht das.

Der Prototyp sollte so heißen: MyFkt(FLOAT *InArray, FLOAT *OutArray)

Zitat:Ich habe auch schon Versucht mit der MoveBlock Funktion aus LV... ging aber auch nicht, weil nicht verstanden.

Eigentlich: Vergiss' es. Das ist Technik von vorgestern.

hallo... vielen dank für die antwort!

ich habe zu dem vorschlag noch ein verstängnisproblem.
vorschlag:
Typ single, Wert Zeiger in Wert. Dann ist das zwar ein Pointer, aber den kannst du in der DLL inkrementieren und als quasi-Array-Index benutzen.

meinst du das so, dass ich im LV knoten als typ numerisch auswählen soll mit einen zeiger auf wert? dann habe ich doch in LV ein verdrahtungsproblem (array-->numerisch)...

wenn ich als typ array einstelle und als array format Array-Datenzeiger... ist das dann so das LV an die DLL einen pointer (*ArrayIn) übergibt mit der anfangsadresse wo die daten gespeichert sind? dann muss ich doch in der DLL mir die daten von der stelle an holen, bearbeiten und den zeiger um 4 (float) inkrementieren, bis ich alle daten bearbeitet habe (4096). wenn ich jetzt die bearbeiteten daten speichern möchte, muss ich den pointer (*arrayOut) auf den nächst freien speicherblock stellen (ArrayIn+4*4096) und von da an speichern. könnte das der grund für die fehlermeldung in LV sein, weil so hatte ich das nicht gemacht.

vorerst vielen dank...
mfg
dennis

' schrieb:wenn ich als typ array einstelle und als array format Array-Datenzeiger... ist das dann so das LV an die DLL einen pointer (*ArrayIn) übergibt mit der anfangsadresse wo die daten gespeichert sind?

Jawohl.

Zitat:dann muss ich doch in der DLL mir die daten von der stelle an holen, bearbeiten

Jawohl.

Zitat:und den zeiger um 4 (float) inkrementieren

Im Prinzip Jawohl.
Die Frage ist nur, ob du in C++ um 4 inkrmentieren musst. In Delphi z.B. reicht ein inc(Ptr), weil der Pointer typisiert ist, sodass der Kompiler weis, dass er bei einem inc(Ptr) den Wert von Ptr um 4 erhöhen soll. Würdest du (in Delphi) inc(Ptr,4) schreiben, so würde der Wert von Ptr um 4*4, also 16, ansteigen. Ob das in C++ genau so ist, weis ich nicht.

Zitat:bis ich alle daten bearbeitet habe (4096).

Jawohl.

Zitat:wenn ich jetzt die bearbeiteten daten speichern möchte, muss ich den pointer (*arrayOut) auf den nächst freien speicherblock stellen (ArrayIn+4*4096)

Nein. Blos nicht!
ArrayOut bekommst du von LV geliefert! So wie du von ArrayIn liest, so tust du auf ArrayOut schreiben! Wichtig ist nur, dass am DLL-Knoten am Ausgang ein (Float)Array der Größe 4096 hängt.

Zitat:könnte das der grund für die fehlermeldung in LV sein, weil so hatte ich das nicht gemacht.

Nein, ich glaube eher nicht. Mach doch mal ein Bild vom DLL-Knoten mit Anschlüssen.

Ich häng dir mal mein (leider immer noch nicht ganz fertiges) DLL-Tutorial an. Da kannst du noch einige allgemeine Sachen zu DLL nachlesen.

hallo...
ich habe dir mal den knoten angehängt... zum thema pointer, vielen dank, das denke ich jetzt verstanden zu haben
gruss
dennis

Das mit dem Knoten sieht schon mal gut aus. Folgendes muss noch verifiziert werden.

Du hast im DLL-Knoten I32 anstelle von float angegeben. Dann musst du natürlich auch in deinem C-Programm mit I32 arbeiten.

Das Ausgangsarray soll ja 4096 (oder entsprechend) Werte enthalten. Diese Anzahl musst du bei dem Ausgangsparameter in der DLL-Knoten-Konfiguration angeben (zumindest bei mir in LV8.2 geht das). Es könnte (das weis ich jetzt aber gerade nicht genau) auch folgendes gehen: Auch der Ausgangsparameter hat ja am DLL-Knoten einen "Eingang". Wenn du an diesem Eingang ein Array mit 4096 anschließt und am Ausgang auch einen Draht hinmacht, dann kommt am Ausgangsdraht das Array so lange heraus, wie das Array am "Eingang" lang ist.

danke... du bist ein gott!!!

ich habe deinen rat befolgt und am eingangsdraht des ausgangknotens ein definiertes array (wie in dem beispiel array[4]) gelegt... somit war die fehlermeldung weg... ich poste die lösung dann für die nachwelt später rein...
aber nochmals vielen dank...
gruss dennis

hallo...zur beschreibung des Programms:
aus einer Reihe von Messdaten sollte eine Hüllkurve berechnet werden. Um das Problem zu lösen habe ich die Messdaten in eine DLL geschrieben und dort ausgewertet. Den Auswertalgorithmus habe ich in c geschrieben und in der DLL eingefügt. Als Rückgabe wird die berechnetete Hüllkurve als Array[4096] nach LV ausgegeben. Das Problem war das hin-und zurückschreiben von Arrays in LV. LV speichert die Daten, die in der DLL geschrieben werden auf dem Stack und holt sich die Rückgabewerte wieder vom Stack. Ich hoffe das das öffnen und schließen des Stacks in LV oder in der DLL selbst geschieht (sonst kommt es zum Stack overflow).
Beim holen vom Stack muss der Speicherbereich definiert sein, sonst kommt in LV eine Fehlermeldung und das Programm kann nicht ausgeführt werden. Somit hat mich "IchSelbst" mich darauf gebracht, am Eingang des Rückgabeknotens ein definiertes Array anzuschließen und schon läuft das ganze...

Danke IchSelbst... du hast mir das Oster-WE gerettet:-)
Der Funktionsprototyp in der DLL lautet: __declspec (dllexport) long Array (float *ArrayIn, float *Maxwerte, long size, float *ArrayOut)
oder wenn man sich das mit hilfe von LV erstellen lässt:
__declspec (dllexport) long Array (float ArrayIn[], float Maxwerte[], long size, float ArrayOut[])

Die Verdrahtung des Knotens in LV:

' schrieb:LV speichert die Daten, die in der DLL geschrieben werden auf dem Stack und holt sich die Rückgabewerte wieder vom Stack.

Das ist so wie es dasteht sinngemäß richtig. (Sinngemäß deswegen, weil es nicht heißt "die in der DLL geschrieben werden" sondern "die in die DLL geschrieben werden". Die Daten, die in der DLL geschrieben werden, schreibt ja die DLL. "Der" ist Dativ und bezeichnet den Ort. "Die" ist Akkusativ und bezeichnet die Richtung. Auf die "Der"-Daten hat LV keinerlei Zugriff. Die Daten, die in die DLL geschrieben werden, die kommen von LV, dem schreibenden. Deustche Sprache, schwere Sprache).

Zitat:Ich hoffe das das öffnen und schließen des Stacks in LV oder in der DLL selbst geschieht

Ja das geschieht so. Das handeln die DLL und der LV-DLL-Knoten untereinander aus.

Zitat:Beim holen vom Stack muss der Speicherbereich definiert sein, sonst kommt in LV eine Fehlermeldung und das Programm kann nicht ausgeführt werden.

Im Prinzip ist das wieder richtig. Aber: Auf dem Stack liegen die Pointer, die auf die Daten im Array zeigen. Die Daten selbst müssen nicht zwangsläufig am Stack liegen - sie können. (Lägen sie am Stack, müssten sie nach Beendigung des DLL-Knoten "in den Ausgangsdraht" kopiert werden. Das aber kann aufwändig sein. Zeigt der Pointer direkt "in den Draht", kann man sich viel Overhead sparen.)

Und noch eins:
Eigentlich ist es unschön, Konvertierungen durch LV machen zu lassen. Die Konvertierungen sieht man an den Punkten an der Stelle, an der die Drähte in den DLL-Knoten (respektive in ein VI) gehen. Besser wäre, das Array gleich mit dem richtigen Datentyp zu belegen. Dazu musst du im unteren Kreis nur die konstante Null von double nach single manuell konvertieren.

' schrieb:Jawohl.

Jawohl.

Im Prinzip Jawohl.
Die Frage ist nur, ob du in C++ um 4 inkrmentieren musst. In Delphi z.B. reicht ein inc(Ptr), weil der Pointer typisiert ist, sodass der Kompiler weis, dass er bei einem inc(Ptr) den Wert von Ptr um 4 erhöhen soll. Würdest du (in Delphi) inc(Ptr,4) schreiben, so würde der Wert von Ptr um 4*4, also 16, ansteigen. Ob das in C++ genau so ist, weis ich nicht.

Wenn Du eine Deklaration hast wie:

Function(float *array); oder: Function(float array[]);

kannst Du in C(++) ganz einfach schreiben:

array++

um den Pointer zu inkrementieren.

Durch die sogenannte Operator-Prezedenz in C kannst sogar etwas schreiben wie:

*array++ = something

Das weist dem aktuellen Element im Array einen Wert zu und erhöht danach den Pointer um ein Element.

Rolf Kalbermatter