+- LabVIEWForum.de (https://www.labviewforum.de)
+-- Forum: LabVIEW (/Forum-LabVIEW)
+--- Forum: LabVIEW Allgemein (/Forum-LabVIEW-Allgemein)
+---- Forum: Datenerfassung (DAQ) (/Forum-Datenerfassung-DAQ)
+---- Thema: Suche nach dem Performance-Killer (/Thread-Suche-nach-dem-Performance-Killer)
Seiten: 1 2
Suche nach dem Performance-Killer - Soean - 31.05.2012 08:07
Hallo Experten,
ich schreibe gerade die Software für einen Prüfautomaten neu. Diese läuft dann als Applikation auf dem PC in der Linie. Nun habe ich das Problem, dass, sobald ich die Software starte, die Prozessorlast bei nahe 100% liegt, und dementsprechend ruckelig läuft und zeitkritische Funktionen u.U. zu spät ausgeführt werden.
Zur Zeit hat die Software eine Main-Loop und 4 parallel dazu arbaitende Schleifen. Ich denke, ich konnte das Problem auf eine Schleife eingrenzen. Wenn ich diese deaktiviere, sinkt die Prozessorlast auf unter 30%. Schon mal gut. Einen Fehler konnte ich darin jedoch leider nicht finden. Sie ist sorgfältig "gebremst" (Wait ms) und führt auch sonst keine sonderlich aufwendigen Operationen durch. Was habe ich übersehen?
Ich habe euch die verdächtige Schleife extrahiert und angehängt.
Danke für eure Hilfe!
Gruß,
Soean
RE: Suche nach dem Performance-Killer - Lucki - 31.05.2012 10:03
Wenn Du diese vielen Bytes so oft pollen musst, dann würde ich auf alle Fälle für DAQ die Betriebsart "kontinuierlich" wählen. Die Datenerfassung läuft dann auf der Messkarte autark ab, der PC wird entlastet. Die Waits fallen weg: DAQmx Read wartet solange, bis wieder eine Sample im Puffer ist.
Ansonsten fiel mir beim willkürlichen Öffenen eines Sub-Vis diese Umständlichkeit auf:
Das hier
[attachment=39976]
würde ich so machen:
[attachment=39979]
RE: Suche nach dem Performance-Killer - Soean - 31.05.2012 10:16
(31.05.2012 10:03 )Lucki schrieb: Wenn Du diese vielen Bytes so oft pollen musst, dann würde ich auf alle Fälle für DAQ die Betriebsart "kontinuierlich" wählen. Die Datenerfassung läuft dann auf der Messkarte autark ab, der PC wird entlastet. Die Waits fallen weg: DAQmx Read wartet solange, bis wieder eine Sample im Puffer ist.
Danke, hört sich vernünftig an. Werde ich ausprobieren :-)
Zu deinem 2. Hinweis: Hatte ich früher so gemacht wie du es vorgeschlagen hast. In diesem Fall musste ich jedoch "trocken" Programmieren, also Programm so weit wie irgend möglich fertig stellen, ohne ausprobieren zu können. Und ich musste mich auf die Eingangsbelegung verlassen, die ich auf einem Stück Papier mitgeteilt bekommen habe. Wenn ich jetzt einfach mithilfe der Funktion "Array to Cluster" Array[0] auf Cluster1 (usw) setze und damit Programmiere, und sich hinterher heraus stellt, dass Array[0] eigentlich zu dem Eingang gehört, den ich auf Cluster4 gelegt habe, hätte ich überall, wo das Cluster aufgerufen wird, die entsprechende Abfrage ändern müssen. So kann ich einfach in der FGV das Wire von Array[0] zu Cluster1 umverdrahten auf Array[0] zu Cluster4.
Hm...war das jetzt noch verständlich?
Na ja, ich versuche erstmal die kontinuierliche abfrage :-)
Gruß,
Soean
RE: Suche nach dem Performance-Killer - Soean - 31.05.2012 12:37
Soo...gesagt getan.
Leider bekomme ich folgende Fehlermeldung: ...You Have Requestet: Sample Clock You Can Select: On Demand. (Code: -200077)
"Continious Samples" scheint also nicht zulässig zu sein...oder habe ich noch etwas falsch gemacht?
PS: Die Einzelbenennung der Lines ist nicht schön gemacht, ich weiß. Ich musste es jedoch aus einem MAX-Task abschreiben, der auch nicht von mir erstellt wurde. Wollte die ganzen Eingänge nicht umverdrahten müssen.
RE: Suche nach dem Performance-Killer - Lucki - 31.05.2012 12:47
Bin in Eile, nur ganz kurze Antwort:
Leider ist es bei vielen Messkarten so, daß man keine digitale Waveform ein/ausgeben kann, weil der interne Taktgeber dafür fehlt.
Ob man das noch managen kann, indem man einen der anderen Zähler auf der Karte dafür umfunktioniert, weiß ich jetzt nicht, da fehlt mir die Erfahrung. Weiß da sonst jemand Rat? Und welche Messkarte hast Du?
RE: Suche nach dem Performance-Killer - Soean - 31.05.2012 12:54
Bei der Messkarte handelt es sich um eine USB-6501, ein recht günstiges Modell.
RE: Suche nach dem Performance-Killer - Knarrre - 01.06.2012 14:23
Hi!
Also ich habe ein ganz ähnliches Problem!
Ich habe ein Programm gebaut, welches einerseits Messfühler (ein paar Thermoelemente und zwei Drucksensoren) aufnimmt und protokolliert, andererseits Heizbänder steuert (in von je einem Thermoelement).
Nun habe zuerst mehrere Schleifen nebeneinander laufen lassen.
Zunächst hatte ich auch das Problem, dass der Prozessor sofort ausgelastet war und alles immer langsamer lief. Dies konnte ich beheben, indem ich "Ablaufebenen" eingeführt habe. Ich habe mir gedacht, dass die Messwert aufnahme stehts am schnellsten laufen soll, alle Schleifen in denen irgendetwas auf die Messwerte zugreift um den Faktor 10 langsamer. Realisiert habe ich das mit dem Verzögerungs Vi.
Dies hat das Problem mit der Prozessorauslastung behoben, sie liegt nun bei ca. 7%.
Jetzt habe ich jedoch das Problem, dass sich der Arbeitsspeicher kontinuierlich langsam vollschreibt. Dies ergibt im Taskmanager eine schöne Treppe.
Ich habe eine NI USB-6210 Messkarte die auch KEINEN Taktgeber hat! Kann das tatsächlich daran liegen?
Ich habe nämlich festgestellt, dass dieser Effekt selbst auftritt, wenn ich einfach nur eine Schleife laufen lasse, die nur Messwerte aufnimmt und diese in eine Datei schreibt...
Je mehr Messfühler ich benutze, desto stärker ist der Effekt...bzw. desto steiler die Treppe!
Irgendwann schmiert der Rechner dann ab!
Ich habe das VI mit nur Messaufnahme mal drangehängt...selbst hier entsteht die Treppe. Bei den Eingängen steht Dev2 muss evtl geändert werden. Liegt es am fehlenden Taktgeber?
Danke und Gruß
Knarrre
RE: Suche nach dem Performance-Killer - GerdW - 01.06.2012 14:32
Hallo Knarre,
1. Verdacht: nicht-initialisierte Schieberegister, in denen Daten gesammelt werden: ok, kommt anscheinend nicht vor...
2. Verdacht: unsinnige Konvertierungen von Waveform nach DDT nach 1D-Array[DBL]: kommen zu hauf vor...
3. Verdacht: unsinnige Verwendung von DAQmxCreateTask/Channel, gepaart mit Nicht-Verwendung von DAQmxClearTask: hast du vielleicht schon mal gelesen, dass man nicht in jeder Iteration Tasks/Channel neu anlegen muss? Und wenn man das schon macht (warum auch immer), dann sollte man den Task nicht nur stoppen, sondern auch löschen! Aber sowas gehört ja eh nicht in die Schleife hinein...
Noch mehr RubeGoldberg:
- Wenn du schon ein Array baust, um es anschließend zu dezimieren: warum nicht einfach transponieren und indizieren?
- statt einer Casestruktur kann man auch schon mal die Select-Funktion nutzen...
- manchmal bietet sich eine FOR-Loop an, wenn man für alle Zeilen (oder Spalten) eines Arrays die gleiche Rechenoperation durchführen will...
RE: Suche nach dem Performance-Killer - Knarrre - 01.06.2012 14:50
Hi!
Also anscheinend bin ich ein echter Goldberg-Fan!
Ich habe mal meine komische Art mit dem Task erstellen, stoppen durch einen DAQ-Assistenten ersetzt und schwups...Problem gelöst
Es lag also wohl wirklich hauptsächlich daran. Vielen Dank!
Ich kann den Assistenten jedoch nicht benutzen, dar ich hier nur immer eine Art auslesen kann (oder?). Wie mache ich das denn mit den Tasks? Alles so wies ist nur Erstellen und Beenden außerhalb der Schleife!
RE: Suche nach dem Performance-Killer - GerdW - 01.06.2012 14:55
Hallo Knarre,
Zitat:Ich habe mal meine komische Art mit dem Task erstellen, stoppen durch einen DAQ-Assistenten ersetzt und schwups...Problem gelöst1) Ich bezweifle, dass deine Probleme damit gelöst sind - sie sind jetzt nur anders gelagert...
2) Der Daq-Assi übernimmt zumindest das ordentliche Löschen des Task für dich...
3) Trotzdem gilt meine Aussage, dass Init & Clear nicht in die Schleife gehören, immer noch...
Zitat:Wie mache ich das denn mit den Tasks? Alles so wies ist nur Erstellen und Beenden außerhalb der Schleife!War ich nicht klar genug in meinen Ausführungen? Alternativ: Es gibt auch mit LabVIEW mitgelieferte Beispiele...
Ich würde auch das CreateChannel aus der Schleife rausnehmen...