Micro coupure sur parcour d'usinage ?

[rddt]

Bonjour a tous

Pour ne pas polluer le post de Julien3464 j'en ouvre un autre qui est similaire.
Bien que le petit souci qui ce présente sur ma Cn ne pose pas de réel problème a la finalité des pièces usinées, j'aurai aimé cependant savoir ce qui peut provoqué ce phénomène.
Lors d'un usinage d'un rectangle avec deux demie cercles a chaque extrémité, au moment ou le parcours d'usinage change pour attaqué et sortir des demi cercle j'ai des micros coupures dans le parcours, que ce soit en G64 ou G61.
J'ai réalise une petite vidéo ou l'on vois et entend le problème.
Pour la vidéo j'ai fait simple au niveau du Gcode (qui est en pièce jointe).
La question, le souci provient il de Cambam ou de Linuxcnc ?? ou bien ai je fais une boulette dans la création de ma pièce ?
Une solution peut être...

Voir la pièce jointe Test1.txtRenommer le fichier en .cb


++

 

[gaston48]

Yo !

ta vidéo est privée ?

 

[rddt]

Bonsoir Gaston

ta vidéo est privée ?

Ouuups.....
C'est ok.
++

 

[dh42]

Salut,

Après analyse de ton fichier, je pense que ça viens de la polyligne qui sert de base au contour ; lorsque les parcours sont générés, il y a création de 2 micros arcs qui doivent fortement déplaire à ta machine.

Je te donne plus d'infos sur la manière dont je m'y suis pris pour voir ça, et bien sur comment on peu tenter d'y remédier (si c'est bien ça qui crée le pb)

Après avoir généré les parcours pour le contour, j'ai crée un nouveau calque vide, puis dans le menu contextuel de Ebauche D, j'ai utilisé 'convertir les parcours d'outils en géométries', ce qui a pour effet comme on s'en doute de créer des polylignes qui sont l'exact reflet des parcours d'outil, à ceci prêt qu'il est possible de les décortiquer pour voir à quoi ils ressemblent.

Ces polylignes ont atterries sur le nouveau calque créé, et si on cache tous les autres, on peut voir la composition des parcours (double clic sur la polyligne pour afficher les points de contrôle)

Comme on vois sur l'image suivante, il y a 2 micros-arc à gauche, c'est dut au fait que l'arc de gauche de la polyligne de départ à un petit défaut et ne fait pas exactement 180°, mais un poil moins ; CB ajoute donc ces micro arcs pour faire le raccord lors de la génération des parcours.

C'est comme les arcs qu'il ajoute au angles d'un parcours extérieur sur un rectangle, sauf qu'ici il l'ajoute entre la ligne droite et le début de l'arc, il n'y aurait aucun angle si l'arc faisait bien 180° mais ce n'est pas le cas, l'écart est faible mais existant.

Pour régler ce problème, plusieurs solutions:

- redessiner la forme avec des arcs corrects ; pour cela il y a un truc on ne peut plus simple ; tu fais un rectangle de 22 x 54.0523 ( taille lue dans 'outils/afficher taille des objets' pour ta polyligne), puis tu règle le paramètre 'rayon d'angle' du rectangle sur 11 et tu a ta forme bien propre.

- sans refaire la forme, tu peux éditer la collection de points de ta polyligne, et changer le 'bulge' pour avoir des demis cercles complets (mettre le bulge à 1 au lieu des 0.97...) attention, cette 2ieme méthode aura pour effet de faire passer ta pièce de 54.05 à 54.3 mm de large

je te met un fichier modifié, la polyligne à été refaite avec la méthode du rectangle. les micros arcs ont disparu des parcours. (et elle reste à 22x54.05)

Dis moi si ça règle ton pb.

bon WE
++
DavidVoir la pièce jointe Test1_mod1.txt

 

[rddt]

Salut David

Merci de plancher sur mon problème.

Après essai du fichier que tu ma renvoyer il y a effectivement une net amélioration, mais le phénomène na pas complètement disparus, il y a toujours un micro temps d’arrêt a chaque changements de G3 F360.0 X-11.5 Y19.6 I-19.6 J0.0 G1 X-43.55, mais comparativement a avant (ancien fichier) le micro temps d’arrêt est nettement moins important.

Après avoir mis la loupe sur fois 1000 (mes yeux oblige) je vois bien les micros arcs dont tu parle, je me suis compliqué la vie en tirant deux polylignes et en y insérant deux arcs a chaque extrémités alors que ta méthode est beaucoup plus simple et effectivement génère moins d'erreurs.

Concernant le problème et après examen du Gcode qui a mon avis va est compliqué de faire plus simple a moins qu'il y est une autre piste, le problème viendrai de Linuxcnc ? ou c'est tout simplement normal !


Bon weekend

++Renaud

 

[gaston48]

Tu peux tenter aussi de paramétrer le P et le Q de G64 P- Q- pour activer
le détecteur naïve cam

http://www.linuxcnc.org/docs/html/common/User_Concepts_fr.html

S'il y en a plusieurs, tu t’aides d’un bon éditeur comme notepad++ et tu fais recherche tous les
G64 remplace par G64 Pxxx Qxxx
Il semble confirmé que le planificateur de trajectoire de Linuxcnc est moins
performant, dans certain cas de figure, que celui de Mach3, Une équipe travaille à son amélioration,
mais je ne trouve pas d’infos.
Bon W.E.

 

[dh42]

Salut,

Concernant le problème et après examen du Gcode qui a mon avis va est compliqué de faire plus simple a moins qu'il y est une autre piste, le problème viendrai de Linuxcnc ? ou c'est tout simplement normal !

Je pense qu'il y a effectivement un problème avec la vitesse constante sur le soft de pilotage ; surement pas un bug mais certainement un mauvais réglage quelque part. Je ne connais pas LinuxCNc, mais je pense que si le dispositif de vitesse constante ne fonctionnait pas, ça se saurait ...

Après avoir mis la loupe sur fois 1000 (mes yeux oblige) je vois bien les micros arcs dont tu parle

En fait il y en a même 4 ; il y en a deux aussi de l'autre coté, mais encore plus petit. Toutefois, même s'il sont petit, il ne le sont pas au point de perturber le système de VC (le plus petit fait 3/10 de mm) mais par contre ils rendent bien visible le faite que la VC ne fonctionne pas.

Sur ma machine, ces micro arrêt ne se produisent que pour des segment bien plus court (moins de 1/100 de long) et c'est très rare.

Ce qui est sur, c'est que sur le fichier modifié, il n'y a plus du tout de micros arcs dans les parcours ; il y a deux droites de 32.05mm et 4 arcs de 90° ... donc le pb est ailleurs et il va te falloir le secours des spécialistes de LinuxCnc car avec ce code, ça devrait être parfaitement fluide est sans le moindre à coup.

Juste une question ; je vois que ta V d'avance est réglé sur 800 sur CB, quelle accélération à tu pour tes axes dans LinuxCnc ? .. une accélération faible par rapport à la V d'usinage est également un facteur qui peux perturber la VC (sur Mach en tout cas), je l'avais déjà noté. Même chose (toujours sur Mach) si on augmente la V d'avance via le soft de pilotage au lieu de la changer dans le Gcode et si il y a un trop grand écart entre la V programmée dans le Gcode et la sur-vitesse choisie , ça arrive à donner des à coups.

Peut être aussi voir si le changement de mode micro pas des drivers à un effet ..

++
David

 

[rddt]

Re

Gaston
J'ai fais des essais avec le paramètre P (P0.015, 0.1, 1.0, ect...) et avec le Q, rien ne change toujours le micro temps d’arrêt.
Une observation que j'ai faite au moment du micro temps d’arrêt, la vitesse de déplacement passe de 360 a 250.

David

je vois que ta V d'avance est réglé sur 800 sur CB

une accélération faible par rapport à la V d'usinage est également un facteur qui peux perturber la VC

La aussi j'ai fait divers essais, même motif même punition.

Peut être aussi voir si le changement de mode micro pas des drivers à un effet ..

Le seul changement de micro pas que je puisse faire est sur le soft, car les drivers sont ceux d'origine de la Cn (1985) et n’ont pas de possibilité de changement de pas.
J'ai fait des essais sur le soft, rien ne change, micro temps d’arrêt.

Cela va resté un mystère...

++