Variation avance intempestive axe A

[Inox 18]

Bonjour,

Lors d'un fraisage avec axe rotatif A, après quelques lignes de Gcode, la vitesse d'avance de l'axe A chute de +/- 500 %.
Vitesse initiale à 500 mm/min puis chute à une vitesse variant de 1 à 12 mm/min. Cela se produit dans un processus en cours sans raison apparente.
J'ai essayé avec une autre config de chemin d'outil et c'est pareil. Aucun souci sur les autres axes.
Fraiseuse chinoise 6040 4 axes sans marque
Ma version Mach 3 est R 3.041

Merci pour vos conseils

 

[PL50]

Essaye de permuter le drive du A avec celui d'un autre axe.
A+

 

[dh42]

Salut,

Dans le menu config/toolpath, vérifie que "Use radius for feedrate" soit décoché.

++
David

 

[Inox 18]

Merci pour ces éclaircissements, je vais vérifier cela.
J'ai remis en route une pièce similaire avec de nouveaux Gcodes en supposant que mon STL de base n'était pas bon ou que le générateur de Gcodes faisait des caprices, mais cela me fait pareil : Il y a +/- 18000 lignes de codes et le problème survient vers la ligne 3000.
Il est vrai qu’avant cette ligne, il n'y avait que du fraisage cylindrique rectiligne ou surfaçage ; c'est quand des différences de rayons arrivent que le problème surgit.

Désolé pour mon vocabulaire qui n'est peut être pas approprié, je découvre. Avant, je travaillais sur une Roland MDX 40 A qui a son propre logiciel de chemins d'outils (Modela Player) et c'est totalement différent.

 

[dh42]

En fait le "Use radius for feedrate" sert à compenser la vitesse de rotation de l'axe rotatif en fonction du rayon (et donc de la position en Z de l'outil), ça permet de garder une vitesse d'avance constante à la surface de la pièce en fonction du rayon, dans le soft de FAO,, tu donnes une vitesse d'avance en mm/min, sans te soucier du Ø usiné et elle doit être convertie en vitesse de rotation de l'axe par Mach3 en fonction du rayon de la pièce. En gros plus la fraise s'approche du centre de l'axe rotatif (le 0 en Z) et plus la rotation de l'axe doit être rapide pour avoir la même vitesse d'avance linéaire à la surface de la pièce.

Pour que ça fonctionne correctement il est impératif que le 0 en Z soit pris à l'axe de rotation .. et que la carte d'axe (si tu es en USB ou ETH) sache gérer ça, ce qui n'est pas garanti avec une carte d'axe Chinoise !

++
David

 

[Inox 18]

Ok David, merci. Je testerai tout ça.
Dans mes paramètres de Gcodes, le zéro de l'axe Z est au sommet de la pièce et non au centre de l'axe de rotation, donc à voir si le problème ne réside pas là et je vérifierai également le "Use radius for feedrate" car effectivement, une vitesse de rotation n'est pas pareille qu'une vitesse d'avance suivant le diamètre.
Par contre, j'ai remarqué que le changement de vitesse de l'axe A n'était pas constant pour un même diamètre ; il variait à chaque passe.

 

[dh42]

Par contre, j'ai remarqué que le changement de vitesse de l'axe A n'était pas constant pour un même diamètre ; il variait à chaque passe.

Tu es sur qu'il ne perd pas tout simplement des pas ? .. si je ne me trompe pas, sur les 6040 4axes, ce n'est pas un réducteur à forte démultiplication sur l'axe A, mais une simple démultiplication à courroie avec un rapport de l'ordre de 1:3 ou approchant, si le moteur n'a pas assez de couple, ça peut simplement trop forcer et perdre des pas.

Il faudrait tester ton GCode en l'air (sans matière à usiner) pour voir si ça change quelque chose.

le zéro de l'axe Z est au sommet de la pièce et non au centre de l'axe de rotation

oui, ça peut y jouer, tout dépend comment ta carte interprète ça ... en 4 axes, il vaut mieux travailler avec le 0 à l'axe, ça t'évitera bien des complications ! (et c'est la norme)

Edit: tu utilises quel soft pour produire ton GCode 4 axes ?

++
David

 

[Inox 18]

Mon axe A est à réducteur à vis sans fin, donc à moins qu'un débrayage de sécurité n'y soit présent entre la vis et le moteur, il ne peut "patiner".
L'opération en cours ne demandait que peu d'effort ; matière bois semi dur, fraise 3 mm 2 lèvres HSS, avance 500 mm/min profondeur de passe et pas 1 mm. La broche fait 2200 W et tourne à 10.000 T/Min
L'axe A fait bien ses 360° avant d'entamer la couche suivante.

Il est vrai que c'est mieux de mettre le 0 à l'axe et plus logique.

J'utilise Desk Proto pour générer les Gcodes.

 

[Inox 18]

Voici ce que j'ai comme config Toolpath.
C'est bon ou il faut changer des paramètres ?
Merci

 

[dh42]

C'est bon ou il faut changer des paramètres ?

C'est OK.

Mon axe A est à réducteur à vis sans fin, donc à moins qu'un débrayage de sécurité n'y soit présent entre la vis et le moteur, il ne peut "patiner".

Les pertes de pas, ce n'est pas la courroie qui patine, c'est le moteur lui-même qui "saute" des pas si ça force trop.

++
David

 

[Inox 18]

OK, merci.
J'ai refait un test avec le 0 à l'axe rotatif, mais c'est pareil.
J'en suis à me demander si ce n'est pas dans le Gcode vu que Mach 3 ne fait que "lire" et interpréter des informations.

 

[dh42]

met ton Gcode en PJ, je regarderais....

++
David

 

[Inox 18]

Voici mon fichier Gcode et à toutes fins utiles le stl correspondant

 

[dh42]

Bon et bien rien d'anormal dans le Gcode, jamais la vitesse pour le A ne descend en dessous de 852.6, au contraire, elle augmente pour atteindre 2134.6 à la ligne 13183 et même finir à 2676.4 en fin de Gcode.

Seule chose qui me surprend un peu, c'est des vitesses d'avance données avec une décimale, mais j'ai essayé dans Mach3 et ça ne semble pas le gêner. C'est toujours sur des rotations, les vitesses de déplacements linéaires n'ont pas de valeurs décimales, j'en déduis que ton soft gère lui-même l'augmentation de la vitesse en fonction du Ø usiné.

Si tu as un moyen de désactiver cette gestion de la vitesse proportionnelle dans ton soft de FAO, ce serait bien de le tenter de façon à n'avoir que des valeurs entières pour F, car si à l'évidence Mach3 n'en est pas perturbé, on ne peut pas être sûr que ta carte d'axe soit du même avis, surtout si c'est une carte Chinoise .... mais je doute quand même, car dés le début du Gcode il y a des rotations avec une vitesse de 653.5, par contre à partir de la ligne 2946, on passe a une vitesse de 1128.9 pour A ... avec les cartes Chinoises on peut s'attendre à tout en matière de bug ..

Il se peut aussi que la vitesse soit trop élevée pour ton 4ieme axe et justement, qu'il perde des pas si on lui demande de tourner trop vite.

++
David

 

[dh42]

re

Je viens juste de voir un truc que je n'avais pas vu en 1iere lecture de ton GCode, ton soft de FAO utilise un G93 avant chaque rotation de l'axe A. Le G93 indique qu'il faut utiliser un autre mode d'interprétation de la vitesse d'avance. En mode "normal" (G94), la valeur après le F est interprétée comme une valeur d'avance en mm/min mais en mode G93 on passe en mode inverse du temps.

G93 - Passe en mode inverse du temps. Dans le mode vitesse inverse du temps, le mot F signifie que le mouvement doit être terminé en [1/F] minutes. Par exemple, si la valeur de F est 2.0, les mouvements doivent être terminés en 1/2 minute.

Donc par exemple, un F1128.9 signifie que le mouvement doit être exécuté en 1/1128.9 minutes, soit 0.00046814 min = 0.028s et ce dans le cas que j'ai regardé, pour faire une rotation de A0 à A2.88, soit ~3/100ieme de seconde pour une rotation de presque 3° .... c'est plutôt brutal !!!

G0 A0.000 'avance rapide A = 0°
G0 Z15.500
G1 Z10.500
G1 Y-17.285 Z10.000 F450
G1 Y-23.000 Z9.500
G1 Y-15.860
G1 Y-15.180 Z9.886
G1 Y-14.500 Z10.284
G1 Y-13.820 Z10.580 F600
G93 'mode inverse du temps
G1 Z10.567 A2.880 F1128.9 ' rotation de 0 à 2.880° en 0.028s
G94 'retour au mode V en mm/min
G1 Y-14.500 Z10.270 F600 'avance à 600mm/min en déplacement linéaire
G1 Y-15.180 Z

Donc 2 choses possibles, soit ton 4ieme axe déclare forfait pour tourner à cette vitesse et le moteur perd des pas, soit tout simplement la carte d'axe ne sait pas gérer correctement les vitesses en mode G93 et fait n'importe quoi de temps en temps. (Mach3 sait gérer ça, mais la carte Chinoise, c'est moins sur)

Ne connaissant pas ton soft de FAO, je ne sais pas si on peut changer ça dans les réglages et forcer l'utilisation du mode G94 pour tout (dans ton code, le G94 est utilisé pour les déplacements linéaires), mais si tu trouves un réglage de ce genre, ça vaudrait la peine d'essayer.

Bon, le soleil va se lever, il est temps que j'aille me coucher

++
David

 

[Inox 18]

Merci pour ta patience et tes recherches David. Je vais voir tout ça en détail avec mon fils qui est plus subtil dans ce genre de technologie.
Je reviendrai sans faute sur les résultats obtenus

 

[Inox 18]

L'analyse et les remarques de David ont été bien utiles à comprendre le problème. Après quelques recherches et essais, le souci semble réglé.
Une mise à jour de Mach 3 s'imposait.

D'autre part, nous avons trouvé une publication concernant ce problème apparemment connu sur Desk Proto.
Je cite :

5.8 - The rotation axis (4th axis) is rotating far too slow / far too fast.
Feedrate for rotation axis toolpaths is a difficult issue.
In standard G-code the Feedrate is defined only in linear speed units (like mm/sec, inches/min, etc). The G-code definition does not
include a rotation speed command. This means that the controller needs to calculate the correct rotation speed that is needed to
reach the prescribed linear feedrate: the closer to the rotation axis, the higher the rotation speed that is needed.
Unfortunately this is a complicated calculation and many controllers do not conform to the ISO G-code specifications in this matter.
For an example see forum issue Rotation axis speed in Mach3.

A more elaborate discussion on this subject can be found on forum issue A axis feed rates.
The good news is that in DeskProto V7 this issue has been solved: DeskProto V7 supports a feature called Inverse Time Feedrate. When
using this feature (code G93) the F word in the NC file does not define the speed, instead it defines the time needed to complete
the movement (or in fact the inverse of the time). The controller then can simply calculate the correct speed for each of the axes
that need to move. So when your machine supports G93 we advise to use that option in DeskProto in order to make your machine move at
the correct speed. Note that in June 2023 a bug has been fixed in the feedrate calculation: make sure to use a DeskProto build from

June 23 or later.
One more setting that you can check in case of a slow rotation axis is the maximum velocity for that axis as defined in the control
sofware. This value generally speaking needs to be higher than for the three linear axes. For Mach3 users: the Mach3 user interface
is confusing (wrong) on this point. For more information see the Mach3 forum link just given.

Source : https://www.deskproto.com/support/faq.php

Et voici la pièce d'essai réussie sans rien changer au fichier et au Gcode

Merci David

 

[dh42]

Salut,



Tu as quelle version de Mach3 maintenant ?

++
David

 

[Inox 18]

Hello,

J'avais la version R3 041 et la mise à jour est la version R3 043.066.
Jusqu'ici, pas de souci, mais j'ai vu que d'autres en avaient eu et ont préféré la version 062

 

[dh42]

Jusqu'ici, pas de souci, mais j'ai vu que d'autres en avaient eu et ont préféré la version 062

Oui, la .066 à quelques bugs, en particulier avec les script Basic qui, parfois, ne se terminent pas, mais c'est très aléatoire, chez certains, ça fonctionne, chez moi, tous mes scripts (notamment le palpage) me posent des problèmes avec la .066 ; problèmes aussi avec le référencement ainsi qu'avec la broche qui "oublie" de démarrer après un changement d'outil, en sortant un message "script error".

Si tu as des problèmes, tu peux trouver la 3.043.062 ici

Software: Mach

Warp9 Tech Design, home of the ESS and USS SmoothStepper motion control boards for Mach 3 and Mach4

warp9td.com

++
David

 

[Inox 18]

Ok, on va sans doute repartir sur la version 062 qui semble plus stable ; cela évitera de devoir à terme reparamétrer tout le bazar.
Reste plus qu'à m'inscrire à un cours d'anglais