VI mit externer DLL macht kein Multithreading

Hallo IchSelbst,
danke für die Hinweise.


Ja, ich meine das selbe VI.

>Ich kann deiner Logik nicht ganz folgen.

Sowas hör ich öfter...

>Ich würde ja folgendes sagen und zwar nur alleine bezogen auf die VIs GerätX.VI: Die Geräte-VIs Gerät1.vi Gerät2.vi Gerät3.vi Gerät4.vi bekommen Ablaufinvariant EIN. Hinweis: Auch wenn nur ein einziges selbes VI läuft, kann man ablaufinvariant einstellen. Nur weil es nur einmal läuft, heißt das noch lange nicht, dass ablaufinvariant aus sein muss.

Das sehe ich anders, bitte aber um Klarstellung falls ich falsch liege:
Die Geräte-VIs Gerät1.vi Gerät2.vi Gerät3.vi Gerät4.vi bekommen Ablaufinvariant AUS, weil ich explizit vermeiden möchte, dass selbe VIs (Werner hat gelernt: selbes) versehentlich gleichzeitig laufen. Gerät1.vi Gerät2.vi Gerät3.vi Gerät4.vi darf gleichzeitig laufen, aber eben nicht zwei mal Gerät1.vi

>VIs haben keinen Parameter "UI-Thread oder beliebigem Thread".
Ja, so ists, die haben keinen solchen Parameter, nur das Call Library Node hat sowas.


>Ich würde sagen: die 4 SUB-VIs: open.vi send.vi read.vi close.vi bekommen Ablaufinvariant EIN. Zum Parameter "UI-Thread oder beliebigem Thread" siehe oben. Die DLL-Knoten, die sich in diesen SubVIs befinden bekommen alle den Parameter "In beliebigem Thread".

Dem stimme ich voll zu.

Da es bei mir genau so ist, aber dennoch die Ablaufzeiten von Gerät1.vi Gerät2.vi Gerät3.vi Gerät4.vi sich addieren wenn die vier in einem einzigen case befinden, statt dass der case nur solange dauert wie das längste VI, z.B. Gerät3.vi gehe ich davon aus, dass ich irgendwo noch was übersehen habe, oder noch ein anderes VI im Spiel ist, dass eben nicht "Ablaufinvariant EIN" hat.

Jetzt wo ichs schreibe, fällt mir ein, ich ahne was: mein Call Library Node hat am Path-Eingang ein VI, welches den DLL-Pfad besorgt. Das muss ich daraufhin prüfen...

Danke Werner