rognage pièce en sortie d'alésage

[Pierreg60]

Bonjour à tous,
j'ai un petit soucis avec Cambam 1,0 sous linux, lorsque la fraise remonte du fond d'un alésage pour repartir à son point de départ, elle vient rogner la pièce mais pas sur les -3 ou -4 premiers mm, juste quand elle est descends vers les -10 -12.

La vitesse d'avance est de 400mm/m et en faisant une autre pièce avec du 200mm/m le phénomène se produit aussi.
le plan de dégagement est de 3mm.

Avez vous déjà rencontré ce phénomène ?

Merci pour votre aide!

EDIT: voici les liens des 2 fichiers
12x12.cb
HS 3 branches plexi.cb

 

[vince_007]

On ne remonte jamais la fraise sur le bord à la cote finale, normalement on met un rayon d'entrée et de sortie pour s'éloigner du bord.

Je ne connais pas CamBam mais il doit pouvoir le faire.

Pour ton problème, le soucis est à chercher du côté de la géométrie de la machine, il doit y avoir un soucis sur la glissière du Z.

 

[Pierreg60]

Voici une photo du détail

Sur cette photo j usinai la partie extérieure. Et la sortie de la matière était réglé sur tangente 1 ou 2D de mémoire.

 

[dh42]

Salut,

Je ne vois rien d'anormal sur le fichier 12x12 ; en simu tout se passe bien et il y a bien les rayons d'entrée et de sortie.

Et la sortie de la matière était réglé sur tangente 1 ou 2D de mémoire.

1 en entrée, 2 en sortie ; et c'est exprimé en mm par en fraction du diamètre.

Je vais peut être dire une bêtise, mais c'est comme si ça manquait d'accélération et que la fraise partait en horizontal avant d'avoir fini de remonter. (comme un lissage de trajectoire)

Que se passe t'il si tu essai avec un plan de dégagement plus important ?

Qu'a tu en valeur d'accélération sur tes axes ?

++
David

 

[Pierreg60]

pour les axes X et Y j'ai ceci,
MAX_VELOCITY = 50.0
MAX_ACCELERATION = 200.0
STEPGEN_MAXACCEL = 400

Pour le Z j'ai ceci
MAX_VELOCITY = 29
MAX_ACCELERATION = 50.0
STEPGEN_MAXACCEL = 100

Je vais essayer sur un brut tout à l'heure en dégageant plus haut, mais ce qui parait bizarre c'est que le phénomène ne s'est jamais produit avec ma version de cambam sous PC.

 

[Pierreg60]

je viens de refaire la pièce et le rognage apparait toujours.
si j'augmente le rayon tangent en sortie le phénomène disparait.

c'est quand même bizarre même, sous cutviewer le phénomène n'apparait pas!

 

[Pierreg60]

j'ai jamais fait gaffe mais le mode de déplacement y est pour quelque chose ?

 

[speedjf37]

Bonjour,

Quel logiciel de pilotage ?

Si LinuxCnc y a t'il un erreur "runtime"

JF

 

[dh42]

Salut,

j'ai jamais fait gaffe mais le mode de déplacement y est pour quelque chose ?

ce qui parait bizarre c'est que le phénomène ne s'est jamais produit avec ma version de cambam sous PC.

je ne connais pas du tout LinuxCNc, et je ne pense pas qu'il y ai une différence entre le GCode sorti par la version Windows et la version Linux (à condition d'utiliser le même PP bien sur)

Il est par contre possible que tes options ne soient pas réglées de la même manière ; tu peux avoir 'trajectoire exacte' réglée par défaut sur Win et 'Vitesse constante' sur Linux dans ton style par défaut (ou pire, "indéfini" ; et dans ce cas c'est le réglage par défaut du soft de pilotage qui sera utilisé)

Sur Mach3, si le mode de déplacement de l'op d’usinage est sur 'vitesse constante' (donc un G64 est sorti dans le Gcode), les trajectoires sont 'lissées', mais par contre j'ai tj pensé, peut être à tort (et je ne l'ai jamais vérifié) que ça ne lissait que les G1/G2/G3, alors que la c'est des G0 entre la remontée et le déplacement en XY ...

Sur Mach3, il y a une option qui permet de désactiver la VC au delà d'un certain angle. Sur LinuxCNc, le G64 peut prendre des paramètres pour faire la même chose il me semble.

J'ai une feuille de calcul qui me permet de calculer le rayon obtenu en VC en fonction de l'accélération et de la vitesse (en supposant la même vitesse sur les 2 axes)

Avec une V de 1700 mm/min pour le Z (28.33 mm/s) et une acc à 50 mm/s², j'obtiens un rayon de ... 8.03mm !

c'est quand même bizarre même, sous cutviewer le phénomène n'apparait pas!

Oui, il ne gère pas la simulation du G64 ni les accélérations.

++
David

 

[Pierreg60]

Oui j'utilise linuxcnc et aucune erreur runtime, pas de perte de pas pas de décalage!

Je vais prévoir le coup et dégager 1 mm plus haut et sortir de la matière plus loin, c'est pas grave en soit sur une petite pièce, mais si j'ai plusieurs heures d'usinage sur un bout, j'ai pas envie de foirer la pièce!

Après j'ai peut être jamais usiner ce cas, je verrai sur les prochaines pièces.

Merci en tous cas de vous être penché sur mon histoire !

 

[Pierreg60]

Oui peut-être Linux me fait le lissage, je relancerai le programme et regarderai la différence entre le trajet théorique et réel.

 

[toff]

bonsoir,
je peux tester de mon côté j'utilise le même couple que toi.
Si je ne rentre pas trop tard du taf demain, je ferai un essai.

 

[Pierreg60]

Bien grâce à vos réponses j'ai pu farfouiller partout et je viens de trouver le soucis, en fait cambam garde sa configuration et non celle du fichier. En fait sous mon windows j'ai bien le réglage trajectoire exacte et sous linux j'était en indéfini!
2 photos pour vous montrer
merci en tous cas!

 

[toff]

Chez moi pas de souci

 

[dh42]

Salut,

Donc le mode de vitesse constante est aussi actif sur les G0 ? ... c'est strange comme idée ; il me semble bien que sur Mach3, ça n'affecte pas les G0. (en tout cas je n'ai jamais eu ce problème et j'utilise la VC à 95% du temps)

++
David

 

[Pierreg60]

Faudrait que j'essaye le mode vitesse constante, en indéfini c'est peut être normal ?

 

[dh42]

Faudrait que j'essaye le mode vitesse constante, en indéfini c'est peut être normal ?

A mon avis, ton LinuxCnc est réglé en mode Vitesse constante par défaut, donc si CB ne sort pas de code G pour définir le mode de déplacement, il utilise Vitesse constante, ce qui arrondis fortement les trajectoires si il y a une grosse différence entre la vitesse et l'accélération.

Du pt de vue du Gcode sorti par CB, si tu est en mode Vitesse constante, il sort un G64, si tu est en Trajectoire exacte il sort un G61, et sur Indéfini, il ne sort pas de code du tout.

Dans le cas de Mach3, si le mode de déplacement n'est pas défini dans le Gcode (donc laissé sur indéfini dans CB), il prends celui défini par défaut sur Mach ; je m'en sert parfois de façon à pouvoir changer manuellement le mode de déplacement en cours d'usinage (un bouton à cliquer sur l'UI de Mach3)

Sur LinuxCnc, contrairement à Mach3, le G64 peut prendre des arguments
http://linuxcnc.org/docs/html/gcode/gcode_fr.html#sec:G64

Après avoir trouvé les valeurs qui donnent un bon compromis entre une vitesse constante et un suivi correct de la trajectoire (en bidouillant manuellement ton Gcode), tu peux ensuite modifier le post pro Linux de Cambam pour qu'il sorte un G64 avec les paramètres (par défaut c'est juste un G64)

par exemple, un G64 P0.02 conservera une précision de suivi dans la tolérance de 2/100 tout en essayant de garder une vitesse constante.

++
David

 

[toff]

Je confirme david, moi je tourne avec G64 P0.01
Par contre, quand j'ai eu le pb a mes débuts, cela arrondissait aussi en dehors du G0

 

[dh42]

Par contre, quand j'ai eu le pb a mes débuts, cela arrondissait aussi en dehors du G0

un de ces jour si je retrouve le chemin de l'atelier , il faudra que je regarde si c'est pareil sur mach3 et si ça 'arrondis' aussi les G0 ; jusqu'à présent je n'ai rien noté de tel, mais j'ai une accélération à 500mm/s², mon Z ne remonte qu'à 2500 mm/min .. donc c'est peut être passé inaperçu, par contre en G1, il n'y a pas de doute, ça arrondi ; sur certaine pièces, au delà de 2000mm/min, je suis obligé de définir mes op en trajectoire exacte, ou d'utiliser l'option angulaire de Mach3 (repasse temporairement en mode trajectoire exacte si l'angle du 'virage' est supérieur à une certaine valeur)

ceci-dit, ce n'est pas la 1ière fois que j'entends parler de ce problème de sortie de la fraise (sur le forum cambam anglais), mais je ne me souviens pas si c'était sous Linux ou non.

++
David

 

[dh42]

Salut,

Plus ou moins par hasard, je suis tombé la dessus
http://linuxcnc.org/docs/html/user/user-concepts-fr.html#_la_programmation_du_planificateur

2.3. La programmation du planificateur
...
...

G64

(mode trajectoire continue sans tolérance) Le mode G64 est le mode par défaut au démarrage de LinuxCNC. G64 est juste une trajectoire continue, le Détecteur naive CAM n’est pas activé. G64 et G64 P0 indiquent au planificateur de sacrifier la précision de suivi du parcours pour conserver une vitesse d’avance élevée. Ce mode est nécessaire pour certains types de matériaux ou d’outillages pour lesquels l’arrêt exact est dangereux. Il peut très bien fonctionner tant que le programmeur garde à l’esprit que le parcours d’outil pourra être plus arrondi que celui indiqué par le programme. Dans le cas d’un mouvement en G0 (rapide) avec G64, faire preuve de prudence sur les mouvements de dégagement et prévoir suffisamment de distance pour éviter les obstacles selon les capacités d’accélérations de la machine.

Ça confirme donc que LinuxCNc applique la correction de trajectoire même en G0

Il pourrait peut être utile dans ce cas, de modifier le PP de façon à sortir un G61 avant chaque G0 et un G64 P0.02 après chaque G0, de cette manière tous les G0 seront exécutés en mode 'Arrêt exact' ... à voir comment ça se comporte sur la machine.

exemple: dans Rapide (section Déplacement du PP), remplacer

{$g0} {$_f} {$_x} {$_y} {$_z} {$_a} {$_b} {$_c}

par

G61.1
{$g0} {$_f} {$_x} {$_y} {$_z} {$_a} {$_b} {$_c}
G64 P0.02

++
David