desactiver correction rayon d'outil

Salut,

Il y a un bouton Décalage outil M/A sur l'écran Décalage ; c'est peut être ça ? ... pour ma part je ne parviens pas à l'activer, donc pas sûr.

Ton Gcode est fait avec quel soft ? ça ne ressemble pas à du Gcode fait par CamBam, la syntaxe est bizare  

Trouve tu des G41/G42, G43 Hxxx dans ton Gcode ? ; en principe c'est ce qui active les décalages outils ; un G40 les désactive.

Il y a aussi un réglage dans la config générale ; assure toi que "Disable Gouge/Concavity Checks" soit coché (Désactiver vérification G41/G42 sur la VF)

++
David

Re

Et bien en fait, la LED à droite de la visu de l'axe A n'a rien à voir avec la correction d'outil G41/G42 ; jazial s'est planté sur son interface ; cette LED correspond à l’activation du décalage de l'axe de rotation du 4ième axe. (vu en regardant le code de la LED dans MachScreen)

Pour qu'elle s'éteigne, il faut une valeur de 0 dans Diamètre des axes rotatifs pour le A sur la page Réglages.

Pas sûr que ce soit ça qui te créé ton problème de décalage ; ça ne devrait pas avoir d'influence en 3 axes XYZ.

++
David

Salut,

Je ne sais pas si c'est en rapport, mais Mach3 ne connais pas le code G40.1 ; il doit être remplacé par G40 ; il faut modifier ton post pro Mach3 dans ta FAO.

++
David

Salut,

Dans ce cas, et vu qu'il n'y a aucun correcteur d'outil dans le Gcode (G41/42), c'est que la correction est intégrée dans les parcours d'outil, comme sur CamBam, et donc, à mon avis, c'est dans RhinoCAM que tu a un réglage qui déconne et qui ajoute cette correction.

Il faudrait faire un Gcode sur CB et un sur Rhino, avec le même dessin ; par exemple un simple contour sur un carré centré sur le 0,0 avec une fraise du même Ø, et comparer les Gcodes. Je ne peux pas savoir si le Gcode te ton précédant message est juste ou non, car je ne sais ni quelle est la taille qu'est censée avoir ta pièce, ni quel est le Ø de la fraise utilisée pour faire le Gcode.

++
David

Salut,

Si j'ouvre les 2 Gcode directement dans CamBam (Objet fichier Gcode > http://www.atelier-des-fougeres.fr/Cambam/Aide/cam/BackPlotting.htm ) les parcours d'outil des 2 Gcodes se superposent exactement, donc les parcours sont OK, il doit y avoir un souci avec les codes d'initialisation de la première ligne.

Édite ton Gcode Rhino avec un éditeur de texte et supprime les codes qui ne sont pas dans le Gcode CamBam pour voir ; il s'agit des codes: G00, G49, G80 et G50 et relance un usinage. Je doute que ça fasse quelque chose, car G49, G50 et G80 sont tous des codes de RAZ (longueur outil, échelle, cycle de perçage) ; le G00 seul ne veux rien dire pour Mach3.

++
David

Salut,

Tout ce qui change, c'est qu'avec le Gcode Rhino, tu usine en avalant et avec le Gcode CamBam tu usine en opposition (c'était le cas aussi sur les 2 Gcodes précédents) ; ça peut faire varier les cotes, surtout si tu usine du bois. Des essais que j'avais fait sur du massif, j'avais facilement plusieurs 1/10iemes de différence suivant le sens d'usinage.

++
David

Salut,

C'est dut à l'élasticité du bois ; en avalant la dent de la fraise attaque la matière perpendiculairement au mouvement et la compresse tout en coupant (et la matière revient en position après le passage de la fraise) alors qu'en opposition la dent passe "derrière" la matière et la tire vers la fraise, l'effort de coupe à l'attaque est parallèle au mouvement.

Est ce qu'il n'y a pas un parametre dans mach3 qui créé un offset en cas de parcours en avalant ?

Non, c'est à toi d'en tenir compte dans la FAO ; sur CamBam tu peux utiliser le paramètre "surépaisseur" (positive ou négative) des op d'usinage pour gérer ce problème.

L'écart est bien sûr très dépendant de la matière usinée ; de l'expérience que j'ai de l'usinage du bois (brut), plus il et dur et plus les cotes sont proches de la valeur demandée.

++
David