' schrieb:2 while schleifen hatte ich schon....mit queue hab ich da aber net gearbeitet....da haben glaub ich beide schleifen während der dll-angehalten...wenn ich mich recht entsinne hab ich noch nie mit queue gearbeitet...muss ich mal beispiele durchforsten
kann nun mit meiner umständlichen methode auf 50ms genau arbeiten.
danke für den tip...ich ziehs mal in betracht
Also LabVIEW ist inherent multithreading und hat damit prinzipiel keine Probleme. Aber es gibt schon ein paar Dinge zu beachten. Ein DLL Aufruf kann entweder reentrant laufen oder im UI thread. Reentrant bedeutet dass LabVIEW ihn innerhalb des aktuellen Diagramms in einem der zur Verfügung stehenden Threads laufen lassen kann und das sind seit LabVIEW 8 doch schon mal so ungefähr 4 pro Execution System (ein VI und damit Diagramm kann einem von 5 oder so Execution Systems zugeordnet werden). Default ist dasselbe Execution System als das aufrufende VI.
Bei DLLs gibt es aber einen Haken. Bei schlecht, schluffig, oder was auch immer programmierten DLLs kann es Probleme geben wenn diese reentrant aufgerufen werden, entweder weil sie mit globalen Variablen arbeiten die sich bei mehreren gleichzeitigen Aufrufen gegenseitig beeinflussen oder weil sie auf irgendeine Weise threadspezifische Information verwenden und nicht damit leben können von verschiedenen Threads aufgerufen zu werden. In dem Fall muss man die Call Library Node eben so konfigurieren, dass die DLL im UI Thread aufgerufen wird, da das der einzige Thread in LabVIEW ist der garantiert immer derselbe bleibt innerhalb einer LabVIEW Session.
Nun ist aber der UI Thread wie der Name schon sagt auch zuständig für das Updaten des User Interfaces und zudem werden ein paar andere Dinge wie etwa Property Nodes aus sicherheitstechnischen Gründen in diesem Thread ausgeführt.
Die Moral von der Geschicht: Wenn Du die DLL reentrant aufrufen kannst dann Du es. Wenn das crasht, oder unerklärliche Phanomene produziert musst Du sie eben im UI Thread laufen lassen. Dann musst Du aber dafür Sorge tragen, dass in anderen Loops die parallel laufen keine Frontpanelelemente geudated werden die ein synchrones Update ausführen (default ist asynchon) und auch keine Property Nodes sind, und auch keine anderen DLLs (oder CINs) die nicht reentrant sind (orange Hintegrundfarbe statt lichtgelber).
Und natürlich müssen alle Loops die parallel laufen sollen immer entkoppelt sein. Das heisst kein Verbindungsdraht von der einen Loop in die andere. Wenn Kommunikation zwischen solchen Loops nötig ist muss das auf andere Weise geschehen (in absteigender Folge der Bevorzugung): Queues, LV2 style globals, Interprocess Kommunikation (shared memory, Netzwerk, DDE/Apple Events, etc), lokale Variablen, oder globale Variablen.
Rolf Kalbermatter
