Performance
La planification des mouvements se fait dans une tâche distincte car le calcul est gourmand en CPU. Cette tâche distincte est appelée tâche de planification et s'exécute en parallèle avec la tâche de bus. Si les performances de l'automate ne suffisent pas à planifier le chemin dans la tâche de planification à temps pour la tâche de bus, il s'agit alors de problèmes de performances.
Les problèmes de performance dans la planification des mouvements peuvent conduire à SMC_CP_QUEUE_UNDERRUN erreur, mais ils peuvent aussi conduire à un mouvement saccadé ou plus lent que prévu. Pour obtenir des informations sur le SMC_CP_QUEUE_UNDERRUN erreur, voir le Erreurs courantes chapitre. Le diagnostic des problèmes de performance liés aux mouvements est décrit ci-dessous.
Diagnostic en cas de mouvements lents ou saccadés
S'il n'y a aucun problème de performance, alors chaque mouvement est planifié de telle manière qu'au moins un des limites efficaces est atteint pendant tout le mouvement. A titre d'exemple, considérons un simple portique bidimensionnel avec deux axes X et Y et un mouvement PTP de la position (0,0) à (10,-10). La vitesse maximale de l'axe est de 20, l'accélération maximale de l'axe est de 100 et l'à-coup maximal de l'axe est de 1 000.
Le mouvement attendu ressemble à ceci :
L'accélération s'établit d'abord avec un à-coup maximum jusqu'à ce que la valeur limite d'accélération de 100 soit atteinte. Après une courte phase d'accélération constante, l'accélération est à nouveau réduite avec un à-coup maximum, de sorte que la valeur limite de vitesse de 20 soit atteinte avec une accélération de 0. Après une phase de vitesse constante, une décélération a lieu de sorte que la position cible soit atteinte avec la vitesse. et accélération 0.
Il y a deux raisons possibles pour lesquelles le mouvement réel s’écarte de cette courbe idéale :
Le mouvement prévu ne correspond pas à la courbe idéale en raison de problèmes de performance dans la tâche de planification.
Le mouvement prévu correspond à la courbe idéale, mais le robot ne l'exécute pas comme prévu.
Cas 1 : Problèmes de performance de la tâche de planification
S’il y a des problèmes de performance lors de la planification, le mouvement pourrait alors ressembler à ceci :
En effet, le mouvement est planifié dans la tâche de planification parallèlement à l'exécution dans la tâche de bus. En moyenne, la tâche de planification doit fournir autant de trajectoire que l’exige la tâche de bus. Si les performances ne sont pas suffisantes, le mouvement est alors ralenti. Cela conduit à la courbe de vitesse ondulée.
Le premier et le plus important outil pour diagnostiquer de tels problèmes est la trace. En plus de fSetPosition, fSetVelocity, et fSetAcceleration variables pour chaque axe, le numTimeBudgetExceeded et numSlowDownLowIpoQueue sorties du SMC_GroupReadPlanningStatistics Le bloc fonctionnel doit également être enregistré. Si ces compteurs augmentent continuellement, il y a alors un problème de performances.
Avis
De la même manière que le fSetPosition, fSetVelocity, et fSetAcceleration variables, il y a aussi les fSetJerk variable pour le jerk. Il convient de noter que l'à-coup n'est pas l'à-coup moyen appliqué pendant le cycle de la tâche du bus (comme on s'y attend souvent), mais plutôt l'à-coup instantané à la fin du cycle. Donc, FSetJerk n'a qu'une importance limitée pour diagnostiquer les problèmes de performances.
Façons d'améliorer le mouvement
La liste suivante contient les étapes permettant de gérer les problèmes de performances :
Ajustement des valeurs limites pour la vitesse, l'accélération et l'à-coup :
Plus il faut de temps pour décélérer depuis la vitesse actuelle jusqu'à l'arrêt, plus la puissance de calcul requise est élevée.
Une valeur limite efficace élevée pour la vitesse et des valeurs limites efficaces faibles pour l'accélération et l'à-coup sont donc plus susceptibles d'entraîner des problèmes de performances.
En particulier, les valeurs limites d'accélération et d'à-coup ne doivent donc pas être fixées inutilement à des niveaux bas.
Augmentez la priorité de la tâche de planification ou diminuez la priorité des autres tâches si elles bloquent la tâche de planification. La tâche de planification doit avoir la deuxième priorité la plus élevée après la tâche de bus.
Attribuez la tâche de planification à un cœur dédié si plusieurs cœurs de processeur sont disponibles (voirConfiguration de la tâche de planification).
Utiliser
SMC_TuneCPKernelpour augmenter la valeur dufPlanningIntervalet/oufSyncBufferDurationparamètres de planification.Le
fPlanningIntervalLe paramètre spécifie l'incrément de planification maximum (en secondes). Le temps de cycle de la tâche de planification ne doit pas dépasser cette valeur en permanence. Une valeur plus élevée réduit la puissance de calcul, mais peut également empêcher que les valeurs limites définies pour la vitesse, l'accélération et l'à-coup ne soient pas pleinement utilisées. A partir d'une valeur de départ de 0,016 seconde (valeur par défaut depuis CODESYS SoftMotion version 4.6.0.0), la valeur doit être augmentée progressivement jusqu'à ce que les performances soient acceptables.Le
fSyncBufferDurationLe paramètre spécifie la taille du tampon entre la tâche de planification et la tâche de bus. Les temps de cycle de pointe de la tâche de planification ne doivent pas dépasser cette valeur. Une valeur plus élevée peut compenser les pics de temps de cycle de la tâche de planification. Mais dans le même temps, cela augmente également le temps de latence pour l'exécution des interruptions et l'abandon des mouvements.
Cas 2 : Le robot ne suit pas le mouvement prévu comme prévu
Si le robot ne suit pas le mouvement prévu comme prévu, cela peut être dû aux raisons suivantes :
Capacité temps réel insuffisante du contrôleur
Problèmes de boucle de contrôle des variateurs
Sur un contrôleur non compatible temps réel tel que le CODESYS Control Win, ou un contrôleur basé sur Linux sans correctif en temps réel du système Linux sous-jacent, des mouvements trop lents ou saccadés peuvent se produire même avec des performances suffisantes. Cela se produit si la tâche de bus n'est pas exécutée à temps dans le laps de temps configuré.
Façons d'améliorer le mouvement
Sur l'onglet "Suivi" de la configuration des tâches 1, vérifiez si la tâche gigue de la tâche de bus 2 est trop élevé. Cela peut être le cas soit parce que la tâche du bus est déplacée par une tâche ayant une priorité identique ou supérieure, soit parce que le contrôleur n'est pas suffisamment capable de fonctionner en temps réel.
Si la gigue est trop élevée et que vous avez déjà veillé à ce que la tâche de bus ait la priorité la plus élevée, la capacité temps réel du contrôleur n'est pas suffisante. Dans ce cas, utilisez un contrôleur doté de meilleures propriétés temps réel.
S'il y a des problèmes de boucle de contrôle dans le variateur, vous devez alors ajuster les paramètres de la boucle de contrôle. Le contrôle anticipé du couple peut également améliorer les performances de la boucle de contrôle.
Pour plus d'informations, voir : Limitation de couple et commande d'avance de couple
1: Il est conseillé de réinitialiser les valeurs mesurées du suivi des tâches dans le menu contextuel car le premier cycle automate après le démarrage de l'application a souvent une durée accrue et un jitter accru.
2: Valeurs de gigue jusqu'à env. 20 us sont très bons et valorisent jusqu'à env. 100 nous, c'est bien. Selon les lecteurs utilisés, un fonctionnement avec des valeurs de gigue plus élevées peut également fonctionner. Les valeurs de gigue qui atteignent l'ordre de grandeur de l'intervalle de tâche de la tâche de bus peuvent entraîner le modèle d'erreur décrit ci-dessus.