PPECommande de Moteurs PAP avec TI89T - Page 1

Bonjour tout le monde,

Durant l'année de Terminale, chaque élève doit réaliser un projet sur six mois appelé PPE.
Cette année notre projet (on est 2) serait de concevoir une "pince amovible" un peu comme celle d'un attrape bonbons

Fichier joint :
Donc il faudrait 4 moteurs Pas à Pas. Mais le must serait de pouvoir les contrôler gràce à une interface avec la TI89T par le port IO.
Il faudrait donc faire comme le Robot de Norland Research (une voiture à 2 moteurs commandées par la TI).

On fouinant dans la sections Hardware j'ai retrouvé un programme de Thibaut Barthélemy: Commanip qui permet d'écrire et de lire sur le port IO
Fichier joint : commanip.zip
Avec un voltmetre on s'aperçoit qu'on peut controler 2 tensions (2 fils) de 3,2 V ~ .

Maintenant ma question: peut-on faire varier les tensions que la TI envoie dans les fils du port (genre envoyer une tension de 1V, ou 2V, ou 3V, ect...) ou non ??

Merci d'avance pour vos réponses

Non, ce sont des sorties numériques.

Il faudra donc que le PIC comprenne les "séries" d'information que le port envoie ? Mais là faut que je me documente...

Oui voilà, il faut que vous définissiez un protocole de communication entre la TI89 et votre PIC.

Après vous n'avez pas forcément besoin de PIC. Vous pouvez utiliser un convertisseur numérique->analogique qui se commande avec deux fils pour générer vos tensions de sortie.
Une bonne piste est de regarder les composants compatibles I²C car la partie logicielle a déjà été faite sur TI89. Par exemple le circuit TDA8444 qui a 8 sorties analogiques avec 64 niveaux de tension pour chaque :
http://www.standardics.nxp.com/products/tda/datasheet/tda8444.pdf
http://www.selectronic.fr/article.asp?article_ref_entier=10.1289-9999

Merci pour tes explications Zerosquare je vais voir ça de plus près.

Juste une précision: le port IO de la TI est compatible avec les composants I2C?? parce qu'il y avait des débats la dessus sur le forum Hardware si je me souviens .

Je suis pas spécialiste du hardware de la TI, mais je pense que ça doit pouvoir fonctionner. Il faudrait vérifier la tension pour l'état haut qui est un peu basse (normalement l'I²C fonctionne en 5 volts), mais pour le TDA8444 par exemple 3.0 volts suffisent, donc ça devrait aller.

Hello !

C'est un vieux programme ce commanip ! Il fonctionne bien sur Titanium ?

Il y a une petite probabilité pour que le port Jack ait une interface à collecteur ouvert. Vous avez cherché de la doc à son sujet ? Si on a bien des collecteurs ouverts, il est facile d'obtenir n'importe quelle tension représentative du niveau haut, avec une simple résistance dite "de pull up". Sinon, ça se règle avec un transistor et deux résistances, ou encore peut-être avec une bonne vieille porte logique TTL. L'I2C n'est pas trop compliqué par rapport aux besoins ? Est-ce que les pilotes TI dont vous parlez sont livrés avec des headers C ? Tant qu'à faire, n'est-il pas plus simple d'utiliser les capacités USB de la TI ? De mémoire, Extended avait documenté l'API USB du système d'exploitation ("ROM calls").

Pour vraiment pas vous prendre la tête, je crois que vous pourriez concevoir votre programme en Basic sur la TI, programme qui enverrait des codes binaires en série sur le port Jack grace à commanip, codes qui seraient reçus par un bête registre dont j'ignore le nom mais assure l'existence C'est un petit CI qui reçoit un code bit par bit sur une patte, et qui ressort le code complet sur 8 pattes de sortie. Un convertisseur série/parallèle quoi. Ça coûte que dalle et c'est hyper simple à employer.
Derrière ce registre, il n'y a plus qu'à coller un convertisseur A/N et un demuliplexeur (en imaginant que vous reservez 2 bits sur les 8 pour commander le demultiplexeur) qui sera chargé d'aiguiller la tension analogique vers l'etage de puissance visé par le code à 2 bits, c'est à dire le moteur désiré.

Voilà ce que je peux dire, avec réserves. Ce sont des composants d'utilisation très simple. Mais si vous commandez des moteurs pas à pas, le démultiplexeur et le CNA sont inutiles, c'est encore plus simple.

Merci Thibault pour tes conseils et je crois que je vais tenter le "pour vraiment pas vous prendre la tête". Je crois que le convertisseur série/parallèle est le
PCF8574 http://www.nxp.com/acrobat_download/datasheets/PCF8574_4.pdf
Je pense commander des moteur pas à pas (enfin sa peut changer) donc je vais voir du coter de ce convertisseur.

Tes moteurs pas à pas se commandent avec combien de broches ? (c'est peut-être une question con, l'electronique c'est loin pour moi).

Ben justement on a pas encore commencé mais le projet est gros donc je me renseigne a l'avance
Donc pour les moteurs je sais pas si je prend des Unipolaires ou des bipolaires .(3fils ou 6 fils).

OK.

Ton datasheet parle d'I2C. C'est peut-être un peu trop compliqué pour l'utilisation qui en sera faite (pas d'I2C). Un registre à décalage suivi d'un registre de mémorisation serait peut-être plus simple ?

Le CI de commande du moteur a besoin de quoi comme infos ? Ça prend une valeur numérique pour la vitesse de rotation, le nombre de pas à effectuer ?? Sur combien de bits ? La capacité en bits des registres dépendra de ça. Je demande ça par curiosité, n'ayant jamais commandé ces moteurs.

Thibaut (./12) :
Ton datasheet parle d'I2C. C'est peut-être un peu trop compliqué pour l'utilisation qui en sera faite (pas d'I2C). Un registre à décalage suivi d'un registre de mémorisation serait peut-être plus simple ?

Faut au moins 3 fils pour ça : 1 d'horloge, 1 de données, et 1 un de synchro (avec un simple registre à décalage sans ce dernier fil, les sorties vont faire n'importe quoi pendant le chargement des données).

Ça n'existe pas des registres avec mémorisation intégrée ? Quand il a reçu 8 bits, il les présente sur la sortie et n'y touche plus tant qu'il n'a pas reçu à nouveau 8 bits ? Ou alors un registre à décalage qui génère un carré après avoir reçu 8 bits, ce qui permettait de commander une mémorisation ?

Si, mais faut justement un fil de plus pour que ça fonctionne bien. Sinon, si pour une raison quelconque ça se désynchronise (un parasite sur la ligne d'horloge par exemple), tout va être décalé d'un bit et ça va partir en vrille. En plus, la plupart des circuits sont dans un état aléatoire à la mise sous tension, donc il faut tout de toute façon un moyen de le réinitialiser.

"Ça prend une valeur numérique pour la vitesse de rotation, le nombre de pas à effectuer ?? Sur combien de bits ? La capacité en bits des registres dépendra de ça"


Desloe je n'ai jamais commander de moteur pas a pas mais la vitesse des moteurs ne sera pas à toucher je pense . Je pense juste commander le sens 'x' du moteur 'n' .Les vitesses seront les memes pour tous les moteurs. Par contre peut etre que commander 4 moteurs est un beaucoups...
Sinon pour le robot de Norland c'est étrange, le CI est étonnement simple , il y a juste un PIC (étonnement compliqué) qui semble tout controler.


http://www.smallrobot.com/scimath.html
http://smallrobot.bizland.com/Instructions.pdf
Le robot se commande par Send() et prend 4 parametres
1er : type de commande (pas important ici)
2e : sens du moteur 1
3e : sens du moteur 2
4e : temps du mouvement en ms

ex: send ( 222, 5000) commmande 2 (jusqu'a que t=0 ou que le capteur soit enclenché) S1= avant S2= avant t=5 sec donc la voiture va vers l'avant durant 5 sec

Zerosquare : Les petites lignes je doute qu'on puisse les parasiter. Donc ça existe ? Ça simplifierait le circuit de Sam. Pour l'initialisation, une cellule RC ferait l'affaire.

Sam : Un pic simplifie la partie matérielle, c'est sur. Toutes les fonctions de demultiplexage et autres serait logicielles. A vous de voir si on vous demande de l'informatique de bout en bout, ou si on vous demande de savoir faire de l'electronique

Thibaut (./17) :
Les petites lignes je doute qu'on puisse les parasiter.

Ça, j'en serais pas aussi sûr que toi

Thibaut (./17) :
Pour l'initialisation, une cellule RC ferait l'affaire.

Ouais, j'y avais pensé aussi, on peut même rajouter un bouton poussoir en parallèle pour réinitialiser à la main, mais ça reste de la bidouille.

Thibaut (./17) :
Donc ça existe ?

Oui. J'ai trouvé ça, mais il y a une entrée séparée pour commander le chargement des sorties, donc ça n'ira pas.
En même temps, l'I²C n'est pas très compliqué à gérer, je ne vois pas trop l'intérêt de chercher autre chose.

Après il y a plusieurs solutions possibles, ça dépend quel est le cadre du projet de Sam (mécanique ? électronique, programmable ou non ? informatique ?), pour savoir si c'est pertinent d'acheter une interface toute faite, par exemple.

Ben pour les PPE une interface toute faite ce n'est pas bon il faut plus ou moins creer le Circuit imprimé mais pour l'utilisation d'un PIC c'est bon (je prefere de loin coder sur un PIC que de trouver son équivalent en composants électroniques)
Donc je preferais l'utilisation d'un PIC. Demain j'aurais accès au robot Noraland et je noterais quel PIC est utilisé (pour avoir une idée)...

Tu n'est pas obligé de prendre le même PIC, il vaut mieux le choisir en fonction de ce que tu comptes en faire et de ce que tu peux acheter/avoir en échantillon

Tu as raison Zerosquare.

Par contre, parés avoir discuter avec mon coéquipier, j'ai choisis d'utiliser plutôt des moteurs à Courant Continu .
Donc il faudrait 8 fils ( 2 par moteurs pour les deux sens de rotation et il y a 4 moteurs) . Les sorties du PIC seraient rélies à un L298 (pont en H en Circuit imprimé) http://www.st.com/stonline/books/pdf/docs/1773.pdf qui lui serait relié aux moteurs ...

Attention, avec les moteurs à courant continu, tu n'as pas de retour d'état : tu ne peux pas savoir exactement de quel angle et à quelle vitesse ton moteur a tourné. Si tu dois pouvoir faire des mouvements programmés à l'avance, c'est gênant. Le gros avantage des moteurs pas à pas, c'est que ce problème ne se pose pas, vu qu'il suffit de compter les pas qu'on envoie.

Après on peut résoudre le problème avec des contacteurs de fin de course (s'il n'y a qu'un petit nombre de positions prédéfinies à atteindre), ou avec des codeuses optiques (qui envoient une impulsion à chaque fois que le moteur a tourné d'un certain angle). Mais ça complique pas mal le circuit.

C'est sur que utiliser des moteurs pas à pas est beucoup plus précis mais ce que je me disais c'est que notre machine mécaniquement parlant ne sera pas très précise donc même avec des moteurs PAP le problème se poserait encore.

Sinon je pensais comme tu disais à des capteurs de fin de course ou bien à un potentiometre (10 tours) qui traduira la position d'un bras par telle ou telle tension (encore faut-il pouvoir que la carte puisse envoyer des infos compréhensibles à la TI ??).

et pour info le robot TI utilise un PIC 12C509A http://www.datasheetcatalog.org/datasheets2/16/1643295_1.pdf

sam22 (./24) :
Sinon je pensais comme tu disais à des capteurs de fin de course ou bien à un potentiometre (10 tours) qui traduira la position d'un bras par telle ou telle tension (encore faut-il pouvoir que la carte puisse envoyer des infos compréhensibles à la TI ??).

Oui, des potentiomètres 10 tours sont une bonne solution aussi. Mais ça sera plus casse-pieds sur le plan mécanique à réaliser

Après il suffit que tu les connectes aux entrées analogiques du PIC que tu auras choisi. Pour la communication, ce n'est pas trop un problème, vu que les 2 côtés sont programmables tu peux faire à peu près ce que tu veux.

(double post)

Il y a eu un montage de mémoire flash I²C sur port IO qui marchait très bien, donc OUI les composants I²C sont compatibles au niveau électrique avec le port IO mais NON, le protocole utilisé par défaut par la TI n'est pas le protocole I²C.

Les pics ont souvent un port I²C, tu peux très bien envisager un pic qui fasse l'interface série TI<=>commande des moteurs pas à pas du bras.