décodeur modulaire pour réseau modulaire , à commande d'ag par micro-moteurs PAP

[trimarco232]

j'ai remarqué ce type de micro-moteur PAP sur un site express , et je me suis demandé s'il était possible de s'en servir comme moteur d'aiguille , à déployer sur mon futur réseau
les inconvénients  :
- nécessite 4 broches d'arduino au lieu de 2
- disponibilité à terme ?
- endurance ?
- fixation et raccordement : je n'ai pas de solution évidente à ce stade
les avantages :
- prix
- dimension
- pas de réglage : on envoie un nombre majoré de pas , à la fin le moteur bute et saute tout simplement  les pas en trop
.
j'ai réalisé un test avec un nano et un petit module avec ponts en H , le fonctionnement me paraît bon : il a la force qui va bien , et il est suffisamment rapide pour un moteur lent

[trimarco232]

Le décodeur , en cours de réalisation par jlcpcb , découle des projets restés en l"état :
https://forum.locoduino.org/index.php?topic=1431.0
https://forum.locoduino.org/index.php?topic=1433.0
On a une carte maître à base de nano , le décodage se fait par la méthode d'Aiko Pras , via un optocoupleur caché sous le nano ; ce dernier commande directement 8 ponts en H
A droite du nano , on a un convertisseur dc/dc qui permet de choisir la tension des moteurs , qui doit toutefois être inférieure à 12v , vu le type de pont en H utilisé ; doit aussi être inférieure à 12v , la tension qui alimente le nano , car s'agissant d'un clone , il est équipé d'un régulateur 5v de type mps1117 , qui ne supporte pas + ; pour régler ceci , j'ai reconduit ma solution simple , de mettre en série dans le 12v= choisi pour l'alimentation des cartes, une zener qui en retranchera ses 4v7
Avec 4 fils par moteur PAP , le nano ne peut en commander que 4 , ce qui va être trop peu pour , par exemple , un module d'entrée de gare moyenne : j'ai donc reconduit mes idées à base de registre à décalage 74hc595 , pour pouvoir ajouter des extensions ; bon , alors le la carte nano revient à 11€ (tout compris) , et la carte d'extension à 9€ : l'économie de ce procédé est psychologique , disons que j'avais envie de le réaliser :  faire modulaire pour des modules , c'est cohérent , et avoir un maître qui tire des esclaves , cela rappelle les trains ... qu'on a connu
Sur la carte qui suit le maître , j'ai illustré 2 variantes de moteurs d'aiguille :
- du mtb , qui nécessite un + commun , disponible en 1ère et dernière position ses borniers à 6 broches ; ce + commun peut aussi être un (-) commun , on peut le sélectionner par le cavalier visible au-dessus du convertisseur dc/dc
- du tortoise , qui ne nécessite pas de tension commune ; il me semble que les moteurs conrad fonctionneraient aussi de cette façon
Pour le mtb et le tortoise , il ne faut que 2 broches de nano , on peut donc en avoir 8 sur une carte
.
Les cartes d'extension nécessitent 3 fils du nano , c'est les 3 fils du périphérique SPI , que j'ai choisi pour alléger le travail du cpu ... le problème , c'est que le nano n'a pas autant de broches ! j'ai donc sacrifié le 1er pont en H : on n'a donc que 7 moteurs type mtb , ou 3 moteurs PAP , sur le maître ... toutefois, le nano visé est , comme illustré , à base de clone lgt8f328p , dont les broches A6 et A7 peuvent aussi être digitales , alors tout marche ; le lgt fonctionne à 32MHz , il est possible que cette puissance me serve pour gérer la commande par registres à décalage , des cartes d'extension
Édité : menues clarifications

[trimarco232]

Des nouvelles du projet : les 1ers tests que j'ai pu faire sont concluants , alors je crois que le concept est viable (toutefois , il y a encore à résoudre la question de l'installation mécanique du moteur)
Le test a été réalisé avec 1 maître et 2 cartes d'extension
La vitesse de translation semble un peu faible : j'ai choisi un pas d'une durée de 10ms , on pourrait réduire pour aller + vite , mais ce serait au détriment de la force ; il faut peut-être réserver le principe aux petites échelles (TT , N , Z) , pour limiter la course , de manière à voir une durée de translation réaliste
Le décodage DCC avec la bibliothèque d'Aiko a fonctionné du 1er coup (y compris ma modif pour utiliser la fonction capture) , pareil pour la commande des ponts en H situés sur la carte maître
Mais j'ai perdu 1/2 journée sur la programmation de la commande des cartes d'extension , à cause d'un double bug conjugué , dont je suis (presque) entièrement responsable :
- une erreur d'offset entre un segment de RAM et son pointeur , c'est classique , mais même mis en évidence par l'analyseur logique , je n'ai pas voulu l'admettre , car bêtement persuadé que je n'avais pas pu me tromper sur ce point
- j'ai voulu absolument utiliser le périphérique SPI pour commander les 74HC595 , car c'est efficace et ... élégant ; mais quand on met le SPI en fonction , la broche MISO se met fatalement en INPUT (amha une tare dans le dessin de l'AVR (que j'avais oubliée) , pas la faute d'Arduino) , or j'utilise cette broche en OUTPUT , pour commander le fil Latch des 74HC595 ... j'ai été sauvé par ma conception des cartes d'extension , qui pour contenir les parasites , terminent le fil Latch sur une résistance reliée au +5v ; ainsi , quand le SPI fonctionne pour transférer les données vers les 74HC595 , le Latch reste gentiment en position HIGH ; à la fin des transferts SPI , (en fait au début , juste avant le démarrage des transferts suivants) , je désactive le périphérique SPI , ce qui permet d'avoir le Latch en OUTPUT , pour envoyer une courte impulsion LOW ; puis le SPI est réactivé (juste écrire un octet dans son registre) , ce qui remet le Latch en INPUT , la résistance le tire vers HIGH , et c'est à ce moment que le Latch est effectif
Un mot concernant le coût : j'en ai eu , port et montage des composants CMS compris , pour 90€ chez JLCPCB , pour 10 cartes maîtres et 5 cartes d'extension ; il faut rajouter 60€ de composants "through hole" (arduinos , supports , connectique , condensateurs , zener) , à monter soi-même , ce qui fait ~10€ la carte finie (+précisément 11€ la maître , et 9€ l'extension , car il y a en + l'arduino à 1€50 et l'optocoupleur à 0€50) ; je précise que ces prix comprennent les composants cms , fournis et soudés sur les cartes par jlcpcb
On en est revenu (peut-on s'en réjouir ?) aux prix délirément bas d'avant la pandémie , comme vous pouvez le voir ici :

[trimarco232]

En vrai , c'est (presque) mieux ; j'ai utilisé les 5 cartes d'extension que j'ai réalisé , pour faire le test , concluant , d'un décodeur pour 24 moteurs PAP , ou ... 48 moteurs MTB , tortoise , Conrad ...
On est à la limite du raisonnable , mais qui marche le plus , marche le mieux
Selon mes principes , j'ai fait une petite interface via la console arduino , ou un logiciel de console quelconque (pas ce CV chez moi : l'arduino a l'USB ! ) , on peut rapidement saisir l'adresse du 1er moteur , le nombre de moteurs , recycler l'arduino , et c'est fait
Les moteurs noirs sont moins chers , mais ils ont un chassis en plastique : il faut veiller à ne pas trop les solliciter , car le plastique ne participe pas à évacuer la chaleur du moteur , et se met même à fondre le cas échéant ... de + ces moteurs sont plus lents que les autres , à cause d'un pas de vis sans fin plus serré
Bien que les tests effectués ne stressent pas assez le système (je n'ai utilisé que 4 moteurs) , on a quand-même un très bon fonctionnement sur une chaîne qui s'approche d'un mètre de long , ce qui pour moi prouve la validité des conceptions matériel et logiciel : j'en suis satisfait (et soulagé ; c'est l'automne , les bugs viennent s'incruster dans les logements et dans les sketches)
Prochaines étapes :
- commande décalée des moteurs
- panachage moteur PAP et MTB (si demande)
- fixation et test de commande d'une aiguille

Edit :
les moteurs noirs (plastique) ont une translation de 1.2mm pour 5 secondes (par pas de 10ms) ; ils peuvent être alimentés en 3v7 , en conservant un couple suffisant
les moteurs métalliques (que j'ai) ont une translation de 3.6mm pour 5 secondes (par pas de 10ms) ; ils doivent être alimentés en 5v , pour avoir un couple suffisant ; le modèle à axes parallèles a une course de 3.2mm

[bobyAndCo]

Bonjour Marc,

Je découvre ce fil avec un certain retard. Ce sujet est intéressant. Il a été effleuré sur un autre post assez récemment et j’avais moi-même acheté un certain nombre de ces micros moteurs il y a pas mal de temps avec, entre autres, comme idée que cela puisse piloter des aiguilles.

Je suis intéressé de suivre cela car tout d’abord tu adoptes des solutions qui sont aux antipodes de mes propres concepts :

-   Commande au travers du bus DCC et décodeurs alors que tu connais ma position d’inconditionnel du CAN (et Ethernet). Et de réserver le bus DCC à la seule traction.
-   Concept de cartes spécialisées, 1 carte pilote 4, 8, x appareils similaires alors que je préfère l’idée de cartes généralistes à l’image des satellites. Une carte peut assurer plusieurs fonctions en input pour des capteurs en tous genres (dont RFID et/ou Railcom) et aussi en output, commandes d’aiguilles, de feux lumineux par exemple.

Mais je n’ai jamais prétendu qu’il n’y avait qu’une vérité et c’est pourquoi ça m’intéresse de suivre ton approche.

Je suis très intéressé de savoir comment tu as réglé mécaniquement le positionnement du moteur par rapport à l’aiguille : Sous le plan ? En surface ? Quel support ? Quel matériau ?  Impression 3D ? Quelles fixations ?

Par ailleurs, tu dis que tu commandes aussi des moteurs tortoise. Cela implique quelques composants pour la puissance, (mosfets ?) et la protection des composants (diodes roues libres, condensateurs…). Peux-tu communiquer ton schéma électronique ?

Tu ne parles pas de solénoïdes, tu n’envisages pas du tout ce cas qui reste par exemple la règle chez Marklin ?

Bon je m’arrête là (pour le moment).

Plein de réussite pour ce que tu as entrepris.

Christophe

[trimarco232]

Bonjour Marc,

Je découvre ce fil avec un certain retard. Ce sujet est intéressant. Il a été effleuré sur un autre post assez récemment et j’avais moi-même acheté un certain nombre de ces micros moteurs il y a pas mal de temps avec, entre autres, comme idée que cela puisse piloter des aiguilles.
Bonjour Christophe , alors tu étais le 1er à en parler , donc tout ceci est de ta faute 


Je suis intéressé de suivre cela car tout d’abord tu adoptes des solutions qui sont aux antipodes de mes propres concepts :
merci pour l’intérêt

-   Commande au travers du bus DCC et décodeurs alors que tu connais ma position d’inconditionnel du CAN (et Ethernet). Et de réserver le bus DCC à la seule traction.
je suis bien d'accord avec cette approche , mais je voulais faire quelque chose que les autres puissent également réaliser et utiliser (même s'il semble que cela n'intéresse personne) : seuls les très grands réseaux nécessitent une préservation de la bande passante du DCC , et ils sont très minoritaires par chez nous
-   Concept de cartes spécialisées, 1 carte pilote 4, 8, x appareils similaires alors que je préfère l’idée de cartes généralistes à l’image des satellites. Une carte peut assurer plusieurs fonctions en input pour des capteurs en tous genres (dont RFID et/ou Railcom) et aussi en output, commandes d’aiguilles, de feux lumineux par exemple.
je pense que "mon" principe modulaire est entièrement compatible avec le principe de satellite : si tu as 3 sorties digitales disponibles , tu peux y ajouter mes cartes d'extension , en quantité qui colle au besoin du secteur du réseau desservi par le satellite

Mais je n’ai jamais prétendu qu’il n’y avait qu’une vérité et c’est pourquoi ça m’intéresse de suivre ton approche.

Je suis très intéressé de savoir comment tu as réglé mécaniquement le positionnement du moteur par rapport à l’aiguille : Sous le plan ? En surface ? Quel support ? Quel matériau ?  Impression 3D ? Quelles fixations ?
oui , ben moi aussi , je n'ai encore rien fait ; mon idée , c'est de faire un petit pcb sur lequel on fixera les petites vis du moteur ; les pads électriques du moteur seraient raccordé en fixe par des petits fils sur des petits pads sur le PCB , reliés à un connecteur où arrive le câble en provenance du décodeur ; le pcb serait lui même fixé sous la planche grâce à des trous oblongs ; il y aurait une fente dans le pcb pour le passage de la corde à piano . C'est la prochaine étape

Par ailleurs, tu dis que tu commandes aussi des moteurs tortoise. Cela implique quelques composants pour la puissance, (mosfets ?) et la protection des composants (diodes roues libres, condensateurs…). Peux-tu communiquer ton schéma électronique ?
les ponts en H utilisés ont tout ce qu'il faut pour commander directement des tortoises , il n'y aurait que le logiciel à compléter , pour l'instant , il ne sait faire que les PAP

Tu ne parles pas de solénoïdes, tu n’envisages pas du tout ce cas qui reste par exemple la règle chez Marklin ?
pour les solénoïdes je ne jure que par un système de décharge capacitive , y compris pour les moteurs munis de Fin de Course ; car c'est la sécurité absolue alors on enlève les FdC pour éviter qu'ils ne provoquent des pannes ; j'ai mis un tel dispositif à l'oeuvre pour le réseau du club , à la grande satisfaction des utilisateurs ; certes , je crois bien que mes cartes d'extension fonctionneraient avec des moteurs maerklin ou roco , mais il faudrait remplacer les ponts en H par des modèles de tension + élevée (ça n'a pas été conçu dans cette optique)

Bon je m’arrête là (pour le moment).

Plein de réussite pour ce que tu as entrepris.
merci et pareil

Christophe

[bobyAndCo]

pour les solénoïdes je ne jure que par un système de décharge capacitive , y compris pour les moteurs munis de Fin de Course ; car c'est la sécurité absolue alors on enlève les FdC pour éviter qu'ils ne provoquent des pannes ; j'ai mis un tel dispositif à l'oeuvre pour le réseau du club , à la grande satisfaction des utilisateurs ; certes , je crois bien que mes cartes d'extension fonctionneraient avec des moteurs maerklin ou roco , mais il faudrait remplacer les ponts en H par des modèles de tension + élevée (ça n'a pas été conçu dans cette optique)[/color]

Bon ça m'intéresse que tu parles de cela car je viens juste de réaliser une platine permettant justement de commander les aiguilles Marklin (74991, 74492...) sur le principe de décharge capacitive !!!



J'attends des composants manquants pour demain normalement et je vais pouvoir faire les tests. Mon condo de 1000µF sera peut être un peu juste mais ce sera facile de mettre un plus gros.

C'est volontaire si j'alimente en DC et non en AC. Ah et aussi, les diodes roue-libre seront des 1N4148 et non 1N4001.

Quel est ton regard d'expert sur ce montage ?

Le sujet est ici sur le forum 3R : https://forum.3rails.fr/t/homemade-marklin-creation-dun-circuit-intelligent/13574/97

Christophe

[trimarco232]

Les résistances de gate de 1kR sont inutiles , car la résistance intrinsèque du mosfet de sortie de la broche de l'arduino est suffisante
En principe , il vaut mieux mettre les 1n4001 aux bornes du moteur , mais c'est en effet + pratique de les mettre sur le PCB , et cela donne une protection suffisante ; perso je mets un condensateur de 100nF / 100v en // sur cette diode , le but est d'absorber instantanément le début du pic de tension , le temps que la diode se mette à conduire pour prendre le relais (mais c'est juste intuitif , je ne sais pas en faire la démonstration)
Concernant la charge du condensateur (des + simples ici) , il faut s'assurer :
- que la résistance tient la puissance à dissiper
- qu'elle protège bien le moteur , en cas de commande intempestivement prolongée , aggravée par une non-fonctionnement du FdC ; ce non-fonctionnement peut être dû à un collage du contact , ou une translation empêchée d'aller à son terme
- que le condensateur soit suffisamment rechargé , avant d'émettre la prochaine commande

En cas de blocage de la commande , la résistance de charge débiterait directement dans la bobine , sous 18v on aurait 18ma soit 324mW : il faudrait utiliser des résistances de 1/2W ; dans ce contexte , la bobine , dont j'ai négligé la résistance dans ce calcul , ne risque rien
La recharge nécessite environ 2s (2x la constante de temps) , ce qui est normalement assez court
Le chimique serait + à l'aise avec une caractéristique à 35v

Donc pour moi , ton schéma est valable
Note que tu peux mutualiser le condensateur , en assurant le séquencement des commandes ; dans ce cas , le dispositif peut être amélioré par une charge à courant constant , voire une interruption de la charge par détection de consommation de courant

[bobyAndCo]

Merci Marc pour ces précisons. Pas mal de petites subtilités à prendre en compte en effet comme le calcul de la résistance

Intéressant le condo de 100nF en // de la diode et effectivement, 100v est une bonne valeur parce que ça peut monter haut en tension.

Pour les diodes roue-libre j'ai mis des 1N4001 mais je préfère et je monterai au final des 1N4148 qui sont à commutation rapide.

Christophe