31 réponses à ce sujet

[Fabarbuck]

Bonsoir,

Encore bonne pioche.

Le pas à pas de Selectronic est moitié moins cher que le Sanyo, il est un peu moins puissant, mais comme je suis surdimentionné, même si sa courbe est moins bonne, il devrait faire l'affaire.

Sur le site de DigChip à mc33887 j'ai obtenu mc33888 qui semblait aussi adapté au problème.
Sur le site de Freescale, j'ai bien récupéré la doc du mc 33887. C'est celui la que tu conseilles. Peut-on lui adjoindre un circuit genre 74 LS 123 ou autre afin de réduire le courant quand il ne reçoit pas d'impulsions car je ne sais pas si non alimenté le couple de maintien est suffisant.
Autre question, si j'opte pour une boucle fermée, le plus simple sur le plan mécanique est un potar sur l'axe, mais ça impose une entrée analogique suivie d'une conversion. Il serait plus logique de rester en digital, on peut mettre une roue dentée mais peut-on distinguer le sens de rotation afin de compter et décompter ?

Super si tu as trouvé ton bonheur chez Selectronic
Si tu cherches des moteurs un peu spéciaux, tu dois aussi pouvoir trouver dans les magasins plus industriels... mais bon si ceux ci te conviennent, c'est parfait !

Tu as des infos directement sur le site de freescale, aussi.

Je ne connais pas les circuits logiques dont tu parles, mais tu peux parfaitement faire un asservissement en courant directement avec le mc33887 (ou consort) et le microcontroleur ; tu peux mesurer le courant qui passe, et inclure cette valeur dans ton asservissement.
Si tu veux etre en roue libre, c'est facile, tu mets ton pont en haute impédance (enable inactif), et du point de vue du moteur, c'est comme s'il n'était pas branché.

Pour ce qui est de la boucle fermée en position, tu as plusieurs options ; il existe des moteurs pas à pas avec un encodeur accouplé sur l'arrière de l'axe, ou alors tu peux utiliser un capteur de rotation.
Il y en a plusieurs types: le plus courant, c'est l'encodeur en quadrature (google est ton ami) qu'on trouve par exemple dans les souris mécaniques ; il y a deux capteurs infrarouge, qui te permettent de compter des impulsions, et aussi de déduire le sens de rotation. En fait, ces deux voies de capteur te donnent une valeur sur 2 bits, et il y a donc 4 états possibles. Selon les transitions que tu observes, tu peux savoir dans quel sens tu fais un pas quand tu en fais un.
L'autre famille de capteur rotatif, ce sont les résoveurs. Ca utilise plusieurs bobinages placés judicieusement, et en faisant des mesures, tu peux avoir une image de la position absolue sur un tour. c'est un poil plus compliqué, mais bon, ca existe aussi.
La solution avec un potar est possible aussi... tu peux d'ailleurs utiliser des convertisseurs analogiques numérique intégrés au uC pour récupérer la valeur (comme dans un servomoteur de modélisme). Le soucis, c'est que ca s'use, et qu'en général, tu ne peux pas faire un nombre illimité de tours....

L'autre option, c'est de mesurer une translation à un endroit de ton mécanisme, avec par exemple un pied a coulisse digital à sortie série (ou bien les capteurs type LVDS, qui utilisent un principe similaire ; c'est un peu un résolveur linéaire), ou bien un capteur de distance type sharp.

Désolé, c'est pas très bien écrit tout ca, mais je suis crevé ! Ca devrait quand meme te donner quelques pistes

[H.Cou29]

Bonjour,

Concernant le but du composant annexe:
La valeur du courant alimentant les phases du moteur est réglé par la valeur d'une résistance quelque part dans le circuit.
Le composant annexe permet de mettre une autre résistance en parallèle avec la première si aucun ordre de marche n'est donné au moteur, c'est une opération indépendante du logiciel, pourquoi s'en priver.

Début de cahier des charges !
D'abord une précision sur ce que je veux faire:
J'envisage dès maintenant 2 axes identiques, en laissant une possibilité pour un troisième si ça ne complique pas. On ne fera cependant qu'une seule carte d'alimentation pour 1 moteur pour faire les essais.

Organisation matérielle.

Je verrais (conditionnel) une platine contenant les alimentations contrôle (5V) et puissance, sur laquelle viendrait s'enficher les cartes:
-- Uc et dialogue avec le port série ( max 232)
-- Alim moteur 1
-- alim moteur 2
-- place pour alim moteur 3
-- place pour carte de gestion autonome

La carte de gestion autonome, comprendrait:
une sélection de l'emplacement de la carte du moteur à commander,
un commutateur de marche AV et AR,
un potar de réglage de vitesse,
un poussoir de marche (en vitesse lente, avance de pas à pas).
Cette carte génére des impulsions pouvant faire fonctionner les moteurs via leurs alims mais indépendamment de l'Uc et comme j'opte pour une mesure de position par potentiomètre, un simple voltmètre me permet de repérer la position et suffit pour les essais de la mécanique.


Sans trop entrer dans le détail, le rôle de l'Uc serait:
le dialogue avec le pc,
la gestion des asservissements,
La sortie des trains d'impulsions.

En fonctionnement normal le dialogue avec le pc se résume à la receptions des infos, mais pour les essais, je souhaiterais renvoyer sur le pc l'info de la position de la mécanique pour qu'en mode debug, je puisse vérifier la qualité de l'asservissement. Actuellement dans le pc, j'ai fait une simu d'un asservissement et j'enregistre dans un fichier texte les positions données par le logiciel et celles sensées être obtenues après asservissement.

Je ne pense pas que le retour de position soit utile, mais il vaut mieux la prévoir en conv. A/D sur l'Uc.

Tous les x temps (x varie de 0.10s à 0.15s), le pc envoie une info (3 fois 2 octets) qui doit générer une interruption dans le programme d'asservissement, ces valeurs sont reprises par l'Uc qui calcule alors les éléments du fonctionnement moteur pour la durée de 0.15s qui suit. Je serais en retard d'au moins 0.15s.

Pour fabriquer des impulsions pour une sortie, je vois à peu près comment faire mais, pour deux sorties en même temps, avec des fréquences différentes, je cale.

Voilà où j'en suis en cette fin de jour.

[Fabarbuck]

héhé, ca se précise, apparement

Ok pour le role du composant. Pas certain d'avoir tout pigé, mais c'est pour fixer une valeur max de courant par phase, non? Pour cela, on utilise effectivement souvent un potentiomètre qui va donner une tension de consigne max. A partir de là, deux options: l'option purement logicielle, ou c'est le uC qui pilote la partie puissance, qui va comparer la valeur actuelle du courant et la valeur de consigne, pour piloter la partie puissance en correspondance. C'est plus flexible et plus simple coté matériel. L'autre solution, c'est d'avoir un montage physique (du genre un comparateur rapide, qui désactive la partie puissance si le courant dépasse la valeur limite). C'est bien parce que c'est potentiellement plus fiable et plus réactif, par contre, ca devient coquin de faire un asservissement dans l'uC s'il n'est pas 'au courant' de ce que fait réellement la partie puissance.. (la réaction de la boucle de courant est percue comme une perturbation pour l'asserv de vitesse/position, en gros).

Ca me semble une bonne idée de faire des le départ ce qu'il faut pour piloter un axe, et ensuite, de le dupliquer au besoin. Par contre, il faut bien prévoir le fait que le pc ne va pas lui meme adresser les différents messages à tes différentes cartes... enfin, j'en sais rien, il faudrait voir la tete des messages d'info qu'envoie ton soft !

Coté gestion autonome, si je comprends bien, c'est en quelque sorte un mode de debug..? pourquoi ne pas utiliser directement ton port série et ton pc pour piloter differement ton systeme? Ca me semble aussi simple, et quand tu en sera à faire des essais de programmation du uC, tu passeras surement par la... autant réutiliser le tout pour tester ta meca dans le meme temps.
Parce que le probleme, c'est que tu ne peux pas piloter les pas à pas (ie, générer les impulsions de controle) sans le uC... ou alors, c'est que tu t'orientes vers un système différent (électronique numérique discrete, par exemple).

Pour info, tu fais tes simulations d'asservissement comment?

Coté retour d'information, sauf si le uC est plein à craquer, il y aura la place de l'ajouter plus tard... à la limite, autant prévoir la place pour, meme si tu ne le fais pas tout de suite

Tu peux faire des essais, 0,10s à l'échelle du uC, c'est assez long... il y a des informations sur le temps de calcul de commande en boucle ouverte d'un moteur pas à pas dans l'application note que je t'ai fourni. Avec un peu de chance, ton uC peut:

- périodiquement (la réception d'un message sur le port série déclenche une interruption spéciale. Il n'y a pas de systeme d'exploitation, donc c'est à toi de le gérer), récupérer une commande du pc et définir les paramètres à donner en entrée aux routines d'asservissement.

- périodiquement (par exemple, un timer du uC qui va se déclencher à intervalle fixe), lancer la routine qui effectue les calculs d'asservissement. On peut la lancer deux fois successives, avec deux jeux de parametres d'entrée différents, pour calculer l'asserv du 1er moteur, puis celle du 2nd moteur.

- périodiquement (idem), effectuer la commande réelle du moteur, en fonction de ce qui a été calculé précédement.

Ca donne une idée de code qui n'est pas de débutant... mais c'est tout à fait possible, en t'appuyant notamment sur l'application note pour la commande de moteur pas à pas, et éventuellement, sur l'une des app note (ou explications de sites internet) pour la communication par port série.
Tu peux peut etre faire ca autrement... ce que je te décris, c'est plus le systeme final ! Juste pour dire que c'est faisable... mais il faut commencer par faire une élec de puissance pour un moteur, une carte simple à uC qui peut la piloter, et zou, tu pourras faire des essais ! Il faut y aller progressivement

[H.Cou29]

Réponses et réflexions, très en vrac.

-1 Avec des aéronefs peu rapides, avions de club, hélico, parapente, le pilotage "aux fesses" c'est à dire par les sensations ressenties au niveau du corps, est très important. Quand tu te sens partir en avant c'est ton bras qui tire sur le manche sans que ta tête ne semble préocupée par cette tâche. En simulation, c'est presque plus difficile qu'en réel car tout ce fait uniquement à partir de ce que tu vois à l'écran, on a là un bel exemple de multi-tâche. C'est une partie de ces sensations que je voudrais récupérer .

-2 Dans les drivers industriels de moteurs pas à pas, en dehors de la gestion du mouvement existent en général 2 fonctions supplémentaires, la réduction de courant à l'arrêt afin de réduire l'échauffement et le boost au démarrage. Ces fonctions doivent être activées ou non une fois pour toute dans le programme. Je dois avoir prévu assez de puissance pour ne pas utiliser le boost, mais j'ai noté de l'intérêt pour la fonction réduction d'ailleurs très peu contraignante.

-3 Dans le logiciel de simulation FlyII, mon collègue m'a fait une dll qui me récupère l'angle de tangage pitch_vrai (200 pour 20°), ce toutes les 0.1s.
A partir de cet angle et de la mémorisation de la position (simulée) de la mécanique neff1, j'ai fait en m'imposant des limites pour la vitesse du moteur ainsi que pour son gradient, un programme ( if..if..if) qui calcule la vitesse du moteur et le nombre de pas à effectuer pendant le cycle. Ce n'est pas un véritable
asservissement, je ne fais que courrir après une valeur. Je ne pense pas qu'en 0.1s on puisse faire mieux, si ça monte pendant 2 cycles, ce n'est pas évident que ça monte encore au troisième. Partant de la position 0, je peux voir de proche en proche le suivi du mouvement. Naturellement je ne suivrais pas un looping, (je ne fais pas ça pour la foire du trône).
Quand la dll est activée, la fonction debug me crée un fichier texte dont je donne un extrait:

----------------------------------------------------------
pitch_vrai pitch_limite neff1 (time_counter) [f2th f2 neff2]
080.4678 0080 00000080 (000.0940) [-00040 -00020 000081]
082.1016 0082 00000081 (000.0973) [000040 000020 000081]
084.0176 0084 00000081 (000.1171) [000040 000060 000085]
085.3004 0085 00000085 (000.1009) [-00060 -00040 000086]
087.2813 0087 00000086 (000.1202) [000060 000040 000086]
088.7275 0088 00000086 (000.1030) [000000 000020 000089]
091.0509 0091 00000089 (000.1237) [000020 000040 000092]
092.6577 0092 00000092 (000.1077) [-00040 -00020 000093]
095.0603 0095 00000093 (000.1261) [000060 000040 000094]
096.7749 0096 00000094 (000.1124) [000000 000020 000097]
098.4307 0098 00000097 (000.0955) [000000 000020 000099]
100.9362 0100 00000099 (000.1155) [000000 000020 000101]
102.5916 0102 00000101 (000.0979) [000000 000020 000103]
105.1055 0105 00000103 (000.1177) [000020 000040 000106]
106.7537 0106 00000106 (000.0997) [-00040 -00020 000107]
109.1820 0109 00000107 (000.1198) [000060 000040 000108]
110.6183 0110 00000108 (000.1022) [000000 000020 000111]
112.4527 0112 00000111 (000.1208) [000000 000020 000113]
113.5322 0113 00000113 (000.1035) [-00020 000000 000114]

Il faut comparer la première colonne pitch_vrai (ex: 080.4678) qui est la valeur à suivre, neff1 (3ème colonne: 0000080) qui est la position du système et neff2 ( dernière valeur à droite ex:000081) celle qui est prévue pour la fin du cycle. ( neff2 sera neff1 pour le cycle suivant).

-4 Toutes les 0.1s récupérer les données, les traiter, sortir les impulsions en une seule tâche, ça veut dire que 10ms seront consacrées au traitement et que pendant ce temps le moteur doit être mis en roue libre, d'où la nécéssité d'un retour d'information. Je pense que c'est acceptable avec une liaison élastique qui absorbe les à-coups.

-5 Mon réflexe primaire de mécano m'avais conduit à décomposer les problèmes et c'est pourquoi je souhaitais une commande indépendante du pc pour les essais, (d'autant que pour l'instant, pc et mécanique se trouvent dans des endroits différents). Après réflexion, on peut adjoindre à l'Uc potars et boutons poussoir ainsi qu'un programme simple pour une commande manuelle du moteur, je retire donc une carte !

[H.Cou29]

Bonjour,

Le sujet du post était PicBasic ou Rovin, je pense que cela ne sera ni l'un ni l'autre.
Certainement que l'on peut faire beaucoup de choses en assembleur cad avec un logiciel adapté (qu'il faut avoir et bien maitriser), la programmation en basic étant certes plus simple mais moins riche en possibilités.
Certains pic pourraient satisfaire mon problème mais au prix d'une programmation qui aujourd'hui me dépasse un peu.
Du fait de leur caractère multi-tâches, les Rovin gèrent mal (tout au moins de façon simple) les "delay".
L'auteur d'une carte Universelle à PicBasic m'a vivement conseillé l'utilisation d'un Cubloc qui effectivement me permettrait de programmer facilement deux axes. Au travers de la doc, c'est le seul Uc dans lequel j'ai l'impression de m'y retrouver pour commencer simplement, ceci sans fermer la porte à un développement plus fin ultérieurement.

[Fabarbuck]

Ca me semble etre une bonne analyse Reste à tater du cubloc pour voir ce que ca vaut (je ne connais pas en détail, et je ne peux pas t'en dire plus...). Amuse toi bien !

[H.Cou29]

Bonsoir,

Je ne sais pas si c'est une bonne analyse, je viens de reprendre toute la doc AVR, elle doit être plus précise pour les inités mais moins claire pour les non initiés.
Comme il existe sur ce site des spécialistes donnant de très bons conseils, je me permet d'abuser. Merci.
Pour commencer sur des bases saines, j'aurais bien voulu avoir un kit faisant à la fois la programmation et une utilisation simple tel que l'affichage sur un afficheur de valeurs récupérées sur pc et traitées par le programme enregisté. Le STkit200 pour un ATmega88 répond-il à cette question ? en général sur les autres kit, il existe une prise pour la programmation et une autre pour une utilisation.
L'offre logicielle liée à ce kit est-elle suffisante ? sachant que je n'ai rien d'autre.
Il existe aussi l'easy3 mais je n'ai pas compris son offre logicielle, j'ai cru comprendre qu'il fallait en plus un langage de programmation.
Enfin, pour piloter en même temps plusieurs axes de façon continue, il me faudra un uC par axe et un pour le calcul, est ce que ces bêtes la s'interfacent facilement pour se passer les infos: celui dédié au calcul récupérant les données du pc et les traitant pour les envoyer aux autres.

[Fabarbuck]

Salut

Alors... c'est effectivement du boulot que de se plonger dans de la doc, et ce, pour tout le monde

Pour ce qui est des bases saines, c'est effectivement une bonne approche que d'investir dans un petit kit de développement qui marche immédiatement (ou presque, le temps d'installer tout ce qu'il faut). Le stk200 est en ce sens une bonne option ; le seul probleme: lextronic le vend super cher à mon gout... (90euros, annoncé 58 sur le site de kanda...).
Je dirais qu'il vaut mieux chercher un kit pas cher pour commencer... surtout s'il n'a pas exactement les caractéristiques des cartes que tu veux réaliser par la suite, et que donc il ne te servirait que comme support pédagogique, on va dire...

D'autre part... à des fins purement pédagogiques toujours, peut etre qu'un kit plus petit et plus simple, genre basé sur un ATtiny26 et ne faisant pas 5000000 trucs pourrait te permettre d'apprendre ce que tu as à savoir avant d'envisager la réalisation d'une carte perso. Ensuite... tout dépend de ta motivation et de ton budget.

Coté logiciels... de toute facon n'importe quel kit à avr aura amplement de quoi satisfaire tes besoins ; les outils fournis par atmel (avrstudio) et la communauté d'utilisateurs (winavr) sont assez bien faits et sont amplement suffisants pour ton utilisation.

Le kit avreasy3 je ne connaissais pas... mais encore une fois, ca devrait pouvoir faire l'affaire. Coté offre logicielle, ils sont bons princes et te filent des démos d'outils que tu peux trouver par toi meme... les outils cités précédemment restent bien entendu complètement utilisables sur cette carte...

Coté interfacage entre plusieurs uC... c'est une autre histoire. C'est possible, mais apprends déjà à te servir des fonctions de base, des outils de développement, et tu te farciras les aspects techniques relatifs à ce genre de communication plus tard

Je crois que le mieux pour toi, c'est d'avoir un kit de dev le plus simple possible avec un cable de programmation et un cable de communication avec le pc ; tu pourras faire tes premiers pas sans trop de soucis avec ca.
Après, tu pourras tester un peu le pilotage d'un pas à pas en montant une interface de puissance à relier à ton kit.
Ensuite, tu pourras prendre une carte d'experimentation, et essayer de monter toi meme un autre uC... pour te familiariser avec cet aspect. Tu pourras ensuite tester la communication entre plusieurs uC.

Voila... j'espere que ca éclaire ta lanterne... s'il reste des points d'ombre, n'hésite pas à redemander

[H.Cou29]

Bonsoir et merci pour ces renseignements.

[H.Cou29]

bonsoir,
Epilogue.
J'étais pratiquement décidé pour AVR quand j'ai rencontré les profs du Génie Electrique de l'IUT qui s'intéressent à mon problème pour en faire un projet étudiant, comme ils sont Pic, ce sera Pic avec un Pic pour les calculs et un Pic par axe.
Pour la commande des pap, j'étais décidé dans un premier temps pour une solution L297 + 2 x L6203 or selectronic commercialise une telle carte pour le prix des composants, mes essais commenceront donc avec.
Je pense qu'ultérieurement j'ajouterais dans le programme une affectations des pulsations pour supprimer le L297 et n'utiliser que 2 MC33886.
Je vous tiendrais au courant de l'avancement de ce projet, de ce qui marche et ne marche pas.

[JEF]

argh fabarbuck!!! encore un "futur utilisateur d'AVR" qui te file entre les doigts .

bon, ben perso, je prefere les PIC, ils très utilisé dans l'enseignement aparement donc c'est qu'il sont plus adapté pour apprendre, je pense que c'est mieux d'utilisé ça.

bon courage car tu as apparement pas mal de boulot........

[Fabarbuck]

Bah.. j'ai pas d'actions chez atmel

J'essaye de répondre aux questions et donner un coup de main, et pour ca, ben je parle de ce que je connais, et je ne connais pas les pics suffisament pour les conseiller ! donc... c'est pas un soucis pour moi