VI mit externer DLL macht kein Multithreading

' schrieb:Mach dich mal vertraut mit dem Zitieren. Einfach "Zitieren" anklicken und ganz am Ende des Themas auf Antworten. Im Text dann [ quote ] und [/ quote ] einfügen.

Ok, danke.

' schrieb:Ein VI kann man nur ganz schwierig versehentlich auf das BD setzen.

Wenn mehrere Leute am Projekt arbeiten geht das doch. Ich gehe beispielsweise davon aus, dass nur das Erzeuger-Verbraucher-Modell verwendet wird. xy.vi wird da also nur einmal im Verbraucher-Case aufgerufen.

Nun kommt Anwender A, der macht mal eben "testweise" einen Button, wo er im Event xy.vi aufruft.
Dann kommt Anwender B mit der genialen Idee, alle 10 Sekunden in einer Hintergrund-Loop xy.vi aufzurufen.

schon läufts 3x gleichzeitig.

Es kostet mich doch nix, nur da Ablaufinvarianz einzustellen, wo ich es auch wirklich will.

Noch eine Frage: Wenn das Top-Level VI Ablaufvarinanz hat, muss dann per Hand auch jedes darin verwendete VI auf Ablaufinvariant gesetzt werden ?

Werner

' schrieb:Es kostet mich doch nix, nur da Ablaufinvarianz einzustellen, wo ich es auch wirklich will.

Im Gegenteil, das ist ausserordentlich sinnvoll. Ablaufinvarianz kostet nämlich etwas, und zwar Speicher und Verwaltungsaufwand in LabVIEW und zwar auch wenn diese Ablaufinvarienz nicht benützt wird. Zudem kann es sehr wohl gewünscht sein VIs eben gerade nicht ablaufinvarient auszuführen. Das von Dir geschilderte Szenario ist ein gutes Beispiel aber auch beispielsweise intelligente globale Variablen (IGV). Die funktionieren nur als gewünscht, wenn sie nicht ablaufinvarient sind.

Zitat:Noch eine Frage: Wenn das Top-Level VI Ablaufvarinanz hat, muss dann per Hand auch jedes darin verwendete VI auf Ablaufinvariant gesetzt werden ?

Ja! Alblaufinvarienz wird nicht vererbt in der Hierarchie. Das ist auch sinnvoll da Du zum Beispiel oben erwähnte IGVs auch in ablaufinvarienten VIs einsetzen können willst.

Von Hand ist aber nicht unbedingt nötig. Mit VI Server und ein klein wenig Scripting geht es auch automatischer.

' schrieb:Im Gegenteil, das ist ausserordentlich sinnvoll. Ablaufinvarianz kostet nämlich etwas, und zwar Speicher und Verwaltungsaufwand in LabVIEW und zwar auch wenn diese Ablaufinvarienz nicht benützt wird. Zudem kann es sehr wohl gewünscht sein VIs eben gerade nicht ablaufinvarient auszuführen. Das von Dir geschilderte Szenario ist ein gutes Beispiel aber auch beispielsweise intelligente globale Variablen (IGV). Die funktionieren nur als gewünscht, wenn sie nicht ablaufinvarient sind.
Ja! Alblaufinvarienz wird nicht vererbt in der Hierarchie. Das ist auch sinnvoll da Du zum Beispiel oben erwähnte IGVs auch in ablaufinvarienten VIs einsetzen können willst.

Von Hand ist aber nicht unbedingt nötig. Mit VI Server und ein klein wenig Scripting geht es auch automatischer.

Danke für die Klarstellung. Bin jetzt dabei das hier erlernte jetzt gezielt einzubauen und zu prüfen/testen.
Ich mach UDP, und blocking habe ich berücksichtigt. Es geht erstmal nicht um Performance. Sondern um klare Struktur und Einfachheit. (Daher das Auf-senden-receiving-zu). Ich will schlicht mehrfach meine DLL-Funktion aufrufen, und wenn nix blockt, sollen diese Aufrufe parallel erfolgen.

Momentan hält nix in meiner DLL den Thread an - also sehe ich erstmal das Problem darin, LV dazu zu bringen das auch zu machen.

Melde mich wieder.

Werner

AAlso,
ich bin immer noch nicht schlauer.

Ich habe nun alles versucht, der SRC-Code unds LV-Projekt LabVIEW Version 8.61lv86liegen bei.

Versucht habe ich:

1.) CodeInterfaceNode "In UI-Thread ausführen" oder beliebigem Thread
2.) VI-Eigenschaften Ablaufinvariante Ausführung an oder aus
3.) Bevorzugtes System wie Aufrufer oder Standard.

Komplett gelesen habe ich:
Application Note 114 Using LabVIEW to Create Multithreaded VIs for Maximum Performance and Reliability von Norma Dorst
und
Using External Code in LabVIEW

Aber weitergekommen bin ich nicht.

Es ist leider umfangreich, das VI auf das es mir ankommt ist das TAE-Test-Dauertest.vi - zu finden im Ordner "Test VIs einzelner Geräte"
Darin laufen in einer For-Schleife 2 Sub-VIs (TAE-Test-PFG1000RF.vi und TAE-Test-PR4000.vi).
Jedes VI einzeln braucht 300ms.
Sollten parallel laufen, tun Sie aber nicht richtig, denn die For-Schleife benötigt 600ms.

Mit einem Port-Sniffer sehe ich, dass beide UDP-Pakete etwa zeitgleich losgehen (ca. 16ms auseinander) und auch zeitgleich kommen (nach 300ms).
Aber ich befürchte meine Empfangerei macht Mist.

Zu finden in der Datei TCPIP.cpp und zwar in der Funktion:

DLL_FUNC int winsock_recvbinary(int nDeviceNumber, char* cData, int* nLen, int nBufSize,
int nTimeOutms, LPDWORD lpdwDuration, char* szAbsender)

Wie gesagt, ich mach UDP, und da gibt es eine Variable "lpdwDuration", mit der ich messe, wie lange es dauert, bis ich die Nachricht empfangen habe.

Wenn ich im CodeInterfaceNode den Parameter auf "In UI-Therad ausführen" habe, dann stimmen die angezeigten Zeiten.
Klar, weil ja beide VIs brav hintereinander ausgeführt werden, nehm ich an.
Wenn ich aber "in beliebigem Thread ausführen" anhabe, dann zeigt die Variable "lpdwDuration" komischerweise die 600ms an, die es auch insgesamt dauert.

Da ist also was faul: denn ich hol mir die Zeit ja per GetLocalTime() und merke mir die in lokalen Variablen, und da hier 2 Threads diese Funktion gleichzeitig aufrufen, sollten Sie doch auch gleichzeitig fertig werden. Sehr komisch.

LV-Projekt und C-Source der TCPIP Sachen liegt als ZIP bei.

Werner

Nach einem weiteren Tag des Testens ist mein Kenntnissstand nun folgender:

LabVIEW ist schon in der Standardeinstellung gut.

Ich gebe jetzt mein Wissen zum Multithreading mit LabVIEW kund, und bitte um Richtigstellung falls ich etwas falsch sehe.

In LV 8.61 ist die Standardeinstellung bei VI-Eigenschaften-->Ausführung "Ablaufinvariant aus" und Bevorzugtes System "Wie Aufrufer" und im CodeInterfaceNode "In UI-Thread ausführen".

Selbst damit laufen meine 4 Sub-VIs Gerät1-Gerät4 parallel (ja, ich staune selber).
Weil nämlich meine DLL-Aufrufe jedes Gerätes (open.vi send.vi read.vi close.vi) in SUB-VIs verpackt sind, macht damit das LabVIEW System im Prinzip folgendes:

Gerät1-open, dann Wechsel zu Gerät2-open, dann wechsel zu Gerät3-open usw.
Die Laufen zwar nicht wirklich parallel, aber LV wechselt durch die VIs durch, und zwar so schnell dass es für mich wie parallel aussieht.

Echt parallel wirds, wenn ich im CodeInterfaceNode "In beliebigen Thread ausführen" wähle.

Aber mein Problem ändert sich dadurch nicht, weil, ja weil: der Fehler ist nicht LV oder meine DLL, das Problem sitzt in dem SerialDeviceServer, der eben 4 serielle Schnittstellen an TCP/IP bringt. Dieses Teil sendet zwar auf allen 4 Ports gleichzeitig aus, aber die gleichzeitig über RS232/485 eintreffenden Antworten queued das Mistding, und legt diese dann 300ms nacheinander aufs Netz, so dass selbst meine Parallele Empfangerei die Antwort des 4. Gerätes erst nach 300ms*4=1200ms in LabVIEW anzeigen kann.

Ich hätt das nie für möglich gehalten, und hatte LV oder meine DLL im Verdacht.

Der Hersteller des Gerätes ist informiert und ich warte auf Antwort.

Danke für eure Hilfe.

Werner