+- LabVIEWForum.de (https://www.labviewforum.de)
+-- Forum: LabVIEW (/Forum-LabVIEW)
+--- Forum: LabVIEW Allgemein (/Forum-LabVIEW-Allgemein)
+--- Thema: Eigene Schleife für FP-Elemente? (/Thread-Eigene-Schleife-fuer-FP-Elemente)
Seiten: 1 2
Eigene Schleife für FP-Elemente? - Soean - 02.07.2012 15:56
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
RE: Eigene Schleife für FP-Elemente? - M Nussbaumer - 02.07.2012 16:02
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
RE: Eigene Schleife für FP-Elemente? - Soean - 02.07.2012 16:09
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!!
RE: Eigene Schleife für FP-Elemente? - M Nussbaumer - 02.07.2012 16:11
(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
RE: Eigene Schleife für FP-Elemente? - jg - 02.07.2012 16:16
Ich dachte, wir waren inzwischen bei max 25 % Auslastung:
http://www.labviewforum.de/Thread-Hohe-Prozessorauslastung-nach-Festlegen-von-Fenstergroesse-Position?pid=138268#pid138268
Wieso denn jetzt wieder 90%?
Haarscharf vorbei am Doppelposting.
Gruß, Jens
RE: Eigene Schleife für FP-Elemente? - Soean - 03.07.2012 07:57
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!
RE: Eigene Schleife für FP-Elemente? - Soean - 03.07.2012 09:19
Schade...unten stehende Konstruktion wirkt sich eher negativ auf auf Prozessorlast aus. Erzwinge ich hier in jedem Schleifendurchlauf einen Wechsel in den UI-Thread?
RE: Eigene Schleife für FP-Elemente? - GerdW - 03.07.2012 09:22
Hallo Soean,
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...
RE: Eigene Schleife für FP-Elemente? - jg - 03.07.2012 09:26
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!!
RE: Eigene Schleife für FP-Elemente? - Soean - 03.07.2012 10:27
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.