Pourquoi cette bibliothèque QuickStep

Sommaire:
      Objectifs de la bibilothèque QuickStep
      Limitations

Pourquoi cette bibliothèque QuickStep

En analysant les différentes bibliothèques pour les moteurs pas à pas que j'ai trouvées, et n'ayant pas les caractéristiques dont j'ai besoin, je me suis écrit ma propre bibliothèque. J'avais surtout besoin de performance.

Pas de temps mort entre deux déplacements
Bien souvent quant on enchaîne deux déplacements, il y a un temps de mise en place du nouveau déplacement qui entraîne un temps d'arrêt entre ces deux déplacements. Ainsi faire deux déplacements de 200 pas n'est pas identique mécaniquement à un déplacement de 400 pas. Il y a un petit arrêt entre déplacements. C'est dommage. Mais si on est en régime de sur-vitesse, le petit arrêt peut provoquer la perte de pas, voir l'arrêt du moteur. Dans cette bibliothèque, il n'y a pas ce temps mort dans la mesure du possible. Si les pas doivent s'enchaîner toutes les 6µs, et que les ordres sont courts, il est possible qu'il y ait un temps mort, car on a trop peu de temps libre pour pouvoir calculer et mémoriser les ordres.

Le temps programmé entre deux pas est le temps effectif
La plupart des bibliothèques que j'ai vues, font un pas, et lancent une temporisation pour utiliser micros() pour le pas suivant. Du coup si il y a quelques microsecondes entre la fin de la temporisation précédente et sa prise en compte, et quelques microsecondes entre la prise en compte et la relance de la nouvelle temporisation, tous les pas vont durer quelques microsecondes de trop. On arrive quand même à nos fins si à chaque fois que l'on programme un déplacement, on retire le temps correspondant (qui n'est pas spécifié). Je préfère que le temps entre deux pas que je donne soit le bon.

Ne pas être (trop) limité en vitesse de rotation
C'est surtout ce point qui m'était important. Surtout que je conseille fortement les moteurs pilotés en courant et en mode 16 (ou 8) micro-pas. J'ai vu une bibliothèque qui affiche qu'au delà de 1000 pas par seconde, il peut y avoir des fluctuations, mais 1000 ordres d'avancer par seconde et avec un moteur à 200 pas par tour, en mode 16 micro pas, cela ne fait que 0,3 tours par seconde (18 tr/mn). Et même en mode pas, cela ne fait que 5tr/s (300tr/s). On est bien loin de la vitesse limite du moteur (3000tr/mn en général). Je veux pouvoir tourner au moins 100 fois plus vite.

Je veux pouvoir utiliser du code bloquant quand mon moteur tourne
Une fois que mon ordre d'avancer est donné, je veux pouvoir faire autre chose, comme tracer une droite sur un écran. Je ne maîtrise pas forcément ce tracé qui peut être bloquant. De plus si je donne plusieurs ordres de déplacements (il faut bien entendu que ces demandes ne soient pas bloquantes), je dois pouvoir utiliser tout le temps mis pour faire ces différents ordres pour faire autre chose (par exemple effacer un écran qui est bloquant et qui peut prendre plusieurs centaines de ms). En fait si j'utilise deux codes en même temps, il est inutile que les deux soient bloquants. En utilisant la gestion des moteurs pas à pas avec une bibliothèque non bloquante, cela simplifie le reste du code.

Je veux pouvoir faire tourner un seul moteur ou gérer le mouvement de deux moteurs
J'ai essayé une bibliothèque pour gérer deux mouvements en même temps. Tant que la vitesse est faible tout se passait bien, mais quand j'ai été un peu plus vite, cela ne fonctionnait plus. Ci-contre le déplacement obtenu pour deux déplacements identiques aller de 1000 pas, suivi d'un retour par le même chemin de 2000 pas. Le tracé s'est fait dans le sens horaire. Pour une vitesse faible j'obtiens bien une droite (trajets droits qui se superposent entre l'aller et le retour), mais pour une vitesse plus élevée (sans passer en sur-vitesse!), apparaît un hystérésis. Le moteur X va plus vite que le moteur Y, ce qui fait que le tracé s'incline, et quand le moteur X a fini son déplacement, il s'arrête et le moteur Y finit sa course. Pour chaque déplacement, il y a donc deux segments de droite. Ceci ne me convient pas et ne permet pas le passage en sur-vitesse par accélération. Je veux donc un tracé rectiligne et ce quelle que soit la vitesse. J'ai donc écrit la bibliothèque pour gérer les moteurs soit indépendamment soit par deux.

 

Limitations

Si on utilise Step, il doit être actif sur front montant
Dans cette bibliothèque, le signal Dir peut changer entre le front montant de Step et son front descendant. Si on utilise Par contre tout fonctionnera correctement si les ordres enchaînes sont dans le même sens, ou si les ordres ne sont jamais enchaînés.

Certains drivers ne précisent pas comment savoir à l'avance sur quel front le moteur avance. Voir la page "Mon moteur avance-t-il sur front montant de Step?" pour savoir.

Les bases de calcul sont le nombre de pas et l'intervalle entre chaque pas.
Certaines bibliothèques demandent l'angle de rotation souhaité. Cela pose des problèmes de représentation, car il faut utiliser les réels avec les risques d'arrondis qui vont avec. Avec un moteur 200 pas par tour, si je veux avancer d'un seul pas, il faut que je programme un angle de 0,555555555... degré. Il y a forcément un arrondi quelque part, et rien ne me garanti que si je répète 200 fois cet ordre, je fasse exactement un tour. Autre exemple, si je demande, toujours avec mon moteur 200 pas par tour, de tourner de 120°, il devrait tourner de 66,666... pas, mais comme c'est impossible, il va sans doute tourner de 66 ou 67 pas (cela dépend comment est fait l'arrondi). Du coup tourner 3 fois de 120° ne fera pas 360°. C'est pour cela que pour les déplacement, je préfère donner le nombre de pas.

Je conseille très fortement l'utilisation des micro-pas si ils existent; 10 à 16 me semble une bonne valeur. Il faut alors indiquer à la bibliothèque le nombre de micro-pas à faire, par exemple demander un déplacement de 200*16 pour faire un tour avec un moteur 200 pas par tour en mode 16 micro-pas. En fait celle valeur 200*16 doit être calculée quelque part; si c'est la bibliothèque qui doit le calculer, cela prendra le même temps que si c'est l'utilisateur. Mais ce dernier n'a pas forcément besoin de le calculer dans le programme. On économise autant de temps pour faire autre chose. Comme certain disent utiliser des moteurs 2048 pas (car ils tiennent compte du réducteur de vitesse) on peut parler d'un moteur 3200 pas part tour si on est en 16 micro-pas. Si maintenant le moteur est inséré dans une table croisée, on peut aussi calculer une fois le nombre de pas par cm et utiliser ce nombre.

De même toutes les bibliothèques programment l'intervalle de temps qui sépare deux pas. C'est donc cette valeur qui est demandée. Si vous avez une vraie vitesse en pas/s, faites passer l'inverse (en réalité l'inverse multiplié par 2.000.000 si l'intervalle doit être passé en demi-microsecondes, par 250.000 si l'horloge est de 4µs...).

Les accélérations et décélérations se font par palier
Il est possible de calculer les intervalles des pas pour que la vitesse augmente progressivement. Mais dans ce cas il faut un calcul par pas, ce qui prend beaucoup de temps. J'ai choisi de faire des accélérations par paliers car il y a beaucoup moins de calculs à faire et ces derniers sont plus simples. Cela laisse plus de temps libre pour faire d'autres tâches.

Les accélérations et décélérations doivent être passées en nombre de pas
Par exemple, on dira "je veux que mon moteur fasse 3200 pas, mais qu'il accélère sur les 200 premiers pas". Normalement une accélération se mesure en pas par seconde carré. Ce n'est pas parlant, je ne suis pas sûr que beaucoup de monde sache calculer une accélération. J'ai eu une fois à le faire, j'y suis allé par essais successifs et pas par calcul.

Les accélérations partent de la vitesse nulle et décélérations finissent à vitesse nulle

Il n'est donc pas prévu de tourner à 50 pas/s puis d'accélérer lentement pour arriver à 100 pas/s. Si tel est votre souhait, rien ne vous empêche de calculer vos paliers de vitesse pour le faire et appeler plusieurs fois l'ordre de mouvement.

Le nombre de moteurs utilisables est limité
Pour l'instant il faut un timer pour un seul moteur ou pour une paire de moteurs associés. Sur une Uno, il n'y a qu'un seul timer 16 bits. Sur la méga, il n'y en a que 4. Un projet est d'utiliser aussi les timers 8 bits, qui permettrait d'utiliser 3 moteurs ou paires de moteurs sur une Uno et 6 moteurs ou paires de moteurs sur une Mega. Un autre projet est de n'utiliser qu'un seul timer pour autant de moteurs que l'on souhaite.

 


dansetrad.fr Contactez-moi