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!
12.10.2010, 15:52 (Dieser Beitrag wurde zuletzt bearbeitet: 12.10.2010 16:22 von htw10870.)
6.1, 8.00, 8.2, 8.2.1, 8.5, 8.5.1, 8.6, 2010
2004
de
01468
Deutschland
Queuereferenzen im Blockdiagramm verteilen
Hallo,
ich habe eine Anwendung bei der ca. 20 Prozesse parallel und asynchron laufen. Jeder jeweils in einer eigenen While-Schleife. Den Datenaustausch möchte ich über Queues realisieren. Da meine Programminitialisierung im 1. Fenster einer gestapelten Sequenz läuft in der auch die Queues erstellt werden und die While-Schleifen im 2. Fenster habe ich mir überlegt die Queue-Referenzen ebenfalls im 1. Fenster zu verteilen und über lokale Sequenzvariablen direkt an die While-Schleifen im 2. Fenster zu übergeben, quasi an Ort und Stelle genau vor der Nase der jeweiligen While-Schleife. Das spart das Ziehen von Querverbindungen im Hauptfenster vor den While-Schleifen.
Ist eine lokale Sequenzvariable kritisch was Resourcenverbrauch angeht? Wie würdet ihr das machen?
Grüße
Mathias
12.10.2010, 19:56 (Dieser Beitrag wurde zuletzt bearbeitet: 12.10.2010 19:58 von IchSelbst.)
' schrieb:ich habe eine Anwendung bei der ca. 20 Prozesse parallel und asynchron laufen. Jeder jeweils in einer eigenen While-Schleife.
An sich ist das richtig so ...
Zitat:Den Datenaustausch möchte ich über Queues realisieren.
... und auch das ist eher sehr gut ...
Zitat:Da meine Programminitialisierung im 1. Fenster einer gestapelten Sequenz läuft in der auch die Queues erstellt werden
... auch hier bin ich noch auf deiner Seite ...
Zitat:und die While-Schleifen im 2. Fenster
... aber: 20 Prozesse, jeweils eine While-Schleife, in einem Sequenzrahmen, also alles im MainVI? - Neeee.
Zitat:habe ich mir überlegt die Queue-Referenzen ebenfalls im 1. Fenster zu verteilen und über lokale Sequenzvariablen direkt an die While-Schleifen im 2. Fenster zu übergeben, quasi an Ort und Stelle genau vor der Nase der jeweiligen While-Schleife.
Theoretisch ja. Aber eben nur theoretisch.
Zitat:Das spart das Ziehen von Querverbindungen im Hauptfenster vor den While-Schleifen.
Nebenbei: Das Einsparenwollen von Drähten im Blockdiagramm ist immer die schlechteste aller Lösungsmöglichkeiten.
Zitat:Ist eine lokale Sequenzvariable kritisch was Resourcenverbrauch angeht?
Dieser Ressourcenverbrauch an sich wäre in deinem Falle irrelevant, da ja die Hauptarbeit im 2. Rahmen stattfindet. Während der eigentlichen Arbeit liegen die lokalen Sequenzvariablen also brach.
Zitat:Wie würdet ihr das machen?
Pro Prozess ein SubVI. Gesteuert per Queue oder per FGV, Datenrückmeldung per Melder oder per FGV.
Jeder, der zur wahren Erkenntnis hindurchdringen will, muss den Berg Schwierigkeit alleine erklimmen (Helen Keller).
6.1, 8.00, 8.2, 8.2.1, 8.5, 8.5.1, 8.6, 2010
2004
de
01468
Deutschland
Queuereferenzen im Blockdiagramm verteilen
Hallo,
danke für den Hinweis. Reicht es beim Anfordern einer Queue wenn sie an einer einzigen Stelle mit einem Typ definiert wurde, bspw. bei der Initialisierung des Programms oder muss das überall geschehen wo sie angefordert wird?
beim Anfordern einer Queue muss der Typ immer bekannt sein, also mit angeschlossen werden. Du kannst aber über den Namen der Queue immer auf die gleiche Queue zugreifen...
Ich mach das mit den Queues immer so. Ich mach ein FGV mit einem Parameter, der in der FGV als "GetReferenz" vorbesetzt ist. Die FGV hat prinzipiell drei Cases: Queuereferenz erstellen (CreateMyQueue), Referenz lesen (GetReferenz), Referenz schließen (CloseMyQueue). Im ersten Sequenzrahmen rufst du die FGV auf mit "CreateMyQueue" auf, im mittleren Rahmen ohne Aktualwert (der GetReferenz hieße), im letzten Rahmen rufst du die FGV mit "CloseMyQueue" auf. Das hat den Vorteil: Du vergisst zum QueueAnfordern das QueueFreigeben nicht.
Zu jedem einzelnen QueueAnfordern muss es einen expliziten QueueFreigeben geben.
Jeder, der zur wahren Erkenntnis hindurchdringen will, muss den Berg Schwierigkeit alleine erklimmen (Helen Keller).
' schrieb:Legst du dann für jede evt. Queue eine eigene FGV an und handhabst den Queuetyp innerhalb der FGV?
Das kommt darauf an.
Im Allgemeinen gilt:
Aus einer FGV müssen ja per Ausgang Daten herausgeführt werden. Der Ausgang selbst ist aber immer typspezifisch. Typunspezifische, also variante Ausgänge sind unsinnig. Die Ausgangsdaten müssten dann ja im aufrufenden BD konvertiert werden. Das kosten aber unnütz Platz. Einzige Lösung wären mehrere Ausgänge am FGV.
Im Speziellen gilt:
Ich gehe davon aus, dass jeder Prozess einen eigenen Queue-Datentyp hat. Demzufolge sind also auch die Queue-Referenzen typspezifisch und haben somit keine gemeinsame Basis. Daraus müsste man schließen, das pro Queue ein FGV existieren müsste.
Fazit:
Eine FGV pro Prozess ist dann sinnvoll, wenn pro Prozess mehrerer Queues und/oder Melder verwendet werden. Bei mehreren unterschiedlichen Queues/Meldern pro Prozess würde eine einzige FGV für alle Prozesse zu unübersichtlich werden.
Wenn es dir gelinkt, die Queues/Melder aller Prozesse auf identischen Datentypen aufzubauen - dann geht alles auch mit einem FGV. Dann nämlich kannst du die Queues/Melder aller Prozesse in einem Arr[NbProzess]OfClust(Q1,Q2,M1,M2) ablegen. Der Ausgang der FGV wäre dann je nach Gusto entweder der Cluster (ein Ausgang) oder der Inhalt des Clusters (vier Ausgänge). Als Eingang gibt es dann nur die Prozessnummer und der Mode.
Jeder, der zur wahren Erkenntnis hindurchdringen will, muss den Berg Schwierigkeit alleine erklimmen (Helen Keller).
/
Queuereferenzen im Blockdiagramm verteilen
