G-codes ISO et axes rotatifs

Le codage ISO est un système ancien qui a de nombreuses limites et aussi quelques lacunes. En voici une qui semble tenir tête à plusieurs d'entre vous qui usinez en 4 axes. Petits rappels préalables :
- Au départ, le code ISO a été créé pour programmer au pied d'une machine 3 axes XYZ avançant lentement (pas de cinématique). Ensuite, on a fait ce qu'on a pu pour le faire évoluer, mais ces racines restent palpables. On a notamment créé des axes supplémentaires avec les adresses U V W (linéaires) et A B C (rotatifs respectivement parallèles à X Y Z).
- Les vitesses de mouvement sont codées derrière le tag 'F', en nombres entiers ou réels, l'unité étant en général le mm/min ou le pouce/min selon l'unité G70/G71 courante (on trouve parfois des unités de vitesse différentes à cause d'une imprécision dans la définition du codage, j'ai même vu des Hz sur certaines implémentations baroques).
- Ces vitesses s'appliquent pour le mode G1/G2/G3 courant et sont révisables par le tag 'F' suivant. Bien que rien ne le précise dans la définition du codage, la plupart des constructeurs de CN considèrent qu'une vitesse F s'applique à toutes les lignes G1 G2 G3 qui suivent jusqu'à révision. Mais quelques irréductibles, heureusement rares, distinguent les F applicables à G1, à G2 ou à G3. Dans le doute, mieux vaut mettre un F à chaque nouvelle ligne G1, G2 ou G3 si la vitesse a changé entre-temps. Inutile par contre de coller un F à chaque ligne, sauf si la FAO inclut un préprocesseur cinématique.
- La vitesse en mode G0 n'est en général pas définie dans le fichier, mais sur le tableau de bord de la machine. On y définit les vitesses inactives XY, Z vers le bas et Z vers le haut. On trouve néanmoins des fichiers contenant des lignes G0 F puisque la norme ISO n'a jamais dit que c'était interdit. A la machine ou au pilote CNC d'en décider. Lancelot les ignore, Kay les applique, Galaad les produit si une vitesse de dégagement est spécifiée.
- Les coordonnées sur un axe rotatif sont des degrés d'angle. Je ne crois pas qu'on puisse utiliser d'autres coordonnées, par exemple des radians, mais je me trompe peut-être. Les gens ont de l'imagination.
- Rien dans le codage ne définit une vitesse angulaire sur un axe rotatif. Une ligne G1 F600 A180 indique un mouvement de 180° de l'axe A à une vitesse de 600 mm/min, soient 10 mm/s (on considère qu'on est en coordonnées relatives pour simplifier, ou bien que la coordonnée A précédente est 0, ce qui revient au même). Vous voyez tout de suite le problème qui pointe le bout de son nez : comment fait-on une *rotation* de 180° à une vitesse *linéaire* de 10 mm/s ? Et c'est effectivement à partir de là qu'il va y avoir un sacré bordel...

Certaines implémentations de l'ISO considèrent que le tag F dans une ligne à mouvement strictement angulaire (i.e. sans mouvement linéaire), par exemple cette G1 F600 A180 indique pour le coup une valeur de vitesse angulaire, en général en °/min. Ca pourrait tenir la route, mais si une ligne G1 X100 sans F suit derrière, que doit-on faire du F600 qui a été lu ? L'appliquer aussi sec en mm/min ? Le mettre de côté pour les seules lignes G1 A qui suivent ? Une fois de plus, chaque constructeur de CN a interprété à sa façon, pratique hélas courante en ISO, ce qui est un comble pour un codage normalisé. Heureusement, il y a des constructeurs qui ont plus de poids que d'autres (Fanuc, Num, Siemens) et c'est ceux-là qu'on suit, du moins quand ils sont d'accord (Fanuc et Num sont par ailleurs incompatibles sur le codage des interpolations circulaires, ce qui n'est pas une mince affaire). Encore plus heureux, la plupart des poids lourds ne considèrent pas que la valeur F devient angulaire dans ce cas.

Revenons donc à notre ligne G1 F600 A180 qui fâche. Si, en plus, elle contient un petit mouvement linéaire, par exemple G1 F600 Z1 A180 (cas vécu, merci Christian), on peut imaginer que la vitesse s'applique sur le mouvement linéaire Z, et que l'axe A suivra par interpolation. On est toujours en coordonnées relatives, s'entend. La ligne s'interprète alors comme G1 F600 Z1 avec un mouvement A interpolé mais annexe, de 180°. Que croyez-vous qu'il se passe ? Eh bien Z fait son mouvement de 1 mm à 600 mm/min, donc en 0.1 seconde, et puisque A est interpolé, il fait son mouvement dans le même temps, c'est à dire 180° en 0.1 seconde, soient 5 tours/s. Pour le coup, ça fait peut-être un peu rapide. C'est pourtant comme ça que Galaad interprétait une ligne de ce genre jusqu'à une date récente.

En plus, ça ne résoud même pas notre problème avec G1 F600 A180 qui mélange vitesse linéaire et mouvement angulaire.

Dans un fichier ISO d'usinage 4 axes, on peut considérer que, dans la quasi-unanimité des cas (hélas à un "quasi" près), les coordonnées Y et Z ont leur point zéro sur l'axe A, c'est à dire que Y=0 lorsque l'outil est à la verticale de l'axe de rotation du mandrin et Z=0 lorsque la pointe de l'outil est sur le même plan horizontal que l'axe du mandrin. Ceci va nous aider à sortir de cette situation. Mais comme chaque médaille a son revers, ça va aussi apporter des soucis en plus. Ce serait trop simple.

Si Yo et Zo sont le point de contact de l'outil avec l'axe A, pour chaque position YZ on a donc une distance à l'axe A, c'est à dire un rayon. Si l'axe A se met à tourner, l'outil usine un cercle autour de A, la distance de l'outil à l'axe étant le rayon de ce cercle. Pythagore nous donne de quoi le calculer : c'est la racine carrée de la coordonnée Y plus la coordonnée Z préalablement élevées au carré. Si l'on a un rayon, on peut convertir une vitesse linéaire F applicable à l'avance de l'outil sur la circonférence du cercle, en une vitesse angulaire. C'est magique. Donc on peut dire que, dans la ligne G1 F600 A180, si à ce moment on a Y=0 (cas général en usinage cylindrique) et Z=15, le rayon du cercle autour de A est 15 mm, donc une vitesse tangentielle de 10 mm/s sera convertie en 10/15*2*PI = 0.106 t/s = 38°/s. C'est ce que Galaad faisait - et fait toujours - dans ce cas où le mouvement est uniquement rotatif.

Reste le cas d'une ligne G1 F600 Z1 A180 (coordonnées relatives). Aujourd'hui, Galaad considère que la vitesse est la vitesse d'avance calculée par recombinaison de la vitesse tangentielle sur la circonférence de 180° et de la vitesse linéaire de l'axe Z qui remonte de 1 mm pendant la rotation. Auparavant, il aurait considéré seulement le mouvement linéaire, d'où les sauts de vitesse angulaire observés par Christian.

Au fait, quel est le rayon applicable pour calculer la vitesse tangentielle, puisque Z varie ? En fait, c'est simple, il suffit de prendre le rayon moyen, c'est à dire au milieu du mouvement Z. On aura une vitesse angulaire trop lente au début du mouvement et trop rapide à la fin, mais la moyenne est correcte. Si le mouvement Z est petit, ça passera par pertes et profits. Inversement, si la ligne est de type G1 F600 Z100 A1, utiliser la vitesse angulaire est un non-sens. Il est évident que, dans ce cas, la vitesse qui nous intéresse est quasi-linéaire, puisque la rotation est toute petite. Comme dirait Lénine, que faire ?

Je ne sais pas ce que Lénine aurait fait (probablement fusillé le patron de l'atelier et glorifié l'opérateur au nom du prolétariat qui souffre), mais Galaad fait la chose suivante quant à lui : il calcule la circonférence moyenne décrite par l'outil autour de l'axe A ainsi que la distance décrite par l'outil sur les axes linéaires, y applique le théorème de Pythagore (donc prend la racine carrée de la somme des carrés de ces distances) en considérant qu'on est dans un espace-temps où les axes rotatifs ne sont jamais que des dimensions enroulées, et obtient ainsi une distance déroulée, virtuellement linéaire, à laquelle la vitesse F peut s'appliquer, ce qui nous donne une durée de mouvement. On peut ensuite calculer la vitesse applicable à l'axe majeur (celui qui parcourt le plus grand nombre d'incréments), ce qui nous dispense de trancher de façon arbitraire entre Z et A : quel que soit le cas de figure, Z majeur ou A majeur, le mouvement sera fait dans le temps calculé, donc la vitesse sera la bonne, du moins en moyenne. Ca marche évidemment quel que soit le nombre d'axes linéaires en mouvement.

On aura compris que, pour une vitesse tangentielle (avance de l'outil sur le cylindre), plus on est proche de l'axe, plus celui-ci doit tourner vite, et plus on s'en éloigne, plus il doit tourner lentement. C'est pour ça qu'en tournage, Gawain accélère la rotation lorsque l'outil se rapproche de l'axe, afin de conserver une vitesse tangentielle constante à la pointe de l'outil. Sauf que cette vitesse devient infinie sur l'axe, et de toute façon le point de contact de l'outil n'est pas infiniment petit. Donc on triche un peu, mais c'est pour la bonne cause. Comme l'interpolation ne concerne pas la vitesse de rotation, Gawain morcèle les vecteurs et envoie entre chacun d'eux une consigne de rotation au moteur du mandrin, du moins si celui-ci est asservi. C'est pour ça qu'on voit le mandrin ralentir et accélérer en fonction de la coordonnée X de pénétration dans le cylindre.

Si Galaad était un logiciel parfait, il morcèlerait de la même façon le vecteur pour pouvoir recalculer à chaque fois la vitesse selon le rayon, ce qui ferait qu'on aurait une composante angulaire rapide sur la partie du mouvement la plus proche de l'axe, et lente sur la partie éloignée. Ca nécessiterait au passage un paramètre de segmentation. Mais une grande paresse m'a envahi sur ce sujet, d'autant plus grande qu'il aurait fallu en tenir compte rétroactivement dans la chaîne cinématique, ce qui n'était pas simple, et je me suis donc contenté d'une moyenne sur le vecteur même si celui-ci est long. De toute façon, les usinages cylindriques ont rarement des variations démesurées de rayon sur un mouvement unique, et même dans ce cas, il faudrait que la distance angulaire soit importante pour que ça pose problème, genre une spirale multitours à large rayon décrite sur une seule ligne de G-code. On pourra imaginer que ça n'arrive pas tous les jours.

En conclusion, pas de conclusion, sinon que le G-code offre un grand bac à sable à l'imagination des programmeurs. Des gens intelligents ont depuis créé des codages un peu mieux fichus, par exemple le code NCP-Remote d'Isel, mais les cas de figure ci-dessus peuvent rester sources de problème, sauf à avoir un recalcul dynamique du mouvement en cours, ce que seules les CN industrielles peuvent faire avec leur grosse puissance de calcul. Et le prix qui va avec.