Contrôle numérique des aiguillages

[bricoleau]

Bonjour

Voici le petit chantier qui m’occupe actuellement, sur lequel j’aimerais bien recueillir vos avis éclairés 

Commençons d’abord par préciser que je n’ai aucun réseau à la maison, ni aucune expérience du modélisme ferroviaire. Mais j’ai d’autres compétences et centres d’intérêt qui font que je commence à maîtriser un peu arduino et ce qui gravite autour.

Un ami m’a demandé de lui filer un coup de main pour passer son réseau (courant continu) en commande numérique. Il dispose d’une quinzaine d’aiguillages électriques de type jouef, ainsi que quelques dételeurs, qu’il souhaite commander par ordinateur, ou par une centrale qu’il se fabriquera.

On n’est clairement pas dans du modélisme haut de gamme et dispendieux.
Du coup, pour rester dans la même philosophie, mon objectif était de lui proposer une solution bon marché. Suite à la lecture de plusieurs articles très intéressants sur locoduino, je suis parti sur la création de modules de commande d’aiguillages.

Chaque module a 8 sorties, pour gérer 4 aiguillages simples.
Il est constitué d’une arduino pro mini et deux ULN2803, dont les sorties sont couplées deux à deux pour être en mesure de fournir jusqu'à 1A aux bobines de l'aiguillage, bien que j’ai quelques doutes sur la pertinence de ce montage. L’expérience dira si cela tient la route longtemps.
Le tout est assemblé à la main, soudé sur une plaque de prototypage pastillée, avec une connectique de type bornier à vis côté 12V/Aiguillages.

L’arduino pro mini fonctionne comme un périphérique escale I2C. Les modules pourront être branchés en cascade, chacun ayant sa propre adresse I2C. Le tout devra être piloté par une centrale. Une foultitude d’options est possible à ce niveau-là, à affiner plus tard.

Je suis actuellement en phase de réalisation du premier prototype. Mon objectif initial est atteint : le coût matériel d’un module est de moins de 4€ frais de port compris, soit moins de 1€ par aiguillage à commander. Evidemment, il s’agit de composants achetés en ligne auprès de vendeurs asiatiques.

Photo avec les ULN2803 pas encore montés :



Pour les soudures, j’en suis resté aux gros pâtés d’étain bien baveux. Pas très doué à ce niveau-là 

Si l'approche reste minimaliste côté hardware, c’est l’inverse côté logiciel embarqué dans l’arduino pro mini : aucune économie de neurones n’est tolérée. Je suis plutôt du genre à ne figer une version de code que lorsque je ne vois absolument plus rien d’améliorable.

L’arduino mini gère en autonomie le premier niveau de sécurité des aiguillages : durée des impulsions, contrôle d’exclusion des sorties contradictoires etc.
J’ai retenu ce principe de module « intelligent » pour sécuriser les équipements contre toute défaillance logique de la centrale en amont et/ou perte de la communication avec celle-ci.

Du coup, c’est dans les fonctionnalités « ferroviaires » que j’ai quelques doutes, du fait de mon manque d’expérience dans ce domaine.

Voici ce qui est réalisé pour l’instant :
L’arduino mini reçoit des consignes de positionnement de chaque aiguillage. Il peut même recevoir simultanément plusieurs consignes pour des aiguillages différents.
Puis, de manière asynchrone, il gère l’activation des deux bobines de chaque aiguillage, sous forme d’impulsions et selon trois paramètres  communs à toutes les sorties :

• Durée d’une impulsion vers une bobine (exemple : 500 ms)
• Durée minimum de repos d’un aiguillage. S’applique à partir de la fin d’impulsion sur une des deux bobines de l’aiguillage (exemple : 300 ms).
• Durée minimum entre deux débuts d’impulsion sur des aiguillages différents. Là, il s’agit de donner la possibilité de ménager la source d’alim 12V, selon sa capacité à délivrer du courant. Si cette durée est à zéro, les 4 aiguillages peuvent être basculés simultanément. Si elle est supérieure à la durée d’impulsion, un seul aiguillage à la fois peut être actif. Et entre les deux, cela permet de régler le nombre maximum de bobines activables simultanément.

Toute consigne reçue et non immédiatement exécutable est mise en attente pour être exécutée dès que possible.

De plus, le dispositif I2C Maître a la possibilité d’interroger l’arduino mini pour connaître son état instantané :

• Positions théoriques des aiguillages (= consignes)
• Positions réelles des aiguillages
• Nombre de bobines en cours d’alimentation
• Durée écoulée depuis la dernière fin d’impulsion
• Valeurs des paramètres utilisés, que le Maître peut également modifier.

Cela donne la possibilité au Maître de gérer le niveau de sollicitation de la source d’alim 12V, de manière globale pour l’ensemble des modules présents sur le bus.

Les trames échangées en I2C comportent aussi des CRC, pour réduire les risques d’erreurs de communication liées à des parasites électriques. Une trame incorrecte est ignorée, charge au Maître de gérer la chose.

A ce stade, la question est : quelles fonctionnalités utiles pourrais-je avoir oubliées, au niveau de l’arduino mini, dans une optique de module le plus générique possible ?

Je m’interroge par exemple sur la position réelle des aiguilles.
Il n’y a aucun capteur pour donner un retour information. Ainsi, à la mise sous tension, la position de chaque aiguillage est indéterminée tant qu’une première impulsion n’a pas été envoyée. De plus, si l’aiguille est déplacée manuellement ou par un train qui circulerait en sens inverse (possible ?), il peut y avoir un déphasage logique avec l’arduino mini.
Actuellement, si l’arduino considère qu’un aiguillage est déjà dans la position indiquée par une nouvelle consigne, il ne déclenche rien.
Peut-être ajouter une fonctionnalité de remise en phase logique?

Autre interrogation : les aiguillages liés, typiques d’un changement de voie entre deux voies parallèles.
Ils seront commandés séparément, mais est-il utile ou nécessaire de gérer leur cohérence au niveau de l’arduino mini?

Autres points oubliés ?

[DDEFF]

Salut Bricoleau,

Avant de parler de ce qui manquerait, parlons de ce qu'il y a !
Je trouve cette réalisation sympa, très bon marché et typique du DIY. Bravo ! 

Je te rassure sur un point : la mise en parallèle de 2 sorties ULN2803 va fonctionner. On voit ça dans beaucoup de revues d'électronique.
Par contre, j'attends avec impatience les tests en vrai sur un réseau pour l'usage de l'I2C. Là, j'aurais plus de craintes...
J'aurais naturellement tendance à lui préférer le bus CAN, nettement plus sûr.
Ceci dit, tu parles d'un CRC sur l'I2C et ça me parlerait bien.

Ce qui me parait intéressant, ce sont tes idées concernant les aiguilles.

Dans l'alimentation des aiguilles, il y a au départ 2 problèmes :
1°) Le fait que si on alimente un moteur d'aiguille trop longtemps, il crame. D'ailleurs, ne pas oublier de voir si l'ULN2803 ne chauffe pas, lui aussi.
2°) La surcharge de l'alimentation centrale.

Si l'idée de calibrer la durée d'impulsion est classique, celle d'avoir une durée mini de repos l'est nettement moins.
Et c'est une excellente idée. 

Qu'appelles-tu "contrôle d’exclusion des sorties contradictoires" ?

J'aimerais avoir des précisions sur ce passage :
"Si cette durée est à zéro, les 4 aiguillages peuvent être basculés simultanément. Si elle est supérieure à la durée d’impulsion, un seul aiguillage à la fois peut être actif. Et entre les deux, cela permet de régler le nombre maximum de bobines activables simultanément."

1°) "Si cette durée est à zéro, les 4 aiguillages peuvent être basculés simultanément" : OK.
J'en déduis que ton alim supporte l'alimentation de 4 aiguilles.
2°) "Si elle est supérieure à la durée d’impulsion, un seul aiguillage à la fois peut être actif." : Donc, on est maintenant à 5 aiguilles simultanées ?
3°) "Et entre les deux, cela permet de régler le nombre maximum de bobines activables simultanément."

Mon problème : il n'y a qu'un seul nombre d'aiguilles commandables simultanément.
Deuxio : les aiguilles commandées simultanément peuvent l'être sur plusieurs modules. Par exemple 4 réparties sur 4 modules.
Donc, le maxi n'est gérable que par le Maître. Ce que tu dis d'ailleurs un peu plus loin.

Mais j'ai eu l'impression que tu gérais ça aussi au niveau du module ? Mais je me trompe peut-être ?

Tonneau des Danaïdes : trouver la position réelles des aiguilles...

En tout cas, une bonne idée : ne pas accepter deux fois la même consigne.

Enfin, "cohérence des aiguilles liées" : d'abord, il n'est pas évident qu'elles soient sur le même module. C'est au Maître de gérer ça.

[bricoleau]

Bonjour

Pour les ULN2803 qui crament, j'ai "investi" dans des supports pour CI 

Le contrôle d’exclusion consiste à garantir, au plus bas niveau logiciel possible, qu’en aucun cas une bobine ne peut être alimentée si l’autre bobine du même aiguillage est déjà sous tension.
Ce contrôle est codé juste avant le digitalWrite() pour une fiabilité maximale.

La durée minimum de repos est gérée de manière globale pour les deux bobines d’un même aiguillage. Avant de mettre sous tension une bobine, le programme vérifie qu’elle et sa sœur sont au repos depuis au moins cette durée paramétrée.

Le dernier paramètre est un poil plus compliqué.
La règle s’énonce simplement, mais sa conséquence est moins triviale.
Elle s’applique de manière globale sur les 4 aiguillages (8 bobines) commandés.
Le paramètre définit un délai minimum entre les débuts de mise sous tension de plusieurs bobines. On ne s’intéresse là qu’aux fronts montants.
Ainsi, avant de mettre sous tension une bobine, le programme recherche la dernière bobine activée, et vérifie que ce délai minimum d’écart est bien respecté.

Par exemple, prenons comme hypothèses :
- une durée d’impulsion à 500 ms
- un ordre de bascule des 4 aiguillages simultanément, reçu à T0

Avec le paramètre positionné à 0 :
- les 4 aiguillages vont être activés simultanément, de T0 à T0+500

Avec le paramètre positionné à 100 :
- l’aiguillage 1 va être activé de T0 à T0+500
- l’aiguillage 2 va être activé de T0+100 à T0+600
- l’aiguillage 3 va être activé de T0+200 à T0+700
- l’aiguillage 4 va être activé de T0+300 à T0+800
Donc entre T0+300 et T0+500 on aura les 4 aiguillages actifs simultanément

Avec le paramètre positionné à 200 :
- l’aiguillage 1 va être activé de T0 à T0+500
- l’aiguillage 2 va être activé de T0+200 à T0+700
- l’aiguillage 3 va être activé de T0+400 à T0+900
- l’aiguillage 4 va être activé de T0+600 à T0+1100
Là il n’y a plus au maximum que 3 aiguillages actifs simultanément, entre T0+400 et T0+600

Et ainsi de suite en augmentant la valeur du paramètre.

Avec le paramètre est positionné à 600 :
- l’aiguillage 1 va être activé de T0 à T0+500
- l’aiguillage 2 va être activé de T0+600 à T0+1100
- l’aiguillage 3 va être activé de T0+1200 à T0+1700
- l’aiguillage 4 va être activé de T0+1800 à T0+2300
Et là seul un aiguillage est actif à la fois.

D’une part, ce paramètre permet de borner le nombre maximum de bobines actives simultanément au niveau d’un module.
D’autre part, il me semble (mais pas sur) que les instants de mise sous et hors tension des bobines génèrent le plus de parasites (inductance) sur la ligne d’alim 12V. Ce paramètre permet ne pas avoir de multiples fronts montants ou descendants simultanés. Un genre de debounce d’alim.

La nécessité de se pencher sur ce paramètre dépend des caractéristiques de l’alim 12V.
Et effectivement, si cette nécessité est avérée, il faudra aussi s’en préoccuper au niveau au-dessus, qui gère plusieurs modules parallèles.
Le maître I2C a accès à toutes les infos nécessaires pour gérer cela, dans les messages remontants. C’est vrai qu’à la fin, cela a fait une gestion à deux niveaux, mais tout ce qui peut être pris en charge au niveau le plus bas me semble plus fiable.

Dans mon cas, toujours en approche minimaliste, je pense partir sur une petite alim 12V 1,5A pour l’ensemble des aiguillages.
J’aurai donc au maximum une bobine active par module, et un seul module actif à la fois (gestion au niveau du Maître I2C : récupération régulière de l’état des modules, et envoi d’un ordre à un module seulement lorsque tous les autres sont au repos).

Pour l’I2C on verra bien. Je suis plutôt confiant car les modules ne seront pas positionnés sous le réseau, mais regroupés à la place des boitiers de boutons poussoirs actuels. Les câbles vers chaque aiguillage sont déjà tirés. Donc le réseau électrique 5V sera court et relativement distant des rails.

Pour la fiabilisation des positions d’aiguilles : admettons qu’une fonction soit prévue au niveau du maître I2C, pour resynchroniser tous les aiguillages (déclenchement manuel par appui sur un bouton poussoir, lorsque l’humain sent qu’il y a un truc qui déconne quelque part).

En l’état, le maître sera alors obligé de basculer tous les aiguillages dans un sens, puis dans l’autre, pour fiabiliser leur position. Pas terrible.
Je pourrais ajouter une fonction supplémentaire au niveau des modules, pour relancer une impulsion sur les bobines. Si l’aiguillage est censé être droit, je rebalance une impulsion sur la même bobine.

Dans la plupart des cas, l’impulsion ne servira à rien, car l’aiguillage sera déjà dans la bonne position. Du coup, je me demande s’il n’y a pas un risque à forcer trop longtemps sur la fin de course.
Il serait peut-être plus adéquat de passer par des impulsions plus brèves. Par exemple, au lieu d’une impulsion standard de 500 ms, envoyer 2 impulsions de 250 ms espacées d’une seconde.

Autre point :
Jusqu’ici j’ai raisonné aiguillage, en supposant qu’un dételeur fonctionne de la même manière. Aucune distinction n’est effectuée au niveau du module.
Est-ce adéquat ?
Par exemple, est-ce qu’il y aurait nécessité à pouvoir paramétrer séparément la durée d’impulsion, selon le type de matériel commandé ?

[Thierry]

Voilà un projet qu'il est très intéressant !

En développant UAD, j'ai dû revoir certaines idées préconçues à propos des moteurs à bobine.
Il y a pour ma bibliothèque trois types de ces moteurs : les classiques Jouef/Marklin/etc avec deux bobines comme tu as déjà décrit.
Mais il y a aussi les moteurs Kato et Rokuhan qui sont mono bobine : c'est l'inversion de polarité qui fait le choix de la direction.
Enfin il y a les dételeurs, eux aussi mono bobine mais avec une durée d'activation nettement plus importante que les aiguillages. elle doit pour moi être réglée spécialement pour cet usage.
Si on voulait être complet, il faudrait aussi traiter les servo moteurs et les moteurs à mouvement lent comme les Seep, Cobalt, et autre Tortoise...

J'ai traité le mouvement concurrent de plusieurs moteurs différemment en permettant de construire des groupes d'accessoires à manipuler ensembles, mais de manière séquentielle ou simultanée... Ton approche de la non simultanéité d'alimentation par un délai de mise en route est très intéressante...

Enfin, comme tu le dis, un bouton pour 'reseter' tous les moteurs dans une position de départ théorique, ou pour remettre en conformité avec ce que l'Arduino croit savoir de la position de chaque aiguille est une bonne idée. Et quid de la sauvegarde de la position courante de chacune en EEPROM pour repartir avec les bonnes données après une extinction du système ? A noter que je n'ai rien fait de tout ça dans UAD !

[bricoleau]

Sauvegarder la position courante pour la récupérer au prochain allumage du système, je verrais bien ça au niveau de la centrale.
Et au redémarrage on balance une synchro sur cette position théorique.
Par contre ça risque de faire beaucoup d'écritures sur une Eeprom.

Les 56 octets de ram non volatile d'un DS1307 feraient peut-être mieux l'affaire.
Prenons 4 octets pour une signature, et il en reste 52 d'usage libre, sans limite de réécriture.
De quoi sauvegarder la conf chaque seconde.

[Jean-Luc]

Bonjour,

Concernant la sauvegarde de la position courante, il s'agit de la position extrême : droite ou déviée (je pense là à des servomoteurs plutôt). En admettant que la position d'un aiguillage change toutes les 5 secondes (ce qui est une borne très très supérieure), 100000 écritures permettent 140 heures de fonctionnement environ. À cela on peut ajouter l'utilisation de techniques de tampon circulaire sur l'EEPROM afin de repartir les écritures sur plusieurs cases, technique présentée dans une application note de ST signalée par Marc-Henri. En l'occurrence, on serait à 1000h avec une EEPROM d'1ko qui serait entièrement libre pour cette sauvegarde.

Enfin, il existe des composants de détection de chute de tension comme le TC54VX43 (composant 3 broches que l'on trouve en boîtier TO92). Quand la tension chute en deçà de 4,3V, la sortie passe à 0. Il s'agit donc de connecter ce composant sur une entrée d'interruption et, dans la routine d'interruption, de faire la sauvegarde de l'état dans l'EEPROM. Il faut, bien entendu, s'assurer que le temps restant avant que le micro se plante à cause de la baisse de tension est suffisant pour effectuer la sauvegarde.

[bricoleau]

J'ai pensé à un principe simple pour gérer la synchro.

J'ai déjà 3 statuts d'aiguillage :
- droit
- courbe
- indéterminé
Ce dernier étant uniquement la valeur au démarrage du système, tant qu'une première impulsion n'a pas été envoyée.

Jusqu'ici je gérais 2 types d'ordre reçus de la centrale :
- basculer droit => si le statut n'est pas déjà "droit", alimente la bobine et passe le statut à "droit"
- basculer courbe => idem mais en retournant la chaussette

Il suffit que j'ajoute un type d'ordre :
- oublier => ne fait rien sur la bobine et passe le statut à "indéterminé"

Ainsi, la resynchro peut être effectuée en envoyant d'abord un ordre d'oubli, puis un ordre de bascule.

Et derrière, si besoin, je peux même gérer deux manières d'effectuer les bascules d'aiguillage :
1) la bascule franche, pour passer de "droit" à "courbe" ou inversement : une impulsion de la durée nominale
2) la bascule douteuse, lorsque l'aiguillage est "indéterminé" : une série d'impulsions plus courtes et espacées, pour éviter de forcer longtemps sur la fin de course.

[bricoleau]

Bonsoir

Ca y est ! Premiers tests réussis haut la main !

Le programme pour l'arduino mini est achevé.
J'attends d'avoir terminé les tests pour le mettre en ligne.

Au final, j'ai opté pour ce que j'envisageais ci-dessus : implémentation d'un ordre supplémentaire pour "oublier" la position supposée de l'aiguillage, ainsi qu'une gestion des bascules douteuses.

Lorsque la position de l'aiguillage est indéterminée, le module balance deux impulsions de la moitié de la durée nominale, espacées du délai normal de repos de l'aiguillages (et donc entrelacées avec d'éventuelles autres demi impulsions vers d'autres aiguillages).

Cela fonctionne très bien.
J'ai testé avec un seul aiguillage branché (celui qui m'a été prêté pour l'expérimentation).



Ce qui me surprend, c'est qu'une impulsion très brève suffit à faire basculer entièrement l'aiguillage.
Au départ, j'avais prévu 500 ms, mais une durée de 100 ms suffit largement.
Avec une durée de 50 ms, la bascule est déjà quasi complète.
Visuellement, j'ai l'impression qu'une impulsion très courte met le mécanisme en marche, et qu'ensuite le mouvement se termine par inertie mécanique. L'aiguillage est neuf et coulisse vraiment très bien manuellement.
A moins que l'inertie provienne de l'inductance de la bobine.

Ca vous paraît normal?

[bricoleau]

Bonjour

J'ai terminé le programme de mon contrôleur pour 4 aiguillages à commande I2C

Les tests sont OK, en commande directe comme en commande I2C depuis une centrale (une autre arduino)

Vous pouvez très facilement vous faire une idée de son fonctionnement.
Il suffit de téléverser le programme ci-joint dans n'importe quelle carte arduino. Une uno fera très bien l'affaire.
Le seul câblage à réaliser consiste à relier les pin 11 et 12 avec un fil.

A partir de là, le programme démarre en mode maintenance : un menu est proposé sur le terminal série (à 9600 bauds)
Ce menu tourne en parallèle de toutes les autres fonctionnalités du contrôleur.
Il permet de modifier les paramètres de fonctionnement, et même de simuler la réception d'ordres de bascule.
Dans ce dernier cas, il affiche également un chronogramme d'activation des bobines.
Cela permet de bien comprendre le fonctionnement du contrôleur, ainsi que le rôle de chaque paramètre.


Sur la première photo au début de cette discussion, on voit le cavalier ajouté sur l'arduino mini, qui permet de démarrer en mode maintenance.
En mode normal : le contrôleur est muet sur la liaison série. Tout passe par l'I2C.
En mode maintenance : c'est le contraire. Les messages I2C sont simulés et passent par les mêmes fonctions de traitement.

Ce mode maintenance m'a permis de mettre au point le contrôleur, et d'effectuer les premiers tests en le branchant directement sur le PC.

A noter que la led 13, implantée sur l'arduino, est utilisée comme témoin de fonctionnement.
En mode normal, elle est allumée dès lors qu'au moins une bobine est sous tension.
En mode maintenance, elle clignote rapidement.

Le programme fourni ne nécessite aucune modification pour fonctionner.
Il peut être téléversé tel quel sans se poser de questions.

Pour une meilleure accessibilité, j'ai volontairement opté pour une programmation simple (sans utiliser d'objets autres que ceux natifs de l'environnement arduino) et linéaire (aucune librairie à installer).
Ca ressemble à du C "de base", avec des fonctions regroupées en sections.

[DDEFF]

Bravo !
Bonne analyse du problème au départ, bonne réalisation du programme, clair et facile à lire.

Je n'ai pas testé sur une vraie aiguille (l'aiguillage, c'est l'action de bouger l'aiguille ...  ), mais je te fais confiance.

J'ai particulièrement apprécié la gestion avec un code CRC.
Je verrais si je peux m'en servir aussi. C'est en tout cas une excellente idée.
On a peine à croire qu'il faut toutes ces lignes pour bouger une aiguille  .
Mais on est très loin d'une appli basique.

Quant aux délais pour le mouvement d'aiguille, c'est très variable entre une aiguille neuve, une installée, mais un peu tordue par la pose, la marque, ...
Tu dois savoir aussi que quelques vielles aiguilles Peco consomment 2A !!
Pour certaines, qui n'ont pas de ressort, on a même des rebonds ...
C'est beaucoup moins fiable que l'Arduino 

Une question reste en suspens : trouver une idée pour savoir si l'aiguille est bien dans la position qu'on a voulue.
Et là, on blinde complètement le processus.

Encore bravo !

[Jean-Luc]

Connaître la position de l'aiguille est assez simple en fait (à condition que ça marche car je n'ai pas essayé :-))

À chaque extrémité de la traversé tu colles un aimant au néodyme de petite dimension. Par exemple http://www.supermagnete.fr/aimants-cube-neodyme/cube-magnetique-1mm-neodyme-n45-nickele_W-01-N

Dans le ballast, tu noies un ILS de manière à ce qu'il colle quand la traverse est en position. Si l'un des ILS est passant, l'aiguillage est dans une position correcte et connue, si aucun des deux n'est passant, l'aiguille est quelque part au milieu. Si les deux sont passant c'est qu'il y a un problème :-)

[DDEFF]

Excellente idée.
On peut aussi tout mettre en dessous, via la tige qui commande la traverse.
J'ai en effet un doute sur la possibilité que la partie mobile de l'aiguille se magnétise.
Moi non plus, je n'ai as essayé.

[Jean-Luc]

Ces aimants sont extrêmement puissants, ça devrait marcher.

[DDEFF]

Merci Jean-Luc. Je vais essayer. 

Je vais un peu recentrer sur la problématique de bricoleau :

Prenons la problématique d'après ses bases.

Il y a 2 problèmes à gérer qui concernent ce qui peut chauffer :

1°) L'alim parce qu'on lui en demande trop en même temps
2°) l'aiguille parce qu'on l'alimente trop longtemps ou trop souvent

Je vais prendre un  exemple avec des chiffres "plausibles"
Alim 3 A, aiguille qui consomme 0,8 A pendant 10 ms et 0,4 A pendant 40 ms.
Puisque tu utilises des ULN2803, c'est que tu souhaites alimenter tes bobines par du continu (bonne idée).
Premier réflexe : mettre une diode à l'envers dite "diode de roue libre" ou "diode anti-retour" qui absorbe la pointe à la fin de l'impulsion. OK. Classique.
Deux sorties 500mA suffisent pour 1A. OK.

Grâce à ta logique, tu décales de, mettons, 20 ms pour être au large.
Donc, sur un module, 2 bobines ne démarrent pas en même temps. Excellent.

Autre paramètre : ne pas ré-alimenter une aiguille qui est déjà dans la bonne position.
Je n'ai pas décortiqué complètement, mais je pense que c'est OK aussi.
Donc, pour un module, tout va bien.

Mais il faut un maître. Et, là, ça se complique.

Un de mes itinéraires fait 16 aiguilles. L'alim ne va pas aimer, si on met tout en même temps.

Premier problème :

Coordonner les modules pour que, une fois que les 4 premier ont eu chacun leur décalage de 20 ms et sont donc non en phase (ce qui est recherché), que ça continue avec le module d'après pour lequel la première bobine soit bien 20 ms après la dernière bobine du module précédent.
Et, évidemment, on ne sait pas quel est le module précédent. 

Si je prends les aiguilles dans le sens 1-2-3-...15-16, ça n'est pas pareil que 16-15-...-3-2-1 !
Et si la gare est complexe, il peut y avoir plein de solutions.
Et, ça, seul le maître peut le gérer.
Admettons qu'il sache qui va après qui. Comment rendre ça cohérent avec le bus I2C ?

Deuxième problème :

On a le bon décalage dans tous les cas. OK.
Mais, même décalé, au bout d'un moment, on a dépassé les possibilités de l'alim. Et il va falloir attendre un peu pour reprendre le rythme.
C'est donc à gérer aussi.

Comme quoi, à partir d'un problème qu'on trouve simple, au départ, on est amené à de sacrés trucs 
Mais je sens que tu es plein de ressources.

[Jean-Luc]

Bonne analyse.

Note que l'uln intègre des diodes roue libre.