C-dll einbinden: LabVIEW hängt

<blockquote>Hallo zusammen,

ich muss c-DLL (Borland) in LabVIEW 2010 einpacken und als Bibliothek (subVIs) unseren Kunden abgeben.
Meine subVI soll Daten von RS232 kontinuierlich (while-Schleife) lesen und in Puffer speichern.

DLL:

//header Datei
export.h

#ifndef _EXPORT_H
#define _EXPORT_H
.
.
.
extern "C" short __declspec(dllexport) WINAPI D_Thread_ReceiveCont(void * puf, BOOL * abbruch);

#endif

Beschreibung:

puf : Zeiger auf den Puffer für den Messdatensatz. Der Puffer (struct) muss mindestens eine Länge 2300 Bytes haben.
abbruch: wenn „TRUE“, Messung wird abgebrochen.


Probleme:

subVI „hängt“ ohne Fehlermeldung oder LabVIEW wird abgestürzt.


Kann mir jemand helfen?

Vielen Dank

Gruß

eug</blockquote>

' schrieb:kontinuierlich (while-Schleife) lesen und in Puffer speichern.

Hier sehe ich Probleme.
Du hast also in einer Funktion innerhalb der DLL eine While-Schleife, die an sich kontinuierlich läuft. Während sie läuft, soll sie Daten in einen Puffer schreiben, der sich in LV befinden. Richtig so?

Und dann soll die While-Schleife auch noch abbrechbar sein?

Schreibst ihr die DLL komplett selbst? Dann könntest ihr euch doch an die Gegebenheiten von LV anpassen, oder nicht?

Zitat:subVI „hängt“ ohne Fehlermeldung oder LabVIEW wird abgestürzt.

Wo ein Pointer in Spiel ist, stürzt ein Programm gerne mal ab.

Was macht den diese Funktion genau? Probiert sie in den Bufferspeicher zu schreiben nachdem die Funktion in LabVIEW zurückgekehrt ist? Oder bleibt die Funktion selbst in einer Schleife? Und wie ist denn das VI programmiert mit dem diese aufgerufen wird (Hint: man kann hier auch VIs und source code uploaden)?

Fragen, Fragen, und Fragen und wenig wirklich tiefgehende Antworten bis jetzt. Es ist immer wieder verblüffend welche parapsychologischen Gaben viele Fragensteller bei den potentiellen Beantwortern vermuten. Leider kann ich noch immer nicht Gedanken lesen, oder in die Zukunft sehen. Wenn ich das könnte hätte ich schon lange beim Lotto mitgemacht.

Hallo zusammen!

Sehr geehrter Guru IchSelbst und Guru rolfk,

tatsächlich, in diese Funktion stehet "do-while(!abbruch)" - Schleife (das ist meine Fehler- ich habe es nicht bemerkt).
Diese Funktion:
extern "C" short __declspec(dllexport) WINAPI D_Thread_ReceiveCont(void * puf, BOOL * abbruch);
soll Messdatensätze von der RS232 ablesen in "struct XY" (2300 Bytes). Ich vermute, dass soll ich für "XY" durch puf Speicher allokieren.(z.B. Array U8 length 2300)
Genau diese Messdatensätze ("XY"), möchte ich für weitere Funktionen (aus DLL) übergeben und am Ende, will ich Messdaten in LabVIEW zeigen.

Leider DLL ist nicht von mir: ich habe es geerbt. Quellcode kann ich nicht ändern.
Und außerdem, ich bin Anfänger in LW, deswegen, kenne ich nicht alle Verfahrungen um DLL in LW einzupacken.

Habe Sie Ideen?

Vielen Dank

Gruß

eug

Das sieht schlecht aus! Solange die DLL Funktion nicht zurückkehrt kann LabVIEW mit den Werten im Buffer rein gar nichts tun. Das "do while" construct ist also ein ganz böser Killer hier und gelinde gesagt ist das sowieso eine Hackfunktion in dieser Weise. Das funktioniert in keiner einzigen modernen Programmierumgebung sinnvoll, ausser man macht ein dumbes 3 Zeiler Konsolenprogramm in C.

Ohne diese Funktion grundsätzlich zu modernisieren sehe ich da keine sinnvolle Möglichkeit um das auf eine gute Art in LabVIEW zu integrieren.

Da die ganze Kommunikation eh seriel ist denke ich aber das die Implementation dieser Funktion ganz in LabVIEW mittels VISA Funktionen 120% sicher die viel einfachere und bessere Lösung ist.

' schrieb:Das sieht schlecht aus! Solange die DLL Funktion nicht zurückkehrt kann LabVIEW mit den Werten im Buffer rein gar nichts tun. Das "do while" construct ist also ein ganz böser Killer hier und gelinde gesagt ist das sowieso eine Hackfunktion in dieser Weise. Das funktioniert in keiner einzigen modernen Programmierumgebung sinnvoll, ausser man macht ein dumbes 3 Zeiler Konsolenprogramm in C.

Ohne diese Funktion grundsätzlich zu modernisieren sehe ich da keine sinnvolle Möglichkeit um das auf eine gute Art in LabVIEW zu integrieren.

Da die ganze Kommunikation eh seriel ist denke ich aber das die Implementation dieser Funktion ganz in LabVIEW mittels VISA Funktionen 120% sicher die viel einfachere und bessere Lösung ist.

Hier ist Ablauflogik für diese Funktion:

test.c

struct XY //2300 Bytes
{
………
};
BOOL* D_Abbruch = false;

short D_Thread_ReceiveCont(void * puf, BOOL * abbruch)
{
.
.
XY *buffer = (XY *)puf;
bool dat_ok = false;
D_Abbruch = abbruch;
.
.
do
{
while( DatenLesen1() )
{
if(D_Abbruch == true)
{ return 6;} // Abbruchcode
.
.
dat_ok = true;
}
}
while(!dat_ok)

}
return 0;

Also, die Fuktion hat keine endloseschleife:
mit abbruch kann man zwangsweise Funktion abbrechen;
mit dat_ok das passiert automatisch wenn, DatenLesen1() ist gut gelaufen (Messwerte gelesen).

Die Funktion liest nur ein Messwert und dann return.
Frage:l
Soll ich subVI organisieren für einzige Messwert und dann "in LW" subVi in while kapseln?

Vielen Dank

eug

Nun also Du kannst als Abbruch natürlich immer True übergeben, dann wird die Loop jeweils genau einmal ausgeführt und kehrt dann nach LabVIEW zurück. ABER: Man kann nicht (nun ja mit viel Hokuspokus und noch ein paar Zaubereien aber dann sprechen wir von Techniken wo man eindeutig ungefähr 5 Klassen höher über C Programmierung beherrschen muss dann was dieser Code an Programmierkenntnissen vermuten lässt) einen Pointer auf eine Boolean Variable an die Funktion geben und diese Boolean dann in LabVIEW veränderen währenddem die Funktion noch ausgeführt wird.

Und da Du scheinbar den Sourcecode eben schon hast noch mal die Empfehlung: Prorammiere die ganze Chose in LabVIEW neu. Das kostet Dich im Endeffekt sicher weniger Zeit als dies hier sinnvoll zum Laufen zu bringen, Diese Funktion ist schlichtweg nicht geschrieben um in höheren Programmiersprachen aufgerufen zu werden, und LabVIEW ist nun mal eine höhere Programmiersprache die in Abstraktionslevel einiges über C liegt.

Hallo LVF-Gurrus,

ich habe meine DLL so in LV angepackt, wie in Tutorial "Einbinden einer DLL in LV" beschrieben.
Aber Software läuft nicht stabil:
manchmal nach 5e, manchmal nach 200e Iterationen stürzt die ab.

Hier ist ein Beispiel:

  Test1.vi (Größe: 17,14 KB / Downloads: 335)


PS: ohne Gerät VIs funktioniert nicht. passwort: qwert.

Bitte, wer hat Ahnung, helfen Sie mir!

Dann lad Dein VI doch mal in LabVIEW 2009 oder älter Format hoch. Ich habe im Moment kein 2010 installiert. Und bitte gib auch das entsprechende Header File mit und eventuele Dokumentation zu der Funktion die Du aufrufst. Grundsätzlich bezweifle ich noch immer dass das Ganze mit der von Dir am Anfang beschriebenen DLL einfach zum Laufen zu bringen ist. Diese DLL versucht scheinbar asynchron in einen Buffer zu schreiben der vom Aufrufer übergeben wird. Das geht in LabVIEW nicht so einfach. Ein Buffer zu einer Call Library Node ist dort nur solange gültig bis die Funktion zurückkehrt. Wenn die DLL danach asynchron in den Buffer zu schreiben versucht schreibt sie halt manchmal, oft, vielleicht, bei Vollmond oder wenn Du Zahnschmerzen hast in einen ungültigen Speicherbereich und WUMMS -> crash!

Oder Du hast den typischen LabVIEW-Programmierer-Call-Library-Node-Benützer-Fehler begangen indem Du den Buffer den Du an die DLL Funktion übergeben hast nicht explizit anlegst durch Benützung der Initialize Array Funktion. LabVIEW kann nicht wissen wie gross der Buffer sein soll, und die C Funktion kann und sollte den Buffer nicht anzulegen versuchen da sie keinerlei Informationen hat auf welche Weise die aufrufende Anwendung Speicher verwaltet. Darum muss das der Aufrufer machen und da LabVIEW nicht parapsychologische Eigenschaften hat kann es nicht mal zu ahnen versuchen wieviel Speicher da jetzt nötig wäre. Also musst Du als Programmierer das bestimmen indem Du diesen Buffer explizit anlegst.

@rolfk:
Hier ist sein VI für LabVIEW 8.0, allerdings fehlen die ganzen SubVIs :

  Test1.vi (Größe: 20,72 KB / Downloads: 373)



Gruß Markus