Cnc mach3 défaut découpes

[LORVMAX]

Bonjour. Lorsque je lance mes découpes j'ai comme des " parasites " qui apparaissent sous forme de rond sur le trait de coupe d'environ 3mm de diamètre et ce à chaque fois au même endroit si je relance la découpe. Je ne trouve rien dans le Gcode par contre. Gcode crée par Canam
Merci pour vos réponses

 

[pascalp]

Bonjour.
Passer par la case présentation nous aurait permis d'avoir un aperçu de ton activité/vécu. Ce qui peut aider pour donner des réponses pertinentes, on en est pas encore là. Il va falloir commencer par des questions sur le où/quand/comment.

Est-ce un nouveau problème, quelle machine, quel contrôleur, quel post-processeur, quel niveau d'expérience, etc.

Mets en pièces jointes, le DXF d'origine ainsi que le gcode généré. Si il n'y a pas d'anomalies flagrantes. Il faudra investiguer côté machine. Mach3 est plutôt "respectueux" du gcode qu'il a traiter. Et, comme ça, je ne vois pas quel paramétrage pourrait générer ce genre de défaut.

L'intérieur aussi bien que l'extérieur de ton couple semblent affectés.

 

[LORVMAX]

Bonjour. J'ai bien suivi le gcode pour y déceler un problème il n'y a pas de lignes générant ces parasites. Je pencherais plutôt vers un problème logiciel. Ci-joint le matériel utilisé pour traduire le gcode en données machine.

 

[Jipé11]

Depuis le temps que Mach3 est commercialisé ça m'étonnerai fort que le problème soit logiciel. Je chercherai plutôt du coté du logiciel qui a généré le code et du post processeur chargé de l'interpréter.
JP

 

[LORVMAX]

Canbam pour le code
Quand au post processeur comment je le trouve ?

 

[pascalp]

Le fait de poser la question est une réponse en soit !

C'est toi qui sélectionne le post-processeur au niveau de CAMBAM. Tout en bas de la liste des paramètres d'usinage.
On peut le laisser par défaut, mais c'est quand même mieux de le mettre le gcode généré en cohérence avec la manière dont il va être interprété. Tu trouveras "Mach3" dans la liste.

 

[Mcar]

ça ne serait pas une histoire de paramétrages des attaches dans CAMBAN ?
difficile d'en dire plus sans informations complémentaire de la gamme d'usinage utilisée dans CB ?
Au passage, Angevillers ce n'est pas loin de mon chez moi

 

[rentemplan]

C'est un contrôleur autonome rien a voir avec mach3

 

[Jipé11]

Alors il faut reprendre les fonctions de ton contrôleur et vérifier leur comptabilité avec le code généré par CAMBAM. Ce ne serait pas la première fois qu'un code de fonction générique soit interprété différemment par un contrôleur "propriétaire".

 

[pascalp]

Je rappelle que "Mach3" fait partie de l'intitulé du fil. Je ne sais pas d'où vient cette spécification.

Il n'y a rien dans le manuel DDCS V3.1 sur la "compatibilité G code", on peut supposer l'utilisation du mode standard comme post-processor dans Cambam.

https://www.usinages.com/threads/post-processeur-ddcs-v-3-1.161782/

 

[LORVMAX]

Donc personne n'a une piste sachant que comme la plupart des gens utilisant occasionnellement ces programmes je ne touche pas aux réglages orignaux qui sont hors de mes compétences actuelles ?

 

[hazet]

Je pense qu'il faut te faire aider directement devant la machine.
Mcar se propose

 

[Mcar]

Avant toute chose,
peux tu nous mettre ton fichier *.cb pour que l'on puisse l'analyser, si toute fois il n' y a pas de confidentialité
il faudra le renommer en *.pdf

 

[LORVMAX]

voilà un des fichiers...

 

[Mcar]

j'ai utilisé cutViewer Mill
comment peux tu usiner des encoches carrées (forme intérieure) avec une fraise
Quel est le dia. de ta fraise ?
quelle la largeur des encoches ? sur le programme il semble que c'est 4 mm

de mon point de vue, ta forme intérieure ne peux pas être usinée en contour extérieur sans aménagement.

 

[LORVMAX]

Fraise de 2mm
Il y a une fonction dans canbam pour rentrer justement dans ces coins. Mais on s'écarte du problème posé

 

[Mcar]

Fraise de 2mm
Il y a une fonction dans canbam pour rentrer justement dans ces coins. Mais on s'écarte du problème posé

oui, je comprends mieux, on voit bien deux usinages aux coins des encoches

je pensais que les encoches étaient mal réalisés et que les défauts venaient de ces encoches justement.
en simulation avec cutViewer on voit rien, ce qui signifie que le programme gcode est sain.
il faut donc chercher ailleurs

 

[Jipé11]

Bonjour,
J'ai ouvert ton code sur ma machine (bCNC/grbl) sans problème et l'affichage graphique des parcours ne fait apparaître aucune dérive.
Le code est classique avec des fonctions basiques qui sont reconnues par tous les contrôleurs (G0, G1; G2, G3). Le problème n'est pas dans le code mais plutôt dans l'interface post processeur machine. C'est ta première utilisation de cette machine ?
JP

 

[dh42]

Salut,

Si le défaut est toujours au même endroit, c'est bien que le problème viens du Gcode, ou plutôt de l'interprétation qu'en fait ton DDCS.

Il est possible qu'il ne sache pas gérer correctement les µ-arcs .. et des µ-arcs il y en a dans ton Gcode. (des arcs de moins de 0.01mm de long, j'en ai trouvé de 0.006mm)

Je pense qu'il te faut régler un ou deux paramètres dans ton post processeur.

1) dans un 1ier temps, il te faut sélectionner le post processeur appelé "default" comme post processeur à utiliser par défaut sur les nouveaux fichiers dans les options de CamBam, ce sera fait pour les prochains projets et tu n'aura plus à t'en soucier.

http://www.atelier-des-fougeres.fr/Cambam/Aide_V1/cam/PostProcessor.htm

2) sur ton fichier déjà existant, sélectionnes le post pro "default" dans la section Usinage pour être sur que ce sera bien celui-la qui sera utilisé. (ça ne sera pas nécessaire sur les nouveaux fichiers, la ligne devra rester vide, ce qui signifie d'utiliser le post pro sélectionné par défaut dans les options)

3) maintenant, vas sur l'onglet Système, sélectionne le post pro appelé "default" et modifie les valeurs de "longueur minimale des arcs" te de "rayon maximum des arcs" pour les mettre respectivement à 0.01 et 10000

Puis clic droit sur le nom du PP > Enregistrer.

Ensuite essais de générer un nouveau Gcode .. et croises les doigts ; ce réglage devrait transformer tous les arcs de moins de 0.01mm de long par des droites ce qui devrait plaire d'avantage à ton DDCS (Mach3 non plus n'aime pas trop les arcs trop courts ...)

Si tous les paramètres ne sont pas affichés, utilises le bouton Basique/Avancé pour passer en mode affichage complet.

++
David

 

[LORVMAX]

Ok merci pour cette avancée qui promet d'être la bonne piste.
Laissez-moi un peu de temps pour relancer ce projet qui est en attente depuis un certain temps. Je reviendrai vers vous pour peut-être une bonne conclusion.

 

[pascalp]

David,
Je viens de vérifier mes post-processeur Cambam en 0.9.8 et 1.0. , ils sont tous en "0.0001" et "10000" avec un rare "0.001". Je n'ai jusqu'à présent pas eu de problème que ce soit avec MACH3 ou GRBL.
Est-ce qu'une modification "préventive" serait une approche prudente, au cas où ?

 

[Mcar]

je viens également de vérifier chez moi, post pro GRBL
longueur minimal des arcs : 0.001 / rayon maximum des arcs : 1000
A priori , ces paramètres ne sont pas les mêmes pour chacun d'entres nous.

peux tu stp nous expliquer quelles sont les incidences sur le gcode , sur la pièce.

Dans ma compréhension,
la longueur minimal de l'arc si l'arc est inferieur à 0.001 (pour mon cas) alors le gcode généré est il transformé en ligne droite reliant le point de départ et d'arrivée de cet arc ?
et je suppose dans la même logique, si le rayon de l'arc est plus grand de 1000 alors les points de départ et arrivée de cet arc seront reliés par une droite egalement ?

je viens de tracer sur fusion un cercle de rayon 1000 sur un arc de 200 mm, la flèche fait 5 mm, donc pas vraiment négligeable

 

[dh42]

Salut,

David,
Je viens de vérifier mes post-processeur Cambam en 0.9.8 et 1.0. , ils sont tous en "0.0001" et "10000" avec un rare "0.001". Je n'ai jusqu'à présent pas eu de problème que ce soit avec MACH3 ou GRBL.
Est-ce qu'une modification "préventive" serait une approche prudente, au cas où ?

J'avoue que je ne sais pas exactement ou se situe la limite .. et elle est certainement différente suivant le soft. Pour ma part j'ai déjà vu ce problème créer des "crop circles" avec Mach3 mais aussi avec CutViewer ... mais ce n'est pas systématique, je pense que comme souvent en programmation "géométrique", ça se joue aux arrondis .... Par défaut les PP de CamBam sont tous configurés pour des pouces, d’où le nb de décimales important. Le problème qui se pose c'est que parfois, sur un arc ultra court, le soft l'interprète "à l'envers", autrement dit il trace l'arc complémentaire (et donc tu te retrouve avec un "presque" cercle)

0.01 pour la longueur mini me semble bien pour des mm, par contre pour le rayon maxi il semble que ce soit plus rare que ça pose des problèmes, 10 000 me semble une bonne valeur (1000, effectivement ça peut être un peut limite ..)

Dans ma compréhension,
la longueur minimal de l'arc si l'arc est inferieur à 0.001 (pour mon cas) alors le gcode généré est il transformé en ligne droite reliant le point de départ et d'arrivée de cet arc ?
et je suppose dans la même logique, si le rayon de l'arc est plus grand de 1000 alors les points de départ et arrivée de cet arc seront reliés par une droite egalement ?

oui, c'est ça ...

En principe de toute façon ça se voit sur la simu des parcours sur Mach3, LinuxCNC ou CutViewer ... pour le DDCS par contre, je ne sais pas, j'ignore s'il affiche les parcours à l'écran

++
David

 

[Mcar]

Merci David, pour ces explications.

 

[pascalp]

C'est vrai que l'origine US explique la foultitude de décimal.
Vu comme ça, le 1/100 ou à la limite le 1/1000 de mm sont plus cohérents.

Comme marco, les post-pro GRBL sont en "0.001" et "1000"
Je vais "uniformiser" sur ces valeurs.

 

[dh42]

C'est vrai que l'origine US explique la foultitude de décimal.

Oui, d'ailleurs sur d'autre softs comme Fusion360, il y a des PP séparés pour mm et pouces. Tous les PP d'origine de CamBam sont paramétrés pour les pouces, je suppose que c'est parce qu'un PP en pouce fonctionne généralement sans problème avec des mm alors que l'inverse pose problème.

CamBam, c'est Anglais, pas Américain .. et de plus Andy m'avait dit que le soft est nativement développé en mm du pt de vue de la programmation, le passage en pouce est donc une conversion depuis les mm.

++
David

 

[pascalp]

Merci