Drei Queues in einer While-Schleife mit case-Struktur

(16.05.2017 15:40 )EinVolvic schrieb:  

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?

Die Alternative hängt von der Eigenschaft ab. Alles außer Value ist sowieso fragwürdig in der kontinuierlichen Verwendung. Statt Value auf jeden Fall lokale Variablen nehmen, besser noch das Anzeigeelement selbst.

Zitat: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.

"Zwischen ihnen wechseln"? Was hast du denn für eine CPU?

Hast du denn schon mal ein VI gepostet (am besten 2015 oder früher)? Dass wir halt mal einen optischen Eindruck bekommen, wie das Blockdiagramm aussieht, das zum Frontpanel gehört.

Anzeige

Eigenschaftsknoten sind oftmals unentbehrlich, aber sie sollten sich nach Möglichkeit nicht innerhalb einer zeitkritischen Schleife befinden. (Das meinte IchSelbst mit "fragwürdig in der kontinuierlichen Verwendung")
Bewährt hat sich z.B die Behandlung von Eigenschaften in einer besonderen Ereignisbehandlungsschleife.
Dass das Programm mal stockt, wenn Windows ein anderes Programm ausführt, ist normal. Aus diesem Grunde erfolgt die Datenübergabe zwischen der Messkarte (=Echtzeitsystem) und Labview immer gepuffert. So können keine Werte verloren gehen. Wichtig ist nur, dass die maximal mögliche Daten-Verarbeitunsgeschwindikeit des Programm deutlich höher ist als die Messwert-Erzeugungsrate, so dass solche Staus sich nicht akkumulieren können.

Aber wie IchSelbst auch schon sagte: Ein Blockdiagramm von Deinem VI wäre nicht schlecht...

Zitat:Statt Value auf jeden Fall lokale Variablen nehmen, besser noch das Anzeigeelement selbst.

Ich nutze zur Darstellung im ersten Messmodus nur Anzeigeelemente und im zweiten nur die Value-Eigenschaftsknoten. Ich denke als weitere Optimierungsmaßnahme wäre das Umstellen auf eine einzige Schleife zur Darstellung (beider Messmodi) sinnvoll. Somit würde ich auch nur einmal die Anzeigeelemente benötigen und könnte auf die Eigenschaftsknoten verzichten.

Zitat:Was hast du denn für eine CPU?

Nur einen Dual Core mit 1,33GHz, war aber trotzdem nichts kostengünstiges. Ich denke es hängt, wie Lucki gesagt hat, auch mit dem Betriebssystem zusammen.

Zitat:Hast du denn schon mal ein VI gepostet (am besten 2015 oder früher)?

Ich würde gerne das VI posten, bin mir aber nicht sicher, ob mein Arbeitgeber damit einverstanden wäre. Ich weiß, ein Bild / VI sagt mehr als tausend Worte. Ich würde versuchen ein Bild (zeitweise) zu posten.

Zitat:Bewährt hat sich z.B die Behandlung von Eigenschaften in einer besonderen Ereignisbehandlungsschleife.

Das klingt interessant, würde sie auch mit einer while-Schleife realisiert werden? Die Schleife wird von einem Ereignis getriggert und würde ja unendlich weiterlaufen?

Zitat:Wichtig ist nur, dass die maximal mögliche Daten-Verarbeitunsgeschwindikeit des Programm deutlich höher ist als die Messwert-Erzeugungsrate, so dass solche Staus sich nicht akkumulieren können.

Solange man nicht zu lange bei den Diagrammen-Anzeigen verbleibt, staut sich nicht so viel im Puffer. Falls doch habe ich als Lösung einmal einen größeren Sample-per-Channel Wert oder den Wert "-1" (also immer den gesamten Puffer auszulesen).