↑ L'Arduino , ici un modèle spécial , noir , à STM32 , commande une rangée de 4 ULN2003 (réseau de 7 Darlington) ; en haut il y a la connectique vers les moteurs , au choix des connecteurs JST XH , ou des borniers à visser au pas de 3.5mm
En bas , on a la rangée des 16 leds indicatrices
Le choix de l'arduino (programmé sous STM32duino) , s'est imposé car je voulais quelque chose d'assez puissant , avec des convertisseurs ADC de qualité , et 16 sorties PWM pour disposer du pwm pour chacune des 2 commandes de chacun des 8 moteur
Du coup , l'arduino à STM32F103RVT6 , 64 broches (le STM32 est situé , avec le CH340 pour l'USB , au dos du pcb de l'arduino , pour gagner de la place) , peut également commander directement les 16 leds , il "suffit de" faire le routage des pistes
Cet arduino , malgré les gains de place , grâce aux doubles rangées de broches et aux implantations sur les 2 faces , reste relativement imposant , d'où un encombrement du décodeur qui dépasse un peu ce que je fais d'habitude
Comme l'alim 12V dc , l'interface loconet traverse le pcb , afin de permettre de les chaîner facilement , et d'avoir un câblage fluide ; la connectique est une RJ12 (6p6c) standard loconet , ou au choix un jst xh à 5 broches , "standard moi" ; pour s'interfacer à loconet , il faut un comparateur et un transistor : ces composants , avec leurs cours de résistances , sont placés sous l'arduino
La particularité , l'intérêt , le + , bref la motivation , s'observe sous la forme par exemple des 2 résistances , R11 et R12 , placées à droite du 1er uln2003 (vous les avez ?) . C'est des résistances de shunt , mise en série entre le GND de l'uln2003 , et le vrai GND du pcb (soit le 0v de l'alim 12v dc) ; il y a 2 résistances en // , c'est pour se partager la dissipation calorique , en toute sécurité ; la tension générée par ce shunt lors du fonctionnement du moteur , est mesuré pa un canal ADC du stm32 , cela permet d'avoir une image du courant consommé par le moteur ; des échantillons sont prélevés régulièrement pendant la course du moteur , comme ça :
--↑--↑--↑--↑--↑--↑--↑--↑--↑--↑--↑--↑--↑--↑--↑--↑--↑--↑--↑ etc , il y en a 80 , soit toutes les 50ms pendant 4 secondes ; la valeur des échantillons est simplement additionnée , la somme finale reflète la consommation (le "milliampérage") moyenne
les résultats des mesures tournent autour de la valeur 500 (je n'ai pas inventé d'unité pour ça) ; quand j'empêche le moteur de tourner en freinant le curseur avec le pouce , cela tourne autour des 1500 : d'une part , car le courant consommé par le moteur contraint est plus élevé , et d'autre part car le moteur met + de temps à atteindre sa fin de course , on aura donc d'avantages d'échantillons qui ne sont pas à la valeur 0v
En tous cas , l'anomalie de fonctionnement est bien détectée , je suis satisfait (voire soulagé , car c'est toujours gonflé de partir dans le dessin et le prix d'un pcb , sans expérimentation , ni même de calcul préalable)
Je vais pouvoir continuer , et même si j'ai bien avancé , ce n'est que la partie ludique du projet qui est réalisée : il reste encore beaucoup de travail
J'ai pu remarquer que les moteurs consomment + dans un sens que dans l'autre , par exemple 550 au lieu de 450 , alors que la conception symétrique du MP1 devrait donner un résultat proche de l'égalité ? On comprend pourquoi en observent le curseur : pour le sens où il consomme le + , il part d'abord un peu sur la gauche , avant de faire sa translation vers la droite : ceci est dû au fait que sur la couronne , le maneton qui entraîne le curseur , n'est pas bien en phase avec l'arbre de la came qui actionne l'interrupteur (inverseur) de course ; est-ce un problème général , ou le résultat des tortures infligées aux 2 moteurs qui me servent pour les tests ?
On verra bien ; Le cas échéant , j'ai les moyens électroniques et logiciels pour y remédier
Edit du 18 fév 25 : l’asymétrie de course affecte tous les MP1 ; cela peut aussi être dû au moment de bascule de l'interrupteur , variable selon la profondeur actionnée par la came ; on ne peut pas demander mieux pour le prix , mais c'est dommage que le curseur parte d'abord pour aller forcer une lame qui est déjà collée , avant de prendre la bonne direction ; il faudra bien choisir , en fonction de sa longueur , la section de la corde à piano entre le moteur et l'aiguillage !
(+menues corrections)
Edit du 25 fév 25 : fin de la programmation pour la prise en compte / mise en attente des commandes (au bout de 2 jours , j'étais dans une impasse ; j'ai remis tout à plat le 3ème , et ça a fini par fonctionner) le décodeur encaisse très bien les commandes intempestives , improbables , surnuméraires , précipitées , et contradictoires , qui lui sont adressées !
prochaines étapes :
- implémentation de l'interface loconet selon ma méthode (ok (ouf) 14 mars 2025)
- gestion de la tension d'alimentation des moteurs = ajustement du pwm en fonction de cette tension
- implémentation du fonctionnement en locobuffer (interface loconet ↔ usb) : profiter de la puissance du stm32 et de sa grande capacité en ram , et de l'interface usb (de tout arduino) pour éviter d'avoir un appareil dédié
