Parametrage vitesse constante

[Julien3464]

Bonjour à tous,

Je viens vous demander de l'aide sur un paramètre dans CamBam qui me pose beaucoup de soucis Le mode de déplacement : vitesse constante / trajectoire exacte.

Explications: Quand j'ai usiné ma première forme 3D (Avec Profilage 3D) ma fraiseuse faisait des "à coup". En regardant l'écran de LinuxCNC, je me suis rendu compte que pendant ces opérations 3D, chaque petit déplacement avait une vitesse différente (cela pouvait aller de 300 mm/min jusqu'à la vitesse programmée à savoir 2800 mm/min). J'ai donc été dans CamBam et j'ai changé le fameux paramètre pour le mettre sur "Vitesse constante" mais cela ne change rien

En regardant le Gcode, je m'aperçois que l'avance est programmée qu'une seule fois sur la première ligne du profilage 3D par F2800 mais lors de la lecture du code en instantanée, je vois la vitesse changer.

Je ne comprend pas d'où cela vient...

Merci à ceux qui souhaiterons m'aider,

Je tiens à préciser certains points :
1- J'usine de la mousse polyuréthane (planche usinable "Prolab65") : les vitesses d'avances sont élevées même si je ne suis pas aux limites de ma machine.
2- L'ordinateur qui commande ma machine tourne sous LinuxCNC, mais celui ci est déjà assez vieux (Est ce possible qu'il n'arrive pas à lire assez vite les lignes du code ?)
3- Ci dessous les paramètres du profilage 3D qui pose problème:

 

[ChristianR]

Tu as des rampes d'accélération et de freinage sous Mach3, ça peut venir de là.

 

[dh42]

Tu as des rampes d'accélération et de freinage sous Mach3, ça peut venir de là.

Salut,

Sauf que c'est EMC²

Le fait d'activer la V constante dans une opération d'usinage de Cambam, n'a pas d'autre effet que d'ajouter le code G correspondant dans le Gcode (G61/G64).

Si tu a des à coups alors que tu a bien un G64 dans ton Gcode, alors le pb n'est pas à chercher dans Cambam, mais dans EMC² ... et je ne pourrais pas t'en dire plus, je ne connais pas du tout EMC².

++
David

 

[Julien3464]

Salut Christian,

Je suis sous LinuxCNC et non pas Mach3. Y a t-il les mêmes paramètres ?

 

[Julien3464]

Tu as des rampes d'accélération et de freinage sous Mach3, ça peut venir de là.

Salut,

Sauf que c'est EMC²

Le fait d'activer la V constante dans une opération d'usinage de Cambam, n'a pas d'autre effet que d'ajouter le code G correspondant dans le Gcode (G61/G64).

Si tu a des à coups alors que tu a bien un G64 dans ton Gcode, alors le pb n'est pas à chercher dans Cambam, mais dans EMC² ... et je ne pourrais pas t'en dire plus, je ne connais pas du tout EMC².

++
David

Salut David,

Merci de ta réponse,

Voilà le début du code en profilage 3D, je ne vois pas de G64

( Profilage3D1 )
G0 Z3.0
( T6 : 6.0 )
T6 M6
M3 S16000
G0 X86.99382 Y-149.5958
G0 Z-1.0
G1 F1000.0 Z-2.2
G1 F1900.0 X86.14097 Y-148.70963
G2 X86.00958 Y-148.56385 I2.16157 J2.0803
G2 X82.47236 Y-144.31721 I335.0567 J282.68047
G2 X82.34619 Y-144.15247 I2.31716 J1.90546
G2 X79.16466 Y-139.65454 I660.7566 J470.74658
G2 X79.04238 Y-139.46573 I2.4551 J1.72409
G2 X76.23412 Y-134.74608 I4866.94342 J2899.09758
G2 X76.12522 Y-134.54592 I2.57888 J1.53278
G2 X73.69246 Y-129.60922 I1016.82989 J504.15238
G2 X73.6055 Y-129.41442 I2.6942 J1.31957
G2 X71.56285 Y-124.28516 I479.7372 J194.01838
G2 X71.49735 Y-124.10056 I2.79301 J1.09504

Peux tu m'en dire plus sur le G64 ?

 

[dh42]

Re

Tu a bien choisis un PP pour LinuxCNC ?

C'est bizarre, sur ton code il y a plein d'autres infos qui n'y sont pas, c'est comme si tu utilisait le PP "default" ... ou que tu n'ai pas mis le début du code.

Voila ce que tu devrais avoir en début de fichier.

( Made using CamBam - http://www.cambam.co.uk )
( Sans titre 6/16/2014 9:50:37 PM )
( T5 : 3.0 )
G21 G90 G64 G40
G0 Z5.0
( T5 : 3.0 )
T5 M6
( Poche1 )
G17
M3 S12500
G0 X-30.3 Y26.7
G0 Z3.0
...
...

++
David

 

[Julien3464]

Le post pro est bien sur LinuxCNC.

Je n'ai pas mis le début du code, car il y avait un surfaçage avant (cette opération s'est bien passée).

Voilà comment il commence:

( Made using CamBam - http://www.cambam.co.uk )
( Moule Ext Bash Guard 5/25/2014 10:51:44 AM )
( T1 : 1.5 )
( T2 : 8.0 )
( T6 : 6.0 )
G21 G90 G64 G40
G0 Z20.0
( T2 : 8.0 )
T2 M6
( Surfacage haut 2mm )
G17
M3 S16000
G0 X16.4 Y-200.0
G0 Z1.0
G1 F1000.0 Z-1.0
G1 F4456.0 Y0.0
G0 Z20.0
...

Merci de ton aide

 

[rddt]

Bonsoir

Un sujet intéressent, j'ai le même phénomène (je suis aussi sous Linuxcnc), lors d'une opération de contournage d'un rectangle avec deux demi cercles a chaque extrémités , au changement du gcode G1X....Y...., G2 X.... Y.... I... J...., j'ai un micro temps d’arrêt !! que ce soit en G64 ou G61(PP Linuxcnc).
Cela na pas d'incidence sur le résultat final, mais je me suis posé la question d’où cela pouvait venir, sans trouvé de réponse..

++

 

[Julien3464]

Effectivement, le résultat obtenu reste bon.

Ce qui est plus contrariant, c'est d'une que du coup le temps d'usinage est allongé (j'avais 80.000 lignes de code qui faisaient cela du coup, ça a du prendre, je pense, dans les 40% de temps en plus) et de deux, tout se met à trembler au rythme de la fraiseuse !!! Les moteurs font énormément d'accélérations et décélérations brutales, je ne pense pas que cela soit très bon pour eux !!!

En revanche, j'ai pas l'impression que ce soit un micro temps d'arrêt, je vois bien sur l'écran d'EMC2 que la vitesse change lorsque j'ai ces a coups (quand la valeur n'est pas celle que j'ai programmé, je me demande bien d'où il sort les autres valeurs En tout cas, elles sont toujours inférieures à celle programmé)

 

[dh42]

Bonsoir

Un sujet intéressent, j'ai le même phénomène (je suis aussi sous Linuxcnc), lors d'une opération de contournage d'un rectangle avec deux demi cercles a chaque extrémités , au changement du gcode G1X....Y...., G2 X.... Y.... I... J...., j'ai un micro temps d’arrêt !! que ce soit en G64 ou G61(PP Linuxcnc).
Cela na pas d'incidence sur le résultat final, mais je me suis posé la question d’où cela pouvait venir, sans trouvé de réponse..

++

Re

Parfois ça peut arriver s'il y a des micro mouvements, autrement dit des segments ou des arcs très petits (au niveau des parcours) ; dans ce cas ça ne le fait qu'à quelques endroits, et c'est assez rare.

Par contre ça n'explique pas le pb rencontré par Julien. J'avais eu ce problème sous Mach3 et c'était un réglage dans le soft mais j'ignore s'il y a la même chose sur LinuxCnc.

Je met le lien au cas ou ça puisse t'aiguiller ...

https://www.usinages.com/threads/vitesse-constante-pas-constante.29954/#p342206

++
David

 

[Julien3464]

Salut à tous,

Pour revenir à mon problème, j'ai fait deux petites vidéos :
- La première montre le mouvement de la fraise,
- L'autre ce qui se passe sur Axis.

J'ai essayé de changer quelques paramètres mais rien n'y fait... Ce qui est étonnant, c'est que sur la vidéo, au début de l'usinage, ont voit (et entend surtout !) que le mouvement est régulier. Ensuite ça se dégrade, la fraise fait des déplacements qui ne sont plus à la même vitesse (En écoutant dans la vidéo le bruit des moteurs, ont comprend que la trajectoire n'est pas régulière...)

Voilà les vidéos, j'espère que cela pourra aider pour trouver le problème (Si besoin, je peux mettre les vidéos avec une meilleure qualité) :

https://www.youtube.com/watch?v=OUkJ2nIOltM

https://www.youtube.com/watch?v=MxbancrOkmo

Le GCode utilisé pour la vidéo est en PJ.

Julien Voir la pièce jointe Simul 3D Prob.txt

 

[rddt]

Salut

effectivement il y a un os.
Peut tu mettre le fichier .cb en pj?
++

 

[Julien3464]

Salut

effectivement il y a un os.
Peut tu mettre le fichier .cb en pj?
++

Oui le problème est assez gênant, surtout sur plus de 30.000 lignes
Le fichier est en PJ (Changer l'extension en .cb)

Petite précision aussi, j'utilise Autodesk Inventor pour la CAO de mes pièces. Je les enregistre au format STP pour les passer dans CamBam. J'ai remarqué que CamBam décomposait mes surfaces 3D en plein de petits morceaux (Une autre piste pour le problème ?).

Julien Voir la pièce jointe Moule Ext Bash Guard FINAL.txt Changer .txt par .cb

 

[rddt]

Re

Pour ce que tu montre sur tes vidéos, je pense que ton problème est un nombre trop important de segment dans tes polylignes.
Tu devrait regarder sur ce lien les vidéos qu'a fait David, si ce n'est deja fait.
++

 

[Julien3464]

Ok mais je laisse faire CamBam pour les formes 3D. C'est lui qui génère tout ces petits déplacements à partir de la forme de ma piece. D'ailleurs ma pièce a été créer en révolution donc elle est parfaitement ronde...

Donc que me conseille tu de faire exactement ?

 

[rddt]

Re

D'ailleurs ma pièce a été créer en révolution donc elle est parfaitement ronde...

B'un non !!

Regarde bien la première image, ton cercle est composé d'une multitudes de points, entre chaque point c'est une polyligne droite et non pas un arc de cercle.
Je me suis fait aussi piéger, c'est David qui me la fait remarqué a juste titre.

Pour corriger ce problème, une façon parmi d'autres: sélectionner la polyligne incriminé clic droit ->Édition, la tu verra tout les points, ensuite dans la barre des taches->Menu Édition->Polyligne->Insérer des arcs->Tolérance (ex: 0.07)->ok.


Donne ceci

Fait deja un essai avec ce que je suppose le contour de ta piece pour voir si tu a un changement du comportement de ta vitesse constante de trajectoire ainsi que réaction de ta Cn.

++

 

[Julien3464]

Effectivement ont doit pas être loin de la vérité, le petit problème c'est que je n'arrive pas à sélectionner les polylignes comme tu l'a fait !!! (Je débute avec CamBam !!)
Faut-il que je convertisse toute ma pièce en polylignes, puis sélectionner celles qui constituent un cercle de ma forme 3D pour faire ce que tu as fait ??

- Quand je fais un profilage 3D, je sélectionne toute la pièce; est ce la bonne méthode ?
- Y a t-il une méthode pour passer d'un fichier CAO à CamBam sans avoir le problème qu'il décompose les pièces en plein de petits morceaux plats ?

Julien

 

[dh42]

Ok mais je laisse faire CamBam pour les formes 3D. C'est lui qui génère tout ces petits déplacements à partir de la forme de ma piece. D'ailleurs ma pièce a été créer en révolution donc elle est parfaitement ronde...

Donc que me conseille tu de faire exactement ?

Salut,

Pour les formes 3D, tu n'a pas vraiment de choix ; tu ne peux pas optimiser comme sur les formes 2D ; les parcours 3D sont obligatoirement constitués d'une multitude de petite traits/arcs ; c'est le seul moyen de suivre la forme de la pièce.

Je vais essayer ton Gcode sur ma CN pour voir ce que ça donne

- Y a t-il une méthode pour passer d'un fichier CAO à CamBam sans avoir le problème qu'il décompose les pièces en plein de petits morceaux plats ?

non, le problème vient du soft qui exporte le dessin ; il te faut utiliser "insérer des arcs" pour corriger ça

++
David

 

[dh42]

Re

Sur ta vidéo, c'est les op d'usinage 3D du fichier que l'on vois ? que je teste la même partie sur la mienne.

++
David

 

[Julien3464]

Re

Sur ta vidéo, c'est les op d'usinage 3D du fichier que l'on vois ? que je teste la même partie sur la mienne.

++
David

Oui c'est le début de celle que j'ai appelé "3D Haut"

 

[dh42]

Ok, je vais tester/filmer.

Quel valeurs à tu en accélération pour tes axes ? ; je vois que tu utilise une V d'avance assez élevée (2800 mm/min) ; pour un bon résultat il faut que l'accélération soient suffisante.

Je vais tester sans changer la V d'avance (mes accélérations sont à 300mm/s²)

à tout

++
David

 

[Julien3464]

Ok, je vais tester/filmer.

Quel valeurs à tu en accélération pour tes axes ? ; je vois que tu utilise une V d'avance assez élevée (2800 mm/min) ; pour un bon résultat il faut que l'accélération soient suffisante.

Je vais tester sans changer la V d'avance (mes accélérations sont à 300mm/s²)

à tout

++
David

Pour l'axe X je suis à 2750 mm/s2 avec Vmaxi à 150 mm/s (0,0545sec pour atteindre la Vmaxi en 4,0909mm)
Pour l'axe Y je suis à 2500 mm/s2 avec Vmaxi à 100 mm/s
et pour Z je suis à 2800 mm/s2 avec Vmaxi à 100 mm/s

Oui les vitesses d'avances sont assez élevés, et ça monte à parfois plus que ça (c'est de l'usinage dans de la mousse polyuréthane pour la fabrication de modèle ou moule qui me permette de fabriquer mes pièces en composite derrière).

J'attends tes résultats avec impatience

 

[dh42]

Ok, je te met la vidéo dans un moment.

Je peux déjà te dire que ça fait pareil sur la mienne à 2800 mm/min acc à 300, mais que c'est fluide à 1800.

Si j'augmente l'accélération à 600, c'est un peu mieux à 2800, mais ça reste saccadé ... je me demande donc si ce n'est pas tout simplement le PC qui n'arrive pas à suivre (dans mon cas un P4 3.00 ghz)

Je te met la vidéo dans un moment ... si je suis plus rapide que l'orage qui approche

++
David

 

[dh42]

Et voila la vidéo.

J'ai essayé de faire des modif sur le PP (longeur min des arcs, nb de décimale etc) pas de changement ; même chose sur mes 2 machines, même à la F maxi de Mach3 (100Khz) ...

++
David

 

[Julien3464]

Merci David d'avoir pris le temps d'essayer sur ta machine.

Il semblerait que c'est bien le GCode qui provoque ces a coups, car malgré que la vitesse soit stable, ont entend bien que les moteurs ne font pas le bruit d'une belle interpolation circulaire sur 360° !

Dans tout les cas, comme tu l'a dit, la forme 3D est généré par pleins de petits segments. Pourtant dans le gcode, c'est des courbes très petites qui sont générés et pas des segments de droite, cela ne devrait donc pas être saccadé. Ont dirait que les courbes ne se rejoignent pas ou bien qu'elles sont décalées...

Ce ne serait pas non plus nos ordinateurs car même à faible vitesse, le phénomène se produit...

Reste à essayer la technique de rddt, mais je n'arrive pas à le faire dans CamBam

 

[dh42]

Reste à essayer la technique de rddt, mais je n'arrive pas à le faire dans CamBam

L'optimisation ne marchera pas sur de la 3D, c'est uniquement pour les polylignes.

++
David

 

[gaston48]

Bonjour,

Essaye de paramétrer le G64

Comme : G64 F0.05 Q0.1

 

[dh42]

Re

Je viens de demander à Andy (le programmeur de Cambam) s'il a une idée pour résoudre le pb ; je lui ai passé un bout de ton fichier .cb et les liens vers nos vidéos

++
David

 

[Julien3464]

Bonjour,

Essaye de paramétrer le G64

Comme : G64 F0.05 Q0.1

Salut,

Tu peux expliquer ce que signifie F0.05 et Q0.1 stp ?
J'essai le week end prochain ! Merci !

Re

Je viens de demander à Andy (le programmeur de Cambam) s'il a une idée pour résoudre le pb ; je lui ai passé un bout de ton fichier .cb et les liens vers nos vidéos

++
David

Super David,

Merci beaucoup, le probleme devrait vite être résolu !

 

[gaston48]

Julien, quand tu importes dans Cambam un solide ou un surface, il est au
format STL. Toutes les descriptions mathématiquement vraies des éléments
du solide sont perdus, tel qu’une sphère décrite par les cordonnées de son
centre et son rayon. Tout est approximé par des facettes, sous la forme de listes
de coordonnées des sommets des facettes.
Dans ton cas, pour un solide de révolution, une coupe déterminera un cercle
discrétisé, facettisé, sous la forme d’un polygone régulier.
Le planificateur de trajectoire de Linuxcnc n’est pas sensé savoir qu à l’origine
c’était un cercle parfait programmé avec une seule ligne G2 ou G3.
Il va tenter de suivre le plus vite possible une trajectoire qui l’oblige à passer
rigoureusement par chaque point du polygone. C’est extrêmement contraignant
pour un mobile en déplacement car son vecteur vitesse change instantanément
de direction. Le planificateur de trajectoire doit anticiper l’arrivé d’un point pour
gérer freinage et accélération en fonction de ses performances dynamique.

Il y a plusieurs façon d’être moins contraignant, l’une est fournie par Cambam,
elle consiste à tenter d’adoucir les transitions des sommets points par des
arc de cercles. A l’extrême, on reconstitue le cercle d’origine de ton solide de
révolution. Il me semble que contrairement à ce qu’affirme David ,
la méthode de rddt est applicable sur du profilage 3D.
Dans les options, on dispose bien de "l’insertion auto d’arcs" qu’il faut
activer sur vrai, ainsi que la tolérance d’insertion d’arc qu’il faut paramétrer
à une valeur supérieur à 0 .En augmentant cette tolérance et en examinant le fichier
g code on voit d’abord disparaître les lignes G1 joignant chaque arc, puis
diminuer le nombre d’arcs.
L’autre façon d’être moins contraignant et d’être plus tolérant sur le respect
du passage par les points caractéristique de la trajectoire imposé au planificateur.
G64 donne la priorité à la vitesse, mais arrondit les transitions angulaires ou
se permet des dérives de trajectoire comme lors du passage d’un point de transition
ligne arc, avec une tolérance proportionnelle à la vitesse. Elle n’est pas quantifiée,
une très basse vitesse peut entraîner le même résultat qu’un G61.
Paramétrer le G64 avec P et éventuellement Q déclanche un dispositif
complémentaire le naïve cam.
Le paramètre P fixe une tolérance maximum de passage par un point donc la vitesse
reste une priorité jusqu’à une certaine limite.
Le paramètre Q fixe une tolérance qui laisse la possibilité de fusionner plusieurs lignes
en une seule en respectant cette tolérance. Il va donc réduire le nombre de
points contenu dans la trajectoire, mais toujours à base de lignes ce qui entraînent toujours
des transitions brusques.
Par défaut, quand Q n’est pas spécifié, il est néanmoins actif et a la même valeur que P.

C’est à tester, mais je pense que jouer sur la tolérance d’insertion d’arc dans cambam
sera plus efficace.

Il semble que même si les transitions d’arc à arc ou de ligne à arc se font en douceur,
avec une continuité de tangence, il existe toujours une transition avec un point,
une discontinuité par rapport à une fonction continu, qui va solliciter le planificateur
de trajectoire. Ce qu’on observe sur la pièce simple de rddt (j’ai observé
beaucoup de simulation et c’est même un phénomène aléatoire) semble lié
aussi au performance de traitement du PC, latence et vitesse du port // .
Je vais configurer une machine virtuel avec ma carte mesa pour comparer

Le nouveau planificateur plein de promesses est en bêta test içi :
il semble moins consommer de ressource de calcul dans les transitions
que le "parabolique blends" actuel et il permet donc d’anticipé plus loin la
trajectoire qu’il doit gérer.

http://www.linuxcnc.org/index.php/french/forum/10-advanced-configuration/27368-new-trajectory-planner-testersprograms-wanted