ESP32 moteur pas à pas ArduinoIDE

[neo888]

Bonjour à tous,

Je suis entrain de concevoir un thermostat qui nécessite l'ouverture d'une trappe via un moteur pas à pas de type BYJ.
Le thermostat est géré par une carte type arduino ESP32 dev. Pourquoi l'ESP32? pour sa puissance et son intégration du WiFi et BLE.
Pourquoi un moteur pas à pas plutôt qu'un servomoteur? Parce que pour des question de place et de nombre de tour je n'ai pas le choix.
Je possède plusieurs moteur de ce type :
un 28BYJ-48, un ST35 et un 35BYJ412. Mon choix s'est porté sur le 35BYJ412 pour ses caractéristiques de couple principalement.
les 2 permier sont à 300 et 500g.cm alors que lui est à 3000g.cm.

Mon problème réside dans le fait que toutes les librairies sont étudiées et créées de façon à optimiser l'usage du 28BYJ-48. il a un nb de pas de 64/trs et un coef de réduction de 1/64 ->4096 pas/tour. Beaucoup de librairies ne permettent pas de paramétrer ces points (ou du moins sans rentrer dans le coeur de la librairie).
Le 35BYJ412 possède 96 pas/tour et une réduction de 1/42.5 ce qui représente 4080 pas/tour.
A l'utilisation, si les différentes librairies fonctionne bien avec le 28BYJ, ce n'est pas le cas avec le 35BYJ. La seul librairie qui fonctionne bien c'est cheapstepper et seulement avec l'exemple newMoveTo(). Seulement elle ne m'intéresse pas dans le sens où elle fonctionne avec une rotation permanente (non bloquante pour le reste du programme).
Pourquoi les autres exemples de cette même librairie ne fonctionnent pas?
On entend le moteur comme si il y avait un saut de pas permanent.

Il y a bien d'autres librairies mais encore plus restrictives dans le paramétrage (elles sont dédiée à un nb de pas de 64)
Avez-vous une idée de comment traiter le probème?
Comment faire pour ne pas avoir de saut de pas?
Il y a quelques temps j'ai conçu une cnc avec des moteurs type nema fonctionnant sous mach3 et là j'avais du modifier la fréquence de transmission pour résoudre des sauts de pas. Est-ce qu'ici le problème vient du fait que je suis en 115200Bps alors que les programme sont fait avec 9600? normalement c'est juste pour la liaison avec le moniteur non?

J'arrête les questions...
Merci pour votre aide
-----

[jiherve]

Bonsoir
le soucis c'est que nous ne savons rien de ces librairies, de la fréquence de commande utilisée, des drivers(hardware) employés etc etc.
Normalement la fréquence de la liaison RS ne devrait pas avoir trop d'influence sauf sur du code très mal écrit, en effet si la gestion de cette liaison est faite par polling cela ne fonctionnera pas bien du tout, mais même si gérée par interruption celle ci peut bouffer tout le temps CPU si activée trop souvent; donc pour voir on peut baisser la fréquence de la liaison.
Si cela continue à sauter des pas c'est peut être que la commande est trop rapide car la durée d'un pas doit tenir compte des caractéristiques électrique du moteur (L,R) et là il faudra rentrer dans le code.
JR

[PA5CAL]

Bonsoir,

Je crains que ton problème soit la conséquence de l'« Arduinisation » du développement des systèmes électroniques, qui s'appuie sur l'assemblage simpliste de briques matérielles et logicielles prédéfinies, un peu comme un jeu de Lego.

Malheureusement, si cette façon de faire est pratique pour s'initier et commencer à bricoler sans devoir apprendre et mettre en œuvre tout ce qui serait normalement nécessaire, elle finit rapidement à se heurter à la complexité de la dure réalité. Si on ne fabrique pas nos voitures ou nos avions de ligne en Lego, ce n'est pas sans raison.


Une démarche de conception correcte exigerait de connaître le besoin avant de trouver une solution qui convienne puis de choisir les éléments adaptés pour réaliser celle-ci.

Partir bille en tête sur la mise en œuvre de bibliothèques logicielles (« library » en anglais) en s'appuyant sur des exemples fournis sans vraiment savoir à quels besoins elles répondent n'est certainement pas la bonne méthode pour s'assurer d'atteindre ses objectifs, d'autant plus quand on n'a pas pris la peine de définir ces derniers.

En effet, l'apparente simplicité d'utilisation des moteurs pas-à-pas est trompeuse. S'il « suffit » d'envoyer des impulsions pour les faire avancer, leur comportement ne peut être garanti que si l'étude de motorisation du système dans son environnement (et notamment les aspects dynamiques mécaniques, électriques et de commande logicielle) a été sérieusement menée.

Sinon, il est tout-à-fait naturel qu'un moteur pas-à-pas mal commandé ou mal dimensionné se mette à sauter des pas, à réaliser des mouvements erratiques, voire à tourner dans le mauvais sens. C'est le fait qu'il puisse parfois tourner comme prévu qui devrait constituer une surprise.

Lorsque le résultat à obtenir a été correctement défini, le logiciel de commande du moteur est suffisamment simple pour qu'on en écrive le code correspondant sans recourir à des bibliothèques logicielles, surtout quand celles dont on disposent sont incertaines, et finalement inadaptées pour la plupart.


Il faut dont commencer par le commencement, en se demandant ce que les moteurs doivent mettre en mouvement (masses et moments dynamiques ? frottements ?) et quelles performances doivent être atteintes ou peuvent être réalisées (vitesses ? accélérations ?). Ces questions doivent aboutir à des équations qui conditionnent directement les caractéristiques électromécaniques des moteurs et de leurs circuits électroniques de puissance (s'il est permis de les choisir) puis la chronologie de la commande logicielle.

[neo888]

Bonsoir, et merci pour vos commentaires pertinent et qui demande réflexion !

Juste une parenthèse parce que ce n'est pas ici le fondement précis du sujet, je trouve ça intéressant et ça mériterait un débat à lui seul :

Je crains que ton problème soit la conséquence de l'« Arduinisation » du développement des systèmes électroniques, qui s'appuie sur l'assemblage simpliste de briques matérielles et logicielles prédéfinies, un peu comme un jeu de Lego.

Malheureusement, si cette façon de faire est pratique pour s'initier et commencer à bricoler sans devoir apprendre et mettre en œuvre tout ce qui serait normalement nécessaire, elle finit rapidement à se heurter à la complexité de la dure réalité. Si on ne fabrique pas nos voitures ou nos avions de ligne en Lego, ce n'est pas sans raison.

Une démarche de conception correcte exigerait de connaître le besoin avant de trouver une solution qui convienne puis de choisir les éléments adaptés pour réaliser celle-ci.

Je ne suis pas entièrement d'accords avec ta réflexion. ici il n'est pas question de fabriquer un avion ou une voiture et même si ce sont des exemples, l'arduino comme moyen de prototypage est vraiment un très bon outil (les exosquelettes, domotiques, ...) à l'heure, où concevoir une machine ou autre avec une technologie dédié qui fera que lorsqu'une panne se produit il faut tout changer, l'arduino prend tout son sens. l'outil est modulable, évolutif à souhait et finalement se situe dans la lignée d'une consommation "responsable" et peu couteuse. Alors oui j'entends ce que vous dites et je suis en partie d'accords avec vous, de plus la popularité de ce genre de produit étant de plus en plus importante qu'il y a aussi plus de soucis de compatibilité (les ordinateurs étant peut-être les premiers exemples). Bref, je n'ai peut-être pas la bonne démarche d'approche (certainement même!), mais je suis arrivé à un stade où, possédant ce matériel, il serait dommage de ne pas l'utiliser. (à la base les moteurs n'étaient pas prévu pour ça, on dira que je fais de la récup ), je ne pense pas que pour faire coulisser un volet sur 11cm j'ai besoin d'un moteur cc 220v. De plus j'avais fais un test au préalable avec un 28BYJ-48 qui faisait tout juste le travail mais je le trouvais limite en couple (frottement,...).
La complexité ne me fait pas peur, je suis autodidacte dans plein de domaine, je mets du temps à comprendre mais j'arrive souvent à mes fins. Cela fait 3 ans que j'utilise des romeo ble, uno, avec l'utilisation de rtc, SD, ecran, servo, ventilateur en pwm, gestion de leds rgb. J'y suis toujours arrivé, je suis patient et surtout persévérant, sinon il est vrai que ce côté facile de façade doit en faire abandonner plus d'un! pour ce thermostat j'ai même créé sur l'esp32 un réseau en point d'accès relié à une application mobile permettant de récupérer les infos de capteurs mais aussi de changer la consigne. Ce n'est pas parfait j'en suis sur (sans doute mal optimisé aussi), mais j'arrive à un résultat qui, une fois que j'aurais trouvé la solution pour ce moteur pas à pas, sera correct.
Bref Je clos le débat même si je le trouve intéressant !
Pour être plus précis, le but est de concevoir un panneau aérothermique complètement indépendant du conduit sur lequel il est raccordé, ce qui implique que tout doit se trouver sur le panneau lui même (donc un registre traditionnel ne peux pas faire l'affaire à cause du câble d'alimentation mais aussi de son prix)
Je reviens au sujet et je vous joints des photos pour montrer ce volet dont toutes les pièces sont fabriquées avec une cnc et en komacel 6mm (le matériaux est léger, la surface est lisse):
Sans titre1.pngSans titre2.pngSans titre3.png
la courroie de type T5 n'est pas dessinée mais je pense que vous voyez le principe. Il y a un pignon maitre et l'autre esclave, la courroie est directement fixée dans le volet de part et d'autre dans les empreintes. Il y a deux trous, le volet coulissant suivant les températures récupérées ouvre ou ferme l'accès à l'une des deux sorties. Le tout a été conçu de tel manière qu'une circonférence de pignon corresponde à la totalité du déplacement. Donc le moteur pas à pas doit faire exactement un tour pour atteindre sa position.
Le test est concluant avec le 28BYJ, sauf qu'il est un peu faiblard. en changeant de moteur je récupère ainsi un couple 10 fois plus grand qui ,et j'en suis sur, est largement suffisant et un fonctionnement 12v indépendant de l'esp32 (via une alimentation général 12v) .
Le soucis comme énoncé ce sont les librairies (ou moi! ) mais ce que je comprend encore moins c'est que le moteur fonctionne sous une librairie mais qu'avec UN de ses exemples!

Donc ce que je me suis dit:
-J'ai besoin d'une fonction bloquante (cheastepper en fournit). c'est à dire que le reste du code est bloqué le temps de l'opération. j'imagine que le cpu sera intégralement fixé sur celle-ci et donc moins de risque de perte de pas.
-D'une librairie fonctionnant avec un moteur BYJ mais avec un pas de 96 et une réduction de 42.5 au lieu de 64 et 64.
-Le moteur a une connectique identique à l'autre moteur, c'est à dire de type XH à 5 fils pilotable avec un contrôleur uln2003a 5-12v (géré aussi par cheapstepper).

Cette librairie correspond à mes besoins. Est-elle compatible avec mon moteur? c'est là le soucis. Limite, me plonger dans la librairie pour en modifier une partie (si c'est du c++ je devrais m'en sortir "peut-être") ça ne me fait pas peur mais je ne sais pas par où commencer. comment interpréter ce qui pourrait être la cause de ces sauts de pas.
Pour le moment je n'ai pas intégré de code dans le programme du thermostat , mais seulement tester les exemples fournis avec les librairies.

Désolé pour le roman et pour les éventuelles fautes d'orthographes (en temps normal je revérifie mon texte mais vu l'heure j'ai les yeux qui ne suivent plus! et merci de l'intérêt que vous portez à ma cause!

[A voir en vidéo sur Futura]

[PA5CAL]

l'arduino comme moyen de prototypage est vraiment un très bon outil (les exosquelettes, domotiques, ...) à l'heure, où concevoir une machine ou autre avec une technologie dédié qui fera que lorsqu'une panne se produit il faut tout changer, l'arduino prend tout son sens. l'outil est modulable, évolutif à souhait et finalement se situe dans la lignée d'une consommation "responsable" et peu couteuse.

En ce qui me concerne, j'ai commencé à m'intéresser sérieusement à Arduino il y a à peu près une dizaine d'année. À cette époque, je fondais certains d'espoirs sur cette plateforme, notamment en ce qui concerne la possibilité d'initier des néophytes à l'électronique numérique et à l'informatique industrielle, ou encore la facilité de bricoler et de réaliser des prototypes (du moins avec beaucoup moins d'efforts et de moyens que ceux auxquels j'ai dû consentir sur ce type de technologie durant ces quatre dernières décennies). J'avais néanmoins des incertitudes quant à leur justesse, et j'ai décidé de me lancer dans l'aventure afin de voir par moi-même.

Aujourd'hui, après une assez longue expérience sur les produits du projet et au contact de leurs utilisateurs (en direct et au travers des forums), le constat se résume à de relatives désillusions sur la plupart de ces questions.


Je pense toujours que le projet Arduino (avec ses cartes, son IDE et ses bibliothèques) est un bon moyen pour commencer à découvrir le monde des micro-contrôleurs et de l'électronique numérique, mais j'ai acquis la conviction qu'il était important de rapidement en sortir afin de pouvoir évoluer dans ces domaines et d'éviter de contracter de très mauvais réflexes dans la conception, le développement et l'usage de ces systèmes.

Quant à l'enseignement soit-disant apporté, force est de constater que les utilisateurs doivent commencer par apprendre tout seuls le langage C++, qu'en matière de programmation les habitudes inculquées sont bien plus adaptés à de relativement gros systèmes informatiques qu'à de petits micro-contrôleurs disposant de fonctions matérielles spécialisées et de ressources limitées, et que la maîtrise d'une chaîne de compilation n'est pas au programme. De plus les promesses d'apprendre l'électronique au travers de ce projet sont totalement illusoires, les bases essentielles étant majoritairement ignorées, même en matière d'électronique numérique. Le fait que, sur les forums consacrés au projet, les conseils soient généralement prodigués par des bricoleurs visiblement incompétents (et qui parfois se complaisent dans leur médiocrité tout en empêchant les autres de dépasser leur niveau) n'est pas fait pour arranger les choses.

Au bout du compte, le projet tend plus à produire des joueurs de Lego et des apprentis-sorciers que des personnes aptes à apprendre à développer sérieusement un appareil fiable et fonctionnel.


Question matériel, les cartes Arduino restent pratiques à utiliser, mais il est important de garder à l'esprit qu'elles souffrent pour la plupart de défauts de conception, et parfois de qualité de fabrication (notamment depuis qu'une partie est officiellement produite en Chine), et que le marché est submergé de clones (ou de cartes présentées comme tels) qui rendent incertaines les caractéristiques et le fonctionnement réels des éléments qu'on a en main.


Concernant la modularité, ce n'est pas un avantage nouveau (Arduino étant loin d'être précurseur en la matière), mais ce peut être également un grave inconvénient. Pour ma part, la plupart des dysfonctionnements subis avaient pour origine des problèmes de connecteurs. Et le fait que le format des cartes (Uno ou Mega) soit hors standard (le pas n'étant pas partout de 1/10") rend plus complexe et coûteux le montage de modules indépendants du projet.


À partir d'un certain niveau de complexité qui est vite atteint, l'emploi de l'ensemble des éléments du projet Arduino ne peut plus constituer une façon sérieuse de faire du prototypage. Tout au plus peut-on réaliser des « proofs-of-concept » (encore que, dans ces conditions, un échec ne signifierait pas que le concept mis en œuvre soit mauvais). Mais une fois un montage réalisé par ce moyen et apparemment en état de marche, le véritable travail de prototypage doit commencer pratiquement depuis le début. Au final c'est plutôt une perte de temps, et potentiellement une cause d'erreurs (on constate que des montages finissent par « tomber en marche » accidentellement du fait d'éléments du projet masqués par les simplifications excessives d'Arduino, et donc non maîtrisés par le développeur).

[PA5CAL]

Comme je l'ai indiqué, il faut commencer par le commencement, et non pas partir du principe que les éléments matériels, électroniques et logiciels conviennent en se basant sur de simples impressions obtenues « au doigt mouillé ». Et mettre le nez dans le code des bibliothèques pour découvrir comment elles fonctionnent (ou pourquoi elles ne fonctionnent pas comme souhaité) ne présente aucune utilité tant qu'on ne sait pas précisément ce qui devra être réalisé.


Si l'on doit s'attendre à ce qu'un moteur qui n'est pas assez puissant saute des pas, il faut aussi craindre qu'un moteur trop puissant ou bien commandé selon des séquences incompatibles avec les caractéristiques de sa charge mécanique ne réalise pas non plus le travail convenu.

Notamment, un moteur qui reçoit plus d'énergie que celle nécessaire pour atteindre la vitesse escomptée risque de faire plus d'un pas à chaque impulsion de commande. De même, si l'on commande à un moteur de passer presque instantanément d'une vitesse nulle à une vitesse rapide dans un délai trop court pour permettre à sa charge de se mettre en mouvement, ou si la mise en mouvement réussie du moteur se heurte à l'inertie de cette charge après une phase de rattrapage de jeux, alors les pas commandés risquent de ne pas être effectués, puis le comportement du moteur devenir erratique (vibrations, déplacements aléatoires). Le moteur peut même se mettre à tourner en sens inverse (notamment si après un dépassement excessif de la position centrale du pas courant, mais sans saut de pas, l'impulsion suivante survient durant la phase de rappel du rotor vers cette position)

Sur cette vidéo on peut voir un court exemple de ce comportement erratique (à 1:51). On constate que ce n'est pas une charge trop lourde qui en serait responsable.


Bref, on doit commencer par une petite étude mécanique du système afin d'établir le couple moteur et l'accélération correspondant réellement aux mouvements souhaités, conformément aux équations de la dynamique (lois de Newton).

[neo888]

Je suis d'accord avec tout ce que tu dis sur le fond, et tu as un niveau de compétence bien supérieur au miens pour constater le "dysfonctionnement" à terme de la pédagogie sur ce type de matériel. Et je te rassure, si j'avais eu les connaissances en électronique pour concevoir un vrai thermostat avec juste ce qui est nécessaire à son fonctionnement, je l'aurais fait. Peut-être ça viendra un jour, mais je ne peux pas apprendre en quelques années le soir ce qui met des années à temps complet.
Sur la compatiblité arduino, j'en convient, d'ailleurs pour ce moteur s'en est complètement le cas.
Il y a une chose aussi c'est qu'un prototypage par définition n'est pas le produit fini, il est expérimental et doit être retravaillé jusqu'à son bon fonctionnement pour en devenir une version final (comme tout), cela implique de faire des modifications, évolutions pas forcément constatées lors de la "construction théorique". Bref encore une fois le débat est passionnant et ne peut-être 0 ou 1.

Très intéressante la vidéo au passage. et il est vrai que la vitesse est l'un des problème lié au saut de pas. (j'avais réglé ma cnc sur ce point à cause du décrochage de l'axe asservi en Y).

Pour mon projet, je n'ai pas fait de calcul de frottement komacel/komacel. A l'usage les pièces glisses très bien entre elles. Ce n'est pas du téflon mais mais le coefficient est quand même réduit. Pour celui-ci je vais me contenter d'utiliser ce que j'ai déjà en ma possession et tenter de comprendre avec vous ou pas (mais je préférerais ) le fonctionnement de ce moteur avec ce que veut dire concrètement la référence et caractéristiques afin de l'exploiter dans les meilleurs conditions. Si je doit acheter un contrôler différents et quelques composants, je le ferai!

Bon je pars depuis la référence du moteur : 35 BYJ 412 - 01
Je sais que 35 exprime le diamètre du corps du moteur
BYJ : ?
412 : il me semble que ce soit lié au pilotage (exemple 48 veut dire qu'il peut être piloté avec un ration de 1 et 1/2? 4 phases et 8 phases?) 412 veut peut etre dire qu'il ne fonctionne qu'en 4 phases et 12v.
01 : doit être lié à la résistance et couple (tous les BYJ ne font pas le même couple et n'ont pas la même résistance.) à moins qu'il veut dire unipolaire (5 fils)

Je vais rechercher des caractéristiques plus poussées et je reviens vers vous!

[jiherve]

Bonjour,
c'est un PAP unipolaire 4 phases 12V donc facile à commander avec 4 transistors , les enroulements font 100ohm donc même pas besoin de transistors de puissance. En clair c'est un tout petit PAP dont le couple ne tient que par la réduction.
JR

[neo888]

Bonjour jiherve!



Donc pour le piloter il n'y a pas besoin d'un controleur? Du coup ça veut dire que chaque phase à son pin sur l'esp32 et je créé une boucle pour le faire tourner?
j'ai trouvé un tableau correspondant à la société qui fabrique le moteur avec la référence: je l'ai acheté chez gotronic, qui eux-même font appel à seeed studio qui achètent à szcxmotor.


Alors si je prends en compte ce qu'il y a d'écrit sur le moteur :
CX35BYJ412-01
12V DC 90 Ohms

ça correspondrait au 2ème dans le tableau vu la résistance. (quoique le -01 en fin de référence me ferait dire que c'est le premier mais du coup la résistance n'est plus bonne).
Chose que je ne comprends pas c'est le pas, il est dit qu'il fait 3.75°/42.5, ça veut dire quoi? si le pas est de 3.75 c'est qu'il y en a 96 pour un tour, à quoi correspond les 42.5? la réduction fait bien 1/42.5 ce qui devrait donner 4080 révolution par tour
là encore pour les couples, sur le site ils sont stipulé 3000 et 1500 gf.cm ce qui correspondrait encore au 1er (il n'y aurait que la résistance de mauvaise).
le rôle du transistor dans ce cas quel est-il? régulateur?

[jiherve]

Re
il faut un transistor commandé en tout ou rien pour commander une phase/bobine du moteur le µc ne peut le faire seul, voir sur le net le timing correct pour ces commandes.
JR

[neo888]

Il y a aussi tout le temps un paramètre d'écrit sur tous les moteur à savoir les pps (fréquence en hz il me semble) est-ce que je dois les utiliser pour définir la fréquence d'impulsion?

[polo974]

https://github.com/tyhenry/CheapStep...CheapStepper.h
ligne 42:
void setTotalSteps (int numSteps) { totalSteps = numSteps; }

donc appeler myStepper.setTotalSteps(4080);

et voilà (enfin... si la lib est ok...)

[neo888]

bonjour polo,

j'ai déjà fait cette manip mais sans succès. d'ailleurs comment ce fait-il que le moteur fonctionne nickel avec le newMoveTo() et pas le simple moveTo()? ce sont deux fonctions quasi identiques faisant appel aux mêmes variables!
j'ai même fait la manip avec la ligne 40 où j'ai remplacé 4076 par 4080 dans le .h et fait appel à cette fonction mais idem.
Il y a une autre lib qui à l'air de gérer en plus l'accélération et décélération : TinyStepper_28BYJ_48.h je regarde ce que je peux faire avec.

[polo974]

j'avais bien mis: "et voilà (enfin... si la lib est ok...)"

il faudrait bien vérifier et lire le code et peut-être aussi voir s'il n'y a pas des conflits de ressources (genre un IO aussi utilisé en sortie PWM (c'est juste un exemple ! ! !)).

je ne côtoie pas vraiment le monde Arduino, donc je vais te laisser mettre les mains dans le cambouis jusqu'aux coudes tout seul, désolé...

les moveTo(...) prennent un nombre de pas en paramètre donc le setTotalSteps ne sert qu'au modulo (pourquoi un modulo ? ? ?))

les moveDegrees(..) prennent un angle, mais gare aux arrondis...

il faut aller voir les exemples dans le git que j'ai indiqué...

sauf erreur, chaque appel est limité à un tour complet.

[neo888]

Des conflits, j'en ai eu mais résolus, j'avais toujours le même problème.

ça fonctionne bien avec Tinystepper28BYJ-48
Elle gère l'accélération et la décélération moteur.
Le seul problème que je rencontre c'est qu'il reste en mode maintient alors qu'l faudrait qu'il se coupe complètement pour ne pas chauffer et utiliser du courant inutilement. Peut-être mettre un relais sur l'alim? ou est-il possible que changer l'état des pins du moteur alors qu'ils sont gérés par la librairie?

[neo888]

Bonjour,
c'est un PAP unipolaire 4 phases 12V donc facile à commander avec 4 transistors , les enroulements font 100ohm donc même pas besoin de transistors de puissance. En clair c'est un tout petit PAP dont le couple ne tient que par la réduction.
JR

Ce cas de figure m'intéresse (en tout cas j'ai envie d'étudier la chose).
Donc si je comprends bien, normalement avec 4 pin sur l'esp32, je gère la commande des enroulements via des transistor npn (pas besoin de mofset vu la puissance), mettre une résistance entre le 1 et 3 du transistor? si oui quelle valeur?

est-il correct?
Du coup il faut que je trouve le timing pour passer d'un enroulement à un autre. en gros soit 1 pas soit 1/2 pas! et est ce que c'est là que c'est histoire de fréquences entre dans le calcul? je parle des valeurs de 600et 700 pour le moteur 2

[jiherve]

bonsoir,
schéma tout faux!
on ne place pas la charge dans l'emetteur car le µC sera bien incapable de commander la base.
Donc les bobines dans les collecteurs ,emetteur à la masse et une resistance serie (2,2k) entre les sortie du µC et les bases, il vaudrait mieux utiliser des darlington ou des MOSFET TTL compatibles, des modeles (BJT ou MOS) capable de tenir 1 A, et important penser à rajouter les diodes de roue libre et des découplages serieux!
JR

[neo888]

ok je vais le refaire!

Si j'essaie de comprendre, les diodes servent à empêcher le courant produit par le moteur en roue libre de revenir vers le transistor et de créer une surcharge?
Mais au final, quel est la différence entre un uln2003 et ce type de montage? la puissance admissible est supérieure? car au final j'utilise un uln2003 pour mon PAP. Du coup ce qu'il me manque c'est ce fameux timing et gérer moi-même dans mon programme les impulsions à envoyer via les 4 pins?

[jiherve]

Re
avec un ULN2003 branché correctement cela devrait fonctionner. Pour ce qui est de la commande soit tu depends des librairies soit tu te paluches le code mais si tu ne maitrises pas cet aspect logiciel alors essayes de de tuyauter sur les librairies.
lis bien la datasheet :http://www.ti.com/lit/ds/symlink/uln2003a.pdf
JR