While-Schleife aus zweiter Schleife steuern

(17.03.2015 17:34 )flipp86 schrieb:  

Zitat:Nur wird die untere Schleife den Case Serial-Port Run immer wieder aufrufen, weil sie den Befehl ja selber immer wieder in die Queue schreibt.

Genau das ist der entscheidende Punkt. Ich brauch ja eine Struktur, die automatisch immer wieder aufgerufen wird, um die Daten über die Serielle Schnittstelle zu empfangen.
Ist es nun sinnvoller dies mittels des Eigenaufrufes zu lösen oder ist es besser eine ganz normale while-schleife parallel laufen zu lassen?
Oder gibt es noch eine weitere Möglichkeit ?

Wäre super, wenn mir da noch jemand helfen könnte. Ansonsten läuft es nämlich ziemlich gut dank eurer Hilfe.

LG Philipp

Hallo Philipp,

Zitat:Genau das ist der entscheidende Punkt. Ich brauch ja eine Struktur, die automatisch immer wieder aufgerufen wird, um die Daten über die Serielle Schnittstelle zu empfangen. Ist es nun sinnvoller dies mittels des Eigenaufrufes zu lösen oder ist es besser eine ganz normale while-schleife parallel laufen zu lassen?

Wenn der Eigenaufruf quasi die Befehlsqueue blockiert, ist das wohl nicht sinnvoll.
Momentan kannst du diesen "Eigenaufruf" nicht einmal unterbrechen, da dieser Case ja gleich wieder sich selbst über die Queue aufruft…

Wenn du Gerätekommunikation unabhängig/ungestört von anderen Dingen erledigen willst, dann sollte das in einer parallelen Schleife stattfinden!

Was auch noch nicht so toll ist:
Wenn du Referenzen durch eine Case-Struktur verdrahtest, dann solltest du das in allen Cases tun.

Hi Gerd,

danke für deine Antwort. Damit ergeben sich leider doch wieder neue Fragen

Zitat:Wenn der Eigenaufruf quasi die Befehlsqueue blockiert, ist das wohl nicht sinnvoll.
Momentan kannst du diesen "Eigenaufruf" nicht einmal unterbrechen, da dieser Case ja gleich wieder sich selbst über die Queue aufruft…

Stimmt, verlassen im sinne von beendet kann sie immoment nicht werden. Die soll aber auch wenn das Programm läuft, immer aufgerufen werden.
Wenn von der Event-Struktur ein neuer Befehl auf die Queue geschrieben wird, dann wird dieser Fall auch abgearbeitet. Es stehen dann ja beide Befehle in der Queue.


Ich könnte auch eine eigenen Queue nur für die "Serielle-Kommunikation" benutzen und für zeitkritische Dinge eine zusätzlichhe Queue. Wäre da grundsätzlich was dran auszusetzten? Wäre das unsauber/ unschön?

Das mit dem Durchverdrahten in den Cases wird noch gemacht. Danke

LG Philipp

Moin,

Du weißt aber nie, an welcher Stelle in der Queue Dein Eigenaufruf gerade landet. Unschön.

Du könntest den Abfrage-State auch als default-Case definieren. (Achtung! Nur dann, wenn die Abfrage weder zeitkritisch ist, noch für nennenswerte Verzögerungen sorgt.) Zusätzlich muss eine weitere Case-Struktur im Default-Case prüfen, ob das System läuft (serielle Abfrage möglich) oder nicht (einfach ein paar ms Verzögerung stattdessen im Case platzieren).

Die "saubere" Lösung ist aber in jedem Fall eine seperate Schleife die sich "nur" um die serielle Schnittstelle kümmert.
Je nachdem ob alle Ergebnisse oder nur das letzte benötigt werden, kann man dann wiederum Notifier oder Queue benutzen um diese an die anderen Schleifen zurück zu geben.

(23.03.2015 09:39 )flipp86 schrieb:  [...]
Ich könnte auch eine eigenen Queue nur für die "Serielle-Kommunikation" benutzen und für zeitkritische Dinge eine zusätzlichhe Queue. Wäre da grundsätzlich was dran auszusetzten? Wäre das unsauber/ unschön?

Nöh....

(17.03.2015 17:22 )Nordvestlys schrieb:  [...]
- als Faustformel für eigene Schleifen würde ich sagen, alles was Verzögerungen verursachen kann (z.B. Benutzereingaben) oder zeitkritisch ist (z.B. Messwerterfassung) kommt in unabhängige Schleifen und wird mit Queues, Meldern etc. synchronisiert.
Alle übrigen Sachen "dürfen" zusammen abgearbeitet werden.

Um die Verdrahtung von etlichen verschiedenen Queues, Meldern etc. übersichtlich zu halten, kann man sie auch als Cluster zusammenfassen und die verschiedenen Schleifen in einzelne SubVIs packen.

Vorteil: Gewinn an Übersichtlichkeit .... genau ein VI für genau eine Aufgabe.
(Wobei "Aufgabe" hier im Sinne von "Gruppe-zusammengehöriger-Aufgaben" zu verstehen ist.)