approche CNC

[zirga]

Bonjour à tous.
Je voudrais votre avis sur un sujet qui me préoccupe pendant que je conduis la folie de développer une fraiseuse CNC autour du MC68000 (une fois de plus). Il s'agit de la décomposition des mouvements sur un plan disons XY. en fait j'ai ecrit un programme en assembleur depuis quelques années pour accomplir la tache et ça marche bien (en prenant sur le model de coordonnes HPGL des coordonnes de départ et d’arrivée). Le programme me donne le sens de rotation des moteurs ainsi que la succession des pas sur les moteurs X et Y (moteurs pas à pas). Mais en son temps j'avais pris la liberté de ne commander UNIQUEMENT un pas à la fois . ma ligne est donc constituée d'un agencement de segments horizontaux et verticaux . Mais voila, pour avoir récemment lu sur la décomposition de lignes de Bresenham qui elle inclut les lignes obliques, je me demande si je ne pourrait pas faire preil. LA QUESTION EST; CELA CONSTITUE -T-IL UN AVANTAGE DE PERMETTRE DES LIGNES OBLIQUES SI LON PENSE QUE MÉCANIQUEMENT ON N'A AUCUNE CERTITUDE QUE LES 2 MOUVEMENTS SE FERONT SIMULTANÉMENT. ? EST-CE QUE LA STABILITÉ DU CHARIOT NE S'EN TROUVE PAS MISE A MAL.? Autrement en CNC est-ce selon selon Bresenham qu'on décompose les mouvements pour une ligne définie. Cette séquence oblique me pose vraiment problème.
Si vous en savez quelque chose , merci d’éclairer ma lanterne.
-----

[webscience]

Bonjour,

Tous dépends de l'angle, mais pour un angle à 45 degrés, voici les données

Pour un tracé oblique allant vers la droite en bas

1) Avance d'un pixel, puis descente vers le bas

Pour un tracé oblique allant vers la gauche en bas

2) Recule d'un pixel, puis descente vers le bas

Pour un tracé oblique allant vers la droite en haut

3) Avance d'un pixel, puis monter vers le haut

Pour un tracé oblique allant vers la gauche en haut

4) Recule d'un pixel, puis monter vers le haut

Les moteurs doivent avancer en même temps, si c'est pas le cas, tu risques d'avoir des escaliers.

L'électronique, ainsi que la mécanique doivent être la même, et d'une grande précision.

Question intéressante, qui ma donnée bien des soucis lors de la création de mon programme CNC

A+

[zirga]

Merci webscience pour ta reaction .
Tu dis:

Tous dépends de l'angle, mais pour un angle à 45 degrés, voici les données

Pour un tracé oblique allant vers la droite en bas

1) Avance d'un pixel, puis descente vers le bas

ce qui signifie que tu ne realise pas le segment oblique mais la projection en segment horizontal PUIS vertical.Donc pas de simultaneité. jusque là ca m'arrange!

Par contre tu dis encore:

Les moteurs doivent avancer en même temps, si c'est pas le cas, tu risques d'avoir des escaliers.

il ya comme une contradiction non?
je suis conscient de l'escalier mais est-ce évitable ?

[gienas]

Bonsoir à tous

... Avance d'un pixel, puis descente vers le bas

ce qui signifie que tu ne realise pas le segment oblique mais la projection en segment horizontal PUIS vertical.Donc pas de simultaneité ... Les moteurs doivent avancer en même temps, si c'est pas le cas, tu risques d'avoir des escaliers ...

Je ne suis pas certain de lire la même chose que toi. Je lis:

... Pour un tracé oblique allant vers la droite en bas ... Les moteurs doivent avancer en même temps, si c'est pas le cas, tu risques d'avoir des escaliers ...

Il est bien évident que si chaque moteur fait ses pas "dans son coin" sans tenir compte de l'autre, il y a forcément des marches.

Cependant, les probabilités pour que les angles soient de 45 degré sont très minimes. Et puis, j'ose espérer qu'un pas représente une résolution très fine, que je suis tenté de qualifier d'imperceptible, ou alors c'est un "char d'assaut".

[A voir en vidéo sur Futura]

[webscience]

Bonsoir à tous,

il ya comme une contradiction non?

Non, il y a aucune contradiction, logiciellement ça se passe comme ça, après tous est envoyer en même temps.

C'est bien pour cela qu'il faut faire un G-code : https://fr.wikipedia.org/wiki/Progra...num%C3%A9rique

Tu es obligés d'arrondir tes chiffres, à prévoir logiciellement en plus ou moins.

Exemple pour une ligne droite, si tes moteurs pas à pas avance de 1 micron par pas.

Si tu veux aller à 1,4567 mm ça donneras 1,457 mm ou 1,456 mmm

L'escalier est inévitable à l’échelle nanométrique, car tu auras toujours un moteur plus rapide que l'autre, même si tous
est identique, mais invisible à l’œil, enfin reste à voir la finesse du concepteur comme le dit gienas.

Point vue programmation, si c'est une ligne oblique, il suffit de détecter le pixel qui est autour de lui pour qu'il suive le chemin
si tu veux un bout de code je te l'envoi.

A+

[zirga]

Très aimable à vous de m'apporter tous ces éléments de réponse qui contribuent à défricher mon domaine. Pour recadrer je compte sur une avance par pas de 0.025 mm sur chaque moteur, j'estime cette précision suffisante (vous me direz si non), et voici la question. Est-ilt juste dans le cadre des pas de mes moteurs de banir tout mouvement oblique (les deux moteurs en simultané) pour le remplacer par deux mouvements distincts (un pas vertical PUIS un pas horizontal ou vice versa) pour le prétexte que dans cette dernière façon de faire on a à tout moment un moteur en mode frein qui profite à la stabilité du chariot mobile? Ai-je raison de croire que même en envoyant les commandes en simultané le déplacement final reel peut ne pas etre l'oblique mais la décomposition en pas l'un après l'autre du fait des inertes et frottements différents sur les 2 axes? telle est la question . Qu'en pensez-vous. Webscience, ton code sera bienvenu, le temps que je me fasse les idées sur cet aspect plutot mecanique.

[webscience]

Bonsoir,

je compte sur une avance par pas de 0.025 mm sur chaque moteur

C'est parfait

Est-il juste dans le cadre des pas de mes moteurs de bannir tout mouvement oblique (les deux moteurs en simultané) pour le remplacer par deux
mouvements distincts (un pas vertical PUIS un pas horizontal ou vice versa) pour le prétexte que dans cette dernière façon de faire on a à tout moment un
moteur en mode frein qui profite à la stabilité du chariot mobile?

Ai-je raison de croire que même en envoyant les commandes en simultané le déplacement final réel peut ne pas être l'oblique mais la décomposition en pas l'un après l'autre du fait des inertes et frottements différents sur les 2 axes? telle est la question .

Surtout ne pas bannir les deux moteurs en simultané, car tu es obligé de le faire, la solution d'un pas vertical, et un pas horizontal,
te feras des escaliers.

il faut adapter la mécanique, et l'électronique, pour éviter l'effet frein du chariot mobile, ou autre frottement, ça appartient au concepteur
de prévoir tous cela.

Si tes moteurs sont identiques et que la mécanique et ok, à l’échelle nanométrique, tu auras toujours un moteur qui avanceras plus vite
que l'autre, c'est inévitable.

Fait l'expérience avec un stylo, en traçant une diagonal sur une feuille de papier, entre deux points, décompose le mouvement en deux fois,
après tu le fait en simultané, tu vas voir qu'il y a une différence.

Pour que tu te fasse une idée voici un bout de programme, tu appuis sur Marche

A+

[zirga]

Merci Webscience.
J'ai été indisponible quelques jours je m'en excuse.
Je vais coder tout ça pour faire plus concret et te revenir au besoin si tu es toujours disponible bien sûr.

En attendant, merci vraiment.

[jiherve]

Bonsoir,
L'algo Bresenham induit des mouvements en X,en Y ou en XY mais un pas au max à chaque fois donc si ceux ci sont de faible amplitude, par exemple avec 200 pas par tour et une vis 2mm cela fait 1/100 mm qui sera lissé par l'inertie des chariots donc il n'y aura pas d'escalier mais bien sur la vitesse de déplacement moyenne varie avec l'angle du mouvement elle sera minimale sur les axes et maximale au voisinage des multiples impairs de PI/4, le ratio fait racine de 2.
Comme par principe on sort un couple par itération il n'y a normalement pas de soucis de synchronisation si aucun moteur ne saute de pas.
Par ailleurs il existe un algo du même tonneau pour les cercles ce qui est pratique, on peut généraliser à d'autres mouvements si l'on sait générer le terme d'erreur qui pilote l'algo.
Les autres algo de tracé sont du type DDA et ne sont pas vraiment adaptés au PAP mais par contre permettent de garantir des vitesses d'avance constante avec des moteurs 'non discrétisés', c'est le dual de la problématique des balayages cavalier ou TV (Stroke/raster) pour les moniteurs graphiques qui se posait il y a une trentaine d'années, çà ce fut mon fond de commerce.
Perso j'ai développé sur Propeller en assembleur avec un interpréteur Gcode en SPIN et cela fonctionne bien d'un point de vue électronique , je suis dans la méca!
JR

[zirga]

Merci Jiherve pour cette réponse plutôt avisée.
Pour autant je vais me permettre de coder les deux approches et voir à l’expérience si le résultat ce voit.
Je m'excuse j'ai été pris recemment par des realisations en mecanique et l'electronique a du patienter.
Je vous tiendrai au courant de l'evolution du projet des que j'arrive à avancer.

Excellente soirée à tous!







La vie c'est pas du catch, c'est du sumo!