Mehrere Tests parallel laufen lassen

Huhu,
ich habe mich eben einem neuen Programm angenommen, weil dort etwas nicht ganz funktioniert und etwas fehlt.
Zu allererst muss ich das Programm neu schreiben, weil es unübersichtlich ist.

Es sind 10 While-Schleifen mit einer Menge Localer Variablen und Filmsequenzen.

Alle kein Problem.
Mir fällt nur keine Lösung für die 10 Schleifen ein.

Im Endeffekt funktioniert das folgender Maßen:

1. Einstellungen vornehmen
2. Messung starten
3. Warten bis fertig

Das Ganze soll 10 Mal möglich sein, sodass 10 Tests zeitgleich ablaufen können. Diese Tests müssen aber zu unterschiedlichen Zeitpunkten startbar sein.
Desshalb wurden bisher 10 Whileschleifen verwendet.
Im Frontpanel sind es 10 Tabs, welche man anwählen kann.

Gibt es andere Möglichkeit für eine parallele Verarbeitung oder geht es nur mit so vielen While-Schleifen?

Danke für alle Tips und Tricks.

Schauen kann ich leider erst übernächste Woche. Ich ziehe um und habe mir nächste Woche frei genommen.

Ein schönes Wochenende wünsche ich Euch.

Hallo Minako,

es ist anscheinend Urlaubszeit ...

Wenn du das Programm neu schreibst, dann kannst z.B.

Ein VI für die Messung schreiben (alle 10 sind ja weitgehend identisch). Die zugehörige Benutzeroberfläche entweder inclusive oder als separates VI.
Das Ganze muss ein reentrantes VI sein. Dann kannst du es 10 mal starten.
Diejenige Messung die der Benutzer deiner Software sehen will, die wird dann in einem Subpanel angezeigt.

Mahlzeit Minako,

es kommt ganz drauf an was in den 10 Schleifen denn passiert, ob man diese zusammenfassen kann in zB eine Datenerfassung und eine Auswertung, so kannst du immer alle Channel aufnehmen wenn diese an einer Messkarte hängen und nur die benötigten auswerten.
Oder ob die Schleifen komplett unabhängig voneinander sind und jede sein eigenes Timing braucht oder gar ganz andere Funktionen hat (scheint bei dir aber nicht so).

Ich bin Fan von dem Delacor QMH geworden, dort gibt es auch ein Modul für mehrere Instanzen, falls du in den 10 Schleifen programmtechnisch das Gleiche machst. Das geht auch in die Richtung von Martin und mit dem Tool muss man sich nicht um jede Kleinigkeit kümmern.
Hier kannst du die Datenerfassung entweder im jeweiligen Modul machen, oder ein Erfassungsmodul, das die Daten dann verteilt.

Viel Erfolg
Timo

Hi ihr Beiden,
war leider kein schöner Urlaub. Wir sind am umziehen.... Waren leider so doof und haben uns kein Unternehmen gebucht.

Aber egal. Zurück zum Thema.
Diese 10 Messungen sind unabhängig voneinander. Wie ich geschrieben hatte werden diese nicht zeitgleich gestartet und somit auch nicht zeitgleich ausgewertet.
Es wird bei jeder Messung ein neues Gerät angesprochen, welches von Hand angegeben werden muss.
Auch alle anderen Einstellungen werden von Hand angegeben und können zueinander verschieden sein.

Natürlich könnte ich ein subvi erstellen damit ich alle 10 Schleifen auf dem Bildschirm betrachten kann aber das ändert nichts an den 10 Schleifen.

@Martin.Henz
Reentrantes VI höre ich zum ersten mal. Ich hab mir mal eine Erklärung durchgelesen und bin nicht ganz sicher, ob ich das richtig verstanden habe...
Ich schreibe ein Sub VI welches die Grundfunktion der Messung durchführen kann.
Mein Main VI kann dann über eine Event case alle start und stop Buttons für alle 10 Messungen in 2*10 Fällen verwalten, welche auf das Sub vi zugreifen und das kann mit der Einstellung auf reentrantes VI vollständig parallel ablaufen?

Das könnte eine Lösung sein, wenn das so funktioniert.

@Timo
Es muss unabhängig voneinander sein. Zumindest verstehe ich das Ganze als unabhängig, wenn jede Messung zu einem anderen Zeitpunkt gestartet werden soll und auch beendet wird. Im Notfall auch mal abgebrochen wird. Dabei sollen nicht alle Messungen, sondern nur die eine Abgebrochen werden.

Hallo Minako,

Zitat:Reentrantes VI höre ich zum ersten mal. Ich hab mir mal eine Erklärung durchgelesen und bin nicht ganz sicher, ob ich das richtig verstanden habe...

Ein VI ist dann "reentrant", wenn es mehrfach parallel abgearbeitet werden kann, ohne dass sich die Instanzen gegenseitig beeinflussen.
Bedeutet:
- Du kannst darin nicht mit (einer) globalen Variablen (oder anderen globalen Speichern/Resourcen) arbeiten, wenn diese von den Instanzen verändert wird -> das würde die anderen Instanzen beeinflussen.
- Jede Instanz muss ihre "Variablen" intern selbst verwalten, also z.B. Shiftregister verwenden.
- LabVIEW kann dann diese Instanzen parallel im Speicher halten und passt dafür den VI-Namen (im Speicher an) -> es wird etwas schwieriger, an eine VI-Referenz für die jeweilige Instanz zu kommen.

Das Gegenteil ist dann: Wenn ein VI "nicht reentrant" ist, dann kannst du sie zwar parallel aufrufen, aber LabVIEW wird intern nur eine VI-Instanz verwenden, die die Aufrufe nacheinander abarbeitet. (Parallele Aufrufe nicht-reentranter VIs blockieren sich gegenseitig.)

(19.08.2024 11:23 )Minako schrieb:  Hi ihr Beiden,
war leider kein schöner Urlaub. Wir sind am umziehen.... Waren leider so doof und haben uns kein Unternehmen gebucht.

Aber egal. Zurück zum Thema.
Diese 10 Messungen sind unabhängig voneinander. Wie ich geschrieben hatte werden diese nicht zeitgleich gestartet und somit auch nicht zeitgleich ausgewertet.
Es wird bei jeder Messung ein neues Gerät angesprochen, welches von Hand angegeben werden muss.
Auch alle anderen Einstellungen werden von Hand angegeben und können zueinander verschieden sein.

Natürlich könnte ich ein subvi erstellen damit ich alle 10 Schleifen auf dem Bildschirm betrachten kann aber das ändert nichts an den 10 Schleifen.

@Martin.Henz
Reentrantes VI höre ich zum ersten mal. Ich hab mir mal eine Erklärung durchgelesen und bin nicht ganz sicher, ob ich das richtig verstanden habe...
Ich schreibe ein Sub VI welches die Grundfunktion der Messung durchführen kann.
Mein Main VI kann dann über eine Event case alle start und stop Buttons für alle 10 Messungen in 2*10 Fällen verwalten, welche auf das Sub vi zugreifen und das kann mit der Einstellung auf reentrantes VI vollständig parallel ablaufen?

Das könnte eine Lösung sein, wenn das so funktioniert.

@Timo
Es muss unabhängig voneinander sein. Zumindest verstehe ich das Ganze als unabhängig, wenn jede Messung zu einem anderen Zeitpunkt gestartet werden soll und auch beendet wird. Im Notfall auch mal abgebrochen wird. Dabei sollen nicht alle Messungen, sondern nur die eine Abgebrochen werden.

Also - so wie ich den letzten Satz verstehe - laufen potentiell mehrere Messungen auch mal parallel. Falls nein - SubVI und in eine Schleife und alles ist gut (lediglich ne Auswahl welches Gerät grade gestartet werden soll).
Falls ich richtig verstanden habe:
Worauf Martin eventuell hinaus wollte ist, den Asynchronen Call zu nutzen. Sprich: Du startest das SubVI, wartest aber nicht auf das Ende der Ausführung. Daher: Deine Schleife muss die Messung nur starten, aber nicht stoppen. Das ganze Reentrant (bei den Einstellungen des VIs) damit mehrere Instanzen des SubVI gleichzeitig laufen dürfen. Du musst dir dann lediglich überlegen wie du mit dem gestarteten VI "kommunizierst" (zumindest sollte man das wenn man im HauptVI auch die Möglichkeit haben will die SubVIs zu beenden). Hierzu kannst du Queues oder ähnliches verwenden. Prinzipiell kannst du dir damit vom SubVI auch Daten an deine Oberfläche zurücksenden lassen (so gewünscht) und auch den "Ende" status damit abfragen. Der "Ende"-Baustein für asynchrone Calls hilft dir wahrscheinlich weniger, da der eigentlich nur auf das Ausführungsende wartet (mit Timeout (hat der den?) müsste man pollen können welche der VIs schon beendet sind). Dann kannst du die "normalen" Datenflussausgänge des VIs zum VI Ende noch auslesen. Ich hatte dafür bisher allerdings noch keine Use Case - wenn ich sowieso zwischendurch über Queue mit dem VI reden muss / will, dann muss ich das eh handeln, dann kann ich da auch meine Daten rüber schieben.

Wichtig: Machst du's über Queues musst du dir überlegen wie du die antwortenden VIs auseinanderhälst, bzw. das VI was du "kontaktieren willst" eindeutig identifizierst. Eine Queue pro VI start erlaubt eine eindeutige identifikation (ohne Name erzeugen und eindeutige ID nutzen), für den Rücklauf kannst du eine gemeinsame Queue nutzen, dann musst du im HauptVI nur einen Kanal auswerten und dann zuordnen von wem der kam (das SubVI sollte eine eindeutige ID zurücksenden, z.B. die Queue referenznummer - irgendwas was du leicht vergleichen kannst).

Hoffe das war nicht zu wirr und die Idee ist verstanden.

Ich nutze so ein ähnliches Konzept aktuell um in einer Klasse quasi "Listener" zu erstellen, die dann Daten aus Hardwareschnittstellen an ein GUI streamen.

Gruß Kiesch

Anzeige

Huhu,

jetzt kann ich mich nach lagne Zeit endlich mal drauf melden.
Habe mich jetzt eine Weile damit beschäftigen können und kann das VI auf jedenfall zwei mal starten.
Bin mir aber nicht ganz sicher, ob ihr das so gemeint hattet.    
Es ist die einzige Variante, die ich ans laufen bekommen habe.
Es bleibt aber das Problem des Schliessens.
Im Sub VI habe ich einen Stop Button. Dieser soll die Messung abbrechen, wenn man was falsch eingegeben hat oder die Messung pausiert werden muss.
Da werde ich noch mal schauen müssen.

Ich habe noch keine Ahnung, wie man so einen Clone schließt, damit er keine Kapazitäten mehr verbraucht.
Und wie kann ich (falls ich das brauche) hergehen und einen Stop-Button des Sub.VIs im Main.VI auslesen, damit das Main.VI das Sub.VI schließen kann.
Also im Invoke Node kann ich Werte rausholen das ist kein Problem.
Nur muss das alles dem richtigen Clone zugewiesen werden.
Aktuell sage ich ja, dass er nicht aufs VI warten soll und die Whileschleife geht weiter.
Da kann ich auf kein Stop-Signal warten.

Vielen Dank für eure hilfreichen Tipps.

Hi Minako,

(09.10.2024 14:48 )Minako schrieb:  Bin mir aber nicht ganz sicher, ob ihr das so gemeint hattet.

Jain - eher nicht.

Sondern eher ein VI mit dem du über Queues oder über Userevents kommunizierst. Dann kann dir das VI auch sagen, wann ein Test beendet ist und andere Informationen. Und du kannst dem VI mitteilen, dass jetzt ein neuer Test gestartet werden soll (und mit welchen Einstellungen) und dem VI kannst du auch mitteilen, dass es sich beenden soll.

Guten Morgen Minako,

ich benutze Delacor QMH, dort gibt es clonable modules, diese können unbegrenzt oft aufgerufen werden. Das ganze nötige drum herum macht das Tool selbst und man kann sich größtenteils um die eigentliche Software kümmern. Zugegeben, das QMH denken fällt mir teils immer noch schwer für bestimmte Aufgaben..

Ich weiß es ist nicht leicht sich in so Tools einzuarbeiten, aber von Grund auf ein eigenes QMH würde ich nicht so einfach hinbekommen und braucht auch Einarbeitung (da gibt es sicher auch Tutorials oder gar Exampels für).

Grüße Timo

Hi TpunktN,
wenn ich das richtig sehe, ist das ein externes Programm?
Also nichts, was direkt in LabView eingebunden ist?
Könnte Probleme mit meiner IT geben.

Hi Martin.Henz,
hmm, ich habe noch nie mit Queues gearbeitet. In LabView Core 2 habe ich grob erfahren was es ist und macht aber wie ich das nutzen kann ist mir noch schleierhaft.
Für mich ist der Grundaufbau mit Queues als reentrante Version ein schwarzes Loch. Ich habe keine Vorstellung davon.
Ich weiß es gibt irgendwo in Labview sicher ein paar Beispiele.
Jedoch hatte ich gehofft, es auf meine Art irgendwie lösen zu können.
Scheint dann aber sehr kompliziert zu werden.
Ich habe das ganze Prinzip mit reentrantem Arbeiten in Labview noch nciht ganz durchblickt.
Zumindest nicht die Umsetzung davon. Die zu nutzenden Parts in Labview widersprechen sich gegenseitig, was bei mir nicht selten zur Verwirrung führt....

Ich probiere mich mal weiter aus. Ich werde sicher den Rest meines Lebens immer wieder neues erfahren.

Danke.