Utilisation

L'utilisation de ce composant peut être très diverse. Obtenir le fonctionnement désiré est souvent un jeu de piste et demande une certaine persévérence.

Cible

Selon la cible choisie et l'utilisation du LM629, les approches peuvent différer. L'utilisation du LM629 va entrainer plusieurs recommandations.

On distingue 2 cas, que l'on peut considérer d'extrêmes :

• Utilisation sur une cible plutôt limitée, à la fois en entrées/sorties, en possibilité de manipulations de données et surtout de calcul mathématique. (Une très grande majorité des microcontrôleurs sont dans ce cas : PIC ...).
  Si réaliser plusieurs opérations en virgule flottante demande une place mémoire, et un temps d'exécution considérable, alors on est dans ce cas.
  Ici, la communication avec le LM peut déjà demander un certain nombre de ressources (recréation d'un bus, etc). Le LM629 sera utilisé comme un périphérique à part entière. Il n'y a pas non plus de calculs (Conversions d'unité) entre les différentes grandeurs (vitesse, position, etc) du LM.
  C'est à dire, qu'il lui sera demandé d'effectuer une trajectoire. On ne se soucie pas de l'exécution proprement dite de la trajectoire. Seules la fin de la trajectoire, les erreurs ... sont importantes.
  • L'utilisation de l'IT devient intéressante, pour signaler les différents problèmes, erreurs, etc.
  • Les commandes demandées resteront simples.
  • Les communications avec le LM ne seront pas permanentes, mais juste en cas de nécessité.
  • Lors du codage, si la place est limitée, on essaiera de faire au mieux pour s'adapter aux différents formats des valeurs à envoyer (COUNT,SAMPLE, entier, virgule fixe, etc). Ces unités n'ayant souvent rien à voir avec les réalités physiques (mètres, secondes, etc). Il sera envisagé soit des "précalculs", soit des raisonnements exclusivement basés dans les unités du LM (COUNT, etc).
  • Le LM dans cette optique permet de conserver une position du moteur, une vitesse et les différents paramètres de la commande. Il soulage le micro de ce travail et permet de libérer de la place mémoire et du temps de calcul.
  • Cela impose de se soucier de l'action exacte de chaque commande pour ne pas venir 'corrompre' une des valeurs internes du LM (position), etc.
  • Cette approche est réalisable dans le cas de la commande d'un moteur devant effectuer un déplacement d'un certain angle ou d'une certaine distance, un maximum de paramètres étant "précalculés" lorsque cela est possible.
    
    
• Utilisation sur une cible pouvant réaliser aisément des calculs en virgule floattante (typiquement un DSP, gros µC ayant des fonctions de multiplication en hard) sur des procédés plus complexes. Ce cas peut se poser lorsqu'il s'agit de commander de façon coordonnée plusieurs moteurs.
  • Il est souhaitable de réaliser une couche (plusieurs fonctions) permettant de "s'abstraire" des différents formats utilisés par le LM (COUNT, etc), d'une part pour commander le LM via des unités plus parlantes (mètres, secondes, etc) et d'autre part pour ne pas avoir de problèmes lors de calculs entre les différents valeurs utilisées.
  • L'utilisation va se limiter à un périphérique capable de réaliser l'asservissement du moteur et de gérer le codeur (compteur/décompteur) permettant d'avoir une information absolue.
    La génération de trajectoire sera utilisée mais peut aussi être détournée par l'envoi régulier et à fréquence élevée de consignes.
    
  • Les paramètres contenus dans le LM seront avantageusement mémorisés dans la cible (DSP, etc) permettant une utilisation plus souple, en permettant notamment de redémarrer le LM sans se soucier de la perte ou de la corruption de ses données internes.
  • L'utilisation de l'IT peut être remplacée par une communication régulière (lecture de position, vitesse, etc) : polling.

Ces 2 approches sont des cas plus ou moins antagonistes, mais dans la pratique on peut être entre les deux.

Utilisation

Le développement d'applications avec le LM est grandement simplifié, si l'on peut visualiser les différentes valeurs que peut retourner le LM. Sur des architectures micro limitées, cela peut être assez complexe (afficheurs, sortie analogique, etc). Sur des structures plus grosses, il faut souvent réaliser une couche logicielle supplémentaire permettant cette visualisation.

Dans tous les cas, en testant les éléments les uns après les autres on réduit les sources de problèmes potentiels en fractionnant la recherche des erreurs. Le temps "perdu" à l'implémentation de fonctions qui ne sont pas directement utiles pourra être gagné par la suite en réduisant le temps de recherche des erreurs ...

Tester le fonctionnement du LM

Cette étape permet de s'assurer à la fois du fonctionnement de la communication avec le LM et du fonctionnement du codeur optique.

Il faut alimenter le LM et y relier une horloge ainsi que le signal de reset.

Le codeur optique doit être alimenté et relié aux broches A et B du LM (L'index IN étant ramené à 1 via une résistance de pull up, 1k par exemple). On doit pouvoir détecter des impulsions lorsque l'on tourne le codeur (plus le codeur est précis et plus il faudra tourner peu). On peut soit regarder ces impulsions à l'oscilloscope, soit les tester au multimètre (ce qui impose d'avancer TRES peu le codeur pour avancer d'un demi pas ...). Ces impulsions arrivant au LM, celui-ci peut travailler et compter/décompter la position actuelle.

Il est possible de relier le LM directement sur un bus (DSP, gros µC par ex), ou sur un bus recréé (petit µC).

Il est nécessaire de commencer par coder la fonction permettant de lire le registre de status (il s'agit d'une lecture sur le registre de commande). On pourra donc :

• Attendre que le bit 'BUSY', ne soit plus à 1.
• Faire attention que le bit 'COMMAND ERROR' soit à 0. Dès qu'il y a une erreur de protocole (lecture/écriture sur le mauvais registre,etc), ce bit passe à 1 et bloque toute autre commande ! Dans un premier temps, on peut se contenter de le signaler (led, message, etc) et réinitialiser le LM à la main. Par la suite, on peut gérer ce cas et aller effacer cette erreur (RESET_INTERRUPTS)

On peut envisager ensuite l'envoi de la commande READ_REAL_POSITION et la lecture de cette position réelle (lecture de 4 octets de données). On doit voir la valeur lue évoluer en fonction de la rotation du codeur.

On s'assure ainsi que :

• Le LM fonctionne.
• La communication par le BUS est correcte.
• Le fonctionnement du codeur est correct.

Récupérer la position actuelle

La commande présentée comme test au-dessus permet de récupérer la position réelle. Elle peut être effectuée périodiquement (si l'on souhaite garder une trace de la position actuelle ou la traiter avec d'autres capteurs) ou sur demande lorsque cela est nécessaire.

Tester le fonctionnement du générateur de trajectoire

Pour tester le générateur de trajectoire, il est nécessaire de :

• Charger une trajectoire par LOAD_TRAJECTORY_PARAMETERS on indique :
  • Une position à atteindre (qui peut être déterminée par les essais effectués sur le codeur plus haut)
  • La vitesse maximale en COUNT/SAMPLE
  • L'accélération maximale en COUNT/SAMPLE/SAMPLE
    
    Des valeurs trop petites peuvent entrainer une trajectoire trop rapide et l'on ne pourra pas voir son évolution.
    
    
• Effectuer un START_MOTION, pour lancer cette trajectoire.
• Lire la position désirée actuelle par READ_DESIRED_POSITION. Cette position doit évoluer pendant la génération de la trajectoire et finir par atteindre la position à atteindre ...

Démarrer une trajectoire 'physique'

Démarrer une trajectoire physique (effectuant donc un déplacement) demande nettement plus d'opérations. Il est nécessaire de :

• Pouvoir communiquer correctement avec le LM (cf tester le fonctionnement).
• Pouvoir générer une trajectoire (cf tester le fonctionnement du générateur de trajectoire).
• Connecter l'étage de puissance en sortie du LM (PWM et sens).
• S'assurer du fonctionnement du codeur en lisant la position réelle par exemple.

Le démarrage de cette trajectoire physique demande de :

• Charger une trajectoire.
  On choisira avec interêt une trajectoire devant effectuer un déplacement assez lent (vitesse maximum assez faible) de préférence. (en utilisant le test du fonctionnement du générateur de trajectoire au dessus par exemple). On ne réduira pas trop l'accélération pour assurer un démarrage assez rapide.

• Charger un filtre PID par LOAD_FILTER_PARAMETERS. On indiquera uniquement un coefficient sur P, assez faible mais NON NUL.

• Appliquer ce filtre par UPDATE_FILTER.

• Lancer la trajectoire par START_MOTION.

A ce moment, le générateur de trajectoire doit se lancer. L'erreur entre la position réelle et la position désirée doit augmenter. Le filtre PID va donc envoyer au moteur une commande (tension) proportionnelle à cette erreur. Si le système se trouve cablé dans le bon sens, la tension appliquée va tendre à réduire cette erreur et la vitesse va se stabiliser. Sinon, l'erreur va tendre à augmenter et le système va diverger jusqu'à entrer en saturation. Il faut dans ce cas inverser les 2 fils du moteur par exemple.

Tester la fin d'une trajectoire

La fin du travail du générateur de trajectoire est déterminée par le bit 2 du registre de status. A ce moment, le générateur de trajectoire a terminé, mais l'erreur entre la position désirée et la position actuelle n'est pas forcément nulle (donc le mouvement pas forcément réellement terminé).

En fonction de ce que l'on souhaite faire (enchainer une autre trajectoire ou déterminer un arrêt complet) il faudra utiliser d'autres commandes (position réelle ...)

Arrêter une trajectoire prématurément

L'opération peut s'avérer plus hardue que l'on ne peut le penser.
Si l'on souhaite arrêter le générateur de trajectoire, il est possible (en théorie -- non testé) de charger par LOAD_TRAJECTORY_PARAMETERS (pendant la trajectoire), une commande de trajectoire ne spécifiant aucun paramètre mais positionnant un des 3 bits suivant à 1 :

• bit 2: Arrêt "doux" du moteur, le générateur de trajectoire va commencer directement à générer une décélération. La vitesse va donc ralentir "doucement" jusqu'à l'arrêt. Il faudra ensuite attendre que l'erreur d'asservissement diminue (ce qui sera sans doute très bref).
• bit 1: Arrêt "rapide", la position à atteindre et la position désirée vont immédiatement être forcées à la position actuelle. On perd donc la position à atteindre. Il faudra ensuite attendre que l'erreur diminue (ce qui sera sans doute très bref).
  
• bit 0: Arrêt "immédiat", l'asservissement est désactivé et le moteur finit par s'arrêter en roue libre.
  

Aucun de ces 3 fonctionnements n'a été vérifié, leur description peut être fausse mais elle est la plus probable.

L'autre technique consiste à réinitialiser (RESET) le LM ... ce qui permet d'être sûr du comportement mais implique par contre un renvoi de tous les paramètres. L'ensemble des paramètres internes du LM sont perdus (position, filtre, etc). Cette méthode peut s'avérer plus simple, surtout lorsque l'on dispose de la puissance de calcul nécessaire.

Modifier la trajectoire

On peut modifier une trajectoire pendant son exécution. Cette opération permet de l'allonger ou d'augmenter la vitesse par exemple. Le LM va alors modifier sa génération de trajectoire pour tenir compte de ces nouveaux paramètres. Il n'est pas possible de changer l'accélération (que l'on utilise le mode vitesse ou le mode position).

On demande cette trajectoire :

Trajectoire simple.

On envoie un ordre (LOAD_TRAJECTORY_PARAMETERS) et on l'applique (START_MOTION) au moment noté par le point vert, on aura :

Trajectoire modifiée "à la volée"

Pour effectuer cette modification, on effectue un chargement de trajectoire. On ne peut pas changer d'accélération, sinon on reçoit COMMAND ERROR. On suppose que la trajectoire initiale est la trajectoire "simple" suivante :

 

• On charge une nouvelle position en absolu ou en relatif par rapport à la position à atteindre indiquée dans l'ordre initial.
  
  On indique donc la nouvelle position à atteindre.
  
  
  • Si la position à atteindre est plus "loin" que la position initiale :
    

  
  

  
  
  
  • Si la position à atteindre est moins "loin" :
  
  
  
  
  
  
  
• On charge une nouvelle vitesse en absolu ou en relatif (par rapport à la vitesse maximale actuelle)
  
  
  • La vitesse va augmenter/diminuer pour s'adapter à la nouvelle consigne.
  • Ici, la nouvelle consigne ne va rien changer car ce n'est pas elle qui limite.
  

On peut évidemment mélanger les 2 ...

Comportements limites

Action du Filtre PID