Wenn dein Problem oder deine Frage geklärt worden ist, markiere den Beitrag als "Lösung",
indem du auf den "Lösung" Button rechts unter dem entsprechenden Beitrag klickst. Vielen Dank!
ich arbeite momentan an einem Programm (Datenlogger), das diverse Schleifen besitzt, die parallel Dinge wie Datenerfassung, Aufbereitung, Anzeige etc. durchführen. Eine Schleife beherbergt ein Event-Case, für die Bedienelemente der Benutzeroberfläche.
Für die Kommunikation zwischen den Schleifen benutze ich Queues und Melder. Da mich die Verdrahterei aber echt etwas Nerven kostet und ich zuletzt Action Engines und FGV`s entdeckt habe, bin ich übermütig geworden und habe mir gedacht ich könnte doch alle Queues und Melder über ein SubVI verwalten und mir so die Kilometer sparen, die ich sonst mit Leitungen (Referenzen und Error-Leitungen) verlegen müsste. So wäre es nicht nur übersichtlicher sonder (denke ich mal) auch skalierbarer.
Im Anhang befindet sich ein erster Ansatz zu so einem VI. Mein Problem momentan besteht darin, dass wenn ich dieses VI in verschieden Schleifen lade und sagen wir in der einen etwas "enqueuen" lasse während ich es in der anderen "dequeuen" lasse, oft eins von beiden hängt (sichtbar am grünen Pfeil, wenn ich "highlight execution" activiere oder Schritt für Schritt Ausführe).
Ich wäre sehr dankbar, wenn jemand etwas dazu sagen könnte - ich komm hier einfach nicht weiter. Liegt es daran, dass ich das VI mehrfach öffne? Gerne lese ich auch andere Beitrage dazu...ich kann mir dazu nur momentan nicht selber weiterhelfen.
Ja, Roumaen, schwieriger Fall. Ich glaube, so wird das auf Dauer nix. Ich befürchte, hier werden die Nachteile die Vorteile überwiegen. Für mich sieht das VI aus, als ob es einen Selbstzweck habe: nämlich das Verwalten von Queues. Das mag theoretisch gut sein. Auch für das "Verwalten von Queues" kann man eine "Klasse" machen - aber: Eigentlich willst du doch bestimmt keine Queues verwalten, sondern den Inhalt der Queues, z.B. Daten. Oder du willst Queues als Schnittstelle zwischen Modulen verwenden. Queues/Melder sollen ja Mittel zum Zweck sein, nicht Selbstzweck.
Ich mach das immer so:
Ich habe ein VI, Enumerator gesteuert, das Queues/Melder erzeugt, schließt und die Referenzen der Queues/Melder ausgibt. Erzeugen und Schließen wird genau einmal aufgerufen - am Anfang und am Ende des Programmes (das entspricht dem ersten und dritten Case in deinem VI). Während des normalen Ablaufes wird es auch immer aufgerufen, aber nur um die Referenzen zwecks Schreiben/Lesen von Queue/Melder zu holen. Das tatsächliche Schreiben/Lesen, was in deinem VI der mittlere Case ist, wird im entsprechendem Algorithmus gemacht.
Was deine Methode und meine gemeinsam haben, ist, dass keine expliziten Drahtleitungen (nur kurze Drähte zwischen zwei neben einander liegenden Symbolen) notwendig sind.
Skalierbar und wiederverwendbar ist meine Methode deswegen, weil man nur den Typ der Queues änder muss, das Verfahren und die Vorlagen an sich aber beibehalten werden können. Dass eine Anpassung des Typs Folgeanpassungen zur Folge haben kann, nehme ich in Kauf.
Jeder, der zur wahren Erkenntnis hindurchdringen will, muss den Berg Schwierigkeit alleine erklimmen (Helen Keller).
(20.10.2018 14:10 )Roumaen schrieb: Für die Kommunikation zwischen den Schleifen benutze ich Queues und Melder.
Das ist gut so.
Zitat:FGV's
Ich finde es sehr gut von dir, diese Methode der Datenverwaltung zu verwenden. Man kann in FGVs hervorragend Methoden integrieren ...
Zitat:ich könnte doch alle Queues und Melder über ein SubVI verwalten und mir so die Kilometer sparen, die ich sonst mit Leitungen (Referenzen und Error-Leitungen) verlegen müsste. So wäre es nicht nur übersichtlicher sonder (denke ich mal) auch skalierbarer.
Grundsätzlich ist dieser Denkansatz richtig. (Im übrigen bin ich der Meinung, es ist fast noch w/r-ichtiger erst einmal einen Denkansatz zu haben).
Zitat:oft eins von beiden hängt
Das ist wohl wie folgt der Fall:
Das Auslesen der Queues geschieht ohne Timeout. Hier würde das VI stehenbleiben, bis etwas in der Queue steht. Hineingeschrieben werden kann aber nichts - da das VI ablaufvariant ist. Zwar gibt es einen Case "Status holen" - den zu verwenden entspricht aber nicht deiner Intension. Du müsstes vor dem Lesen der Queue den Status abfragen und das Lesen in einen IF-Case packen - das aber bedeutet im Algorithmus Verdrahtungsaufwand und ist "unübersichtlich". Da du den Status sowieso abfragen musst, ist es egal, ob das im "Queue-VI" oder im Algorithmus geschieht. Außerdem gibt es mein Auslesen der Queue immer einen nachfolgenden IF-Case wegen der Fälle Daten, keine Daten bzw. Queue-Fehler.
Zitat:Liegt es daran, dass ich das VI mehrfach öffne?
Eigentlich nicht am mehrfach öffnen (Hinweis: Es ist nicht "Öffnen", eher sowas wie "in einem BD verwenden"). Problematisch ist eher die gleichzeitige(!) Verwendung des VIs, die infolge der Parallelität der Algorithmen entsteht.
Jeder, der zur wahren Erkenntnis hindurchdringen will, muss den Berg Schwierigkeit alleine erklimmen (Helen Keller).
21.10.2018, 17:54 (Dieser Beitrag wurde zuletzt bearbeitet: 21.10.2018 17:57 von GerdW.)
Zitat:Da mich die Verdrahterei aber echt etwas Nerven kostet
Echt?
Zitat:und ich zuletzt Action Engines und FGV`s entdeckt habe, bin ich übermütig geworden
Ja...
Zitat:habe mir gedacht ich könnte doch alle Queues und Melder über ein SubVI verwalten
ALLE Queues UND Melder über nur ein einziges VI verwalten?
Damit führst du aber die Datenkapselung auf die (unnötige) Spitze…
Zitat:mir so die Kilometer sparen, die ich sonst mit Leitungen (Referenzen und Error-Leitungen) verlegen müsste
Diese "Kilometer" macht niemand gern…
Wie ich das so mache:
- Anstatt das Enum in eine Zahl umzuwandeln, nutze ich FormatIntoString und wandle das Enum in einen Text um: aus "DAQ Queue" wird so nicht die Nummer "0", sondern der Text "DAQ Queue". Ergibt viel eindeutigere und aussagekräftigere Queue-Namen!
- Wenn ich eine Queue in mehreren subVIs benötige, erstelle ich mir ein weiteres subVI (nur für diese spezielle Queue), in der ich die Queue-Referenz (über den Namen) erzeuge und zusätzlich noch den Datentyp (der ja quasi immer ein typdefinierter Cluster ist), ausgebe. Also ein subVI als Ersatz für ObtainQueue… Jetzt kann ich einfach mit diesem subVI die Queue anfordern und hinterher über ein normales CloseQueue wieder freigeben:
Dieses "Get Queue" wird in ca. 40 subVIs im Project aufgerufen, der String-Input gibt einen Namen vor. (Es wird für eine mehrstufige Queue verwendet, wo alle Teilnehmer den gleichen Datentyp verwenden.)
Das kleine rote "Stop" ist übrigens auch eine FGV: sie dürfte gefühlt 200× im Project aufgerufen werden…
danke an der Stelle für die Tips und, dass sich jemand die Zeit nimmt meine Versuche anzugucken - ich profitiere sehr von diesem Forum!
Da ich mir das alles (LabVIEW) versuche selber zu erarbeiten, gehe ich erstmal den Weg alles zu verdrahten und wenn das Programm steht (sinnvoll ) zusammenzufassen bzw. in SubVI`s zu packen. Ist wahrscheinlich klüger als alles auf einmal umzusetzen.
Trotzdem fürs Verständnis; verstehe ich es richtig, dass es (zumindest ohne eingestelltes Timeout) der Fall ist, dass die eine Instanz des VI`s darauf wartet etwas zu "dequeuen" und damit andere Instanzen des VI`s, die etwas "enqueuen" wollen blockt oder andersherum? Stichwort: reentrant/not reentrant.
Würden - gesetzt den Fall, dass ich die VI´s reentrant aufrufe - jedesmal neue Queues oder Kopien erzeugt werden (first call funktion wird ja verwendet)? Wenn ich richtig informiert bin, bekomme ich dann ja zügig Speicherprobleme.
DANKE und guten Start in die Woche!
EDIT: das mit den Kilometern ist natürlich übertrieben Gerd...ich hab aber wohl einen hohen Anspruch an die "Optik" meines Codes, da ich fünfach geknickte Leitungen und VI`s, die nicht im Raster angeordnet sind als störend empfinde. Wenn ich dann einen Ansatz über den Haufen werfe und alle Queues und Melder neu platzieren und verdrahten muss (passiert mir immer wieder, während ich mich schlau lese), dann hab ich das Gefühl gar nicht voranzukommen. Vielleicht versteht mich ja jemand
Zitat:Trotzdem fürs Verständnis; verstehe ich es richtig, dass es (zumindest ohne eingestelltes Timeout) der Fall ist, dass die eine Instanz des VI`s darauf wartet etwas zu "dequeuen" und damit andere Instanzen des VI`s, die etwas "enqueuen" wollen blockt oder andersherum?
Genau, richtig verstanden.
Zitat:Würden - gesetzt den Fall, dass ich die VI´s reentrant aufrufe - jedesmal neue Queues oder Kopien erzeugt werden (first call funktion wird ja verwendet)? Wenn ich richtig informiert bin, bekomme ich dann ja zügig Speicherprobleme.
Auch richtig verstanden.
Das Grundprinzip einer FGV verlangt, dass diese eben NICHT reentrant gesetzt wird - es sollen ja alle auf die selbe (und nicht nur die gleiche ) Instanz zugreifen!
Zitat:da ich fünfach geknickte Leitungen … als störend empfinde.
Ich auch.
Im Bild oben siehst du aber die typische Nutzung einer Queue (bei mir): ein gerader Draht…
) zusammenzufassen bzw. in SubVI`s zu packen. Ist wahrscheinlich klüger als alles auf einmal umzusetzen.