Erzeuger-Verbraucher Entwurfsmuster und Errorcluster

' schrieb:Wenn ich den Umweg über das SubVI "Queue anfordern" gehe und dort als Eingang einen Error-Cluster platziere und dann davon die Referenz erstelle, geht es.
Ich habe die Referenz zuerst direkt vom SubVI "Element einfügen" erstellt.

Das ist kein Umweg. Das gehört so. Du musst einer Queue vorher miteilen welchen Datentyp sie transportieren soll.

Zitat:Ich habe jedoch eine Verständnisfrage dazu:
Zunächst erscheint mir eine Schleife mit Schieberegister, die nur einmal durchlaufen wird, weniger sinnvoll. Ich verstehe nicht ganz, wieso das Schieberegister hier Wirkung zeigt.

Das was du hier beschreibst nennt sich: FGV (Funktionale Globale Variable). Dabei macht man sich die Eigenschaft von Schieberegistern zu nutze, dass sie uninitialisiert den Inhalt vom letzten Aufruf behalten. D.h. sie merken sich ihren Inhalt von einem (subVI) Aufruf zum nächsten. Desweiteren kann man FGV's, über das Merken von z.B. Referenzen hinaus, noch andere kleine Funktionen verpassen. <strike>Hier hat man die Möglichkeiten: "Queue anfordern" und "gemerkte Queue-Referenz lesen"</strike>
Das stimmt für dieses Beipsiel nicht. Queue anfordern wird wohl nicht in der FGV gemacht! Man kann also nur eine Queue-Referenz reinschreiben oder in die ErrorQueue reinschreiben.

Zitat:Dieses SubVI aus Abb. 8.18 platziere ich doch mehrmals in meinem Programm, jeweils am Ausgang einer "Fehlerkette" oder nur einmal?

FGV's können überall in deiner Applikation eingesetzt werden.

Anzeige

Ach das sind FGVs. Ich habe davon öfters gelesen, aber ohne praktische Beispiele konnte ich mir nur schwer was darunter vorstellen.
Vielen Dank!

' schrieb:
Und: sie durchbrechen das Datenflußprinzip

Wer hat dir denn sowas erzählt?

' schrieb:Wer hat dir denn sowas erzählt?

Wenn ich zwei VIs per Draht verdrahte, arbeitet das zweite VI erst dann, wenn das erste VI beendet ist. Das liegt daran, weil ein Fluß von Daten explizit von VI1 zu VI2 geht.

Verbinde(!) ich beide VIs per Queue/Melder, kann(!) VI2 auch laufen, obwohl VI1 noch gar keine Daten zur Verfügung stellt. VI2 läuft also, obwohl kein Fluß von Daten, die eigentlich in VI2 benötigt werden, besteht.

Datenfluß ist doppeldeutig: Einmal bezeichnet es die explizite, also physikalische Linie zwischen zwei VIs. Zum zweiten bezeichnet es auch den logischen Datenfluß, der aber an keinerlei physikalische Grenzen gebunden sein muss.

Trotzdem fließen die Daten auch in eine Queue und wieder heraus. Hier wird nichts am Datenflussparadigma durchbrochen.

Ich denke, darüber kann man streiten.
Der optische (im Blockdiagramm dargestellte) Datenfluss ist nicht gegeben. Man kann folglich nicht genau sagen, in welcher Reihenfolge die SubVIs bearbeitet werden.

Natürlich fließen die Daten in die Queue und wieder raus, aber man sieht nicht, wann welches SubVI ausgeführt wird.

Anzeige