Wenn dein Problem oder deine Frage geklärt worden ist, markiere den Beitrag als "Lösung",
indem du auf den "Lösung" Button rechts unter dem entsprechenden Beitrag klickst. Vielen Dank!
Bei einer überschaubaren Anzahl von Schleifen kannst du dir z.B. eine Verbindung vim Iterationsanschluss jeder Schleife auf einen Schleifentunnel ziehen (keine Autoindizierung!!) und auf diese Verbindung jeweils eine Sonde setzen. Dann siehst du recht schnell, welche Schleife in nullkommanix auf Millionen Umläufe anwächst.
40-60% ist doch schon ein (kleiner) Fortschritt gegenüber 80%.
Alternative zu Markos Vorschlag: Mit vielen "Diagram Disable Structure" erst einmal alle Schleifen deaktivieren und dann schrittweise zuschalten, dann wird sich sicher der CPU-Fresser detektieren lassen.
Gruß, Jens
Wer die erhabene Weisheit der Mathematik tadelt, nährt sich von Verwirrung. (Leonardo da Vinci)
!! BITTE !! stellt mir keine Fragen über PM, dafür ist das Forum da - andere haben vielleicht auch Interesse an der Antwort!
(08.05.2015 10:39 )Trinitatis schrieb: Bei einer überschaubaren Anzahl von Schleifen kannst du dir z.B. eine Verbindung vim Iterationsanschluss jeder Schleife auf einen Schleifentunnel ziehen (keine Autoindizierung!!) und auf diese Verbindung jeweils eine Sonde setzen. Dann siehst du recht schnell, welche Schleife in nullkommanix auf Millionen Umläufe anwächst.
Das habe ich bereits probiert, die Schleifen laufen unterschiedlich schnell - aber wie auch sonst? Wie lässt sich mein Programm dadurch optimieren?
(08.05.2015 10:42 )jg schrieb: 40-60% ist doch schon ein (kleiner) Fortschritt gegenüber 80%.
Alternative zu Markos Vorschlag: Mit vielen "Diagram Disable Structure" erst einmal alle Schleifen deaktivieren und dann schrittweise zuschalten, dann wird sich sicher der CPU-Fresser detektieren lassen.
Das ist eine Möglichkeit, du hast recht! Werde ich nächste Woche wieder mal probieren. Habe bisher immer nur jeweils eine einzige Schleife über "Diagram Disable Structure" deaktiviert und geschaut, bin aber nicht großartig schlau draus geworden. Dein Tipp ist etwas sinnvoller
Danke ihr beiden!
08.05.2015, 15:30 (Dieser Beitrag wurde zuletzt bearbeitet: 08.05.2015 15:46 von Trinitatis.)
(08.05.2015 15:25 )Agenth schrieb: Das habe ich bereits probiert, die Schleifen laufen unterschiedlich schnell - aber wie auch sonst? Wie lässt sich mein Programm dadurch optimieren?
naja, dass die Schleifen unterschiedlich schnell laufen kann ja auch gut sein. Wenn aber fast alle Schleifen nach 10s eine Iteration im Bereich von 1000-5000 aufweisen und eine Schleife 20000000, dann würde ich in dieser mal nachsehen.
Es kann aber natürlich auch sein, dass es eben die Summe aus allen zu "schnell" laufenden Schleifen ist - dann wird´s schon schwieriger.
Gruß, Marko
Edit:
Ich habe eben nochmal in dein VI gesehen. Ein m. Mn. nach grober Fehler ist schon die gesamte Pollerei in deinem VI. D.h. der Grundaufbau ist schon sehr fragwürdig.
Wenn du also nun versuchst, alle Schleifen mit waits vollzupflastern und das VI irgendwann umfangreicher wird, dann wird´s immer suboptimaler. Su solltest dir mal das Prinzip der Producer-Consumer-Struktur ansehen. Dann würde dein VI auch deutlich übersichtlicher und später besser wartbarer.
Zitat:Wenn du also nun versuchst, alle Schleifen mit waits vollzupflastern und das VI irgendwann umfangreicher wird, dann wird´s immer suboptimaler. Su solltest dir mal das Prinzip der Producer-Consumer-Struktur ansehen. Dann würde dein VI auch deutlich übersichtlicher und später besser wartbarer.
Danke für deine Antwort Markus. Leider fällt es mir schwer die Producer-Consumer-Struktur zu realisieren. Hat jemand Tipps für mich? Ein paar Screenshots zur Übersicht habe ich angefügt.
Zitat:Ein paar Screenshots zur Übersicht habe ich angefügt.
Eine Statemachine ist üblicherweise durch ein Schieberegister gekennzeichnet. Dies sehe ich in deiner Übersicht aber nicht…
Hast du dir das Statemachine-Beispielprojekt angeschaut?
Du verwendest da irgendwelche FGVs (GO_Tipp, MOVE, START) - die kennen wir nicht und die können wir nicht beurteilen!
Zitat:Eine Statemachine ist üblicherweise durch ein Schieberegister gekennzeichnet. Dies sehe ich in deiner Übersicht aber nicht…
Hast du dir das Statemachine-Beispielprojekt angeschaut?
Ja habe ich, jedoch hat die Statemachine in meinem Fall nicht immer dieselbe Ablaufreihenfolge, deshalb Zählervariable "Aktueller Schritt".
Zitat:Du verwendest da irgendwelche FGVs (GO_Tipp, MOVE, START) - die kennen wir nicht und die können wir nicht beurteilen!
wird evtl. etwas übersichtlicher wenn man sich das ganze *.vi anschaut, das in den vorherigen Kommentaren eingebunden wurde.
Das Problem ist, dass die CPU Auslastung drastisch steigt, wenn in der Schleife der Statemachine keine Schleifenverzögerung von 10 ms implementiert ist.
Woran könnte das liegen, bzw. wie könnte man das beheben?
Zitat:Ja habe ich, jedoch hat die Statemachine in meinem Fall nicht immer dieselbe Ablaufreihenfolge, deshalb Zählervariable "Aktueller Schritt".
Häh? Wieso sollte eine Statemachine einen "immer festen Ablauf" haben?
Zitat:Das Problem ist, dass die CPU Auslastung drastisch steigt, wenn in der Schleife der Statemachine keine Schleifenverzögerung von 10 ms implementiert ist.
Manchmal sollte man auf Events warten - ständiges Polling ist nunmal sehr CPU-aufwändig!
(19.05.2015 09:39 )Agenth schrieb: Das Problem ist, dass die CPU Auslastung drastisch steigt, wenn in der Schleife der Statemachine keine Schleifenverzögerung von 10 ms implementiert ist.
Woran könnte das liegen, bzw. wie könnte man das beheben?
Das hatten wir doch schon! Wenn du ungebremst pollst, dann geht die CPU-Auslastung hoch!
(05.05.2015 18:34 )jg schrieb: Das heißt noch lange nicht, dass die Auswertung auch mit 1kHz laufen muss.
Weitere Unschönheiten:
- Deine Speicherschleife (ganz unten) läuft ungebremst.
- Die Start/Reset-Messung Schleife rechts oben läuft ungebremst. - Die Betriebs-/Bewegungsarten-Schleife läuft im Modus "Leerlauf" ungebremst.
- Deine Drive-Handle Schleife ganz oben könnte ebenfalls eine CPU zu 100% auslasten - das hängt aber von der .NET-DLL ab.
- Die Schleife unterhalb der Schleife mit der Event-Struktur könnte auf den ersten Blick ebenfalls eine CPU zu 100% auslasten.
- Die Signaldatenverarbeitungsschleife läuft - wenn keine Messung aktiv ist - ungebremst.
- Wieso ist es nötig neben ein Gauge-Control noch einen weiteren Numeric-Indicator zu platzieren? Rechtsklick -> Visible -> Digitial Display -> Fertig? Und wieso aktualisierst du die Gauge-Controls mit 100 Hz, und einige der Numeric Indicators nur mit 10 Hz? Der typischer TFT-Monitor kann sowieso nur 60 Hz, für das menschliche Auge langen 10-20 Hz.
Gruß, Jens
Wer die erhabene Weisheit der Mathematik tadelt, nährt sich von Verwirrung. (Leonardo da Vinci)
!! BITTE !! stellt mir keine Fragen über PM, dafür ist das Forum da - andere haben vielleicht auch Interesse an der Antwort!
Zitat:Häh? Wieso sollte eine Statemachine einen "immer festen Ablauf" haben?
Sorry, so gut bin ich nicht im programmieren `
Ich habe es so verstanden, dass der nächste State als Schieberegister ausgewählt werden muss. In meinem Fall gibt es 5 States, welche aber in unterschiedlichen Reihenfolgen und auch mehrmals ausgeführt werden.
Hast du vielleicht ein Beispiel das meinem Fall entspricht?
Zitat:Manchmal sollte man auf Events warten - ständiges Polling ist nunmal sehr CPU-aufwändig!
Ja das habe ich auch verstanden, jedoch ist mir unklar wie ich das eventgesteuert umsetzen kann?
Zitat:- Die Betriebs-/Bewegungsarten-Schleife läuft im Modus "Leerlauf" ungebremst.
leider in dem hochgeladenen Screenshot nicht drin. Da habe ich eine Schleifenbremsung in der gesamten while Schleife von 10ms und im unteren False Case beim Leerlauf eine 1ms Verzögerung implementiert.
