' schrieb:Wofuer steht bitte BD?
Blockdiagramm.
Zitat:Moment, das ist jetzt verwirrend. Das Haupt.vi besteht aus einem Producer-Consumer-Pattern.
Ein Pattern ist eine Vorlage - die man nicht unbedingt exakt so einhalten muss. Man kann "Producer-Consumer-Pattern" auch als Konzept sehen. Ein VI ist der Producer, ein anderes der Consumer. Producer und Consumer müssen nicht zwangsweise in einem VI liegen. Lediglich die Queue-Referenz (allgemein: Datenreferenz) haben sie gemeinsam.
Zitat:Im Producer sind bei Dir die Eventbuttons?
In dem VI, das den "Producer" enthält, befindet sich auch die GUI-Schnittstelle. Die GUI-Schnittstelle enthält die Buttons, deren Werte der "Producer" dem "Consumer" senden soll.
Zitat:Consumer-Schleife kann als Sub.Vi ausgelagert werden, wenn man moechte?
Ja natürlich.
Du muss das Gesamtprogramm betrachten. In welchem VI eine Operation ausgeführt wird, ist völlig egal. Zwei VIs (das, das den Producer enthält, und das, das den Consumer enthält) sind ja durch die Queue verbunden. Eine Queue ist eine imaginäre Verbindung zwischen Producer und Consumer. Die Queue-Verbindung zwischen den beiden ist nicht sichtbar - was im BD sichtbar ist, ist nur die Referenz. Da Producer und Consumer keine explizite Verbindung haben, kann man sie auch in unterschiedliche VIs legen. Eine explizite Verbindung wäre ein Draht zwischen beiden.
Zitat:Was genau ist jetzt fuer dich ein Modul
Ein Treiber z.B. ist ein Modul. Ein Modul ist eine Klasse, die das Endgerät komplett steuern kann. Eben je nach Vorgabe durch den Producer.
Zitat:und was bedeutet bitte"liegt am Eingang auf dem BD des Main.vi"?
Du weist ja noch: Producer und Consumer sind durch die Queue verbunden. Liegen beiden z.B. in unterschiedlichen SubVIs muss man den SubVIs die Queuereferenz mitteilen. Dies kann man machen, über einen Eingangsparameter am SubVI.
Zitat:Generell ist mir nicht klar, wie ich die dauerhafte Ueberwachung meines Geraetes programmieren soll, ohne das Gerät für die Eventstruktur ("Buttonklicks" zu blockieren") Im Beispiel unten habe ich testweise eine weitere Schleife gebaut, in der ein wait sitzt. Es scheint zu klappen, aber ich weiss nicht, ob die Umsetzung richtig ist.
Kuck ich mir später an.
Zitat:Der Consumer-Loop entspricht also in diesem Beispiel dem Endgeraet-Modul?
Genau.
Zitat:Haettest Du vielleicht ein Beispiel fuer ein FGVs, dass in einem "komplexeren" Programm eingebettet ist? Es heisst zwar immer, in FGVs kann man Daten speichern, nur weiss ich nicht, wie man an einem im Diagramm weiteren Ort, z.b. in einer anderen parallelen Schleife darauf zugreift.
Für ein Beispielprogramm muss ich mal kucken. Zum darauf zugreifen: Einfach das FGV-SubVI auf das BD setzen und aufrufen ...
Zitat:1. Warum hast Du Dich fuer eine Sequenz entschieden?
Müsste ich jetzt erst kucken. Eine Sequenz (Statemachine?) ist das, was das Modul mit dem Endgerät macht: Nämlich "der Reihe nach" diverse Operationen ausführen: Überwachen dies; Überwachen da; Kucken, ob der Producer was geschickt hat und entsprechens ausführen.
[_quote]2. Warum hast Du darauf verzichtet, ein Event dynamisch zu registrieren? Das war ja mein ursprünglicher Ansatz.[_/quote]Warum soll ich ein dynamisches Event verwenden, wenn es auch ohne und einfacher geht.
[_quote]3. Warum sind in der zweiten while-Schleife im Producer-Loop waits eingebaut?[_/quote]Damit diese While-Schleife nicht unendlich schnell läuft. While-Schleifen dürfen nicht unendlich schnell laufen, sonst blockieren sie die CPU.
[_quote_]Die naechste Herausforderung war nun, dem Geraet mitzuteilen, WANN die Richtungsumkehr erfolgen soll.[_/quote_]Das kuck ich mir später mal an.
Ich muss mal was arbeiten - und mal endlich einen Kaffee holen. Außerdem ist die ANnahl der Quotes schon wieder überschritten.
