Skip to main content

Performance

Die Planung von Bewegungen findet in einer separaten Task statt, da die Berechnung CPU-intensiv ist. Diese separate Task wird als Planungstask bezeichnet und läuft parallel zur Bustask. Reicht die Leistung der SPS nicht aus, um die Bahn in der Planungstask rechtzeitig für die Bustask zu planen, sprechen wir von Performance-Problemen.

Performance-Probleme in der Bewegungsplanung können einerseits zum Fehler SMC_CP_QUEUE_UNDERRUN führen, andererseits können sie auch zu einer ruckartigen oder langsamer als erwarteten Bewegung führen. Informationen zum Fehler SMC_CP_QUEUE_UNDERRUN finden Sie im Kapitel Häufige Fehler. Die Diagnose von performancebedingten Problemen bei Bewegungen ist im Folgenden beschrieben.

Diagnose bei langsamen oder ruckartigen Bewegungen

Wenn es keine Performance-Probleme gibt, wird jede Bewegung so geplant, dass während der gesamten Bewegung mindestens einer der effektiven Grenzwerte erreicht wird. Betrachten Sie zum Beispiel ein einfaches zweidimensionales Portal mit zwei Achsen X und Y und einer PTP-Bewegung von Position (0,0) nach (10,-10). Die maximale Achsgeschwindigkeit beträgt 20, die maximale Achsbeschleunigung 100 und der maximale Achsruck 1000.

Die erwartete Bewegung sieht wie folgt aus:

sm_img_trajectory1.png

Es wird zunächst mit maximalem Ruck die Beschleunigung aufgebaut, bis der Beschleunigungsgrenzwert von 100 erreicht ist. Nach einer kurzen Phase konstanter Beschleunigung wird wiederum mit maximalem Ruck die Beschleunigung abgebaut, sodass der Geschwindigkeitsgrenzwert von 20 mit Beschleunigung 0 erreicht wird. Nach einer Phase konstanter Geschwindigkeit wird so verzögert, dass die Zielposition mit Geschwindigkeit und Beschleunigung 0 erreicht wird.

Es gibt zwei mögliche Ursachen, dass die reale Bewegung von diesem idealen Verlauf abweicht:

  1. Aufgrund von Performance-Problemen in der Planungstask entspricht schon die geplante Bewegung nicht dem idealen Verlauf.

  2. Die geplante Bewegung entspricht dem idealen Verlauf, aber der Roboter führt sie nicht wie erwartet aus.

Fall 1: Performance-Probleme der Planungstask

Wenn es Performance-Probleme bei der Planung gibt, könnte die Bewegung stattdessen wie folgt aussehen:

sm_img_trajectory2.png

Ursache ist, dass die Bewegung in der Planungstask, parallel zur Ausführung in der Bustask, geplant wird. Dabei muss im Mittel kontinuierlich mindestens so viel geplant werden, wie in der Bustask ausgeführt wird. Reicht die Performance dafür nicht aus, wird abgebremst. Das führt zu dem welligen Geschwindigkeitsverlauf.

Das erste und wichtigste Werkzeug zur Diagnose solcher Probleme ist der Trace. Neben den Variablen fSetPosition, fSetVelocity und fSetAcceleration für jede Achse sollten auch die Ausgänge  numTimeBudgetExceeded und numSlowDownLowIpoQueue des Funktionsbausteins SMC_GroupReadPlanningStatistics aufgezeichnet werden. Steigen diese Zähler kontinuierlich an, liegt ein Performance-Problem vor.

Hinweis

Analog zu den Variablen fSetPosition, fSetVelocity und fSetAcceleration gibt es auch die Variable fSetJerk für den Ruck. Es ist zu beachten, dass der Ruck nicht der durchschnittliche Ruck ist, der während des Bustaskzyklus angewendet wird (wie oft erwartet), sondern der momentane Ruck am Ende des Zyklus. Für die Diagnose von Performance-Problemen hat fSetJerk deshalb nur eine begrenzte Aussagekraft.

Möglichkeiten zur Verbesserung der Bewegung

Die folgende Liste zeigt Möglichkeiten, um Perfomance-Probleme zu beheben:

  • Anpassung der Grenzwerte für Geschwindigkeit, Beschleunigung und Ruck:

    • Je länger es dauert, um von der aktuellen Geschwindigkeit in den Stillstand zu bremsen, umso höher ist der Rechenaufwand

    • Deshalb verschlechtern ein hoher effektiver Grenzwert für die Geschwindigkeit und niedrige effektive Grenzwerte für Beschleunigung und Ruck tendenziell die Performance

    • Insbesondere die Grenzwerte für Beschleunigung und Ruck sollten deshalb nicht unnötig niedrig gewählt werden

  • Erhöhen der Priorität der Planungstask oder Verringern der Priorität der anderen Tasks, falls diese die Planungstask blockieren. Die Planungstask sollte nach der Bustask die zweithöchste Priorität haben.

  • Zuweisen der Planungstask auf einen dedizierten Kern, falls mehrere CPU-Kerne vorhanden sind (siehe Konfiguration der Planungstask).

  • Verwenden von SMC_TuneCPKernel, um den Wert der Planungsparameters fPlanningInterval und/oder fSyncBufferDuration zu erhöhen.

    • Der Parameter fPlanningInterval gibt die maximale zeitliche Planungsschrittweite in Sekunden an. Die Zykluszeit der Planungstask sollte diesen Wert nicht dauerhaft überschreiten. Ein höherer Wert senkt den Rechenaufwand, kann aber auch dazu führen, dass die eingestellten Grenzwerte für Geschwindigkeit, Beschleunigung und Ruck nicht voll ausgenutzt werden. Von einem Startwert von 0.016 Sekunden, dem Standardwert ab CODESYS SoftMotion-Versionen 4.6.0.0, sollte der Wert schrittweise erhöht werden, bis die Performance akzeptabel ist.

    • Der Parameter fSyncBufferDuration gibt die Größe des Puffers zwischen Planungs- und Bustask an. Die Zykluszeit der Planungstask darf diesen Wert in der Spitze nicht überschreiten. Durch einen höheren Wert können Spitzen in der Zykluszeit der Planungstask ausgeglichen werden. Gleichzeitig erhöht sich dadurch aber auch die Latenz für Ausführen von Interrupts und Aborting-Bewegungen.

Fall 2: Roboter folgt der geplanten Bewegung nicht wie erwartet

Wenn der Roboter der geplanten Bewegung nicht wie erwartet folgt, kann das folgende Gründe haben:

  • Unzureichende Echtzeitfähigkeit der Steuerung

  • Regelungsprobleme der Antriebe

Auf einer nicht echtzeitfähigen Steuerung wie der CODESYS Control Win, oder einer Linux-basierte Steuerung ohne einen Realtime-Patch des zugrundeliegenden Linux-Systems, kann es auch bei ausreichender Performance zu langsamen oder ruckartigen Bewegungen kommen. Dies passiert wenn die Bustask nicht pünktlich im konfigurierten Zeitraster ausgeführt wird.

Möglichkeiten zur Verbesserung der Bewegung

  • Prüfen Sie in der Registerkarte Monitoring der Taskkonfiguration1, ob der Task-Jitter der Bustask zu hoch2 ist. Dies kann entweder daran liegen, dass die Bustask durch eine Task mit gleicher oder höherer Priorität verdrängt wird, oder dass die Steuerung nicht ausreichend echtzeitfähig ist.

  • Wenn der Jitter zu hoch ist und Sie bereits sichergestellt haben, dass die Bustask die höchste Priorität hat, dann reicht die Echtzeitfähigkeit der Steuerung nicht aus. Verwenden Sie in diesem Fall eine Steuerung mit besseren Echtzeiteigenschaften

  • Bei Regelungsproblemen im Antrieb sollten Sie die Regelungsparameter anpassen. Zusätzlich kann die Drehmomentvorsteuerung die Regelung verbessern.

    Für weitere Informationen siehe: Drehmomentbegrenzung und Drehmomentvorsteuerung

1 Es ist empfehlenswert, die Messwerte des Task-Monitorings über das Kontextmenü zurückzusetzen, da der erste SPS-Zyklus nach Start der Applikation oft eine erhöhte Dauer und einen erhöhten Jitter hat.

2 Jitter-Werte bis ca. 20 us sind sehr gut, Werte bis ca. 100 us sind gut. Je nach verwendeten Antrieben kann auch der Betrieb mit höheren Jitter-Werten funktionieren. Jitter-Werte, die bis in die Größenordnung des Taskintervalls der Bustask gehen, können zu dem beschriebenen Fehlerbild führen.

In diesem Abschnitt: