Design "Erzeuger/Verbraucher

' schrieb:muss ich mir noch ankucken.

Naja, so wie es aussieht, liegt es wohl am Sleep().

Versuch das mit der parellele While-Schleife mal.

ERFOLG ! Danke an alle ! tolles Forum.

Zitat:Naja, so wie es aussieht, liegt es wohl am Sleep().
Versuch das mit der parellele While-Schleife mal.

Die parallele While Schleife brachte keine Verbesserung. Wenn meine DLL Funktion in der sleep-Schleife hängt, hing das ganze LabVIEW.

Ausserdem (bitte im Berichtigung, wenn ich da falsch liege) ist ja eh beim Erzeuger-Verbraucher-Konzept die Verbraucherschleife eine eigene While. Demnach hätte die Erzeuger-while ja dann auch weiterlaufen müssen. richtig ? Aber der UI-Button und alles andere war eingefroren, bis mein DLL-Aufruf zurückkam. Dann lief alles wieder.

Ich habe schon öfters in C multithreading Sachen gemacht. Diesmal in LV wars das erste mal.

Zitat:Sleep(): Sleep() stoppt den gesamten Prozess.
TCP/IP: Wenn der TCP/P-Socket nicht event-getriggert arbeitet, könnte es schon sein, dass die TCP/IP-Unterprogramme erst beendet werden, wenn daten ankommen, oder wenn ein Timeout eintritt.

Ich habe das TCP/IP non-blocking ausgelegt. Mein Problem ist aber, dass ein angeschlossenes serielles Gerät halt zwischen Kommando und Antwort mehrere Sekunden brauchen kann, und ich wollte dafür ein VI haben, dass diese "software" Timeouts intern erledigt, aber mein restliches LV nicht lahm legt.

Prozess=Programm. Sleep sollte den thread schlafen legen, nicht das ganze Programm wie bei mir. sleep() legte mir die LV-GUI lahm. Dies brauchte mich auf die Idee, noch mal das LV-CallLIbraryFunctionNode darauf hin anzusehen. Und siehe da:

   

es gibt eine Thread-Einstellung: in UI-Thread ausführen (dafault, war so bei mir) oder In beliebigem Thread ausführen. Ich änderte diese eine Einstellung in "In beliebigen Thread ausführen" und das wars - LV läuft brav weiter, während es in der Verbraucher-while in meiner DLL-Funktion in der sleep() steckt.

Wunderbar.

Danke nochmals - hat mir alles sehr geholfen.

Werner