Réglages des pas à pas

Le CPU n’est pas le seul facteur déterminant la latence. Les cartes mères, cartes graphiques, ports USB et nombre d’autres choses peuvent la dégrader. La meilleure façon de savoir ce que vous pouvez attendre d’un PC consiste à exécuter le test de latence RTAI.

Lancer un test comme décrit au chapitre sur le test de latence.

Les différente marques de cartes de pilotage de moteurs pas à pas demandent toutes des timing différents pour les impulsions de commande de pas et de direction. Aussi vous avez besoin d’accéder (ou Google) à la fiche des spécifications techniques de votre carte.

Par exemple, le manuel du Gecko G202 indique:

Les spécifications du Gecko G203V indiquent:

Un carte Xylotex donne dans ses données techniques un superbe graphe du timing nécessaire, il indique:

Notez les valeurs que vous trouvez, vous en aurez besoin pour la prochaine étape.

BASE_PERIOD est l’horloge de votre LinuxCNC. A chaque période, le générateur d’impulsions de pas décide si il est temps pour une autre impulsion. Une période plus courte vous permettra de générer plus d’impulsions par seconde, dans les limites. Mais si vous la réglez trop bas, votre ordinateur va passer autant de temps à générer des impulsions de pas que pour exécuter tous le reste de ses tâches, il finira peut-être même par se bloquer. La latence et la génération de pas exigent d’affecter la plus courte période utilisable, comme nous le verrons un peu plus loin.

Regardons l’exemple du Gecko en premier. Le G202 peut gérer des impulsions restant à l'état bas pendant 0.5µs et à l'état haut pendant 4.5µs, il a besoin que la broche de direction soit stable 1µs avant le front descendant et qu’elle reste stable pendant 20µs après le front descendant. La plus longue durée est de 20µs, c’est le temps de maintien. Une approche simple consisterait à fixer la période à 20µs. Ce qui signifierait que tous les changements d'état des lignes STEP et DIR serait espacés de 20µs. C’est tout bon, non?

Faux! Si la latence était de zéro, et que tous les fronts soient espacés de 20µs, tout irait bien. Mais tous les ordinateurs ont une latence. Si l’ordinateur a 11µs de latence, celà signifie que, ce que l’ordinateur exécute aura parfois un retard de 11µs et la fois suivante pourra être juste à l’heure, le délai entre le premier et le second sera seulement de 9µs. Si le premier génére l’impulsion de pas et le second change la broche de direction, le timing de 20µs requis par le G202 sera tout simplement violé. Cela signifie que votre moteur aura peut être fait un pas dans la mauvaise direction et que votre pièce ne sera pas à la cote.

Le côté vraiment mauvais de ce problème est qu’il peut être très très rare. Les pires latences sont celles qui ne se produisent que quelques fois par minute. Les chances qu’une mauvaise latence de ce genre arrive juste quand le moteur est en train de changer de direction sont faibles. Ainsi, vous avez de très rares erreurs qui vous ruinent une pièce de temps en temps et qui sont impossibles à résoudre.

La façon la plus simple pour éviter ce problème est de choisir une BASE_PERIOD qui soit la somme de la plus longue période requise par votre carte plus la durée de la pire latence de votre ordinateur. Si vous utilisez un Gecko avec un temps de maintien exigé de 20µs et que votre test de latence vous avait donné une latence maximum de 11µs, alors si vous définissez BASE_PERIOD à 20+11 = 31µs (31000 nanosecondes dans le fichier ini), vous aurez la garantie de répondre aux exigences de votre carte de pilotage.

Mais c’est un compromis. Faire une impulsion de pas demande au moins deux périodes. Une pour débuter l’impulsion, et une pour y mettre fin. Etant donné que la période est de 31µs, il faut 2x31 = 62µs pour créer une impulsion de pas. Ce qui signifie que la fréquence de pas maximum sera seulement de 16129 pas par seconde. Pas très bon. (Mais n’abandonnez pas, nous avons encore quelques réglages à faire dans la section suivante.)

Pour la Xylotex, la configuration demande des temps de maintien très courts de 200ns chacun (0.2µs). Le temps le plus long est de 2µs. Si vous avez 11µs de latence, alors vous pouvez définir BASE_PERIOD aussi bas que 11+2 = 13µs. Se débarrasser du long temps de maintien de 20µs aide vraiment. Avec une période de 13µs, un pas complet ne dure que 26µs = 2x13 et la fréquence maximum est de 38461 pas par seconde!

Mais ne commencez pas à célébrer celà. Notez que 13µs est une période très courte. Si vous essayez d’exécuter le générateur de pas toutes les 13µs, il ne restera peut-être pas assez de temps pour faire autre chose et votre ordinateur se bloquera. Si vous visez des périodes de moins de 25µs, vous devez commencer à 25µs ou plus, lancer LinuxCNC et voir comment les choses réagissent. Si tout va bien, vous pouvez réduire progressivement la période. Si le pointeur de la souris commence à être sacadé et que le reste du PC ralentit, votre période est un peu trop court. Retournez alors à la valeur précédente qui permettent le meilleur fonctionnement.

Dans ce cas, supposons que vous ayez commencé à 25µs, en essayant descendre à 13µs, vous trouvez que c’est autour de 16µs que se situe la limite la plus basse et qu’en dessous l’ordinateur ne répond plus très bien. Alors, vous utilisez 16µs. Avec une période à 16µs et une latence à 11µs, le temps de sortie le plus court sera de 16-11 = 5µs. La carte demande seulement 2µs, ainsi vous aurez une certaine marge. Il est bon d’avoir une marge si vous ne voulez pas perdre de pas parce que vous auriez réglé un timing trop court.

Quel est la fréquence de pas maximum? Rappelez-vous, deux périodes pour faire un pas. Vous avez réglé la période à 16µs alors qu’un pas prend 32µs. Il fonctionnera à 31250 pas par seconde, ce qui n’est pas mal.

Dans la section précédente, nous avons utilisé la carte de puissance Xylotex pour piloter nos moteurs avec une période de 16µs ce qui nous a donné une fréquence de pas de 31250 pas par seconde maximum. Alors que la Gecko a été bloquée à 31µs avec une assez mauvaise fréquence de pas de 16129 pas par seconde. L’exemple de la Xylotex est au mieux de ce que nous puissions faire. Mais la Gecko peut être ameliorées.

Le problème avec le G202 est le temps de maintien demandé de 20µs. Ca plus la latence de 11µs nous oblige à utiliser une période longue de 31µs. Mais le générateur de pas logiciel de LinuxCNC a un certain nombre de paramètres qui permettent d’augmenter les différentes durées d’une période à plusieurs autres. Par exemple, si steplen passe de 1 à 2, alors il y aura deux périodes entre le début et la fin de l’impulsion. De même, si dirhold passe de 1 à 3, il y aura au moins trois périodes entre l’impulsion de pas et un changement d'état de la broche de direction.

Si nous pouvons utiliser dirhold pour le temps de maintien de 20µs demandé, alors le temps le plus long suivant sera de 4.5µs. Ajoutez les 11µs de latence à ces 4.5µs, et vous obtenez une période minimale de 15.5µs. Lorsque vous essayez 15.5µs, vous trouvez que l’ordinateur est très lent, donc vous régler sur 16µs. Si nous laissons dirhold à 1 (par défaut), alors le temps minimum entre le pas et la direction est de 16µs moins la période de latence de 11µs = 5µs, ce qui n’est pas suffisant. Nous avons besoin de 15 autres µs, puisque la période est de 16µs, nous avons besoin d’une période de plus. Nous allons donc passer dirhold de 1 à 2. Maintenant, le temps minimum entre la fin de l’impulsion et l’impulsion de changement de direction est de 5+16 = 21µs et nous n’avons pas à craindre que la Gecko parte dans la mauvaise direction en raison de la latence.

Si l’ordinateur a une latence de 11µs, alors la combinaison d’une période de base de 16µs et d’une valeur de dirhold de 2 garanti que nous serons toujours dans le respect des délais exigés par la Gecko. Pour les pas normaux (sans changement de direction), l’augmentation de la valeur de dirhold n’aura aucun effet. Il faudra deux périodes d’un total de 32µs pour faire un seul pas et nous avons la même fréquence de 31250 pas par seconde que nous avions eu avec la Xylotex.

Le temps de latence de 11µs utilisé dans cet exemple est très bon. Si vous travaillez par le biais de ces exemples avec des latences plus grandes, comme 20 ou 25µs, la fréquence de pas la plus grande à la fois pour la Xylotex et la Gecko sera plus faible. Mais les mêmes formules sont applicables pour calculer un BASE_PERIOD optimal et pour régler dirhold ou d’autres paramètres du générateur de pas.

Pour un système à moteurs pas à pas avec générateur de pas logiciel rapide et fiable, vous ne pouvez pas deviner la période et les autres paramètres de configuration. Vous devez faire des mesures sur votre ordinateur et faire les calculs qui garantirons les meilleurs signaux dont les moteurs ont besoin.

Pour rendre le calcul plus facile, j’ai créé une feuille de calcul Open Office: Step Timing Calculator (en) - Calculatrice Calendrier étape (fr). Vous entrez les résultats du test de latence et les timing de votre carte de pilotage et la feuille calcule la meilleure BASE_PERIOD. Ensuite, vous testez la période pour vous assurer que votre PC ne sera pas ralenti ou bloqué. Enfin, vous entrez dans la période actuelle et la feuille de calcul vous indiquera le réglage de stepgen nécessaire pour répondre aux exigences de votre carte de pilotage. Elle calcule aussi la fréquence de pas maximum que vous serez en mesure de générer.

J’ai ajouté quelques petites choses à la feuille de calcul pour calculer la fréquence maximum et quelques autres calculs.