rognage pièce en sortie d'alésage

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.

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.

Cliquez pour agrandir...

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

Bonjour,

Quel logiciel de pilotage ?

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

JF

Salut,

Pierreg60 a dit:

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

Cliquez pour agrandir...

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

Cliquez pour agrandir...

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 !

Pierreg60 a dit:

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

Cliquez pour agrandir...

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

++
David

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.

Chez moi pas de souci

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 a dit:

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

Cliquez pour agrandir...

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

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

toff a dit:

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

Cliquez pour agrandir...

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

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.

Cliquez pour agrandir...

Ç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