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
|
:lang: fr
:toc:
= Moteurs pas à pas
[[cha:stepper-diagnostics]] (((Stepper Diagnostics)))
Si ce que vous obtenez ne correspond pas à ce que vous espériez, la
plupart du temps c'est juste un petit manque d'expérience. Accroître
son expérience permet souvent une meilleure compréhension globale.
Porter un diagnostic sur plusieurs problèmes est toujours plus facile
en les prenant séparément, de même qu'une équation dont on a réduit le
nombre de variables est toujours plus rapide à résoudre. Dans le monde
réel ce n'est pas toujours le cas mais c'est une bonne voie à suivre.
== Problèmes communs
=== Le moteur n'avance que d'un pas
La raison la plus fréquente dans une nouvelle installation pour que le
moteur ne bouge pas est l'interversion entre le signal de pas et le
signal de direction. Si, quand vous pressez le bouton de jog dans un
sens puis dans l'autre, le moteur n'avance que d'un pas à chaque fois
et toujours dans la même direction, vous êtes dans ce cas.
=== Le moteur ne bouge pas
Certaine interfaces de pilotage de moteurs ont une broche d'activation
(enable) ou demandent un signal de pompe de charge pour activer leurs
sorties.
=== Distance incorrecte
Si vous commandez une distance de déplacement précise sur un axe et
que le déplacement réel ne correspond pas, alors l'échelle de l'axe
n'est pas bonne.
== Messages d'erreur
=== Erreur de suivi
Le concept d'erreur de suivi est étrange quand il s'agit de moteurs
pas à pas. Etant un système en boucle ouverte, aucune contre réaction
ne permet de savoir si le suivi est correct ou non. LinuxCNC calcule si il
peut maintenir le suivi demandé par une commande, si ce n'est pas
possible il stoppe le mouvement et affiche une erreur de suivi. Les
erreurs de suivi sur les systèmes pas à pas sont habituellement les
suivantes:
- FERROR to small - (FERROR trop petit)
- MIN_FERROR to small - (MIN_FERROR trop petit)
- MAX_VELOCITY to fast - (MAX_VELOCITY trop rapide)
- MAX_ACCELERATION to fast - (MAX_ACCELERATION trop rapide)
- BASE_PERIOD set to long - (BASE_PERIOD trop longue)
- Backlash ajouté à un axe (rattrapage de jeu)
Toutes ces erreurs se produisent lorsque l'horloge temps réel n'est
pas capable de fournir le nombre de pas nécessaire pour maintenir la
vitesse requise par le réglage de la variable BASE_PERIOD. Ce qui peut
se produire, par exemple après un test de latence trop bref pour
obtenir un valeur fiable, dans ce cas, revenir à une valeur plus proche
de ce qu'elle était et réessayez. C'est également le cas quand les
valeurs de vitesse maximum et d'accélération maximum sont trop élevées.
Si un backlash a été ajouté, il est nécessaire d'augmenter
STEPGEN_MAXACCEL aux environs du double de MAX_ACCELERATION dans la
section [AXIS] du fichier INI et ce, pour chacun des axes sur lesquels
un backlash a été ajouté. LinuxCNC utilise une _extra accélération_ au
moment de l'inversion de sens pour reprendre le jeu. Sans correction du
backlash, l'accélération pour le générateur de pas peut être juste un
peu plus basse que celle du planificateur de mouvements.
=== Erreur de RTAPI
Quand vous rencontrez cette erreur:
RTAPI: ERROR: Unexpected realtime delay on task n
C'est généralement que la variable BASE_PERIOD dans la section
[EMCMOT] du fichier ini a une valeur trop petite. Vous devez lancer un
_Latency Test_ pendant une durée plus longue pour voir si vous n'avez
pas un délai excessif quelque part, responsable de ce problème. Si
c'est le cas réajuster alors BASE_PERIOD avec la nouvelle valeur
obtenue.
LinuxCNC vérifie le nombre de cycles du CPU entre les invocations du
thread temps réel. Si certains éléments de votre matériel provoquent un
délai excessif ou que les threads sont ajustés à des valeurs trop
rapides, vous rencontrerez cette erreur.
NOTE: Cette erreur n'est affichée qu'une seule fois par session. En
effet, si votre BASE_PERIOD était trop basse vous pourriez avoir des
centaines de milliers de messages d'erreur par seconde si plus d'un
était affiché.
Plus d'informations <<cha:test-de-latence, sur le test de latence.>>
== Tester
=== Tester le timing des pas
Si un de vos axes vibre, grogne ou fait des petits mouvements dans
toutes les directions, c'est révélateur d'un mauvais timing
d'impulsions de pas de ce moteur. Les paramètres du pilote matériel
sont a vérifier et a ajuster. Il peut aussi y avoir des pertes de pas
aux changements de direction. Si le moteur cale complétement, il est
aussi possible que les paramètres MAX_ACCELERATION ou MAX_VELOCITY
aient des valeurs trop élevées.
Le programme suivant vérifie que la configuration de l'axe Z est
correcte. Copiez le programme dans le répertoire de votre linuxcnc/nc_files
nommez le _TestZ.ngc_ ou similaire. Initialisez votre machine avec Z =
0.000 sur le dessus de la table. Chargez et lancez le programme. Il va
effectuer 200 mouvements d'aller et retour entre 10.00 et 30.00mm. Si
vous avez un problème de configuration, la position de l'axe Z affichée
à la fin du programme, soit 10.00mm, ne correspondra pas à la position
mesurée. Pour tester un autre axe remplacez simplement le Z des G0 par
le nouvel axe.
----
( Faire Z=0 au dessus de la table avant de démarrer! )
( Ce programme teste les pertes de position en Z )
( msg, test 1 de la configuration de l'axe Z )
G21 #1000=100 ( boucle 100 fois )
( cette boucle comporte un délai après chaque mouvement )
( test des réglages d'accélération et de vitesse )
o100 while [#1000]
G0 Z30.000
G4 P0.250
G0 Z10.000
G4 P0.250
#1000 = [#1000 - 1]
o100 endwhile
( msg, test 2 de la configuration de l'axe Z, pressez S pour continuer)
M1 (un arrêt ici)
#1000=100 ( boucle 100 fois )
( Les boucles suivantes n'ont plus de délai en fin de mouvements )
( test des réglages des temps de maintien des pilotes)
( et les réglages d'accélération max )
o101 while [#1000]
G0 Z30.000 .
G0 Z10.000
#1000 = [#1000 - 1]
o101 endwhile
( msg, Fin Z doit être à 10mm au dessus de la table )
M2
----
|
