Variation avance intempestive axe A

I

Inox 18

Nouveau

• 7 Fev 2024

• #1

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

 

P

PL50

Compagnon

• 7 Fev 2024

• #2

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

 

D

dh42

Compagnon

• 7 Fev 2024

• #3

Salut,

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

++
David

 

I

Inox 18

Nouveau

• 7 Fev 2024

• #4

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.

 

D

dh42

Compagnon

• 7 Fev 2024

• #5

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

 

I

Inox 18

Nouveau

• 8 Fev 2024

• #6

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.

 

D

dh42

Compagnon

• 8 Fev 2024

• #7

Inox 18 a dit:

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.

Cliquez pour agrandir...

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.

Inox 18 a dit:

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

Cliquez pour agrandir...

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

 

I

Inox 18

Nouveau

• 8 Fev 2024

• #8

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.

 

I

Inox 18

Nouveau

• 8 Fev 2024

• #9

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

 

D

dh42

Compagnon

• 8 Fev 2024

• #10

Inox 18 a dit:

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

Cliquez pour agrandir...

C'est OK.

Inox 18 a dit:

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".

Cliquez pour agrandir...

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

 

I

Inox 18

Nouveau

• 8 Fev 2024

• #11

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.

 

D

dh42

Compagnon

• 8 Fev 2024

• #12

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

++
David

 

I

Inox 18

Nouveau

• 10 Fev 2024

• #13

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

 

Fichiers joints

• Pendule 03#1_Ébauche.txt

  287.4 KB · Affichages: 28
• Pendule 03.stl

  503.1 KB · Affichages: 25

D

dh42

Compagnon

• 10 Fev 2024

• #14

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

 

D

dh42

Compagnon

• 10 Fev 2024

• #15

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

 

Dernière édition par un modérateur: 10 Fev 2024

I

Inox 18

Nouveau

• 11 Fev 2024

• #16

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

 

I

Inox 18

Nouveau

• 14 Fev 2024

• #17

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

 

D

dh42

Compagnon

• 14 Fev 2024

• #18

Salut,



Tu as quelle version de Mach3 maintenant ?

++
David

 

I

Inox 18

Nouveau

• 14 Fev 2024

• #19

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

 

D

dh42

Compagnon

• 14 Fev 2024

• #20

Inox 18 a dit:

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

Cliquez pour agrandir...

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

 

I

Inox 18

Nouveau

• 15 Fev 2024

• #21

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

 

I

Inox 18

Nouveau

• 31 Jan 2026

• #22

Bonjour à tous,

Comme dit l'adage, "pas de nouvelles, bonne nouvelle" et c'est ce qui explique mon silence depuis mon dernier message.
Mais ..... jusqu'à hier, après l'usinage d'une pièce en bois, je recommence un processus afin de refaire la même à l'identique et là la machine a "pété un câble"

Sur l'axe Y le moteur semble avoir perdu des pas et est rentré droit dans la contre pointe de l'axe rotatif. Le travail en était +/- à 50% quand c'est arrivé.

Par le passé, il m'est arrivé, mais très rarement d'entendre des pertes de pas au démarrage ; j'arrête tout et je recommence et là tout se passe bien.
Des sauts de pas arrivent parfois quand je change la vue du déplacement de la fraise dans la fenêtre en bas à gauche.
Je n'ai pas de points durs sur l'axe en question et la machine n'a travaillé que du bois sans jamais forcer.

Je soupçonne la carte de contrôle qui serait de facture moyenne et de génération assez ancienne. Apparemment, elle n'aurait pas de "bloc mémoire" et les infos viendraient directement du PC .... à voir ?

Certains d'entre vous auraient ils déjà rencontré ce genre de problème et quelle solution avez vous trouvé ?
Existe t'il des cartes plus performantes et fiables que je pourrait mettre à la place de celle d'origine pour autant que le problème vienne de là ?

Pour info, je tourne sur un PC en Windows 7 exclusivement dédié à la machine.
Processeur : IS-4460S , 2.9 GH , 4 CPU , Ram 8 GB
Carte contrôleur CNC : BSMCE04U-PP
BIT Sensor.com

Je tourne sur Mach 3 version R3 043.062

C'est une machine chinoise 4 axes 6040 sans marque avec broche de 2,2 Kw

D'avance, je vous remercie pour vos réponses

PS: Ci dessous, photo de ma carte et en dessous, la même trouvée sur le net sans le fatras de câbles.

 

D

dh42

Compagnon

• 1 Fev 2026

• #23

Salut,

Inox 18 a dit:

Je soupçonne la carte de contrôle qui serait de facture moyenne et de génération assez ancienne. Apparemment, elle n'aurait pas de "bloc mémoire" et les infos viendraient directement du PC .... à voir ?

Cliquez pour agrandir...

Ce n'est peut être pas la meilleure des cartes, mais ce n'est pas non plus une cata comme certaines cartes Chinoises (genre NVEM et cie)

J'ai entendu parler de problèmes d'entrées/sorties qui grillent, mais rien à propos de pertes de pas intempestives. Malgré son bas prix, cette carte n'est pas si mal.

Et si, elle a un buffer (ce que tu appelles bloc mémoire), sinon ça ne pourrait pas fonctionner du tout.

Dans le pire des cas, tu peux toujours la remplacer par une neuve vu son prix ridicule, mais je ne pense pas que le problème vienne d'elle.

Il y a d'autres pistes possibles, surtout sur une machine qui commence à avoir de la bouteille ... un des problème rencontré sur les 6040 Chinoises, c'est la qualité des câbles moteurs ; les fils arrivent parfois à casser à l'intérieur du câble à force d'être pliés et dépliés dans les chaines de câbles lors des mouvements, et suivant la position de l'axe le contact au niveau de la cassure ne se fait plus et le moteur s'arrête (si coupure d'un fil STEP) ou part dans le mauvais sens (si coupure d'un fil DIR). Donc elle pourrait littéralement avoir "pété un câble" comme tu dis !

Vérifie également les serrages des connexions, avec le temps ça peut aussi bouger.

Un autre problème, très aléatoire, peut être lié à un parasitage du signal, particulièrement avec un VFD qui émet pas mal de parasites, mais si tu n'as rien changé à ta config, ce serait surprenant que ça ne le fasse que maintenant.

Inox 18 a dit:

Existe t'il des cartes plus performantes et fiables que je pourrait mettre à la place de celle d'origine pour autant que le problème vienne de là ?

Cliquez pour agrandir...

Oui, mais ce n'est pas du tout le même ordre de prix (200€ ou plus) ... et il faudrait probablement refaire tous le boitier de contrôle car elles sont plus volumineuses et risquent d'être difficiles à loger dans le petit boitier de ce type de machine.

++
David

 

I

Inox 18

Nouveau

• 1 Fev 2026

• #24

Merci David, je vais vérifier tous les câbles et connections.

Le VFD se trouve dans le même boitier à quelques cm de la carte. Je ne sais pas si une petite tôle entre les deux pourrait avoir une influence sur d'éventuels parasites ?
J'ai remarqué aussi qu'en passant l'aspirateur pour évacuer les copeaux de bois pendant le travail, la machine n'est pas perturbée mais je reçois régulièrement une petite décharge genre électrostatique. Je vais voir pour relier le châssis à la terre, cela apportera peut être un mieux.

Le machine a quelques années mais tourne peu. je dirais +/- 4 heures par semaine max sur de petites pièces.

 

Dernière édition: 1 Fev 2026

D

dh42

Compagnon

• 2 Fev 2026

• #25

Inox 18 a dit:

Je ne sais pas si une petite tôle entre les deux pourrait avoir une influence sur d'éventuels parasites ?

Cliquez pour agrandir...

Je doute un peu mais je ne peux pas l'affirmer.

Mais ça marchait avant, donc je ne vois pas pourquoi ça se mettrait d'un coup à déconner ..

Inox 18 a dit:

J'ai remarqué aussi qu'en passant l'aspirateur pour évacuer les copeaux de bois pendant le travail, la machine n'est pas perturbée mais je reçois régulièrement une petite décharge genre électrostatique. Je vais voir pour relier le châssis à la terre, cela apportera peut être un mieux.

Cliquez pour agrandir...

oui, j'ai eu le même genre de désagrément, sauf que c'était de bonnes décharges très désagréables quand je touchais l'embout métallique (buse) du tuyau !! ... c'est le frottement des copeaux de bois sur le plastique du tuyau de l'aspi qui provoque ça ... c'est le tuyau qu'il faudrait mettre à la terre. (et oui, le châssis d'une machine DOIT être à la terre, de même que la carcasse du boitier du controleur)

Les décharges électrostatiques peuvent tout à fait perturber le fonctionnement, ça m'est déjà arrivé sur une de mes CN

++
David

 

I

Inox 18

Nouveau

• 2 Fev 2026

• #26

Merci pour ces précisions.
Je vais déjà régler toutes ces potentielles sources de soucis.

 

P

PL50

Compagnon

• 2 Fev 2026

• #27

Et verifie aussi que tes tiges de glissement des douilles à billes n'ont pas avalé de sciure car ça peut provoquer des points durs.
Idem pour les vis à billes et leurs ecrous....
Des fois les pannes sont débiles, ma 6040 s'arrètait quand le ventilo du pc demarrait!!!!

 

I

Inox 18

Nouveau

• 3 Fev 2026

• #28

J'ai fais les vérifications comme préconisées par David et PL50

Les rails de glissements sont propres et pas de points durs. Pour l'axe X et Z, il y a des soufflets cache poussières qui semblent bien remplir leurs rôle. Pour l'axe Y les rails sont sous la table.

Connections toutes bien serrées et câbles en bon état apparent. Mon souci venait de l'axe Y et les câbles ne sont pas soumis à des torsions ou plis.
Vérification des connections dans le boitier de commande et plus particulièrement ceux de la carte.
J'ai l'impression que ce boitier a été assemblé un vendredi à 16H juste avant le W-E car sur les 23 câbles qui arrivent aux borniers, 8 n'étaient pas assez dénudé et la vis de serrage pressait sur la gaine en plastique. Les contacts ne devaient pas être terribles.

J'ai également relié le châssis de la fraiseuse ainsi que le boitier de commande à la terre.

On verra pour la suite, mais cela fait déjà pas mal de choses potentiellement problématiques qui sont réglées.
Le souci c'est que ce ne sont pas des pannes récurrentes.