CPU Auslastung

Hallo Forenmitglieder,

ich habe ein Programm geschrieben, indem über "Axial Communication Interface" eine Verbindung zu einem Motor hergestellt wird, der auch angesteuert werden kann.
Dort ist ein Dauerlauf programmiert, in dem der Motor vorgegebene Bewegungen hintereinander durchführt.
Dabei messe ich Werte wie Kraft, Drehmoment und Drehwinkel (Verarbeitung über 2 Queue Funktionen) und speichere sie in bestimmten Abständen als .lvm und jeweils 2 Plots von Diagrammen ab.

Schaue ich nun auf meine CPU Auslastung, steht diese bei mehr als 80%, was definitiv nicht sein sollte.
Könnt ihr mir Ratschläge geben, wie man prüfen kann woran dies liegt? Ich verwendet sehr viele FGV (funktionale globale Variablen), kann es daran liegen?

Ich danke euch für die Hilfe!

Hallo Agenth,

Zitat:Schaue ich nun auf meine CPU Auslastung, steht diese bei mehr als 80%, was definitiv nicht sein sollte.

Hast du von einem HexaCore 5 Kerne ausgelastet?

Zitat:über "Axial Communication Interface" eine Verbindung zu einem Motor hergestellt wird

Was soll das sein?

Zitat:Verarbeitung über 2 Queue Funktionen

Mit Queues schiebt man nur Daten von A nach B, aber "verarbeitet" wird da nichts…

Zitat:Könnt ihr mir Ratschläge geben, wie man prüfen kann woran dies liegt?

Du kennst das Problem: Kein VI (oder wenigstens aussagekräftige Bilder), keine Lösung…

Zitat:Ich verwendet sehr viele FGV (funktionale globale Variablen), kann es daran liegen?

Bei korrekter Programmierung: Nein.

Tipps:
- Wenn man wissen will, welcher Programmteil für die hohe CPU-Last verantwortlich ist, dann nutzt man die Disable-Struktur. Damit kommentiert man Programmteile aus und schaut, wann sich etwas an der CPU-Last tut.
- Andere Möglichkeit: wenn man mehrere parallel laufende subVIs aufruft, schaut man sich das aufrufende VI mit Highlight-Debugging im Step-Modus an. So kann man jedes subVI einzeln starten und sieht, bei welchem subVI die CPU-Last in die Höhe geht…

Kann man an Hand der Info, die du lieferst, nicht sagen.
Könnte alles Mögliche sein, z.B. ungebremste Schleifen, zu häufiges Aktualisieren von Plots, zu vielen Daten im Plot etc. pp.

Gruß, Jens

(30.04.2015 08:04 )GerdW schrieb:  Hast du von einem HexaCore 5 Kerne ausgelastet?

Nicht drauf geachtet, hab nur die extrem hohe Prozentzahl gesehen und angefangen zu zweifeln

Zitat:Was soll das sein?

Seitens des Motors gibt es eine Bibliothek, die zur Verfügung gestellt wurde. Sie dient dazu, die Schnittstelle zwischen Motor und LabView herzustellen.

Zitat:Mit Queues schiebt man nur Daten von A nach B, aber "verarbeitet" wird da nichts…

Das tue ich auch, sorry. Dachte es könnte evtl. am Buffer der Queues liegen....

Zitat:Du kennst das Problem: Kein VI (oder wenigstens aussagekräftige Bilder), keine Lösung…

Wahre Worte.

Zitat:Tipps:
- Wenn man wissen will, welcher Programmteil für die hohe CPU-Last verantwortlich ist, dann nutzt man die Disable-Struktur. Damit kommentiert man Programmteile aus und schaut, wann sich etwas an der CPU-Last tut.
- Andere Möglichkeit: wenn man mehrere parallel laufende subVIs aufruft, schaut man sich das aufrufende VI mit Highlight-Debugging im Step-Modus an. So kann man jedes subVI einzeln starten und sieht, bei welchem subVI die CPU-Last in die Höhe geht…

Das werde ich mal austesten. Danke!

(30.04.2015 08:06 )jg schrieb:  Kann man an Hand der Info, die du lieferst, nicht sagen.
Könnte alles Mögliche sein, z.B. ungebremste Schleifen, zu häufiges Aktualisieren von Plots, zu vielen Daten im Plot etc. pp.

Schleifen sind ungebremst, Verzögerungen halfen jedoch nicht.
Das Diagramm ist durchgehend am aufzeichnen, jedoch werden die Daten wieder jedes mal bei Diagrammaktualisierung genullt.

Ich versuche mein Bestes, um es euch anschaulich zu machen. Bitte um Rücksicht.

Hallo Agenth,

Zitat:Schleifen sind ungebremst, Verzögerungen halfen jedoch nicht.

Schleifen sollten immer durch irgendein Elemente gebremst werden - sei es eine der Wartefunktionen, sei es durch DAQmxRead, sei es durch Warten auf Kommunikationspartner.
Ausnahme: du hast eine Rechenschleife, die über ein Array iteriert…
Und es hilft natürlich nicht, nur in einer Schleife eine Wartezeit einzubauen, wenn parallel laufende Schleifen weiterhin ungebremst die CPU zum Glühen bringen…

Zitat:Das Diagramm ist durchgehend am aufzeichnen, jedoch werden die Daten wieder jedes mal bei Diagrammaktualisierung genullt.

Wieso "nullst" du andauernd? Oder was verstehst du unter "nullen"?

(30.04.2015 11:43 )GerdW schrieb:  
Wieso "nullst" du andauernd? Oder was verstehst du unter "nullen"?

Sorry etwas falsch ausgedrückt. Ich nulle einmal damit ich sicher bin dass dort auch nichtsmehr drinsteht an alten Werten. Danach springt die Case struktur in False und dort geschieht nichts.

Hast du auf dem Frontpanel Grafiken abgelegt?
In der Vergangenheit war dies in einem meiner Programme ein gravierendes Leistungsproblem, da die Grafik ständig neu geladen wurde. Grafik entfernt => Leistung ok.

(04.05.2015 08:56 )NoWay schrieb:  Hast du auf dem Frontpanel Grafiken abgelegt?
In der Vergangenheit war dies in einem meiner Programme ein gravierendes Leistungsproblem, da die Grafik ständig neu geladen wurde. Grafik entfernt => Leistung ok.

Ja, 2 Diagramme.... sind aber notwendig

Ein wenig
Bei NoWay ging es IMHO wirklich um Grafiken/Bilder. Vor allem, wenn in LabVIEW etwas übereinander gelegt wird (Graph vor ein Bild) dann frisst das gerne Ressourcen.
Schlechte Erfahrungen gibt es auch mit Arrays mit Elementen aus der Silver-Palette...

Gruß, Jens

(04.05.2015 14:04 )jg schrieb:  Ein wenig
Bei NoWay ging es IMHO wirklich um Grafiken/Bilder. Vor allem, wenn in LabVIEW etwas übereinander gelegt wird (Graph vor ein Bild) dann frisst das gerne Ressourcen.
Schlechte Erfahrungen gibt es auch mit Arrays mit Elementen aus der Silver-Palette...

Gruß, Jens

Das ist korrekt. Man beachte den feinen Unterschied zwischen "Graph" und Grafik