MEFOS est un multi positionneurs de fibre optique pour la spectro multi-objets.
Il est toujours agréable de voir qu'un instrument que vous avez conçu est toujours en utilisation quelques années après sa livraison.
Quand cet instrument fonctionne plus de 20 ans après sa livraison sans avoir eu une remise à niveau ou des modifications importante c'est plus une question que l'on se pose.
Conçu pour le 3,60 m de l'ESO au Chili en 1990-91, récupéré vers 2000 et baptisé Miosotys, en oubliant de citer ses concepteurs
-- Conception du positionneur MEFOS 1990 par Remy Bellenger
-- Réalisation et intégration 1990-91 par Remy Bellenger et Régis Schmidt
Le cablage de Mefos
Carte bras
Les 30 bras
Régis Schmidt
Remy Bellenger
De MEFOS-FIFI à MIOSOTYS
La partie de Miosotys récupérée de MEFOS-FIFI se compose d'un support en fonte d'aluminium (?), de 30 bras et d'un système de contrôle-commande à 30 microcontrôleurs répartie sur chaque bras. C'est ce qui se trouve sur la photo ci-dessus.
La conception mécanique à été faite par André Collin, du bureau d'étude du CNRS de Bellevue, c'est à lui que nous devons le principal du travail.
C'est Jean Sacazes qui réalisa le moule pour la fonderie du support des 30 bras.
Le montage et la mise au point fine de la mécanique de précision, rotation, translation, revient à Raoul de l'atelier des prototypes du CNRS Bellevue.
Enfin pour la partie Contrôle-Commande la conception et spécification revient à Remy Bellenger et la réalisation et intégration fut une entreprise commune de Régis Schmidt et Remy Bellenger.
Le contrôle-Commande de MEFOS-FIFI (Ici je reprends un article paru dans les années 90 dans une revue technique)
[…]
Cet instrument se trouve au foyer primaire du télescope Européen de 3,60m de l'ESO au Chili. C'est un ensemble de 30 robots positionneurs de fibre optique situé de 15° en 15° au bord d'un cercle de 250mm de diamètre ou se forme l'image d'une portion de ciel.
Description mécanique
Chaque positionneur à deux déplacements, une rotation de ±7,5° et une translation de 120mm Ces mouvements animés par deux moteurs à courant continue, permettent le placement d'une fibre optique sur l'image d'une étoile. Les déplacements sont contrôlés par asservissement de position grâce à des codeurs optiques, une sécurité, par des contacts fins de course, existe. Enfin, chaque robot dispose d'un système de détection de collision intra-bras afin d'éviter la casse.
Le cahier des charges de l'asservissement
⁃Le système complet comprend 60 mouvements à asservir sous les contraintes suivantes :
⁃Précision requise de repositionnement mieux que 7micron-mètre
⁃En arrivant en position le bras ne doit pas dépassé sa cible.
⁃L'ordinateur de contrôle est placé à 75mètres.
⁃Le temps maximum de mise en configuration du système est de 4 minutes
⁃La fiabilité du système doit être irréprochable
⁃Enfin le système pourra être adapté ultérieurement dans une configuration à 100 bras, ce qui implique une architecture ouverte
Un Maître, des esclaves, tous frères en 51
Pour répondre à ces exigences nous avons mis en place une architecture distribuée de type maître esclaves. Nous avons disposé une carte microcontrôleur esclave sur chaque positionneur. Le besoin d'un bras est de 30 fils de commande, Moteurs, codeurs, réseau, anti-collision…
Une carte maître (carte "tiny" de Raisonance, modifiée) est disposée dans un ordinateur de contrôle, un PC/AT.
Recherche d'un réseau
Les contraintes de l'application dirigent le choix de l'interface "Maître-Esclaves" :
Un mode sériel s'impose, il limite le nombre de câbles et de connexions, donc augmente la fiabilité
Une vitesse de transfert élevée est nécessaire pour ne pas pénaliser le temps de positionnement, et pour assurer une "mise à jour" des mesures.
Enfin le temps de mobilisation des esclaves sur les communications doit être faible afin de ne pas les détourner de leurs tâches de contrôle.
Deux solutions répondant à ces critères existent parmi les réseaux spécialisés (informatique, automobile ..) mais plus simplement, l'UART commun à tous les 51 convient lorsqu'il est utilisé en mode multiprocesseurs. Nous allons voir les performances de ce mode très spécifique à la famille 51.
Le mode 2 de l'UART du 8031
Le mode 2 de l'UART du 8031 est aussi appelé "multiprocessing" car il a un certain nombre d'avantages par rapport aux autres modes de l'UART, Possibilité de générer une interruption sur l'état d'un 9em bit, bit RB8, ce 9em bit étant positionné, indépendamment des data, par le processeur appelant, bit TB8.
Ceci rend indépendant la transmission du premier octet qui déclenche l'interruption, du reste de la trame qui porte l'information. Vitesse rapide de transfert des datas, cette vitesse est ƒ/32 ou ƒ/64, soit pour un quartz à 12Mhz 375Kbaud ou 187,5Kbaud. Cette vitesse permet de ne pas pénaliser la disponibilité du processeur par des temps de transmission trop importants.
Pas d'utilisation d'un Timer puisque la vitesse de transmission est faite par rapport à la fréquence d'horloge. ce qui permet de faire une demande de transmission à un processeur parmi, au maximum, 256, et de faire le transfert de données, sans interrompre plus longtemps que l'identification du destinataire, les autres processeurs Ce mode de transmission, est un mode propre aux micro-contrôleurs de la famille 8031.
Principe du dialogue
Nous allons donc décrire l'utilisation de ce mode de transmission qui est en général mal décrit dans les documentations.Le but de ces transmissions est de pouvoir commander & interroger chaque processeur du réseau en introduisant un minimum de perturbation sur les autres processeurs. Cette perturbation est bien sûr indispensable pour qu'un esclave puisse identifier si on s'adresse à lui.
C'est le maître qui dirige le jeu et il est le seul à pouvoir le faire de façon fiable c'est pour cette raison que sur le maître il n'y a pas d'interruption. Les points de départ des communications en mode 2 sont les suivants : Le maître à quelque chose à dire à un esclave Le maître veut savoir si un esclave à quelque chose à lui dire Et si un esclave veut dire quelque chose au maître ? et bien il ne pourra le faire que si le maître le lui demande. Cette faiblesse apparente n'est pas foncièrement gênante à partir du moment où l'architecture logicielle est correctement évaluée.
Nous aurons donc de la part du maître à définir deux fonctions :
1- Questionner un esclave
2- Informer ou commander un esclave.
Fonctions auxquelles chaque esclave devra pouvoir répondre.
Procédures de transmission:
Dans une gestion de processus l'utilisation de la ligne série est souvent un point d'irrigation primordiale pour le système. Deux types d'incidents sont à redouter :
1.Attendre en vain un caractère qui n'arrive pas,
2.Parler dans le vide sans le savoir.
Dans toute liaison série nous ne devons jamais attendre plus que ce qui est raisonnable sur une ligne série, pour cela nous mettons systématiquement en place un time-out sur les attentes de caractères. Quand le maître parle à un esclave il demande à cet esclave un acquittement de la communication, m'as-tu compris ? Si la réponse est négative ou s’il n'y a pas de réponse dans un temps donné seul le maître peut redoubler la transmission. Nous travaillerons en dialogue tendu, c’est-à-dire qu'une fois que la communication est établie nous ne la lâchons pas, chez l'esclave nous restons dans l'interruption. En effet, à ces vitesses de transmission, si nous devions générer une interruption à chaque caractère la logique à mettre en place serait trop importante. La transmission d'un caractère de 11 bit, 9+2, est de 33µs, soit pour 10 octets + vecteur + CS un temps de 400µs
Protocole du dialogue :
1.Le maitre émet un mot de 9 bit avec le bit 9 à 1 et l'octet portant l'adresse de l'esclave
2.Puis un identificateur de type de transmission, par exemple si bit 7 à 0 c'est une commande et bit 7 à 1 c'est une demande d'information, le reste de l'octet contenant l'identificateur proprement dit.
3.Puis envoie ou attente de la trame de données
4.Enfin le Checksum :
1.Si c'est une commande le maître envoie le CS à l'esclave qui vérifie avec son propre cacul si c'est le même envoie au maître d'un ACKnoledge sinon au maître d'un NonACKnoledge.
2.Si c'est une demande l'esclave envoi les données puis le CS et romp la communication le maître vérifie le CS de l'esclave par rapport à son calcul Si c'est le même pas de problème sinon le maître peut refaire la transmission.
----------------------------------
Quelques commentaires techniques à propos de cet article :
Pourquoi des moteurs CC ?
Le moteur pas à pas est très à la mode et semble toujours avoir les faveurs de beaucoup. C'est pourtant, dans le cas de MEFOS, un mauvais choix, pourquoi :
Pour maintenir une fibre en place nous pouvons soit garder le moteur sous-tension, il chauffe alors à environ 70°, comme il y a 60 moteurs ce n’est pas terrible au foyer primaire d'un télescope. L'autre solution est de couper l'alimentation puis de la remettre pour un nouveau déplacement, sauf à faire une alimentation des bobines sophistiqué, à la coupure et remise sous tension les bobines du moteur pas à pas ne sont pas alimentés de façons contrôlées, il y a alors une rotation "résiduelle" qui peut au total faire plus d'une dizaine de pas non reproductibles.
Les moteurs pas à pas n'ont pas beaucoup de couple au démarrage comme en utilisation. Le moteur courant continu a lui un couple beaucoup plus important et aucun des inconvénients du pas à pas. La mécanique MEFOS doit fonctionner entre -10 et +10° donc une variation des frottements importante.
Pourquoi mettre un microcontrôleur par bras ?
Toutes les cartes sont strictement identiques, le référentiel de mouvement est donc toujours vu identiquement du point de vue du Bras.
Pourquoi un FPGA XILINX ?
Il n'y avait pas beaucoup de choix en 1989, les composants Altéra étaient de type EEPROM avec une température de fonctionnement élevée, de l'ordre de 40°. Le composant XILINX, ne consomme rien et ne chauffe pas, souple d'utilisation permet une reprogrammation dynamique, ce qui était envisagé pour sortir de situation de conflit entre bras, afin de débloquer des sécurités.
Pourquoi un LM629 ?
Parce que ce composant permet un asservissement soit sur cible soit en vitesse, une sortie avec une commande PWM et un contrôle en entrer par codeur en quadrature, précision du quart de quadrature, avec asservissement PID.
Pourquoi la fibre optique pour le réseau ?
Être au foyer primaire d'un télescope avec une transmission filaire en pièce de contrôle pose toujours un problème de référencement de masse, entre masse électrique du foyer primaire et en salle de contrôle ainsi que la masse mécanique.
Pourquoi un 51 en mode 2 ?
Il n'existait pas encore de microcontroleur avec des bus CAN intégré. Nous avons "singé" le principe du dialogue, défini un protocole totalement tolérant aux fautes et gagner en simplicité et fiabilité.
Et si c'était à refaire ?
Il n'y aurait pas grand-chose à changer sauf à tout intégrer, contrôleur et FPGA dans un même composant, à faire en CMS. Nous avions un devis pour du CMS mais en 1989 c'était encore un peu cher.
L'ensemble est prévu pour fonctionner jusqu'à 127 bras sans aucun changement de programme.
La carte bras peut aussi piloter tout système à 2 moteurs comme une table équatoriale en refaisant un pilotage en vitesse au lieu d'un pilotage sur cible, quelques minutes de travail pas plus, et nous pourrions même piloter plusieurs tables simultanément avec ce système.
Pas la peine de changer les contrôleurs, la charge du processeur est de l'ordre de 20%, donc une très grande marge.
En cours de réalisation, à suivre ...
"Venez chez moi, je vous montrerais mes Polyedres" Alfred Jarry, Ubu Cocu
Les facettes des Polyèdres
MEFOS 1991 - Miosotys 2010