Hallo Kollegen.....
hab wida mal ein problem zu lösen. Ich versuch den Komplizierten Sachverhalt mal plausibel rüberzubringen.
Ich habe ein LabVIEW-VI geschrieben mit dem ich den analogen Eingang einer Messkarte auslese. Das Ganze über eine bestimmte definierbare Zeit (i.d.R 10 sekunden). Grundproblem bei der ganze Sache ist, dass das über eine DLL läuft und mein VI während dieses Vorganges keine Befehle ausführen kann. Ich will nun aber während dem Auslesen der Messkarte (i.d.R. nach 5 sekunden) einen digitalen ausgang der Karte ansteuern.
ich hab das folgendermaßen gelöst.
Kurz bevor die 10 sekunden gemessen werden, schreibe ich mit meinem hauptprogramm, welches die Karte ausliest, einen wert in eine ini-datei(...=True). nun hab ich zusätzlich ein zweites VI geschrieben was kontinuierlich die ini-datei ausliest. wenn der besagte wert TRUE ist steuert dieses VI den digitalen ausgang nach den besagten 5 sekunden an. damit das ganze simultan ablaufen kann hab ich letztendlich aus diesem VI, welches den digitalen ausgang ansteuert, eine exe gemacht.
was anderes ist mir leider nicht eingefallen. ich hoffe es ist verständlich geschrieben(ist es in der regel leider nicht....).
gibts noch andere lösungsansätze? kann man das so machen?
mfg-erbi
Warum so einen Aufwand? könntest doch z.b. per TCPIP über das loopback-device kommunizieren. oder gleich per ActiveX oder DDE ..
TCPIP häte auch den Vorteil das Du die beiden Programme aufverschiedenen Rechnern laufenlassen könntest.
Unter Linux hättest auch per Pipe oder FIFO-Node die Programme verknüpfen können..
Gruß, Rob
versteh ich net.....wie gesagt.....mein programm macht während den 10 sekunden GARNÜSCHT....da fällt quasi alles flach was irgendwie mit dem blockdiagramm des hauptprogramms zu tun hat...
Hast DU mal probiert, zwei parallele Whileschleifen in Deinem VI zu erstellen?
Die erste ruft über DLL den analogen Wert ab und die zweite kümmert sich um den Port.
Die beiden Schleifen können dann über eine Queue kommunizieren.
Gruß
Andreas
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
Hallo erbi,
da gibt es schon zwei fertige Templates in LV.
Kannst Du ja mal für einen ersten Test hernehmen.
Gruß
Andreas
' 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
ach du schande, was man da alles beachten muss.....werd ich mal alles ausprobieren.....vielen dank schonmal.....ich halt euch auf dem laufenden