Commande d'itinéraires par arduino

[Sergio11]

Bonjour à tous,
Je travaille actuellement sur deux réseaux, le mien tout petit et celui d'un ami plus conséquent avec environ 200 aiguilles mais à 500 km de chez moi
J'ai suffisamment de connaissance en électronique mais je débute en Arduino.
La question que je me pose est celle de la commande des aiguilles. Pour mon cas (20 aig)...j'ai plusieurs solutions mais pour mon copain la gestion du réseau ne peut pas se faire par des commandes individuelles des aiguilles. Il faut à mon avis passer pat la commande par itinéraires.
Cela nécessite soit une usine à gaz électronique dont je ne pourrai pas assure la maintenance à distance soit l'utilisation d'un ou plusieurs micro contrôleurs avec une interface standard pour commander chaque tortoise.
Dernière contrainte, je veux conserver la maîtrise technique de ma réalisation...donc éviter un éventuel produit du commerce
Mes questions, qui en susciteront certainement d'autres sont:
Quelqu'un a t'il déjà réfléchi à ce concept?
Y a t'il d'autres solutions plus simples remplissant mon cahier des charges?
Ensuite viendront des questions pratiques telles que:  alimentation des tortoises en 1x12 ou en 2x12 avec point milieu
Quel type de bouton ou de dispositif de commande pour mémoriser les itinéraires lors de la coupure du courant (pour eviter les mouvements d'aiguilles lors de l'intialisation au retour du courant ( je ne souhaite pas mémoriser la situation dans l'eprom)
Merci de prendre le temps de m'apporter votre expérience

[Jean-Luc]

Bonsoir Sergio et bienvenue sur LOCODUINO.

200 aiguillages c'est plus que conséquent. On est dans la catégorie des très grands réseaux.

Avant de continuer, quelle est la taille en terme de distance entre les deux extrémités les plus éloignées ?

[Jean-Luc]

Concernant les Tortoises :

- ils disposent de 2 paires de contact de fin de course. Une paire peut être utilisée pour renseigner l'Arduino sur la position du moteur et donc adopter cette position de départ. Pas besoin de mémoriser la position dans l'EEPROM. La mémorisation de l'itinéraire est faite par la position des moteurs et remontée à l'Arduino qui s'occupe de la commutation des itinéraires.
- ils peuvent être pilotés par un pont en H. Il en existe de très petits et très bon marché comme celui-ci : http://www.electrodragon.com/product/l9110-stepper-motor-driver-controller-board-for-arduino/ qui permettrait de piloter 2 Tortoises.

[Pierre59]

Bonjour

Je pilote 32 aiguilles avec un ATmega8535 (il n'y avait pas encore d'Arduino quand j'ai commencé le réseau).
Les moteurs sont commandés par des L2722 (deux amplis op sortant 1A), les L2722 étant eux même commandés par des démutiplexeurs. On peut commander plus d'aiguilles avec plus de démutiplexeurs et beaucoup d'aiguilles (256 voire plus) avec deux niveaux de démutiplexeurs.

Cordialement

Pierre

[DDEFF]

Bonjour,
200 aiguilles, c'est vraiment énorme.
Je commencerais par distinguer 2 zones : les gares cachées et la zone visible.

En général, quand les réseaux sont de cette taille (que tu ne nous a pas donnée, d'ailleurs  ) il y a énormément d'aiguilles alignées dans une gare cachée.
J'entends par "alignées" des gares dans lesquelles les aiguilles sont les unes derrière les autres et qu'un seul itinéraire est possible, excluant tous les autres.
Chacun permet d'aller vers une voie de garage.
Il y a plein de voies de garages avec un train prêt sur chacune et chaque fois qu'un train rentre, c'est un autre qui sort.
Deux gares de ce type sont sur le réseau et la gestion consiste à envoyer un train d'une gare cachée à l'autre gare cachée.
A partir du moment où il n'y a pas d'itinéraires compatibles, c'est assez facile à gérer.

Et puis il y a la partie visible (avec une troisième gare !), plus complexe à gérer.
Là, trois types de gestion :
Le type PRA (Poste tout Relais Automatique), PRS (Poste tout Relais à transit Souple) et le PRG, plus récent, (Poste tout Relais à gestion Géographique).
Évidemment, on ne le fera pas à relais ...

Le PRA est assez "simple" : on décrit l'itinéraire quelque part, il s'exécute en mettant les aiguilles dans la bonne position (l'une après l'autre pour éviter les appels de courant).
Son défaut viscéral : tant que l'itinéraire n'est pas parcouru jusqu'au bout, il bloque tout le monde.
Ce serai utilisable en gare cachée.

Le PRS est, lui, assez tordu. Là, on voit très très peu de réalisations. C'est une sorte de Graal.
ça démarre pareil, mais dès qu'un autre itinéraire compatible est réalisable, il se lance.
Le premier train finit son itinéraire, mais un autre train est lancé. C'est ça, la souplesse.
ça suppose évidemment que chaque aiguille soit considérée comme un canton, géré comme tel.
C'est nettement plus complexe, surtout en câblage.
Je ne connais que 2 réalisations : Pierre Chenevez en 1972 (avec quelques erreurs de schémas, d'ailleurs) et celle, dans les années 1990, des frères Jesu dans Loco Revue.
Je n'en ai jamais vue en électronique.
Je ne sais pas si un logiciel l'a fait. C'est possible.

Le PRG est du même genre, mais on sélectionne un itinéraire en appuyant sur le bouton Origine de l'itinéraire et sur l'Extrémité pour le lancer.
Sinon, il faut retenir le numéro d'itinéraire, ce qui n'est pas gérable avec 200 aiguilles.
On doit pouvoir le faire avec DES Arduinos. Mais rien de tout fait.

Bon courage !
Denis

[Jean-Luc]

Le PRS ne me semble pas si compliqué à réaliser. Effectivement il ne permet pas de calculer tous les itinéraires hors ligne pour ensuite les sélectionner car le nombre de combinaisons donnerait un volume de données trop important pour loger dans la mémoire de l'Arduino. Il faut calculer les itinéraires au vol.

Et je ne vois pas pourquoi chaque aiguille doit être gérée comme un canton.

Un réseau est un graphe dont les nœuds sont les cantons. C'est un graphe orienté par le sens de circulation. Chaque nœud à des successeurs. Calculer un itinéraire consiste à partir d'un nœud initial à le marquer puis à prendre tous les successeurs, à en faire le nœud initial etc et à parcourir récursivement le graphe jusqu'à trouver le nœud destination ou bien un nœud marqué (ce qui évite de boucler à l'infini). Si plusieurs itinéraires sont trouvés on peut choisir le plus court.

Pour calculer un nouvel itinéraire alors que d'autres sont en cours d'utilisation, il suffit de priver le graphe des nœuds utilisés par les itinéraires en cours et d'appliquer le même algorithme.

On prive également le graphe des nœuds occupés par une rame.

Evidemment l'itinéraire est réservé et un canton ne peut être emprunté par deux itinéraires.

On peut également imaginer que les itinéraires sont parcourus concurremment avec des cantons en commun et que le cantonnement empêche les collisions. Toutefois, il est probable qu'il puisse y avoir des deadlocks ou des livelocks.

[DDEFF]

D'accord avec ta méthode pour calculer l'itinéraire au lieu de stocker tous les itinéraires possibles.
C'est aussi comme ça que je faisais (j'avais potassé en 1998 sur le sujet).
Par contre, on ne choisit pas le plus court. C'est souvent celui qui génère le plus d'incompatibilités avec les autres.
On décide de prendre celui qui va le plus à gauche.
Comme ça, quand il y a 2 diagonales, on a moins de chance de faire des itinéraires qui se croisent.
Le train qui vient de l'extérieur prend donc la diagonale externe et celui qui vient dans l'autre sens prend la diagonale interne.
C'est juste une probabilité : deux itinéraire demandés peuvent être incompatibles, quelle que soit la méthode.

Une fois qu'un itinéraire est construit, on ne peut plus utiliser ses aiguilles tant que le train ne les a pas "effacées" en roulant dessus.
Quand le train parcoure l'itinéraire, il en efface les aiguilles une à une.
C'est cette notion qu'on appelle "souplesse".
Une fois une aiguille effacée, elle devient immédiatement disponible pour un autre itinéraire.

D'où la nécessité de tester l'occupation des aiguilles une par une.
D'où le fait que j'ai raisonné comme ça sur mon projet sur le forum Loco Revue.

Si on va jusqu'au bout du raisonnement, l'itinéraire est accroché non pas à sa voie d'origine, mais à sa voie d'extrémité.

A+
PS : j'ai essayé de mettre une image, mais je n'ai pas compris comment faire.

[Jean-Luc]

Par contre, on ne choisit pas le plus court. C'est souvent celui qui génère le plus d'incompatibilités avec les autres.
On décide de prendre celui qui va le plus à gauche.

C'est peut être vrai sur le réseau que tu as mis en pièce jointe mais dans le cas général, plus l'itinéraire est court et moins de nœuds du graphes sont indisponibles et plus tu as de chances de pouvoir établir un autre itinéraire.

Une fois qu'un itinéraire est construit, on ne peut plus utiliser ses aiguilles tant que le train ne les a pas "effacées" en roulant dessus.
Quand le train parcoure l'itinéraire, il en efface les aiguilles une à une.
C'est cette notion qu'on appelle "souplesse".
Une fois une aiguille effacée, elle devient immédiatement disponible pour un autre itinéraire.

Ok mais tu peux faire la même chose avec les cantons. Le seul cas où je vois une aiguille seule dans un canton c'est le cas d'une TDJ qui permet à deux cantons différents de se croiser.

Si on va jusqu'au bout du raisonnement, l'itinéraire est accroché non pas à sa voie d'origine, mais à sa voie d'extrémité.

Disons que tu le réactualises au fur et à mesure que les cantons sont libérés. Le canton occupé devenant le canton d'origine et définissant un itinéraire plus court et strictement inclus dans l'itinéraire précédent.

PS : j'ai essayé de mettre une image, mais je n'ai pas compris comment faire.

Il semble que tu aies réussi

[DDEFF]

1°) On ne recherche pas d'itinéraire au fur et à mesure que le train roule. On est d'accords, mais on le dit différemment.
On le redéfinit. OK
2°) Attention à un autre point : un croisement ne bouge pas, n'a aucune bobine (Tortoise ou servo), mais pose exactement le même problème que la TJD.
3°) Je propose d'avoir des modules avec un arduino pro mini chacun et qui règlent un problème spécifique :
Une aiguille en pointe, une en talon, un croisement, une bifurcation, une TJD.

[DDEFF]

4°) Il faut que chaque aiguille puisse être alimentée par plusieurs endroits. ça complique aussi le câblage.

[Pierre59]

Bonjour

Dans un PRS l'ensemble des voies et aiguillages est découpé en zones.

Une zone est un groupe de voies, d'aiguillages, de TJD, TJS, croisements, .. tels qu'il ne peut physiquement y avoir qu'un seul train.

Certaines zones n'ont qu'une aiguille, d'autres plusieurs. Toutes les zones ont bien évidemment une détection de présence de train.

Dès qu'une zone est libérée elle peut être utilisée pour un autre itinéraire (transit souple).

Voici un exemple de découpage en zones sur une gare moyenne. C'est en fait le TCO de mon réseau qui est affiché à l"écran.

Pierre

[Jean-Luc]

Merci Pierre,

Ça correspond à la définition que j'ai prise pour mon réseau

[DDEFF]

Bonjour Pierre,

Sur ton schéma, j'aurais 3 coupures à faire en plus :
Quand un train va de Z en E, une fois qu'il a libéré la première aiguille, on doit pouvoir aller de Z en C
Quand il a libéré la deuxième aiguille, on doit pouvoir aller de Z en D.
Par ailleurs, quand on va de T vers le haut, on doit pouvoir aller de Z en T dès que la première aiguille est libre.
Évidemment, ça complique ... 

L'idée que j'ai est de créer des modules standards avec un Arduino chacun et qu'on assemble en fonction du plan des voies.
Exemple en bas de page.
Chaque module s'occupe uniquement des ses entrées sortie (3 ou 4)
Chaque module correspond à un niveau de tension qui est sa position en Y, le zéro étant la voie du bas dans la gare.
On part, par exemple, d'une des voies de gauche.
Potentiels respectifs : 3V, 4V et 5V.
A droite, potentiels de 1V à 7V.

On demande aller de la voie 3 à la voie 6.

A chaque module, on compare la tension de référence du module à la tension de consigne (ici 6V).
Dans le premier module, la consigne est à 6V et la référence à 3,5V => on sort du module par en haut.
Dans le deuxième module, 6V > 4,5V => On sort par en haut
Dans le troisième module, 6V > 5,5V => On sort par en haut
Etc...
Et dans le dernier module on sort par en bas car 6V < 6,5V.

Il y a 6 types de modules :
Aiguille en pointe, aiguille en talon, bifurcation montante, bifurcation descendante, croisement seul et la TJD.

Un itinéraire se construit en appuyant d'abord sur le canton origine puis sur le canton arrivée (géographique)

L'ordre d'appui des boutons donne le sens de circulation du train.
Le sens de recherche des itinéraires est, lui, toujours de gauche à droite.

L'avantage est que le lanceur origine est plus compliqué que le lanceur extrémité. Ici 2 lanceurs origine et 7 lanceurs extrémité.
Le dernier module boucle et prévient le lanceur origine que l'itinéraire est formé.

Vous venez de lire mon idée du 05/02/1991 que je n'ai jamais pu tester (j'ai eu 2 enfants  et pas de place pour un réseau  )

[Pierre59]

Sur ton schéma, j'aurais 3 coupures à faire en plus :
Quand un train va de Z en E, une fois qu'il a libéré la première aiguille, on doit pouvoir aller de Z en C
Quand il a libéré la deuxième aiguille, on doit pouvoir aller de Z en D.
Par ailleurs, quand on va de T vers le haut, on doit pouvoir aller de Z en T dès que la première aiguille est libre.
Évidemment, ça complique ... 

Bonjour

En fait Z est le départ d'une petite ligne à voie unique non cantonnée, il ne peut y avoir 2 trains sur Z. T est un tiroir et il ne peut y avoir 2 trains.
Par contre quand on va de T en D, dès que la première aiguille est libérée on pourrait faire un C vers T (pareil avec Z).

En pratique tout le fond de gare (haut de l'mage) est utilisé pour des manoeuvres a commande manuelle. Cela serait couteux de multiplier les zones qui nécessitent chacune une détection de présence et des relais de commutation des sources en analogique. Une petite simplification est donc faite. Par contre sur les voies principales (A B C) sur le devant de la gare (bas de l'image) le découpage en zones est complet.

Pierre

[Jean-Luc]

Bonjour Denis

Utiliser des différences de tension pour communiquer des consignes aux Arduino me semble extrêmement bizarre. Ce genre de système est prévu pour de l'électronique classique. Avec les Arduino tu as d'autres moyen de communication autrement plus souples et plus simples.