LabVIEWForum.de

Hallo Zusammen

Seit ca. 7 Wochen arbeite ich mit LabVIEW 8.2 und erstelle damit eine Applikation für meine Bachelorarbeit.

Ich habe ziemlich viel hier im Forum nachgelesen, doch leider keine Antwort auf mein Problem gefunden. Die Funktion ist für ein erfolgreiches gelingen meiner Arbeit
sehr wichtig, weshalb ich auch schon bald am verzweifeln bin.

Lage Rede kurzer Sinn... ich bitte euch um eure Hilfe.

Im Anhang habe ich ein VI, welches das ganze vereinfacht darstellt, was ich genau versuche.

Ich fülle in einem Array of Cluster jeweils 3 Array Elemente ab (als Standard-Einstellung für euch gespeichert) das PhysParamArray stellt die Eingabe dar und hat auf dem Frontpanel keine weitere Verwednung. Beim Start wird eine Datei geladen, es handelt sich dabei um Rohdaten welche durch eine Fit-Funktion angepasst werden sollen (Datei ebenfalls im Anhang). Wenn das VI so wie ich es
hochgeladen habe startet, wird der Fit nicht ausgeführt und in der Signal-Anzeige erscheint ein Plot, der auch korrekt ist. Die While-Schleife habe ich "deaktiviert" und dazu einen kleinen Kommentar
verfasst. Wird nun im Array of Cluster im Index 1 bei der Dicke die Checkbox "anfitten?" ausgewählt, lauft das ganze normal durch und es gibt auch keine Probleme. Im Array "lvResultLayer" erscheint
unter dem Index (1/0/0) der gefittete Wert (Er ist nicht korrekt, dies liegt daran, dass ich euch leider ein Datenfile nicht zurverfügung stellen kann). Soweit so gut, ändert man nun die Abbruch bedingung
der While-Schleife auf "Stopp wenn TRUE", schiesst sich LabVIEW komplett ab. Ich habe das VI zweimal ohne änderung jeglicher Werte ausgeführt. Beim zweiten Aufruf erhalte ich den Fehler 1097, der C-
Code manipuliere den Speicher.

Die DLL habe ich euch natürlich auch angehängt, gemäss meinem Teampartner, der die C-DLL erstellte, sind die Einstellungen der Schnittstelle korrekt. Dass die C-DLL funktioniert haben wir an einer kleinen Beispiel Applikation welche er in C geschrieben hat, gesehen.

In meiner Original Applikation wird die DLL zweimal eingebunden, das einemal für einen Fit und das andere Mal für eine Simulation (einfach Plotten der Werte). Wie gesagt, der Fit funktioniert (unter C, wie auch bei einmaliger Ausführung unter LabVIEW). Woran kann es liegen, dass sich das VI bei mehrfachen ausführen des Fit's verabschiedet?

Ich danke euch für eure baldige Hilfe!

Gruss Oliver

PS: In der C-DLL wird mit numerical recipies gearbeitet, da mein Teamkamerad nicht verfügbar ist, kann ich zurzeit keinen C-Code liefern. Wäre der allenfalls notwendig? Dann sagt mir bitte, was genau ihr benötigt.

' schrieb:Ich fülle in einem Array of Cluster jeweils 3 Array Elemente ab (als Standard-Einstellung für euch gespeichert) das PhysParamArray stellt die Eingabe dar und hat auf dem Frontpanel keine weitere Verwednung. Beim Start wird eine Datei geladen, es handelt sich dabei um Rohdaten welche durch eine Fit-Funktion angepasst werden sollen (Datei ebenfalls im Anhang). Wenn das VI so wie ich es
hochgeladen habe startet, wird der Fit nicht ausgeführt und in der Signal-Anzeige erscheint ein Plot, der auch korrekt ist. Die While-Schleife habe ich "deaktiviert" und dazu einen kleinen Kommentar
verfasst. Wird nun im Array of Cluster im Index 1 bei der Dicke die Checkbox "anfitten?" ausgewählt, lauft das ganze normal durch und es gibt auch keine Probleme. Im Array "lvResultLayer" erscheint
unter dem Index (1/0/0) der gefittete Wert (Er ist nicht korrekt, dies liegt daran, dass ich euch leider ein Datenfile nicht zurverfügung stellen kann). Soweit so gut, ändert man nun die Abbruch bedingung
der While-Schleife auf "Stopp wenn TRUE", schiesst sich LabVIEW komplett ab. Ich habe das VI zweimal ohne änderung jeglicher Werte ausgeführt. Beim zweiten Aufruf erhalte ich den Fehler 1097, der C-
Code manipuliere den Speicher.

Die DLL habe ich euch natürlich auch angehängt, gemäss meinem Teampartner, der die C-DLL erstellte, sind die Einstellungen der Schnittstelle korrekt. Dass die C-DLL funktioniert haben wir an einer kleinen Beispiel Applikation welche er in C geschrieben hat, gesehen.

Tja, da hat er wohl irgendwie nicht ganz recht. Irgendwas stimmt da eindeutig nicht. Was lässt sich aber so nicht sagen. Minimal das Header File der DLL sollte schon auch noch anwesend sein.

Zitat:PS: In der C-DLL wird mit numerical recipies gearbeitet, da mein Teamkamerad nicht verfügbar ist, kann ich zurzeit keinen C-Code liefern. Wäre der allenfalls notwendig? Dann sagt mir bitte, was genau ihr benötigt.

Also wie gesagt ohne Header File der DLL (die alle Datentypen genau deklariert) und wenn möglich einem möglichst einfachen C file dass den Aufruf der DLL Funktion dokumentiert ist da gar nichts zu machen.

Ich vermute mal dass ihr entweder Ausgangsarrays nicht gross genug alloziert oder dass ihr einen Überlegungsfehler mit den mehrdimensionalen Arrays macht.

Rolf Kalbermatter

Vielen Dank für die schnelle Antwort, durch regen Vorlesungsbetrieb komme ich leider erst jetzt dazu dir zu antworten.

Ich werde mich bemühen dir die gewünschten Informationen heute im Verlauf vom Nachmittag posten zu können. Den Durchblick im C-Souce habe ich leider nicht ganz und mein Teamkollege sitzt in
einer Vorlesung fest.
Was ich jedoch mal posten kann ist der Funktionskopf, welcher vom Node aufgerufen wird:

[code]/* Dll Schnittstellen Funktion */
__declspec(dllexport) int Read_LVData(double *lvX,

' schrieb:Eine ähnliche Funktion haben wir erstellt um eine Simulation unserer Messung durchführen zu können. Dabei haben wir keine Probleme gehabt (zumindest den in-Parameter Arrays), weshalb wir bisher davon ausgingen dass dies keine Probleme bereitet. Die grösse der Arrays werden übrigens der Schnittstelle übergeben( lvLayerCount, lvAttributeCount, lvParameterCount, sind die Grössen des 3D-Arrays). Ebenfalls haben wir ja keine Probleme wenn die Checkbox für den Fit nicht ausgwählt wird und beim erstmaligen Ausführen des Fits.

Diese Dinge sagen im Zusammenhang mit dem Aufruf einer C Funktion sehr wenig oder gar nichts. Wenn zum Beispiel ein zu kleines Ausgangsarray and eine C Funktion übergeben wird kann das:

1) sofort crashen
2) irgendwann mal später crashen
3) Erst crashen wenn man LabVIEW (oder das VI) abschliesst und LabVIEW beim aufräumen über zerschossenen Pointer stolpert.
4) Andere Daten in Deinem Programm zerstören

Alles hängt davon ab wie in em Moment die verschiedenen Arrays, die LabVIEW Verwaltungsstrukturen selber und so weiter im Speicher angeordnet sind.

Ein Crash beim zweiten Durchlauf könnte zum Beispiel daher rühren dass ihr irgend eine Speicheraddresse überschreibt. Beim zweiten Durchlauf versucht LabVIEW diese neu zu allozieren und will die alte deallozieren aber leider ist da jetzt etwas Falsches so dass der entsprechende free() Aufruf voll in die hosen geht.

Ich habe sehr viel Erfahrung mit Aufrufen von DLLs und grundsäzlich ist dazu zu sagen, wenn es crasht und funkt dann ist beinahe nie LabVIEW der Schuldige sondern der Programmierer. Ob das von einer verkehrten Konfiguration der Call Library Node kommt, von einer zu kleinen Allokation von Buffern oder ganz einfach einem Programmierfehler in der DLL ist dabei völlig egal.

Das zu finden ist nicht immer einfach und grundsätzlich erachte ich Source Code Debugging der DLL bei Aufruf davon aus LabVIEW als die einzige wirklich funktionierende Lösung.

Rolf Kalbermatter

' schrieb:Ich habe sehr viel Erfahrung mit Aufrufen von DLLs und grundsäzlich ist dazu zu sagen, wenn es crasht und funkt dann ist beinahe nie LabVIEW der Schuldige sondern der Programmierer. Ob das von einer verkehrten Konfiguration der Call Library Node kommt, von einer zu kleinen Allokation von Buffern oder ganz einfach einem Programmierfehler in der DLL ist dabei völlig egal.

Vielen Dank für deine Schnellen Antworten, wir haben nun in den letzten Tagen unsere C-DLL nocheinmal genau kontrolliert und konnten den Feheler in C reproduzieren. Unteranderem hat es daran gelegen, dass wir (und auch NR) Variabeln deklariert und gleich instanziert haben. Bei einem erneuten aufruf der DLL wurde die Variable dann nicht neu instanziert und somit waren unsere Array-Indizes schlicht nicht in dem Bereich in dem sie sein sollten.