Eigene Schleife für FP-Elemente?

Hallo LabVIEW-Leuchten,

ich habe mal wieder mein Programm am Wickel, welches mir aufgrund von recht vielen Anzeige- und Bedienelementen probleme mit der Laufzeit bereitet. Die Prozessorlast liegt so bei 80 bis 90 Prozent, wenn ich das Programm minimiere bei weit unter 10.

(Es gibt auch keine ungebremsten Schleifen, FP-Elemente werden nicht dauerhaft über PropertyNodes aktualisiert...das habe ich so ziemlich alles durch, alles was bisher geholfen hat, war konsequentes Löschen von für den Bediener irrelevanten Anzeigen)

Zur Architektur meines Programmes: Es gibt eine Eventloop, welche die Benutzereingaben über einen Queue an meine Consumer-Loop weiter gibt. Diese Consumer-Loop wird auch von anderen Schleifen mit Informationen versorgt, teilweise über den gleichen Queue, teilweise über andere Queues und über einige FGVs. Diese Loop wirde jedoch nur zum Teil über den Event-Queue gesteuert, danach geht sie über in eine automatisierte State-Machine.
Ich habe also mehrere parallel laufende Schleifen, alle haben einige Anzeigeelemente.

Nun zu meiner eigentlichen Frage:

Macht es Sinn, alle Anzeige-Elemente in einer eigenen Schleife zusammenzufassen, um Prozessorlast zu sparen? Wie würde ich die Anzeigen dann am besten aktualisieren, gerade im Hinblick auf die Prozessorlast? Lokale Variablen? Diverse Queues?

Meine Idee dahinter ist, dass es vllt. laufzeitsparender ist, wenn ich die Anzeigelemente alle gemeinsam nur alle 100 ms (Beispielwert) aktualisiere, während meine zeitkritischen Schleifen mit höherer Geschwindigkeit laufen.

Ich habe schon ein wenig gegoogelt und auch hier im Forum gesucht, aber nichts zu einer eigenen Schleife für FP-Elemente gefunden.

Ein paar Erfahrungswerte wären nett


Gruß,

Soean

Es gibt ein Property-Node mit welchem du die Updates deines Frontpanels manuell steuern kannst:

Defer Frontpanel Updates

evtl hilft dir das schon weiter

Gruss Marc

Ja, überlegt habe ich das auch schon. Aber die einzige Idee, die hatte, wie mich diese PropertyNode weiter bringt, war, für jedes Anzeigeleement eine PropertyNode zu erstellen und nur alle 100 ms einmal eine aktualisierung zuzulassen...das kam mir aufwändig vor. Hmm...wo ich das gerade nieder schreibe...ließe sich das mit VI Server automatisieren? Damit habe ich bisher so gut wie keine Erfahrung. Muss ich mir noch mal angucken :-)

Nun aber erst mal Feierabend

Euch einen schönen solchen!!

(02.07.2012 16:09 )Soean schrieb:  Ja, überlegt habe ich das auch schon. Aber die einzige Idee, die hatte, wie mich diese PropertyNode weiter bringt, war, für jedes Anzeigeleement eine PropertyNode zu erstellen und nur alle 100 ms einmal eine aktualisierung zuzulassen...das kam mir aufwändig vor. Hmm...wo ich das gerade nieder schreibe...ließe sich das mit VI Server automatisieren? Damit habe ich bisher so gut wie keine Erfahrung. Muss ich mir noch mal angucken :-)

Nun aber erst mal Feierabend

Euch einen schönen solchen!!

Prinzipiell wird dieses Property-Node für das gesammte Frontpanel gesetzt und nicht auf einzelne Controls Kein Micromanagement notwendig

Gruss Marc

Ich dachte, wir waren inzwischen bei max 25 % Auslastung:
http://www.labviewforum.de/Thread-Hohe-P...#pid138268

Wieso denn jetzt wieder 90%?

Haarscharf vorbei am Doppelposting.

Gruß, Jens

Jo, hab auch überlegt, ob ich den alten Thread wieder aufgreife, oder ob ich einen neuen starte. Habe mich für einen neuen Entschieden, da ich einen (für mich) ganz neuen Ansatz diskutieren wollte. Warum wir wieder bei knapp 90 % sind: Das eine oder andere Anzeige-Element musste halt doch noch dazu, und ich habe die Bremsen in den zumindest einigermaßen zeitkritischen Schleifen so weit wie möglich runter gedreht.

Aso :-) Die PropertyNode sperrt das gesamte FP. Na das ist doch mal ein Ansatz :-) Ich werde also die Aktualisierung für 50 - 100 ms sperren und dann einmal zulassen. Mal gucken, wie sich das auswirkt.

Danke!

Schade...unten stehende Konstruktion wirkt sich eher negativ auf auf Prozessorlast aus. Erzwinge ich hier in jedem Schleifendurchlauf einen Wechsel in den UI-Thread?

Hallo Soean,

du schaltest in diesem Konstrukt das PanelUpdate für 100ms aktiv und für weitere 100ms inaktiv!
Korrektur: du schaltest immer kurzzeitig das FP-Update aktiv, fraglich ist nur, wie kurz es freigeschaltet wird...

- Außerdem sieht man nicht, wie oft dieses Konstrukt aufgerufen wird, es könnte also sein, dass du andauernd diese PropertyNode aufrufst, nur um den gleichen Wert wie erst Mikrosekunden zuvor erneut zu setzen...
- Es sollte auch ausreichen, sich einmal die Panel-Referenz vor der Schleife zu besorgen, statt dies immer wieder in der Schleife zu erledigen...

Zitat:Erzwinge ich hier in jedem Schleifendurchlauf einen Wechsel in den UI-Thread?

Natürlich! Und das jetzt dauernd! Das Setzen der PropertyNode gehört natürlich noch in eine Case-Struktur!

Vielleicht lädst du auch einmal dein Main-VI hoch. Irgendwas muss da seltsam sein. Der UI-Thread wird aus meiner Erfahrung nur bei der Anzeige extrem großer Arrays, von Graphen mit vielen Daten oder bei dauerndem Setzen von PropertyNodes ausgelastet.

Gruß, Jens

EDIT: Schon mal die Hilfe zu DeferPanelUpdate durchgelesen? JEDES setzen löst ein FP-Update aus! Einzig nach einem TRUE-Setzen werden weitere Updates erst einmal verschoben. Aber du setzt ja dauernd!!

Ja, die Referenz vor der Schleife zu besorgen, da hätte ich wirklich auch drauf kommen können. Die Zykluszeit in der Schleife liegt bei 20 ms (Wait ms).

Habe das Ganze nun so aufgebaut, dass der Wert nur gesetzt wird, wenn er sich auch geändert hat. Also DeferPanUpdts wird auf True gesetzt, nach 100 ms einmal auf False und im nächsten Zyklus wieder auf einmal auf True. Leider keine Auswirkung auf die Rechenleistung.

Schade...war eine schöne Idee, finde ich.

Das Main-VI hochladen...ist da wirklich etwas mit anzufangen, wenn die SubVIs fehlen?



PS: Die FeedBackNode muss mit True initialisiert werden, damit das DeferFPUpdate im ersten Zyklus gesetzt wird. Macht aber keinen großen Unterschied.