Arc de rayon nul

Bonjour,
J'utilise Mach3 depuis plousieurs années sur le même matériel.
Aprés des mises à jour de programmes, j'ai le message "Arc de rayon nul" à chaque chargement de programme. Le programme s'arrête sur une ligne d'arc. Si je remplace l'arc par une droite, c'est à la ligne suivante d'arc que le programme se bloque.
Bien sûr, j'ai tout vérifié: config géné en incrémental, remplacement des I,J par le R classique, et même ajouté des décimales (3) sur les cotes.
Et le pire est que j'ai le problème sur deux ordis et ma dernière machine.
Je ne sais plus quoi faire.
Une idée ?

Gipet (machine à macarons)

Salut,

Tu peux mettre un GCode qui pose problème en PJ que je regarde ? (zip le pour qu'il passe sur le forum)

Tu crée ton GCode avec quel soft ?

++
David

Bonjour,
Voici un exemple de programme utilisé (depuis plusieurs années)
Je défini une série de positions en G90 et charge un sous-programme à chque position.
Dans cette dernière version, j'ai même utilisé G91.1 au lieu de G91 sans résultat.
J'ai même ajouté 3 décimales pour éviter les erreurs de tolérance.
A chaque fois, le programme bute au chargement sur la ligne 20.
Si je remplace l'arc par une droite, le programme bute alors sur l'arc suivant à la ligne 40.
A noter que si je remplace I,J par le rayon, j'ai un message différent.
A noter aussi, qu'il me semble (je suis pas sûr) que le problème s'est "transporté" de l'ordi qui me sert à faire les programmes à la nouvelle machine en essai, et qu'elle n'avait pas de problème avant lors des premiers essais.
Merci de regarder ce curieux problème.
.../...
(position 14)
G90 G00 X170.2 Y175 Z-85
M98 P12 Q1

(retour)
N130 G90 G00 X0 Y0 Z0

M30

O12
(macro rond 3 cercles)
N1 M5
N2 G51 X[#1020] Y[#1020]
N10 G91 G0 X0 Y-3 Z[#1030]
N8 M3 S[#1040]
N10 G4 P0.5
N20 G91.1 G2 X-2.898 Y2.223 I0 J3.000 F[#1010]
N30 G91 G0 X-4.8 Y-1.3
N40 G91.1 G2 X-0.273 Y2.071 I7.727 J2.071 F[#1010]
N50 G91.1 G2 X-2.461 Y-7.718 R5 F[#1010]
N60 G91.1 G2 X-1.903 Y3.701 I10.461 J7.718 F[#1010]
N65 G4 P0.2
N67 M5
N70 G91.1 G2 X12.364 Y17.071 Z3 I12.364 J4.071 F[#1010]
N90 G91 G0 X0 Y-15 Z25
N100 G50
M99

Salut,

Bon, et bien ça ne marche pas chez moi non plus

il bloque sur la ligne 20 avec l'erreur "cannot make arc with zero feedrate"

Y manquerais pas la définition de la valeur des variables ?

++
David

Bonsoir,
C'est le message que j'ai en remplaçant I et J par le rayon R.
Je me suis donc posé la question et fait l'essai en remplaçant F[#1010] par une valeur F800 et le résultat est le même.
Maintenant, c'est vrai, j'ai réorganisé les variables.
Je suis bon pour tout reprendre.
Je te tiens au courant

Gipet

si je remplace les variables par des valeurs, ça fonctionne ... excepté que ça ne fait pas un cercle, je pense qu'il y a aussi des pb avec les G91/91.1 (mais j'ai le même résultat quelque soit le mode d'arc choisis   )



en principe, il n'est pas nécessaire de répéter les G91/91.1 : il suffit de les mettre une fois au début du Gcode > G91 mode incrémental pour les G0/G1 et G91.1 mode incrémental pour les G2/G3

++
David

Bonjour,
Cela me fait penser à quelque chose: Depuis le début, j'écris des macros en VB ou les variables sont déclarées automatiquement.
Peut-on les déclarer directement dans le programme G code, au début ? C'est plus logique.
PS: Ton tracé est bon. Ou plutôt il serait bon en retournant l'axe des Y.

Gipet

Salut,

Peut-on les déclarer directement dans le programme G code, au début ? C'est plus logique.

Oui, par exemple:

#1010 = 500

on peut aussi faire des calculs:

#1010 = #1000 + 150

++
David

Je déclarais en début de programme des macros M101, M204 .... pour initialiser les réglages.
En déclarant maintenant directement les variables en début de programme #1010= 1100, #1020= 1.25 ....
je n'ai plus de problème de rayons ! Curieux, cela n'a aucun rapport !
Merci David tu es le roi de Mach3.
Tu as gagné une boite de macarons (si tu me donne ton adresse en MP). Bon, pas tout de suite, un jour ou il fera froid ....

Gipet

je n'ai plus de problème de rayons ! Curieux, cela n'a aucun rapport !

C'est vrai que c'est plutôt étrange ... je suppose que tu utilisais des SetVar() dans tes macros ? ..

++
David

Exemple de macro:

SetVar(1010, 2000)

SetUserLED(1104, 1)

SetUserLED(1101, 0)
SetUserLED(1102, 0)
SetUserLED(1103, 0)
SetUserLED(1105, 0)
SetUserLED(1106, 0)
SetUserLED(1107, 0)

Je ne sais pas si cela est bien écrit et surtout suffisant. Comme cela marche, je ne me suis pas posé plus de question.

Gipet

Bon, j'ai parlé trop vite !
Hier, j'ai des macarons avec un autre programme extrapolé du premier (macarons plus grands avec 3 cercles voir D45.bmp ci-joint) avec le sous-programme suivant:
O12
(macro rond 3 cercles)

N1  G51 X[#1020] Y[#1020]
N10 G91 G0 X-3.8 Y0 Z[#1030]
N8  M3 S[#1040]
N10 G4 P0.2
N20 G91 G2 X6.5 Y-2.7 R3.8 F[#1010]
N25 G91 G2 X-2.7 Y6.5 R3.8 F[#1010]
N30 G91 G0 X0 Y6.3
N40 G91 G2 X0 Y-20.1 I0 J-10.05 F[#1010]
N50 G91 G2 X2.6 Y19.7 I0 J10.05 F[#1010]
N60 G91 G2 X-8.5 Y5.5 R6.3 F[#1010]
N70 G91 G2 X6 Y-31.5 I6 J-15.2 F[#1010]
N80 G91 G2 X0 Y32.6 I0 J16.3 F[#1010]
N65 M5
N80 G91 G2 X0 Y-32.6 Z2 I0 J-16.3 F[#1010]
N90 G91 G2 X0 Y32.6 Z2 I0 J16.3 F[#1010]
N100 G91 G0 X0 Y-10 Z25
N100 G50
M99

Tout c'est "presque" bien passé, hormis le fait que l'arc de rayon 6.3 ligne 60 se faisait de l'autre coté.
A noter que j'avais déja divisé certains arcs pour éviter ce phénomène.
Ce matin, j'ai décidé de supprimer cet arc de 6.3 et d'essayer avec une simple droite.
Et là, le problème d'arc nul est revenu sur la ligne 40 !
Comme j'en ai eu marre, j'ai retracé le dessin en mettant des cotes rondes (D45a.bmp) et en allant au plus simple sans diviser les arcs.
D'où le sous-programme suivant:

O12
(macro rond 3 cercles)

N1  G51 X[#1020] Y[#1020]
N10 G91 G0 X-4 Y0 Z[#1030]
N8  M3 S[#1040]
N10 G4 P0.2
N20 G91 G2 X4 Y4 I4 J0 F[#1010]
N30 G91 G0 X0 Y6
N40 G91 G2 X3 Y-0.461 I0 J-10 F[#1010]
N50 G91 G2 X-7.8 Y5.724 R6 F[#1010]
N60 G91 G2 X4.8 Y0.737 I4.8 J-15.263 F[#1010]
N65 M5
N70 G91 G2 X0 Y0 Z4 I0 J-16 F[#1010]
N100 G91 G0 X0 Y-10 Z25
N100 G50
M99

Et là, le programme fonctionne, mais raconte n'importe quoi !
Tous les arcs sont faux.

Moi, c'est décidé, je me recouche !

Gipet

Finalement, aprés avoir retourné l'axe Y, tout est normal...

Salut,

Tout c'est "presque" bien passé, hormis le fait que l'arc de rayon 6.3 ligne 60 se faisait de l'autre coté.
A noter que j'avais déja divisé certains arcs pour éviter ce phénomène.

Je sais qu'Andy, le créateur de CamBam, avait dit qu'il découpait les cercles en 3 arcs de 120° car certains softs de pilotage (ou simulateurs d'usinage) ne supportaient pas des arcs de plus de 180°. Pour mach3, effectivement, parfois il peut inverser l'arc si on dépasse un certain angle, mais ça ne semble pas être uniquement lié à la valeur de l'angle à décrire, mais aussi de la position (angulaire) du départ de l'arc. J'ai aussi remarqué qu'il pouvait inverser l'arc si celui-ci était vraiment très court (quelque 1/100ieme de mm de long) ; d’ailleurs dans le post pro de Cambam (et d'autre FAO) il y a une option qui permet de remplacer les arcs trop courts (ou avec un rayon trop grand) par des droites.

je ne peux guère t'en dire plus, je ne fais pratiquement jamais de GCode à la main, (ou très simples) et ma FAO ne gère pas les arcs définis via le rayon (R), uniquement les arcs en IJ

Il arrive parfois qu'il mette une erreur du style "le rayon de fin ne correspond pas au rayon de départ" (ou un truc comme ça, je ne me souviens pas du message exact) ; ça arrive si les coordonnées du pt de départ (XY) et du pt de fin de l'arc (IJ) donnent un rayon qui diffère de plus de 0.0025mm (2.5µm) ; ça peut arriver si les valeurs pour XY et IJ n'ont pas suffisamment de décimales. Pour ma part, je travaille toujours avec 4 décimales.

++
David