summaryrefslogtreecommitdiff
path: root/docs/src/motion/tweaking_steppers_fr.txt
blob: a102eb269cf87b849090240adcc64d71257e5837 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
:lang: fr
:toc:

= Réglages des pas à pas

[[cha:Reglages-de-pas-a-pas]] (((Réglages des pas à pas)))

== Obtenir le meilleur pilotage logiciel possible

Faire générer les impulsions de pas au logiciel présente un gros
avantage, c'est gratuit. Quasiment chaque PC dispose d'un port parallèle
capable de sortir sur ses broches les signaux de pas générés par le logiciel.
Cependant, les générateurs d'impulsions logiciels ont aussi quelques
inconvénients:

* La fréquence maximum des impulsions est limitée.
* Les impulsions générées sont irrégulières à cause du bruit.
* Elles sont sujettes à la charge du CPU 

Ce chapitre présente certaines mesures qui vous aideront à obtenir les
meilleurs résultats du logiciel.

=== Effectuer un test de latence

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 <<cha:test-de-latence, au chapitre sur le test>>
de latence.

=== Connaître ce dont vos cartes de pilotage ont besoin

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:
....
Step Frequency: 0 to 200 kHz 
Step Pulse “0” Time: 0.5 µs min (Step on falling edge) 
Step Pulse “1” Time: 4.5 µs min 
Direction Setup: 1 µs min (20 µs min hold time after Step edge)
....

Les spécifications du Gecko G203V indiquent:
....
Step Frequency: 0 to 333 kHz 
Step Pulse “0” Time: 2.0 µs min (Step on rising edge) 
Step Pulse “1” Time: 1.0 µs min 

Direction setup:
    200 ns (0.2µs) before step pulse rising edge 
    200 ns (0.2µs) hold after step pulse rising edge
....

Un carte Xylotex donne dans ses données techniques un superbe graphe
du timing nécessaire, il indique:
....
Minimum DIR setup time before rising edge of STEP Pulse 200ns Minimum 
DIR hold time after rising edge of STEP pulse 200ns 
Minimum STEP pulse high time 2.0µs 
Minimum STEP pulse low time 1.0µs 
Step happens on rising edge
....

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

=== Choisir la valeur de BASE_PERIOD

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.

=== Utiliser steplen, stepspace, dirsetup, et/ou dirhold

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.

=== Pas de secret!

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: 
http://wiki.linuxcnc.org/uploads/StepTimingCalculator.ods[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.