Drei Queues in einer While-Schleife mit case-Struktur

Hallo liebes Forum,

ich würde euch gerne bezüglich den Queues in meinem Progamm um euren Rat und eure Meinungen bitten.

Es geht um mein Messprogramm, welches in zwei Modi Daten erfassen und speichern kann. Das Programm ist nach dem Producer-Consumer Modell aufgebaut; es gibt für jeden Modus eine separate Queue, die vom Producer (erfassen) zum Consumer (speichern) führt. Es soll während einer Messung nur ein Modus aktiv sein.
Den Consumer habe ich mit einer einzigen While-Schleife realisiert, in der sich eine case-Struktur zur Unterscheidung der Messmodi befindet. Folglich führen zwei Daten-Queues zum Consumer.

Ich habe festgestellt, dass ich während der Programmlaufzeit den Selektor (Schalter) für die case-Struktur nicht mehr ändern kann. Er verbleibt immer in seiner Anfangsposition. Das Eigenartige: Wenn ich den Schalter nicht mit dem Selektoranschluss verbinde, wird er während der Programmlaufzeit aktualisiert. Schlussendlich habe ich das Problem so gelöst, dass ich noch eine dritte Queue als Steuerleitung eingeführt habe und seine Daten gleichzeitig mit den anderen Queues in die Schlange hinzugefügt werden. Das Programm funktioniert soweit ohne Probleme, ich möchte mir jedoch die Risiken betrachten und ggf. optimieren, für nächstes Mal besser machen.


Frage 1: Ich habe gelesen, dass die Consumer-While-Schleife normalerweise immer auf die Queue-Daten wartet bevor sie ihren Inhalt ausführt. Wie verhält sie sich bei zwei oder drei Queues? Weißt die Schleife, dass sie für das Ausführen der case-Struktur sowohl die Daten-Queue als auch die Steuerleitung-Queue braucht und wartet dementsprechend?

Frage 2: Gibt es eine Möglichkeit dem Consumer den Selektorwert nur einmal mitzuteilen (bei Änderung)? Sodass sie nicht mehr auf die Steuerleitung zu warten braucht, wäre evtll. dadurch sogar schneller?

Frage 3: Ist die While-Schleife mit case-Struktur günstiger für die Programmlaufzeit als zwei While-Schleifen ohne case-Struktur?

Besten Dank und schöne Grüße
EinVolvic

Das Verwenden einer gesonderten Queue für jeden Producer ist kein guter Ansatz. Besser ist es, nur eine Queue zu verwenden, und damit der Consumer weiß, woher die Daten kommen, müssen die Queueelemente nicht nur die Daten, sondern auch die Datenquelle enthalten.
Das Datenformat in der Queue sollte also ein Cluster sein, bestehend aus Quelle und Daten. Datenformat Qelle: Text oder Enum; Datenformat Daten, falls die Daten je nach Quelle unterschiedliches Format haben: Variant.
Studiere mal das Beispiel, vielleicht erübrigen sich dann die anderen Fragen oder Du hast neue Fragen.

  ProdCons.vi (Größe: 14,64 KB / Downloads: 337)

(13.05.2017 12:30 )EinVolvic schrieb:  Frage 1: Ich habe gelesen, dass die Consumer-While-Schleife normalerweise immer auf die Queue-Daten wartet bevor sie ihren Inhalt ausführt.

Das kann man so machen - muss aber nicht. Theoretisch kann die While-Schleife viele Sachen machen - eine davon wäre die Queue-Daten zu verarbeiten.

Zitat:Wie verhält sie sich bei zwei oder drei Queues?

Siehst du, und genau deswegen sind mehr als eine Queue problematisch.

Zitat:Weißt die Schleife, dass sie für das Ausführen der case-Struktur sowohl die Daten-Queue als auch die Steuerleitung-Queue braucht und wartet dementsprechend?

Die Schleife weiß genau das, was du in sie hineinprogrammierst - sie hat also keine Eigenintelligenz ...

Zitat:Frage 2: Gibt es eine Möglichkeit dem Consumer den Selektorwert nur einmal mitzuteilen (bei Änderung)? Sodass sie nicht mehr auf die Steuerleitung zu warten braucht

Es ist alles nur eine Sache der Umsetzung des Algorithmus, den du dir ausgedacht hast. Du brauchst also einen entsprechenden Algorithmus.

Zitat:wäre evtll. dadurch sogar schneller?

Hinweis: Schneller (bzw. Kürzer) ist nicht immer das beste Kriterium: Debugfähigkeit und Modularität gehen vor ...

Zitat:Frage 3: Ist die While-Schleife mit case-Struktur günstiger für die Programmlaufzeit als zwei While-Schleifen ohne case-Struktur?

Praktischerweise ja: Eine While-Schleife muss immer ihren kompletten Inhalt verarbeiten. Wenn man den Inhalt komplett oder auch nur teilweise in eine Case-Struktur verteilen kann, so kann man zu bestimmten Zeiten nur das tun, was für diesen Zeitpunkt notwendig ist. Da man dann nicht mehr alles tut, wird auch die Verarbeitungszeit kürzer.

Hinweis:
While-Schleife mit Case-Sequenz heißt (gegebenenfalls) Statemachine - macht sind in jedem Programm immer sehr gut.

(13.05.2017 12:30 )EinVolvic schrieb:  Frage 1: Ich habe gelesen, dass die Consumer-While-Schleife normalerweise immer auf die Queue-Daten wartet bevor sie ihren Inhalt ausführt. Wie verhält sie sich bei zwei oder drei Queues? Weißt die Schleife, dass sie für das Ausführen der case-Struktur sowohl die Daten-Queue als auch die Steuerleitung-Queue braucht und wartet dementsprechend?

Fasse alle Steuerungsoptionen in einem Enum zusammen, dann brauchst du auch nur 1 Queue.

Alternativ: Verwende für die Queue einen (typdefinierten) Cluster mit mehreren Enums und weiteren Daten, auch dann brauchst du nur 1 Queue.

Gruß, Jens

Hallo Lucki, IchSelbst und Jens,

danke für eure Antworten, sie haben mir sehr weitergeholfen.

Zitat:Datenformat Daten, falls die Daten je nach Quelle unterschiedliches Format haben: Variant.

@Lucki: Die Idee, nur eine Queue zu verwenden ist mir auch als erstes gekommen. Ich hatte bisher nur Schwierigkeiten mit den zwei unterschiedlichen Datentypen gehabt. Dein Vorschlag mit dem Format Variant habe ich sofort ausprobiert und es klappt hervorragend. Man kann sogar nochmal ein Cluster-Typ als Daten einfügen.

Zitat:While-Schleife mit Case-Sequenz heißt (gegebenenfalls) Statemachine - macht sind in jedem Programm immer sehr gut.

@IchSelbst: Meine erste while-Schleife ist genau als Statemachine programmiert, die unter anderem die zwei Producer enthält.

Zitat:Alternativ: Verwende für die Queue einen (typdefinierten) Cluster mit mehreren Enums und weiteren Daten, auch dann brauchst du nur 1 Queue.

@Jens: Das klingt so ähnlich wie der Vorschlag von Lucki, haben hier alle so gute Ideen.

Ich habe noch eine parallele Darstellung der Daten erstellt, die braucht nun zwingend ja eine zweite Queue (als zweiter Consumer) oder komme ich noch drumrum?

(15.05.2017 19:37 )EinVolvic schrieb:  haben hier alle so gute Ideen

Nee. Die wissen nur, wie's Programmieren richtig geht

Anzeige

(15.05.2017 19:37 )EinVolvic schrieb:  Ich habe noch eine parallele Darstellung der Daten erstellt, die braucht nun zwingend ja eine zweite Queue (als zweiter Consumer) oder komme ich noch drumrum?

Zweiter Consumer, zweite Queue! (Queue ist immer N zu 1)

(15.05.2017 20:28 )IchSelbst schrieb:  

(15.05.2017 19:37 )EinVolvic schrieb:  haben hier alle so gute Ideen

Nee. Die wissen nur, wie's Programmieren richtig geht

Gruß, Jens

(15.05.2017 20:28 )IchSelbst schrieb:  

(15.05.2017 19:37 )EinVolvic schrieb:  haben hier alle so gute Ideen

Nee. Die wissen nur, wie's Programmieren richtig geht

Haha, das glaube ich.

Zitat:Zweiter Consumer, zweite Queue! (Queue ist immer N zu 1)

Dann wäre das auch geklärt, danke!

Letzte Frage: Mir ist aufgefallen, dass die Messzeit des Programms (Zeit zwischen zwei while-Schleifen bei der Messdatenabfrage) stark zunimmt, wenn ich auf dem Frontpanel zur Anzeige mit den Diagrammen wechsle. Dadurch steigt die Anzahl der Samples im Puffer, was für eine kurze Zeit auch kein Problem ist. Langfristig könnte das den Puffer jedoch überfüllen. Ist das ein generelles Problem in Labview? Ich habe festgestellt, auch wenn ich die Darstellung parallelisiere, tritt der Effekt immer noch auf (vielleicht etwas schwächer dann).

(16.05.2017 08:54 )EinVolvic schrieb:  Letzte Frage: Mir ist aufgefallen, dass die Messzeit des Programms (Zeit zwischen zwei while-Schleifen bei der Messdatenabfrage) stark zunimmt, wenn ich auf dem Frontpanel zur Anzeige mit den Diagrammen wechsle. Dadurch steigt die Anzahl der Samples im Puffer, was für eine kurze Zeit auch kein Problem ist. Langfristig könnte das den Puffer jedoch überfüllen. Ist das ein generelles Problem in Labview? Ich habe festgestellt, auch wenn ich die Darstellung parallelisiere, tritt der Effekt immer noch auf (vielleicht etwas schwächer dann).

Ein generelles Problem von Labview ist das nicht. Eine Bildschirm- Graphik zu updaten ist immer aufwendig. Gar keinen Sinn macht es, die Update-Rate höher zu machen als die Monitor-Bildfrequenz von z.B. 75 Hz. Aber das Auge ist noch viel langsamer, selbst Update-Raten von mehr als 10 Hz sind unnötig. Wenn also die Messrate höher ist, ist es sinnvoll, nicht jeden Einzelwert sofort zur Graphik zu senden, sondern immer mehrere Werte gebündelt zu senden.
Aber die Langsamkeit kann natürlich auch noch andere Ursachen haben. Ganz besonders zu warnen wäre z.B. vor dem Aufruf irgendwelcher Eigenschaftsknoten bei jedem Update. Auch die automatische Bereichsanpassung ist schlecht für die Performance. Und das Plotfenster sollte frei sein, also keine numerische Anzeigen oder dergl. dort hineinplazieren

Also meine Verarbeitungsrate liegt bei 200ms, aber dann verarbeite ich immer Daten von mehreren Zeitpunkten. Wenn ich sie sofort verarbeiten würde sobald sie da sind, würde ich mit der Verarbeitung gar nicht hinterherkommen. Dementsprechend müsste die Darstellungsrate auch so in etwa um den Bereich liegen (die while-Schleife zur Darstellung wartet ja auf die Daten in der Queue).

Zitat:Ganz besonders zu warnen wäre z.B. vor dem Aufruf irgendwelcher Eigenschaftsknoten bei jedem Update

Ich verwende Eigenschaftsknoten, und zwar die von den entsprechenden Diagrammen, gibt es dazu eine andere Alternative? Mir würde noch einfallen, die Darstellung für beide Messmodi in einen Consumer zusammenzufassen. Bisher hat jeder Messmodus, aus historischen Gründen, seine eigene Darstellung gehabt.

Das Springen der Messzeit taucht übrigens auch auf, wenn ich etwas CPU- oder arbeitsspeicherlastiges ausführe, z.B. ein Programm öffnen oder zwischen ihnen wechseln.