Tests sur des moteurs pas à pas

Sommaire:
      Pourquoi ces tests?
      Conditions des tests
      Résultats

 

Pourquoi ces tests?

J'ai besoin de faire fonctionner des moteurs pas à pas, et dans les bibliothèques standards, je n'ai pas réussi à obtenir ce dont j'avais besoin. Il est possible que ces bibliothèques ne le permettent pas, mais très certainement aussi, je ne sais pas m'en servir, et j'ai un gros problème pour trouver la doc.

Je n'ai pas réussi à faire tourner mes moteur jusqu'au décrochage en vitesse par exemple. J'ai bien essayé bibliothèque qui permettrait d'avoir une phase d'accélération, mais la vitesse finale état trop faible si je travaillait en micro-steps.

Voici mes exigences

1) Je veux travailler en micro-steps x16, ou à la rigueur x8. Pour les vitesses lentes les moteurs avancent de temps en temps d'un pas. Entre deux pas, il y a donc un arrêt, et c'est autant de chocs à chaque fois. Passer en micro-steps permet de diminuer ces chocs. A plus grande vitesse, j'ai un peu le même problème. En passant en micro-steps, je diminue énormément le bruit des moteurs.

2) Je veux pouvoir imposer ma vitesse, et si un pas est un peu en retard à cause du logiciel, il faut que le suivant arrive à son heure correcte. J'aurais ainsi un pas un peu plus long, le suivant un peu plus court, plutôt qu'un ralentissement. On peut avoir des retard dus à la remise à l'heure de l'Arduino par exemple, cela permet la gestion des fonctions delay(), micros() et millis(). Dans plusieurs bibliothèques, pour les faibles vitesses, la vitesse réelle est proportionnelle à la vitesse demandée, puis au bout d'un moment, elle devient asymptotique. Il me faut alors étalonner le logiciel pour avoir la bonne vitesse. En plus la vitesse limite asymptotique est trop lente...

3) Comme il reste du temps, je veux pouvoir en disposer, notamment, j'ai éventuellement besoin de pouvoir effacer un écran (77ms), tracer une droite (5ms)... même si il faut envoyer des pas toutes les 50µs.

4) Je veux pouvoir enchaîner deux ordres successifs, par exemple deux fois "avance de 1000 micros-pas" sans qu'il y ait un arrêt entre les deux commandes. C'est peu important en basse vitesse, mais il y a au moins deux ennuis:
- cela fait des chocs à vitesse normale
- en mode sur-vitesse les moteurs décrochent, vu qu'ils ne peuvent marquer l'arrêt

5) Je veux pouvoir tracer des droites inclinées (2 moteurs tournant en même temps, pas forcément à la même vitesse). Mais il faut aussi que ces moteurs arrivent en même temps. Je n'ai testé qu'une seule bibliothèque permettant de le faire, mais si à basse vitesse, je peux dessiner sur une table croisée le déplacement et constater que c'est une oblique, en allant un peu plus vite, la courbe se déforme et cela devient inacceptable:

Cette courbe a été obtenue à la vitesse maximale de la bibliothèque en demandant:
- avance de 4000 pas pour les moteurs X et Y
- avance de 4000 pas pour les moteurs X et Y (pour voir si il y a un arrêt avec la demande précédente)
- recule de 8000 pas pour les moteurs X et Y (revient au départ)

Sur ce tracé (déplacement du moteur X) = f(déplacement du moteur Y), on remarque que le moteur X va plus vite que le moteur Y. Le moteur X ayant fini sa course avant, il attend le moteur Y. Moi, j'ai besoin d'une droite!

6) Je veux pouvoir tracer des cercles, pour pouvoir écrire du texte.

 

Conditions des tests

La vidéo qui est faite en dessous est réalisée sur une vieille carcasse de graveur laser, filmée à vitesse normale (c'est pour cela qu'il y a un réveil). Le mouvement demandé est un mouvement accéléré circulaire de 10cm de diamètre.

La carte principale n'est pas au point, il faudrait que je mette dessus un régulateur 5V pour éviter la double alimentation. il faudra aussi que je réfléchisse à une utilisation réfléchies des ports de la carte Mega. Si par exemple tous les ordres de commande des moteurs étaient sur un même port, pour commander tout le monde, une seule écriture d'octet pourrait commander les deux moteurs. Actuellement je suis obligé de donner deux ordres séparés.

Les moteurs sont des Nema17 17HS1352 0,25N.m 1,33A, mais légèrement sous-alimentés. Ils sont pilotée en mode 16 micro-steps. Il y a 800 micro-steps par cm.

L'envoi et le calcul des pas est fait par des procédures non bloquantes, du coup, je me permets de dessiner dans les temps vides. Pour l'affichage du temps, je ne demande pas si j'ai ou pas du temps devant moi, je le fais dans tous les cas. Pour les trais colorés d'animation, je demande si la gestion du moteur a besoin de temps dans l'immédiat, si la réponse est non, je trace une droite. Sans la gestion des moteurs, je ne ferais pas la demande et les droites seraient tracées plus vite. Mais le tracé des droites renseigne sur le "temps en trop"; plus elles se dessinent vite, plus il y a de "gâchis de temps".

Le temps affiché est celui qui sépare l'envoi de deux pas si un seul moteur avance. Pour que le déplacement se fasse à vitesse constante, si les deux moteurs avancent en même temps, la vitesse pour chacun d'eux est réduite d'un facteur √2. Pour les plus fortes vitesses, la résolution de cet écart de temps étant de 0,5µs, l'affichage ne donnant pas les décimales, si on voit afficher deux fois le nombre 20µs, cela veut dire qu'il y a 20,5µs la première fois et 20,0µs la deuxième fois.

J'ai un indicateur qui m'informe si le calcul n'est pas suffisamment rapide (ou si j'ai dessiné trop longtemps) et que la succession des pas a été interrompu. Je peux aller jusqu'à 12,5µs environ. Mais je gère deux moteurs!

Le cercle est réalisé par des segments de droite, débutant et finissant sur le cercle. Le pas de ces segments est calculé pour qu'au milieu de ceux-ci l'erreur ne dépasse pas 1 micro-step.

 

Résultats

La perte de pas intervient à 18,5µs, les calculs vont être faits pour 20µs. A cette vitesse, c'est le moteur entraînant la plus grosse charge qui décroche le premier. Le second décroche à 14,5µs.

J'ai calculé qu'en dessous de 25µs je ne peux plus du tout garantir que les pas sont réguliers, car à chaque segment de droite, il me faut du temps pour recalculer les données en particulier la vitesse. En fait, à chaque segment, comme ils peuvent être indépendants, je suis obligé de recalculer à partir de la vitesse de base, la vitesse réduite de √2. La résolution temporelle entre 2 pas est de 0,5µs et le rapport √2 entre les 2 vitesses est moins précis à 20µs! Mais j'ai l'impression qu'en étant en 16 micro-steps, c'est moins grave si un des micro-step est un peu décalé.

En tout cas à 14,5µs/pas il ne reste quasiment plus de temps de libre (les droites colorées n'avancent plus).

Le timer 0 intervient de temps en temps (toutes les ms environ) pour remettre l'horloge interne à jour. Je n'ai pas constaté de différence notoire entre le laisser et l'arrêter. Je pense que la durée de cette interruption est de l'ordre de 3µs, ce qui décalerait éventuellement un micro pas.

Le mouvement du chariot central est circulaire, en conséquence le mouvement d'un moteur est sinusoïdal. Ne dites pas que j'alimente mes moteur en alternatif 2Hz, Merci.

Le déplacement est de 20µs par micro pas (je note micro pas par mp, et je dis 20µs/mp). La vitesse peut se déduire facilement:
- 1mp c'est 20µs
- j'ai 800mp/cm soit 80000mp/m
- pour faire 1 m, il me faut 80000mp/m . 20µs = 1600000µs = 1,6s
- la vitesse est de 1/1,6s/m = 0,62m/s

Sinon, le mouvement d'un moteur est sinusoïdal, la distance d(t) a la forme d(t)=R.sin(ωt), R étant le rayon (0,05m), ω la pulsation.
- un tour mesure 2πR = 2.3,14.0,05 = 0,31m
- à 20µs/mp, soit à une vitesse de 0,62m/s, je fais 1 tour en 0,5s.
- 1 tour c'est 2π = ωt et donc la pulsation ω vaut ω = 2π/t =4π
L'abscisse ou l'ordonnée sont de la forme d(t)=R.sin(4πt) (Ça va ou êtes vous d.π.t?)

La vitesse v(t) c'est la drivée de d(t) soit v(t)=4πR.cos(4πt).
La vitesse maximale V est donc de 4πR = 4. 3,14 . 0,05m = 0,62m/s (on s'en doutait!)

L'accélération a(t) c'est la drivée de v(t) soit a(t)=-16ππR.sin(4πt).
L'accélération maximale A est donc de 16ππR = 16. 3,14 . 3,14 . 0,05m = 7,8m/s2


dansetrad.fr Contactez-moi