Numérisation TOUR ACIMEX BL200L-1

Bonjour!

Réponses en vrac:

Les vis à billes doivent également être protégées des copeaux.

Oui, mais là, c'est carrément plus facile. Pour faire un protège-engrenages dans le
cas de mon tour, la forme est un peu compliquée et en plus, il n'y a pas de trou de
vis exploitable pour le fixer.
Pour les vis à billes, il existe des vis avec "plastic fingers" qui sont apparemment
assez efficaces. Mais j'avoue que ce n'est pas vraiment mon domaine, donc je préfère
faire profil bas sur cette question. En plus, je pourrais ajouter un joint avec balais,
genre trou avec du poil autour (j'espère que ceci n'est pas hors charte), ce qui ferait
que la plupart des copeaux n'atteindraient même pas les "fingers". En ajoutant un trou
pour air comprimé, souffler un coup de temps en temps permettrait de faire le ménage
de ce qui est pris dans les balais.

Je ne vois pas l'intérêt des rêgles magnétiques surtout que la cohabitation avec les
copeaux est délicate.

Alors là, par contre, c'est mon domaine.
Si j'utilise des brushless, il faut inévitablement un système de mesure. 2 solutions:
- un encodeur rotatif en bout d'arbre. Mais il faut alors implémenter un multitours,
et il ne faut pas que le multitours oublie le nombre de tours quand c'est éteint.
C'est possible avec une résolution d'environ 14 bits / tour (donc 16384 pas),
mémorisation par pile. 14 bits par tour, si on considère que la vis a un pas de 5mm,
ça fait une résolution de 0.3µ. En résumé, c'est acceptable, mais ça mesure le nombre
de tours, pas la distance, et tout repose sur la précision de la vis.
- encodeur linéaire à règle:
-> Optique: très précis (~10 nm), mais très sensible à la poussière, à la vapeur
d'huile, etc... Mieux vaut oublier.
-> Magnétique: moins précis tout en l'étant suffisamment (~100 nm) mais insensible
à la poussière et à l'huile.
Il faut tout de même faire attention aux copeaux ferreux qui risquent de perturber
la règle (je n'en sais rien, mais j'imagine que oui si un copeau se met entre la
règle et le capteur à effet Hall). En la mettant dans un profilé en U retourné avec
des balais de chaque côté, on doit être assez proche d'une solution idéale. Du point
de vue emplacement, si j'enlève la crémaillère, il y a déjà les trous pour fixer tout ça.

Pour les chiffres ci-dessus (10, 100nm), il s'agit bien entendu de la résolution, pas
de la précision. Pour la précision, tout dépend de la règle et des conditions d'utilisation
(température notamment). C'est en tout cas beaucoup plus précis que la solution à moteur
pas à pas, même si celui-ci a un encodeur pour ne pas perdre de pas. Par contre, il y a
peu de solutions clés-en-main apparemment, alors je suis en train de voir ce que je trouve
en matière de moteurs, pas à pas ou BLDC.

@Carlos: vous arrivez à quelle précision de fabrication? Par exemple si vous faites un
dressage, puis un épaulement 10mm plus loin, quelle est la dispersion sur ces 10 mm?
NB: je comprends qu'il soit peut-être un peu tôt pour en parler, d'autant plus qu'il
faudrait faire beaucoup de pièces pour des statistiques, mais j'aimerais bien avoir
des résultats de mesure pour décider de ma méthode.

Ce qui me chiffonne, c'est que vous parlez de 100 impulsions par tour de broche, ce qui
me semble vraiment très peu, mais là encore, je ne suis compétente que pour la mesure
elle-même, pas pour l'ensemble. 100 impulsions par tour, si le filetage a un pas de
1mm, ça fait une précision de max 1/100. Enfin, ça c'est du calcul théorique, il y a
certainement des astuces que je ne vois pas.

Juste pour info: les encodeurs actuels, c'est couramment du 18 bits (donc 250 000
impulsions par tour), c'est pour ça que j'ai l'impression que 100 par tour, c'est peu.
Les extrêmes sont vers les 25 bits (optique), donc 32 millions de pas par tour, et le
bas de gamme vers 12 bits (4096 pas).
D'un autre côté, même avec 100 pas, le résultat est impressionnant, au vu de l'écrou
qui se place parfaitement sur le filetage. On voit clairement que le jeu n'est pas exagéré.

Ouvre un fil de discission spécifique à ton problème,(tu clique sur nouveau) et met
nous des photos de tes machines.

Pour un nouveau fil, je préfère avoir quelque chose de concret à présenter.
Voici mon tour (je viens de comprendre comment mettre des images)


Et voici le problème de la boîte à engrenages de crémaillère. On ne voit pas grand chose,
mais par contre, les copeaux, eux, voient tout de suite comment y aller.



En fait, je ne crois qu'il n'est pas vraiment utile de résoudre ce problème (donc de
faire une discussion à part) parce que je suis décidée à l'attaquer par la méthode dure,
l'automatisation de mon tour. En tout cas merci à tous, merci à Carlos de publier sa
réalisation. Je ne connaissais pas LinuxCNC, je vois que je vais beaucoup apprendre ici.
Il va falloir que je me penche sur l'interfaçage de tout ça...

Élodie.

Bonjour
Surtout éviter l'air comprimé en ce qui me concerne j'utilise un pinceau à poils souple, si tu tape "protection à soufflet" tu as plein de lien sur toutes sortes soufflets et glissières mais il faudra peut être voir comment les fixer sur la machine sans percer le tablier du trainard.

Bonjour Elodie,

Je vois que ton tour ressemble au mien et donc à priori son utilisation est celle d'un hobbyste.

Je suis surpris par la résolution des codeurs que tu penses utiliser. Je ne vois pas comment on peut traiter 250 000 impulsions/tour sur un tour qui tourne à 2000 tr/mn, il faudrait une informatique capable de traiter les infos à une fréquence de 8.25 Mhz et en quadrature 33MHz ...
Je n'ai pas les connaissances nécessaires pour tout comprendre, aussi je raisonne à ma façon.
Si je reprend le temps de latence de mon PC qui est de 3000ns. Cette latence du PC qui est plutot bonne ne me permet pas de descendre en dessous d'une période base équivalente à la latence, ce qui me permettrait virtuellement d'atteindre une fréquence maxi de 0.33 MHz.
Malheureusement, la carte d'interface que j'utilise est une carte bas de gamme sur laquelle je suis limité à 35KHz pour l'ensemble moteurs et codeurs ...
Je rappelle que Mach3 n'utilise que l'index du codeur pour les filetages, donc une seule impulsion par tour. Je crois que son calcul du top départ est fait sur une moyenne de 8 tours. Le risque avec une seule implusion est l'entrée dans la matière qui ralenti forcement la broche même si pour les filetages la prise de copeau est très faible. J'ai constaté dans mes essais un ralentissement d'un ou 2 tours/mn. Une fois en prise la vitesse de rotation est ensuite stable.


Tu penses utiliser des vis à billes et donc remplacer les vis trapézoidales.
Sur le transversal c'est un peu compliqué à cause du peu d'espace disponible et aussi parce qu'on ne trouve pas facilement des vis à billes de 8mm. A cause de cela j'ai conservé la vis d'origine et finalement je ne le regrette pas malgré son jeu axial énorme de 0.3mm. Je me rend compte qu'il suffit de rattraper ce jeu dans les déplacements pour l'annuler.
Sur le longitudinal j'ai remplacé la vis mais il a fallu usiner le banc à cause des portées nécessaires aux supports BK12/BF12. Retrospectivement, je pense que j'aurais pu garder la vis d'origine sans nuire au bon fonctionnement du tour.

Carlos

Bonjour!

D'abord merci pour les tuyaux. Pourquoi pas d'air comprimé?
En fait, je voyais ça plutôt comme un entretien annuel ou mensuel. Mais à mon avis les
copeaux n'auront que peu de raisons de franchir la barrière des brosses circulaires qui
enveloppent la vis, donc c'est vraiment un entretien peu fréquent.

Bon, à part ça, le tablier du traînard, c'est quoi? Tablier semble vouloir dire
quelque chose qui protège autre chose, et traînard quelque chose qui se déplace...
Je dirais au pif que c'est la pièce peinte en gris sur laquelle est fixée le volant
qui fait déplacer le chariot, et aussi l'embrayage des avances?
Si c'est ça, je compte de toute façon l'enlever. J'aimerais réutiliser le volant
en mettant un encodeur bas de gamme juste derrière le volant, et utiliser l'info pour
faire tourner la vis à billes. Donc on pourrait avoir un mode manuel avec le même
look & feel qu'un tour à la papa voire à la pépé. En plus, je peux ajouter un interrupteur
gros / fin. Dans un cas, 1 tour de volant = 5mm, par exemple, et dans l'autre 1 tour = 0.5
ou même 0.05.

Et sinon autour de la vis mère, je pensais aussi à des soufflets tubulaires. Des gaines
extensibles, si on veut. Un de chaque côté et adieu les copeaux. Par contre, il va falloir
voir avec la dimension minimale comprimée pour ne pas trop limiter la course. Bon, c'est
une solution parmi d'autres, on verra. La vis actuelle est sous une simple tôle en L
qui la protège assez bien. Donc tôle plus fingers + brosses... ça devrait être efficace.

Je vois que ton tour ressemble au mien et donc à priori son utilisation est celle d'un hobbyste.

Oui, on peut dire ça. Je l'usilise professionnellement pour faire des prototypes, donc
c'est très loin d'un tour de production. Par contre si j'ai à démonter pour enlever les
copeaux, je vais finir par y passer du temps.

Je suis surpris par la résolution des codeurs que tu penses utiliser. Je ne vois pas
comment on peut traiter 250 000 impulsions/tour sur un tour qui tourne à 2000 tr/mn,
il faudrait une informatique capable de traiter les infos à une fréquence de 8.25 Mhz
et en quadrature 33MHz ...
Je n'ai pas les connaissances nécessaires pour tout comprendre, aussi je raisonne à ma façon.

Il y a beaucoup de sortes d'encodeurs, mais on peut tout de même les classer en 3
catégories.

- Les incrémentaux (A, B, Z). Je pense que vous les connaissez déjà puisqu'il était question de
phase A un peu plus haut. À propos, je ne vois pas comment faire avec la phase A uniquement
parce que le sens de déplacement est perdu. Et si on ne sait pas si ça avance ou si ça
recule, comment veux-tu comment veux-tu que je calcule. Dans le cas s'un encodeur incrémental,
la seule sortie de l'encodeur, ce sont les signaux A, B, Z, en format TTL ou symétrique
(A+, A-, B+, B-, Z+, Z-). Ces encodeurs ont un grand désavantage: il est impossible de
connaître la position instantanée à la mise en route. Donc on est obligé de revenir à 0
à chaque démarrage.
Évidemment, un codeur incrémental, ça pédale vite et il est difficile de suivre directement
avec un processeur parce qu'effectivement, on tourne dans les dizaines de MHz. Mais dans
la pratique, dans les asservissements, on n'a pas besoin d'ajuster à chaque front A/B.

- Les absolus. Cette fois, le signal n'est plus en ABZ, mais en position absolue.
On communique généralement par SPI entre le capteur et le processeur. SPI a l'avantage
d'être connu de tous les processeurs. Sinon par SSI ou BiSS. Donc il n'est plus question
de transmettre toutes les phases ABZ, mais seulement la position absolue quand on veut la
lire. Les encodeurs absolus existent en linéaire aussi bien qu'en rotatif.
Si vous utilisez un absolu, la seule condition pour que le système fonctionne est de faire
au moins 2 mesures par tour. Ça rejoint le théorême de Shannon en traitement du signal.
Et 2 mesures par tour à 2000 tours par minute, ça fait 4000 mesures par minute, donc
66 mesures par seconde, c'est très lent. Il faut voir que la mécanique est toujours TRES
lente par rapport à l'électronique. Dans la pratique, on peut faire facilement beaucoup
plus. Le bus SPI tourne à 10 MHz. Si on lit des trames de 32 bits, ça nous fait 320 000
trames par seconde, maximum théorique. Même si on ne lit que 10 000 trames (1/32 du maxi)
par seconde, on a:
2000 tours par minute, donc 2000/60 tours par seconde. donc 2000 * 360 / 60 degrés par
seconde, donc 12 000 degrés par seconde. En lisant 10 000 fois par seconde, très loin
des possibilités du processeur, on asservit la position tous les 1.2 degrés.
Il est donc toujours possible de réagir assez vite même si on ne lit pas tous les fronts
AB. En plus, quand on approche du point de destination, on peut ralentir. Et plus on
ralentit, moins la rotation du mandrin entre 2 mesures est importante. Et quand on est
presque à l'arrêt, on atteint une résolution très importante. Bref, le processeur se
tourne les pouces et c'est déjà largement suffisant.
Inconvénient: absolu, c'est bien, mais ça ne lit que la position sur un tour.

- Les absolus multitours. En rotatif, c'est un absolu normal couplé à un compteur de tours
qui est lui-même basé sur un encodeur sommaire. Le compteur de tours a soit une pile qui lui
permet de compter les tours même en l'absence d'alimentation, soit un système à base d'aimant
pour générer l'électricité nécessaire. Donc quand vous rallumez la machine, elle lit le compte
tours puis calcule la position angulaire et par conséquent sait où elle est et n'a pas besoin
de "faire le zéro".
On peut noter aussi qu'une autre manière de faire un absolu multitours est d'utiliser 2
absolus mono tour. Un des deux avec un réducteur à engrenages. Par exemple, si je mets
à l'un des deux une réduction de 1/100, alors je pourrai dire que le nombre de tours
est 100 fois le nombre de tours réduit. En combinant le nombre de tours et l'angle,
on obtient un encodeur 100 tours qui a la même précision. Si le pas de la vis à billes
est de 5mm, on peut donc avoir la position absolue même au démarrage sans remettre à 0.

Du point de vue vitesse max, j'ai fait récemment un prototype d'encodeur 18 bits. Je viens
de vérifier, la fréquence maxi d'entrée est de 100 kHz. Si on utilise une roue codeuse
magnétique à 32 poles, ça fait 100 000 / 32 = 3000 tours par SECONDE de rotation
maximale. L'encodeur fonctionne donc jusqu'à 180 000 tours par minute. Il y a de quoi voir venir.

Bon, maintenant, la question de la gestion par le PC. À mon avis, le PC ne peut rien faire
en temps réel. La carte de commande doit tout faire et la communication avec le PC ne
servir qu'à envoyer des commandes (GCode) et recevoir des réponses. 3000 ns (donc 3µ),
ça me paraît bien peu. Vous êtes sûr de vos chiffres? Je dirais plutôt de l'ordre de la
milliseconde. Par exemple si la connexion série fonctionne à 115200 (ma fraiseuse Charly4U,
c'est même moins que ça), alors il faut en gros 10µs pour transmettre 1 bit. Donc pour
transmettre une commande GCode de 20 caractères, 200µs (en série, 8 bits + 1 start bit
+ 1 stop bit = 10 bit par byte). Compte tenu du temps de traitement de la commande,
un temps de latence d'au moins 300 ms m'étonnerait moins.
0.33 MHz est clairement hors de portée d'un port série. Ce qui se passe donc, c'est que
le PC envoie une ligne de GCode, la carte la traite et prévient le PC quand elle a fini.
Le PC envoie la ligne suivante, et ainsi de suite. Enfin c'est comme ça que je l'imagine
du moins.

Voilà. Ceci dit, je n'ai pas encore dessiné la carte, mais je vois en gros comment je
la ferai.

Sur le transversal c'est un peu compliqué à cause du peu d'espace disponible et aussi
parce qu'on ne trouve pas facilement des vis à billes de 8mm.

Si, ça existe. Le lien suivant indique même des vis de 3mm de diamètre. Et le 8 existe.

http://www.kssballscrew.com/us/pdf/catalog/PBS_SG.pdf

Et là, il y en a de 8 x 80, 110, 140 qui pourraient convenir. Je je connais pas le prix.

http://www.linearpositioningsystems.com/sg-precision-ball-screw-listing.html

Bon, ça commence à faire long... quand je commence à déblatérer, on ne peut plus
m'arrêter. Mais le pieu m'appelle. À bientôt!

Élodie.

Bonjour
Voici en gros les différents noms des organes d'un tour.

Pour l'air comprimé, ce n'est pas recommandé car ça envoie des débris de limaille dans les glissières et c'est la cause d'une usure plus rapide.
Comme il faut éviter certaines graisse ou huiles pour les mêmes raisons.

Bonsoir Elodie,

Alors là chapeau ... J'ai pas tout compris et je vais relire ça demain matin.

Les 3000ns c'est le temps de latence obtenu par mon PC après avoir éxécuté le latency test de LinuxCNC.
Un extrait du manuel intégrateur :
"Alors, comment interpréter les résultats? Si le résultat de Max Jitter est en dessous d’environ 15-20 ms (15000-20000 nanosecondes),
l’ordinateur pourra donner d’excellents résultats pour la génération logicielle des pas. Si le temps de latence est à plus de
30-50 microsecondes, de bons résultats seront obtenus, mais la vitesse maximum sera un peu faible, spécialement si des micropas
sont utilisés ou si le pas de la vis est fin. Si les résultats sont de 100mS ou plus (100,000 nanosecondes), alors le PC n’est pas un
bon candidat à la génération des pas. Les résultats supérieurs à 1 milliseconde (1,000,000 nanosecondes) éliminent, dans tous les
cas, ce PC pour faire tourner LinuxCNC, en utilisant des micropas ou pas."
Normalement le temps de latence est inférieur à la période de base.

Je me sers uniquement d'une phase parce que, pour simplifier le cablage de mon tour, j'ai pris l'option de ne tourner que dans un sens.
Juste marche/arrêt et une boite mécanique à 6 rapports.

Carlos

Carlos

Bonjour!

Je n'ai pas tellement le temps maintenant, mais il semble qu'il y ait quelques confusions dans votre message.

15 - 20ms (15000-20000 nanosecondes)

Ce ne sont pas les mêmes nanosecondes qu'au Japon, alors.
Ici, 15-20 ms = 15 000 ~ 20 000 µs (microsecondes) = 15 000 000 ~ 20 000 000 ns.

Si les résultats sont de 100mS ou plus (100,000 nanosecondes)

De la même façon, 100 ms = 100 000 000 nanosecondes.

Les résultats supérieurs à 1 milliseconde (1,000,000 nanosecondes)

Là, c'est juste.

En ce qui concerne la latence, voici un cas concret: Je sors une ligne de GCode d'un de mes
fichiers.
G3 X33.1 Y-49.0 I33.0 J-49.0
Cette ligne fait 28 caractères, et encore les décimales sont toutes à 0. C'est potentiellement beaucoup
plus. En admettant que la liaison série est à 115200, ce qui est rarement le cas dans les systèmes
industriels, il faut alors:
28 x 10 / 115200 = 2.43 ms pour l'envoyer. Ah oui, je n'ai pas compté la fin de ligne à envoyer aussi.
Bon, disons 2.5 ms. Il est évident que mêne si le PC a une latence très courte, rien ne peut se passer
avant l'envoi complet de la ligne. Je pense avoir montré plus haut qu'il est impossible que ce soit le
PC qui gère les moteurs directement, tout se passe dans la carte. Donc elle doit attendre une commande
complète avant de l'analyser (disons 1 ms aussi) et l'exécuter. En bref, on est dans les quelques ms,
pas dans les micro ni les nano secondes.
Sur la fraiseuse Charly4U, on tourne à 38kbps, donc la latence sera 3 fois plus longue.

Ah oui, en me relisant, je m'aperçois que j'avais oublié un morceau de ce que je voulais dire.
Je m'auto-cite:

On peut noter aussi qu'une autre manière de faire un absolu multitours est d'utiliser 2
absolus mono tour. Un des deux avec un réducteur à engrenages. Par exemple, si je mets
à l'un des deux une réduction de 1/100, alors je pourrai dire que le nombre de tours
est 100 fois le nombre de tours réduit. En combinant le nombre de tours et l'angle,
on obtient un encodeur 100 tours qui a la même précision. Si le pas de la vis à billes
est de 5mm, on peut donc avoir la position absolue même au démarrage sans remettre à 0.

À la fin, je voulais dire que si la vis à billes est au pas de 5mm, alors on a la position
absolue sur 100 toures même au démarrage, donc position absolue sur 500 mm.
Mais il est plus simple de faire un seul guide linéaire.

Ah oui, pendant que j'y suis, cette méthode est utilisable si le jeu du réducteur est
inférieur à la moitié de son rapport. Dans cet exemple précis (100 tours), le jeu doit être
strictement inférieur à 1/200 de tour, soit 1.8 degré. Mais il vaut mieux pour être sûr
que ça marche que ce soit encore moins. Par exemple 1 degré.

Élodie.

Re!

Voici en gros les différents noms des organes d'un tour.
[ image ]
Pour l'air comprimé, ce n'est pas recommandé car ça envoie des débris de limaille dans les glissières et c'est la cause d'une usure plus rapide.
Comme il faut éviter certaines graisse ou huiles pour les mêmes raisons.

Merci. Je vois, c'est ce que je pensais. Le traînard est donc ce que j'appelais le chariot.
Donc c'est bien cette pièce (tablier) que je compte changer complètement. En alu anodisé, ça fera chic.

Élodie.

Bonjour
Oui je pense qu'il y a moyen de refaire cette pièce avec les moyen dont tu dispose ça devrait le faire.Tu as donc au vu des photos une crémaillière (la rangée de dent que l'on voit vissée sous le banc) pour une avance manuelle et une vis mère pour une avance automatique je ne voit pas de barre de chariotage en dessous de la vis mère.Sur les tours qui en sont équipés c'est très utile pour éviter une usure de la vis mère qui dans ce cas là ne sert que pour les filetages.

Bonjour

@ Elodie :

"le PC envoie une ligne de GCode, la carte la traite et prévient le PC quand elle a fini.
Le PC envoie la ligne suivante, et ainsi de suite. Enfin c'est comme ça que je l'imagine du moins."
--> Ce mode de fonctionnement est par exemple celui d'une carte arduino contenant le logiciel GRBL et connectée sur un port USB.
Sur le PC,  il y a un 2ème logiciel le GRBL-Controller qui attend effectivement la fin du Gcode en cours.
Problème : GRBL ne connait pas à ce jour les quelques gcodes utilisés pour les filetages sur un tour ...
On retrouve ce mode de fonctionnement sur d'autres cartes utilisant le port USB. Le traitement des Gcodes est intégré dans des PIC.
Là encore, beaucoup ne connaisse pas le G76 ...
--> Ce mode de fonctionnement n'est pas celui de LinuxCNC, ni de Mach3.

"Ce ne sont pas les mêmes nanosecondes qu'au Japon"
--> Rassurez-vous les unités de temps sont universelles.

"Il semble qu'il y ait quelques confusions dans votre message."
--> La confusion est effectivement présente dans l’extrait du manuel de l’intégrateur LinuxCNC.
Pour que ce texte  soit cohérent, Il faut y  interpréter « ms » comme étant des microsecondes « µs » et non pas des millisecondes « ms ».

"G3 X33.1 Y-49.0 I33.0 J-49.0
Cette ligne fait 28 caractères, et encore les décimales sont toutes à 0. C'est potentiellement beaucoup plus.
En admettant que la liaison série est à 115200, ce qui est rarement le cas dans les systèmes industriels, il faut alors:
28 x 10 / 115200 = 2.43 ms pour l'envoyer.
Il est évident que mêne si le PC a une latence très courte, rien ne peut se passer avant l'envoi complet de la ligne"
-->Le temps de latence sert à mesurer la capacité temps réel du PC. Je confirme qu’il s’agit bien dans mon cas de 3000ns ou 3 µs.
A partir de cette valeur, LinuxCNC propose une valeur période de base de 20 µs ce qui correspond à une fréquence de pas de 50KHz.
--> Je ne pense pas qu'on puisse faire une corrélation entre la période de base du système qui représente le temps nécessaire à faire un pas et le temps nécessaire à l'envoi d'une ligne gcode.
--> LinuxCNC ne tourne pas sur un port série ou USB mais uniquement sur le port // et il intègre un noyau temps réel dur (RTAI) dont les performances sont étonnantes (quelques dizaines de µs).
--> Les versions embarquées de LinuxCNC s'appellent Machinekit. Elles utilisent des noyaux temps réel moins performants (Xenomai et RT-PREEMPt).
Ex : Avec une carte Rasbberry Pi2 + Machinekit (noyau temps réel RT-PREEMPT) j'obtiens une latence qui monte facilement à 100µs. J'imagine malheureusement que la fréquence de pas doit chuter proportionnellement.

Carlos

Histoire de continuer à discuter sur les filetages, il est possible de les réaliser sur une fraiseuse CNC équipée d'un 4ème axe.
On monte l'outil à fileter sur l'axe Z (ou une fraise ayant un profil adapté), et on utilise le Gcode G01 pour synchroniser la rotation du 4ème axe avec le déplacement de l'outil. L'utilisation d'un 4ème axe permet de ne pas utiliser les gcodes spécifiques au tournage.
Avec ce montage, le codeur n'a plus d'utilité (sauf si l'on considère que la perte des pas est trop risquée) et, cerise sur le gateau, on connait en permanence le positionnement angulaire de la pièce ce qui permet de faire plusieurs filets ou accessoirement de positionner le départ du filetage par rapport à une réference angulaire de la pièce



Ayant un tour à disposition, je n'ai pas fait de réel filetage avec ce 4ème axe, mais uniquement quelques essais d'usinage d'engrenages hélicoidaux histoire de me faire la main sur leur programmation. Quelques lignes de Gcode suffisent pour réaliser les pignons ci-dessous.



Ces usinages sont des  pseudo filetages avec un grand pas et autant de filets qu'il y a de dents.

Carlos